XML Config

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

XML Config

Jason Porter
Mark, Pete and I discussed a little bit about the XML config (from Solder)
on IRC today. We quickly decided that we needed to move over to the mailing
list for more input, and to make things official.

As things currently exist in the Solder XML Config, it's probably not
portable and would really need some of the changes in CDI 1.1 to work
properly. We also discussed throwing out the idea of completely configuring
beans via XML and using the XML config for other tasks such as applying
interceptors and the like via regex or similar ideas, in other words having
it being a subset of what currently exists today. What is in Solder is very
similar to configuring beans via XML in Spring, and we feel that paradigm
has sailed.

I'm starting this thread to get some other ideas about what we should do
for XML config and also see what people think.

--
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp

Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling

PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu
Reply | Threaded
Open this post in threaded view
|

Re: XML Config

Romain Manni-Bucau
Why i would like to use files (i find xml too verbose) is for constants
(uri for instance) or alternative/interceptor (as mentionned)

Today i find other use case the translation of bad design

...just my opinion maybe
Le 7 sept. 2012 23:01, "Jason Porter" <[hidden email]> a écrit :

> Mark, Pete and I discussed a little bit about the XML config (from Solder)
> on IRC today. We quickly decided that we needed to move over to the mailing
> list for more input, and to make things official.
>
> As things currently exist in the Solder XML Config, it's probably not
> portable and would really need some of the changes in CDI 1.1 to work
> properly. We also discussed throwing out the idea of completely configuring
> beans via XML and using the XML config for other tasks such as applying
> interceptors and the like via regex or similar ideas, in other words having
> it being a subset of what currently exists today. What is in Solder is very
> similar to configuring beans via XML in Spring, and we feel that paradigm
> has sailed.
>
> I'm starting this thread to get some other ideas about what we should do
> for XML config and also see what people think.
>
> --
> Jason Porter
> http://lightguard-jp.blogspot.com
> http://twitter.com/lightguardjp
>
> Software Engineer
> Open Source Advocate
> Author of Seam Catch - Next Generation Java Exception Handling
>
> PGP key id: 926CCFF5
> PGP key available at: keyserver.net, pgp.mit.edu
>
Reply | Threaded
Open this post in threaded view
|

Re: XML Config

Charles Moulliard-2
I would prefer that we avoid to use XML. Otherwise, end users will be
confused about what a CDI / CDI Extension should looks like and why we are
moving one step down to do what Spring / Xbean are doing.

On Fri, Sep 7, 2012 at 11:31 PM, Romain Manni-Bucau
<[hidden email]>wrote:

> Why i would like to use files (i find xml too verbose) is for constants
> (uri for instance) or alternative/interceptor (as mentionned)
>
> Today i find other use case the translation of bad design
>
> ...just my opinion maybe
> Le 7 sept. 2012 23:01, "Jason Porter" <[hidden email]> a écrit :
>
> > Mark, Pete and I discussed a little bit about the XML config (from
> Solder)
> > on IRC today. We quickly decided that we needed to move over to the
> mailing
> > list for more input, and to make things official.
> >
> > As things currently exist in the Solder XML Config, it's probably not
> > portable and would really need some of the changes in CDI 1.1 to work
> > properly. We also discussed throwing out the idea of completely
> configuring
> > beans via XML and using the XML config for other tasks such as applying
> > interceptors and the like via regex or similar ideas, in other words
> having
> > it being a subset of what currently exists today. What is in Solder is
> very
> > similar to configuring beans via XML in Spring, and we feel that paradigm
> > has sailed.
> >
> > I'm starting this thread to get some other ideas about what we should do
> > for XML config and also see what people think.
> >
> > --
> > Jason Porter
> > http://lightguard-jp.blogspot.com
> > http://twitter.com/lightguardjp
> >
> > Software Engineer
> > Open Source Advocate
> > Author of Seam Catch - Next Generation Java Exception Handling
> >
> > PGP key id: 926CCFF5
> > PGP key available at: keyserver.net, pgp.mit.edu
> >
>



--
Charles Moulliard
Apache Committer / Sr. Pr. Consultant at FuseSource.com
Twitter : @cmoulliard
Blog : http://cmoulliard.blogspot.com
Reply | Threaded
Open this post in threaded view
|

Re: XML Config

Bernard Łabno
If you find elegant way to do everything that can be currently done then
it's cool not to use XML, but if we won't be able to i.e. configure bean
properties between compilation and deployment then it will be great
disappointment.

2012/9/10 Charles Moulliard <[hidden email]>

> I would prefer that we avoid to use XML. Otherwise, end users will be
> confused about what a CDI / CDI Extension should looks like and why we are
> moving one step down to do what Spring / Xbean are doing.
>
> On Fri, Sep 7, 2012 at 11:31 PM, Romain Manni-Bucau
> <[hidden email]>wrote:
>
> > Why i would like to use files (i find xml too verbose) is for constants
> > (uri for instance) or alternative/interceptor (as mentionned)
> >
> > Today i find other use case the translation of bad design
> >
> > ...just my opinion maybe
> > Le 7 sept. 2012 23:01, "Jason Porter" <[hidden email]> a écrit
> :
> >
> > > Mark, Pete and I discussed a little bit about the XML config (from
> > Solder)
> > > on IRC today. We quickly decided that we needed to move over to the
> > mailing
> > > list for more input, and to make things official.
> > >
> > > As things currently exist in the Solder XML Config, it's probably not
> > > portable and would really need some of the changes in CDI 1.1 to work
> > > properly. We also discussed throwing out the idea of completely
> > configuring
> > > beans via XML and using the XML config for other tasks such as applying
> > > interceptors and the like via regex or similar ideas, in other words
> > having
> > > it being a subset of what currently exists today. What is in Solder is
> > very
> > > similar to configuring beans via XML in Spring, and we feel that
> paradigm
> > > has sailed.
> > >
> > > I'm starting this thread to get some other ideas about what we should
> do
> > > for XML config and also see what people think.
> > >
> > > --
> > > Jason Porter
> > > http://lightguard-jp.blogspot.com
> > > http://twitter.com/lightguardjp
> > >
> > > Software Engineer
> > > Open Source Advocate
> > > Author of Seam Catch - Next Generation Java Exception Handling
> > >
> > > PGP key id: 926CCFF5
> > > PGP key available at: keyserver.net, pgp.mit.edu
> > >
> >
>
>
>
> --
> Charles Moulliard
> Apache Committer / Sr. Pr. Consultant at FuseSource.com
> Twitter : @cmoulliard
> Blog : http://cmoulliard.blogspot.com
>
Reply | Threaded
Open this post in threaded view
|

Re: XML Config

Romain Manni-Bucau
what does bring xml? i think that's the point

if it is only to get a format with hierarchy  you can use yaml for instance

*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*




2012/9/10 Bernard Łabno <[hidden email]>

> If you find elegant way to do everything that can be currently done then
> it's cool not to use XML, but if we won't be able to i.e. configure bean
> properties between compilation and deployment then it will be great
> disappointment.
>
> 2012/9/10 Charles Moulliard <[hidden email]>
>
> > I would prefer that we avoid to use XML. Otherwise, end users will be
> > confused about what a CDI / CDI Extension should looks like and why we
> are
> > moving one step down to do what Spring / Xbean are doing.
> >
> > On Fri, Sep 7, 2012 at 11:31 PM, Romain Manni-Bucau
> > <[hidden email]>wrote:
> >
> > > Why i would like to use files (i find xml too verbose) is for constants
> > > (uri for instance) or alternative/interceptor (as mentionned)
> > >
> > > Today i find other use case the translation of bad design
> > >
> > > ...just my opinion maybe
> > > Le 7 sept. 2012 23:01, "Jason Porter" <[hidden email]> a
> écrit
> > :
> > >
> > > > Mark, Pete and I discussed a little bit about the XML config (from
> > > Solder)
> > > > on IRC today. We quickly decided that we needed to move over to the
> > > mailing
> > > > list for more input, and to make things official.
> > > >
> > > > As things currently exist in the Solder XML Config, it's probably not
> > > > portable and would really need some of the changes in CDI 1.1 to work
> > > > properly. We also discussed throwing out the idea of completely
> > > configuring
> > > > beans via XML and using the XML config for other tasks such as
> applying
> > > > interceptors and the like via regex or similar ideas, in other words
> > > having
> > > > it being a subset of what currently exists today. What is in Solder
> is
> > > very
> > > > similar to configuring beans via XML in Spring, and we feel that
> > paradigm
> > > > has sailed.
> > > >
> > > > I'm starting this thread to get some other ideas about what we should
> > do
> > > > for XML config and also see what people think.
> > > >
> > > > --
> > > > Jason Porter
> > > > http://lightguard-jp.blogspot.com
> > > > http://twitter.com/lightguardjp
> > > >
> > > > Software Engineer
> > > > Open Source Advocate
> > > > Author of Seam Catch - Next Generation Java Exception Handling
> > > >
> > > > PGP key id: 926CCFF5
> > > > PGP key available at: keyserver.net, pgp.mit.edu
> > > >
> > >
> >
> >
> >
> > --
> > Charles Moulliard
> > Apache Committer / Sr. Pr. Consultant at FuseSource.com
> > Twitter : @cmoulliard
> > Blog : http://cmoulliard.blogspot.com
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: XML Config

Pete Muir
In reply to this post by Romain Manni-Bucau
This is what I would use non-compiled resources for as well.

If I needed to CDI-enable some code without using annotations, I would use the portable extension API directly.

On 7 Sep 2012, at 22:31, Romain Manni-Bucau wrote:

> Why i would like to use files (i find xml too verbose) is for constants
> (uri for instance) or alternative/interceptor (as mentionned)
>
> Today i find other use case the translation of bad design
>
> ...just my opinion maybe
> Le 7 sept. 2012 23:01, "Jason Porter" <[hidden email]> a écrit :
>
>> Mark, Pete and I discussed a little bit about the XML config (from Solder)
>> on IRC today. We quickly decided that we needed to move over to the mailing
>> list for more input, and to make things official.
>>
>> As things currently exist in the Solder XML Config, it's probably not
>> portable and would really need some of the changes in CDI 1.1 to work
>> properly. We also discussed throwing out the idea of completely configuring
>> beans via XML and using the XML config for other tasks such as applying
>> interceptors and the like via regex or similar ideas, in other words having
>> it being a subset of what currently exists today. What is in Solder is very
>> similar to configuring beans via XML in Spring, and we feel that paradigm
>> has sailed.
>>
>> I'm starting this thread to get some other ideas about what we should do
>> for XML config and also see what people think.
>>
>> --
>> Jason Porter
>> http://lightguard-jp.blogspot.com
>> http://twitter.com/lightguardjp
>>
>> Software Engineer
>> Open Source Advocate
>> Author of Seam Catch - Next Generation Java Exception Handling
>>
>> PGP key id: 926CCFF5
>> PGP key available at: keyserver.net, pgp.mit.edu
>>

Reply | Threaded
Open this post in threaded view
|

Re: XML Config

Marius Bogoevici
In reply to this post by Romain Manni-Bucau
Generally speaking, I think it would be good to have a mechanism for
configuring beans that does not require re-compilation - may be of
limited use in greenfield applications, but above all with
brownfield/legacy code. In fairness, for the latter one could use
producers and such, but it may still be a PITA in some cases.

Now, the key here IMO would be to have a scriptable (no recompilation)
and toolable DSL outside the annotation system. It so happens that of
all the options, XML is IMO the most common and better understood by the
average developer. If we manage to define a proper intermediate model
for this mechanism, then there could be plenty of other options (yaml,
or even Groovy or Ruby if one so wishes) to add on later.


On 2012-09-10 3:50 AM, Romain Manni-Bucau wrote:

> what does bring xml? i think that's the point
>
> if it is only to get a format with hierarchy  you can use yaml for instance
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau*
> *Blog: http://rmannibucau.wordpress.com*
>
>
>
>
> 2012/9/10 Bernard Łabno <[hidden email]>
>
>> If you find elegant way to do everything that can be currently done then
>> it's cool not to use XML, but if we won't be able to i.e. configure bean
>> properties between compilation and deployment then it will be great
>> disappointment.
>>
>> 2012/9/10 Charles Moulliard <[hidden email]>
>>
>>> I would prefer that we avoid to use XML. Otherwise, end users will be
>>> confused about what a CDI / CDI Extension should looks like and why we
>> are
>>> moving one step down to do what Spring / Xbean are doing.
>>>
>>> On Fri, Sep 7, 2012 at 11:31 PM, Romain Manni-Bucau
>>> <[hidden email]>wrote:
>>>
>>>> Why i would like to use files (i find xml too verbose) is for constants
>>>> (uri for instance) or alternative/interceptor (as mentionned)
>>>>
>>>> Today i find other use case the translation of bad design
>>>>
>>>> ...just my opinion maybe
>>>> Le 7 sept. 2012 23:01, "Jason Porter" <[hidden email]> a
>> écrit
>>> :
>>>>> Mark, Pete and I discussed a little bit about the XML config (from
>>>> Solder)
>>>>> on IRC today. We quickly decided that we needed to move over to the
>>>> mailing
>>>>> list for more input, and to make things official.
>>>>>
>>>>> As things currently exist in the Solder XML Config, it's probably not
>>>>> portable and would really need some of the changes in CDI 1.1 to work
>>>>> properly. We also discussed throwing out the idea of completely
>>>> configuring
>>>>> beans via XML and using the XML config for other tasks such as
>> applying
>>>>> interceptors and the like via regex or similar ideas, in other words
>>>> having
>>>>> it being a subset of what currently exists today. What is in Solder
>> is
>>>> very
>>>>> similar to configuring beans via XML in Spring, and we feel that
>>> paradigm
>>>>> has sailed.
>>>>>
>>>>> I'm starting this thread to get some other ideas about what we should
>>> do
>>>>> for XML config and also see what people think.
>>>>>
>>>>> --
>>>>> Jason Porter
>>>>> http://lightguard-jp.blogspot.com
>>>>> http://twitter.com/lightguardjp
>>>>>
>>>>> Software Engineer
>>>>> Open Source Advocate
>>>>> Author of Seam Catch - Next Generation Java Exception Handling
>>>>>
>>>>> PGP key id: 926CCFF5
>>>>> PGP key available at: keyserver.net, pgp.mit.edu
>>>>>
>>>
>>>
>>> --
>>> Charles Moulliard
>>> Apache Committer / Sr. Pr. Consultant at FuseSource.com
>>> Twitter : @cmoulliard
>>> Blog : http://cmoulliard.blogspot.com
>>>

Reply | Threaded
Open this post in threaded view
|

Re: XML Config

Anil Saldhana
It is prudent to provide something similar to what Seam Solder provided. As
Marius says, there needs to be a path for legacy apps to migrate to CDI
without recompilation of libraries.

The XML config can be a low priority task and probably the documentation
should be hidden away from the main documentation. Maybe put it in advanced
usecases or customize your application etc.

On Mon, Sep 10, 2012 at 8:20 AM, Marius Bogoevici <
[hidden email]> wrote:

> Generally speaking, I think it would be good to have a mechanism for
> configuring beans that does not require re-compilation - may be of limited
> use in greenfield applications, but above all with brownfield/legacy code.
> In fairness, for the latter one could use producers and such, but it may
> still be a PITA in some cases.
>
> Now, the key here IMO would be to have a scriptable (no recompilation) and
> toolable DSL outside the annotation system. It so happens that of all the
> options, XML is IMO the most common and better understood by the average
> developer. If we manage to define a proper intermediate model for this
> mechanism, then there could be plenty of other options (yaml, or even
> Groovy or Ruby if one so wishes) to add on later.
>
>
>
> On 2012-09-10 3:50 AM, Romain Manni-Bucau wrote:
>
>> what does bring xml? i think that's the point
>>
>> if it is only to get a format with hierarchy  you can use yaml for
>> instance
>>
>> *Romain Manni-Bucau*
>> *Twitter: @rmannibucau*
>> *Blog: http://rmannibucau.wordpress.**com<http://rmannibucau.wordpress.com>
>> *
>>
>>
>>
>>
>> 2012/9/10 Bernard Łabno <[hidden email]>
>>
>>  If you find elegant way to do everything that can be currently done then
>>> it's cool not to use XML, but if we won't be able to i.e. configure bean
>>> properties between compilation and deployment then it will be great
>>> disappointment.
>>>
>>> 2012/9/10 Charles Moulliard <[hidden email]>
>>>
>>>  I would prefer that we avoid to use XML. Otherwise, end users will be
>>>> confused about what a CDI / CDI Extension should looks like and why we
>>>>
>>> are
>>>
>>>> moving one step down to do what Spring / Xbean are doing.
>>>>
>>>> On Fri, Sep 7, 2012 at 11:31 PM, Romain Manni-Bucau
>>>> <[hidden email]>wrote:
>>>>
>>>>  Why i would like to use files (i find xml too verbose) is for constants
>>>>> (uri for instance) or alternative/interceptor (as mentionned)
>>>>>
>>>>> Today i find other use case the translation of bad design
>>>>>
>>>>> ...just my opinion maybe
>>>>> Le 7 sept. 2012 23:01, "Jason Porter" <[hidden email]> a
>>>>>
>>>> écrit
>>>
>>>> :
>>>>
>>>>> Mark, Pete and I discussed a little bit about the XML config (from
>>>>>>
>>>>> Solder)
>>>>>
>>>>>> on IRC today. We quickly decided that we needed to move over to the
>>>>>>
>>>>> mailing
>>>>>
>>>>>> list for more input, and to make things official.
>>>>>>
>>>>>> As things currently exist in the Solder XML Config, it's probably not
>>>>>> portable and would really need some of the changes in CDI 1.1 to work
>>>>>> properly. We also discussed throwing out the idea of completely
>>>>>>
>>>>> configuring
>>>>>
>>>>>> beans via XML and using the XML config for other tasks such as
>>>>>>
>>>>> applying
>>>
>>>> interceptors and the like via regex or similar ideas, in other words
>>>>>>
>>>>> having
>>>>>
>>>>>> it being a subset of what currently exists today. What is in Solder
>>>>>>
>>>>> is
>>>
>>>> very
>>>>>
>>>>>> similar to configuring beans via XML in Spring, and we feel that
>>>>>>
>>>>> paradigm
>>>>
>>>>> has sailed.
>>>>>>
>>>>>> I'm starting this thread to get some other ideas about what we should
>>>>>>
>>>>> do
>>>>
>>>>> for XML config and also see what people think.
>>>>>>
>>>>>> --
>>>>>> Jason Porter
>>>>>> http://lightguard-jp.blogspot.**com<http://lightguard-jp.blogspot.com>
>>>>>> http://twitter.com/**lightguardjp <http://twitter.com/lightguardjp>
>>>>>>
>>>>>> Software Engineer
>>>>>> Open Source Advocate
>>>>>> Author of Seam Catch - Next Generation Java Exception Handling
>>>>>>
>>>>>> PGP key id: 926CCFF5
>>>>>> PGP key available at: keyserver.net, pgp.mit.edu
>>>>>>
>>>>>>
>>>>
>>>> --
>>>> Charles Moulliard
>>>> Apache Committer / Sr. Pr. Consultant at FuseSource.com
>>>> Twitter : @cmoulliard
>>>> Blog : http://cmoulliard.blogspot.com
>>>>
>>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: XML Config

Mark Struberg
Administrator
In reply to this post by Bernard Łabno
Hi Bernard!

There are much better ways for configuration than creating beans via XML. I considered this as kind of abuse in Spring and I still don't like it.
We also already have a configuration system + we even have ProjectStage specific behaviour change with @Exclude.

LieGrue,
strub




----- Original Message -----

> From: Bernard Łabno <[hidden email]>
> To: [hidden email]
> Cc:
> Sent: Monday, September 10, 2012 9:43 AM
> Subject: Re: XML Config
>
> If you find elegant way to do everything that can be currently done then
> it's cool not to use XML, but if we won't be able to i.e. configure bean
> properties between compilation and deployment then it will be great
> disappointment.
>
> 2012/9/10 Charles Moulliard <[hidden email]>
>
>>  I would prefer that we avoid to use XML. Otherwise, end users will be
>>  confused about what a CDI / CDI Extension should looks like and why we are
>>  moving one step down to do what Spring / Xbean are doing.
>>
>>  On Fri, Sep 7, 2012 at 11:31 PM, Romain Manni-Bucau
>>  <[hidden email]>wrote:
>>
>>  > Why i would like to use files (i find xml too verbose) is for
> constants
>>  > (uri for instance) or alternative/interceptor (as mentionned)
>>  >
>>  > Today i find other use case the translation of bad design
>>  >
>>  > ...just my opinion maybe
>>  > Le 7 sept. 2012 23:01, "Jason Porter"
> <[hidden email]> a écrit
>>  :
>>  >
>>  > > Mark, Pete and I discussed a little bit about the XML config
> (from
>>  > Solder)
>>  > > on IRC today. We quickly decided that we needed to move over to
> the
>>  > mailing
>>  > > list for more input, and to make things official.
>>  > >
>>  > > As things currently exist in the Solder XML Config, it's
> probably not
>>  > > portable and would really need some of the changes in CDI 1.1 to
> work
>>  > > properly. We also discussed throwing out the idea of completely
>>  > configuring
>>  > > beans via XML and using the XML config for other tasks such as
> applying
>>  > > interceptors and the like via regex or similar ideas, in other
> words
>>  > having
>>  > > it being a subset of what currently exists today. What is in
> Solder is
>>  > very
>>  > > similar to configuring beans via XML in Spring, and we feel that
>>  paradigm
>>  > > has sailed.
>>  > >
>>  > > I'm starting this thread to get some other ideas about what
> we should
>>  do
>>  > > for XML config and also see what people think.
>>  > >
>>  > > --
>>  > > Jason Porter
>>  > > http://lightguard-jp.blogspot.com
>>  > > http://twitter.com/lightguardjp
>>  > >
>>  > > Software Engineer
>>  > > Open Source Advocate
>>  > > Author of Seam Catch - Next Generation Java Exception Handling
>>  > >
>>  > > PGP key id: 926CCFF5
>>  > > PGP key available at: keyserver.net, pgp.mit.edu
>>  > >
>>  >
>>
>>
>>
>>  --
>>  Charles Moulliard
>>  Apache Committer / Sr. Pr. Consultant at FuseSource.com
>>  Twitter : @cmoulliard
>>  Blog : http://cmoulliard.blogspot.com
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: XML Config

Mark Struberg
Administrator
In reply to this post by Marius Bogoevici
hmm 'scriptable' imo implies that it can be changed at runtime. But that's by design not possible with CDI. Spring supports this, we do not. Otoh this allows us to be much faster in all 'static' use cases.

LieGrue,
strub




----- Original Message -----

> From: Marius Bogoevici <[hidden email]>
> To: [hidden email]
> Cc: Romain Manni-Bucau <[hidden email]>
> Sent: Monday, September 10, 2012 3:20 PM
> Subject: Re: XML Config
>
>G enerally speaking, I think it would be good to have a mechanism for
> configuring beans that does not require re-compilation - may be of
> limited use in greenfield applications, but above all with
> brownfield/legacy code. In fairness, for the latter one could use
> producers and such, but it may still be a PITA in some cases.
>
> Now, the key here IMO would be to have a scriptable (no recompilation)
> and toolable DSL outside the annotation system. It so happens that of
> all the options, XML is IMO the most common and better understood by the
> average developer. If we manage to define a proper intermediate model
> for this mechanism, then there could be plenty of other options (yaml,
> or even Groovy or Ruby if one so wishes) to add on later.
>
>
> On 2012-09-10 3:50 AM, Romain Manni-Bucau wrote:
>>  what does bring xml? i think that's the point
>>
>>  if it is only to get a format with hierarchy  you can use yaml for instance
>>
>>  *Romain Manni-Bucau*
>>  *Twitter: @rmannibucau*
>>  *Blog: http://rmannibucau.wordpress.com*
>>
>>
>>
>>
>>  2012/9/10 Bernard Łabno <[hidden email]>
>>
>>>  If you find elegant way to do everything that can be currently done
> then
>>>  it's cool not to use XML, but if we won't be able to i.e.
> configure bean
>>>  properties between compilation and deployment then it will be great
>>>  disappointment.
>>>
>>>  2012/9/10 Charles Moulliard <[hidden email]>
>>>
>>>>  I would prefer that we avoid to use XML. Otherwise, end users will
> be
>>>>  confused about what a CDI / CDI Extension should looks like and why
> we
>>>  are
>>>>  moving one step down to do what Spring / Xbean are doing.
>>>>
>>>>  On Fri, Sep 7, 2012 at 11:31 PM, Romain Manni-Bucau
>>>>  <[hidden email]>wrote:
>>>>
>>>>>  Why i would like to use files (i find xml too verbose) is for
> constants
>>>>>  (uri for instance) or alternative/interceptor (as mentionned)
>>>>>
>>>>>  Today i find other use case the translation of bad design
>>>>>
>>>>>  ...just my opinion maybe
>>>>>  Le 7 sept. 2012 23:01, "Jason Porter"
> <[hidden email]> a
>>>  écrit
>>>>  :
>>>>>>  Mark, Pete and I discussed a little bit about the XML
> config (from
>>>>>  Solder)
>>>>>>  on IRC today. We quickly decided that we needed to move
> over to the
>>>>>  mailing
>>>>>>  list for more input, and to make things official.
>>>>>>
>>>>>>  As things currently exist in the Solder XML Config,
> it's probably not
>>>>>>  portable and would really need some of the changes in CDI
> 1.1 to work
>>>>>>  properly. We also discussed throwing out the idea of
> completely
>>>>>  configuring
>>>>>>  beans via XML and using the XML config for other tasks such
> as
>>>  applying
>>>>>>  interceptors and the like via regex or similar ideas, in
> other words
>>>>>  having
>>>>>>  it being a subset of what currently exists today. What is
> in Solder
>>>  is
>>>>>  very
>>>>>>  similar to configuring beans via XML in Spring, and we feel
> that
>>>>  paradigm
>>>>>>  has sailed.
>>>>>>
>>>>>>  I'm starting this thread to get some other ideas about
> what we should
>>>>  do
>>>>>>  for XML config and also see what people think.
>>>>>>
>>>>>>  --
>>>>>>  Jason Porter
>>>>>>  http://lightguard-jp.blogspot.com
>>>>>>  http://twitter.com/lightguardjp
>>>>>>
>>>>>>  Software Engineer
>>>>>>  Open Source Advocate
>>>>>>  Author of Seam Catch - Next Generation Java Exception
> Handling
>>>>>>
>>>>>>  PGP key id: 926CCFF5
>>>>>>  PGP key available at: keyserver.net, pgp.mit.edu
>>>>>>
>>>>
>>>>
>>>>  --
>>>>  Charles Moulliard
>>>>  Apache Committer / Sr. Pr. Consultant at FuseSource.com
>>>>  Twitter : @cmoulliard
>>>>  Blog : http://cmoulliard.blogspot.com
>>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: XML Config

Romain Manni-Bucau
In reply to this post by Mark Struberg
drawbacks of DSL:
1) new API
2) add code in place where you shouldnt have
...

legacy libs can still be used with producers or extensions so i don't see a
need of xml here

*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
Reply | Threaded
Open this post in threaded view
|

Re: XML Config

Marius Bogoevici
In reply to this post by Mark Struberg
Spring supports it, but in practice you'd want to stay away from it. I
thought more along the lines of a script that is interpreted at startup.

On 2012-09-10 10:15 AM, Mark Struberg wrote:

> hmm 'scriptable' imo implies that it can be changed at runtime. But that's by design not possible with CDI. Spring supports this, we do not. Otoh this allows us to be much faster in all 'static' use cases.
>
> LieGrue,
> strub
>
>
>
>
> ----- Original Message -----
>> From: Marius Bogoevici <[hidden email]>
>> To: [hidden email]
>> Cc: Romain Manni-Bucau <[hidden email]>
>> Sent: Monday, September 10, 2012 3:20 PM
>> Subject: Re: XML Config
>>
>> G enerally speaking, I think it would be good to have a mechanism for
>> configuring beans that does not require re-compilation - may be of
>> limited use in greenfield applications, but above all with
>> brownfield/legacy code. In fairness, for the latter one could use
>> producers and such, but it may still be a PITA in some cases.
>>
>> Now, the key here IMO would be to have a scriptable (no recompilation)
>> and toolable DSL outside the annotation system. It so happens that of
>> all the options, XML is IMO the most common and better understood by the
>> average developer. If we manage to define a proper intermediate model
>> for this mechanism, then there could be plenty of other options (yaml,
>> or even Groovy or Ruby if one so wishes) to add on later.
>>
>>
>> On 2012-09-10 3:50 AM, Romain Manni-Bucau wrote:
>>>   what does bring xml? i think that's the point
>>>
>>>   if it is only to get a format with hierarchy  you can use yaml for instance
>>>
>>>   *Romain Manni-Bucau*
>>>   *Twitter: @rmannibucau*
>>>   *Blog: http://rmannibucau.wordpress.com*
>>>
>>>
>>>
>>>
>>>   2012/9/10 Bernard Łabno <[hidden email]>
>>>
>>>>   If you find elegant way to do everything that can be currently done
>> then
>>>>   it's cool not to use XML, but if we won't be able to i.e.
>> configure bean
>>>>   properties between compilation and deployment then it will be great
>>>>   disappointment.
>>>>
>>>>   2012/9/10 Charles Moulliard <[hidden email]>
>>>>
>>>>>   I would prefer that we avoid to use XML. Otherwise, end users will
>> be
>>>>>   confused about what a CDI / CDI Extension should looks like and why
>> we
>>>>   are
>>>>>   moving one step down to do what Spring / Xbean are doing.
>>>>>
>>>>>   On Fri, Sep 7, 2012 at 11:31 PM, Romain Manni-Bucau
>>>>>   <[hidden email]>wrote:
>>>>>
>>>>>>   Why i would like to use files (i find xml too verbose) is for
>> constants
>>>>>>   (uri for instance) or alternative/interceptor (as mentionned)
>>>>>>
>>>>>>   Today i find other use case the translation of bad design
>>>>>>
>>>>>>   ...just my opinion maybe
>>>>>>   Le 7 sept. 2012 23:01, "Jason Porter"
>> <[hidden email]> a
>>>>   écrit
>>>>>   :
>>>>>>>   Mark, Pete and I discussed a little bit about the XML
>> config (from
>>>>>>   Solder)
>>>>>>>   on IRC today. We quickly decided that we needed to move
>> over to the
>>>>>>   mailing
>>>>>>>   list for more input, and to make things official.
>>>>>>>
>>>>>>>   As things currently exist in the Solder XML Config,
>> it's probably not
>>>>>>>   portable and would really need some of the changes in CDI
>> 1.1 to work
>>>>>>>   properly. We also discussed throwing out the idea of
>> completely
>>>>>>   configuring
>>>>>>>   beans via XML and using the XML config for other tasks such
>> as
>>>>   applying
>>>>>>>   interceptors and the like via regex or similar ideas, in
>> other words
>>>>>>   having
>>>>>>>   it being a subset of what currently exists today. What is
>> in Solder
>>>>   is
>>>>>>   very
>>>>>>>   similar to configuring beans via XML in Spring, and we feel
>> that
>>>>>   paradigm
>>>>>>>   has sailed.
>>>>>>>
>>>>>>>   I'm starting this thread to get some other ideas about
>> what we should
>>>>>   do
>>>>>>>   for XML config and also see what people think.
>>>>>>>
>>>>>>>   --
>>>>>>>   Jason Porter
>>>>>>>   http://lightguard-jp.blogspot.com
>>>>>>>   http://twitter.com/lightguardjp
>>>>>>>
>>>>>>>   Software Engineer
>>>>>>>   Open Source Advocate
>>>>>>>   Author of Seam Catch - Next Generation Java Exception
>> Handling
>>>>>>>   PGP key id: 926CCFF5
>>>>>>>   PGP key available at: keyserver.net, pgp.mit.edu
>>>>>>>
>>>>>
>>>>>   --
>>>>>   Charles Moulliard
>>>>>   Apache Committer / Sr. Pr. Consultant at FuseSource.com
>>>>>   Twitter : @cmoulliard
>>>>>   Blog : http://cmoulliard.blogspot.com
>>>>>

Reply | Threaded
Open this post in threaded view
|

Re: XML Config

Bernard Łabno
Ok, what If I have library with CDI beans that send emails and need to have
JNDI of mail session configured?
When I attach this library to project A that is deployed on JBoss AS7 it
may have different jndi then in some other project or server.


2012/9/10 Marius Bogoevici <[hidden email]>

> Spring supports it, but in practice you'd want to stay away from it. I
> thought more along the lines of a script that is interpreted at startup.
>
>
> On 2012-09-10 10:15 AM, Mark Struberg wrote:
>
>> hmm 'scriptable' imo implies that it can be changed at runtime. But
>> that's by design not possible with CDI. Spring supports this, we do not.
>> Otoh this allows us to be much faster in all 'static' use cases.
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>> ----- Original Message -----
>>
>>> From: Marius Bogoevici <[hidden email]>
>>> To: deltaspike-dev@incubator.**apache.org<[hidden email]>
>>> Cc: Romain Manni-Bucau <[hidden email]>
>>> Sent: Monday, September 10, 2012 3:20 PM
>>> Subject: Re: XML Config
>>>
>>> G enerally speaking, I think it would be good to have a mechanism for
>>> configuring beans that does not require re-compilation - may be of
>>> limited use in greenfield applications, but above all with
>>> brownfield/legacy code. In fairness, for the latter one could use
>>> producers and such, but it may still be a PITA in some cases.
>>>
>>> Now, the key here IMO would be to have a scriptable (no recompilation)
>>> and toolable DSL outside the annotation system. It so happens that of
>>> all the options, XML is IMO the most common and better understood by the
>>> average developer. If we manage to define a proper intermediate model
>>> for this mechanism, then there could be plenty of other options (yaml,
>>> or even Groovy or Ruby if one so wishes) to add on later.
>>>
>>>
>>> On 2012-09-10 3:50 AM, Romain Manni-Bucau wrote:
>>>
>>>>   what does bring xml? i think that's the point
>>>>
>>>>   if it is only to get a format with hierarchy  you can use yaml for
>>>> instance
>>>>
>>>>   *Romain Manni-Bucau*
>>>>   *Twitter: @rmannibucau*
>>>>   *Blog: http://rmannibucau.wordpress.**com<http://rmannibucau.wordpress.com>
>>>> *
>>>>
>>>>
>>>>
>>>>
>>>>   2012/9/10 Bernard Łabno <[hidden email]>
>>>>
>>>>    If you find elegant way to do everything that can be currently done
>>>>>
>>>> then
>>>
>>>>   it's cool not to use XML, but if we won't be able to i.e.
>>>>>
>>>> configure bean
>>>
>>>>   properties between compilation and deployment then it will be great
>>>>>   disappointment.
>>>>>
>>>>>   2012/9/10 Charles Moulliard <[hidden email]>
>>>>>
>>>>>    I would prefer that we avoid to use XML. Otherwise, end users will
>>>>>>
>>>>> be
>>>
>>>>   confused about what a CDI / CDI Extension should looks like and why
>>>>>>
>>>>> we
>>>
>>>>   are
>>>>>
>>>>>>   moving one step down to do what Spring / Xbean are doing.
>>>>>>
>>>>>>   On Fri, Sep 7, 2012 at 11:31 PM, Romain Manni-Bucau
>>>>>>   <[hidden email]>wrote:
>>>>>>
>>>>>>    Why i would like to use files (i find xml too verbose) is for
>>>>>>>
>>>>>> constants
>>>
>>>>   (uri for instance) or alternative/interceptor (as mentionned)
>>>>>>>
>>>>>>>   Today i find other use case the translation of bad design
>>>>>>>
>>>>>>>   ...just my opinion maybe
>>>>>>>   Le 7 sept. 2012 23:01, "Jason Porter"
>>>>>>>
>>>>>> <[hidden email]> a
>>>
>>>>   écrit
>>>>>
>>>>>>   :
>>>>>>
>>>>>>>   Mark, Pete and I discussed a little bit about the XML
>>>>>>>>
>>>>>>> config (from
>>>
>>>>   Solder)
>>>>>>>
>>>>>>>>   on IRC today. We quickly decided that we needed to move
>>>>>>>>
>>>>>>> over to the
>>>
>>>>   mailing
>>>>>>>
>>>>>>>>   list for more input, and to make things official.
>>>>>>>>
>>>>>>>>   As things currently exist in the Solder XML Config,
>>>>>>>>
>>>>>>> it's probably not
>>>
>>>>   portable and would really need some of the changes in CDI
>>>>>>>>
>>>>>>> 1.1 to work
>>>
>>>>   properly. We also discussed throwing out the idea of
>>>>>>>>
>>>>>>> completely
>>>
>>>>   configuring
>>>>>>>
>>>>>>>>   beans via XML and using the XML config for other tasks such
>>>>>>>>
>>>>>>> as
>>>
>>>>   applying
>>>>>
>>>>>>   interceptors and the like via regex or similar ideas, in
>>>>>>>>
>>>>>>> other words
>>>
>>>>   having
>>>>>>>
>>>>>>>>   it being a subset of what currently exists today. What is
>>>>>>>>
>>>>>>> in Solder
>>>
>>>>   is
>>>>>
>>>>>>   very
>>>>>>>
>>>>>>>>   similar to configuring beans via XML in Spring, and we feel
>>>>>>>>
>>>>>>> that
>>>
>>>>   paradigm
>>>>>>
>>>>>>>   has sailed.
>>>>>>>>
>>>>>>>>   I'm starting this thread to get some other ideas about
>>>>>>>>
>>>>>>> what we should
>>>
>>>>   do
>>>>>>
>>>>>>>   for XML config and also see what people think.
>>>>>>>>
>>>>>>>>   --
>>>>>>>>   Jason Porter
>>>>>>>>   http://lightguard-jp.blogspot.**com<http://lightguard-jp.blogspot.com>
>>>>>>>>   http://twitter.com/**lightguardjp<http://twitter.com/lightguardjp>
>>>>>>>>
>>>>>>>>   Software Engineer
>>>>>>>>   Open Source Advocate
>>>>>>>>   Author of Seam Catch - Next Generation Java Exception
>>>>>>>>
>>>>>>> Handling
>>>
>>>>   PGP key id: 926CCFF5
>>>>>>>>   PGP key available at: keyserver.net, pgp.mit.edu
>>>>>>>>
>>>>>>>>
>>>>>>   --
>>>>>>   Charles Moulliard
>>>>>>   Apache Committer / Sr. Pr. Consultant at FuseSource.com
>>>>>>   Twitter : @cmoulliard
>>>>>>   Blog : http://cmoulliard.blogspot.com
>>>>>>
>>>>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: XML Config

Mark Struberg
Administrator
One of the credos is that you MUST NOT repackage for just moving to a new server.
Either this is in JNDI (same location) or just use @Inject ProjectStage ps; to check on which server you are running.

I see no benefit of moving config to XML if it's not picked up from a really changable location.
To me this just means to replace hardcoding in java sources with hardcoding in some XML which gots scanned by java sources.

LieGrue
strub




----- Original Message -----

> From: Bernard Łabno <[hidden email]>
> To: [hidden email]
> Cc:
> Sent: Monday, September 10, 2012 5:41 PM
> Subject: Re: XML Config
>
> Ok, what If I have library with CDI beans that send emails and need to have
> JNDI of mail session configured?
> When I attach this library to project A that is deployed on JBoss AS7 it
> may have different jndi then in some other project or server.
>
>
> 2012/9/10 Marius Bogoevici <[hidden email]>
>
>>  Spring supports it, but in practice you'd want to stay away from it. I
>>  thought more along the lines of a script that is interpreted at startup.
>>
>>
>>  On 2012-09-10 10:15 AM, Mark Struberg wrote:
>>
>>>  hmm 'scriptable' imo implies that it can be changed at runtime.
> But
>>>  that's by design not possible with CDI. Spring supports this, we do
> not.
>>>  Otoh this allows us to be much faster in all 'static' use
> cases.
>>>
>>>  LieGrue,
>>>  strub
>>>
>>>
>>>
>>>
>>>  ----- Original Message -----
>>>
>>>>  From: Marius Bogoevici <[hidden email]>
>>>>  To:
> deltaspike-dev@incubator.**apache.org<[hidden email]>
>>>>  Cc: Romain Manni-Bucau <[hidden email]>
>>>>  Sent: Monday, September 10, 2012 3:20 PM
>>>>  Subject: Re: XML Config
>>>>
>>>>  G enerally speaking, I think it would be good to have a mechanism
> for
>>>>  configuring beans that does not require re-compilation - may be of
>>>>  limited use in greenfield applications, but above all with
>>>>  brownfield/legacy code. In fairness, for the latter one could use
>>>>  producers and such, but it may still be a PITA in some cases.
>>>>
>>>>  Now, the key here IMO would be to have a scriptable (no
> recompilation)
>>>>  and toolable DSL outside the annotation system. It so happens that
> of
>>>>  all the options, XML is IMO the most common and better understood
> by the
>>>>  average developer. If we manage to define a proper intermediate
> model
>>>>  for this mechanism, then there could be plenty of other options
> (yaml,
>>>>  or even Groovy or Ruby if one so wishes) to add on later.
>>>>
>>>>
>>>>  On 2012-09-10 3:50 AM, Romain Manni-Bucau wrote:
>>>>
>>>>>    what does bring xml? i think that's the point
>>>>>
>>>>>    if it is only to get a format with hierarchy  you can use
> yaml for
>>>>>  instance
>>>>>
>>>>>    *Romain Manni-Bucau*
>>>>>    *Twitter: @rmannibucau*
>>>>>    *Blog:
> http://rmannibucau.wordpress.**com<http://rmannibucau.wordpress.com>
>>>>>  *
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>    2012/9/10 Bernard Łabno <[hidden email]>
>>>>>
>>>>>     If you find elegant way to do everything that can be
> currently done
>>>>>>
>>>>>  then
>>>>
>>>>>    it's cool not to use XML, but if we won't be able to
> i.e.
>>>>>>
>>>>>  configure bean
>>>>
>>>>>    properties between compilation and deployment then it will be
> great
>>>>>>    disappointment.
>>>>>>
>>>>>>    2012/9/10 Charles Moulliard <[hidden email]>
>>>>>>
>>>>>>     I would prefer that we avoid to use XML. Otherwise, end
> users will
>>>>>>>
>>>>>>  be
>>>>
>>>>>    confused about what a CDI / CDI Extension should looks like
> and why
>>>>>>>
>>>>>>  we
>>>>
>>>>>    are
>>>>>>
>>>>>>>    moving one step down to do what Spring / Xbean are
> doing.
>>>>>>>
>>>>>>>    On Fri, Sep 7, 2012 at 11:31 PM, Romain Manni-Bucau
>>>>>>>    <[hidden email]>wrote:
>>>>>>>
>>>>>>>     Why i would like to use files (i find xml too
> verbose) is for
>>>>>>>>
>>>>>>>  constants
>>>>
>>>>>    (uri for instance) or alternative/interceptor (as mentionned)
>>>>>>>>
>>>>>>>>    Today i find other use case the translation of
> bad design
>>>>>>>>
>>>>>>>>    ...just my opinion maybe
>>>>>>>>    Le 7 sept. 2012 23:01, "Jason Porter"
>>>>>>>>
>>>>>>>  <[hidden email]> a
>>>>
>>>>>    écrit
>>>>>>
>>>>>>>    :
>>>>>>>
>>>>>>>>    Mark, Pete and I discussed a little bit about the
> XML
>>>>>>>>>
>>>>>>>>  config (from
>>>>
>>>>>    Solder)
>>>>>>>>
>>>>>>>>>    on IRC today. We quickly decided that we
> needed to move
>>>>>>>>>
>>>>>>>>  over to the
>>>>
>>>>>    mailing
>>>>>>>>
>>>>>>>>>    list for more input, and to make things
> official.
>>>>>>>>>
>>>>>>>>>    As things currently exist in the Solder XML
> Config,
>>>>>>>>>
>>>>>>>>  it's probably not
>>>>
>>>>>    portable and would really need some of the changes in CDI
>>>>>>>>>
>>>>>>>>  1.1 to work
>>>>
>>>>>    properly. We also discussed throwing out the idea of
>>>>>>>>>
>>>>>>>>  completely
>>>>
>>>>>    configuring
>>>>>>>>
>>>>>>>>>    beans via XML and using the XML config for
> other tasks such
>>>>>>>>>
>>>>>>>>  as
>>>>
>>>>>    applying
>>>>>>
>>>>>>>    interceptors and the like via regex or similar ideas,
> in
>>>>>>>>>
>>>>>>>>  other words
>>>>
>>>>>    having
>>>>>>>>
>>>>>>>>>    it being a subset of what currently exists
> today. What is
>>>>>>>>>
>>>>>>>>  in Solder
>>>>
>>>>>    is
>>>>>>
>>>>>>>    very
>>>>>>>>
>>>>>>>>>    similar to configuring beans via XML in
> Spring, and we feel
>>>>>>>>>
>>>>>>>>  that
>>>>
>>>>>    paradigm
>>>>>>>
>>>>>>>>    has sailed.
>>>>>>>>>
>>>>>>>>>    I'm starting this thread to get some
> other ideas about
>>>>>>>>>
>>>>>>>>  what we should
>>>>
>>>>>    do
>>>>>>>
>>>>>>>>    for XML config and also see what people think.
>>>>>>>>>
>>>>>>>>>    --
>>>>>>>>>    Jason Porter
>>>>>>>>>  
> http://lightguard-jp.blogspot.**com<http://lightguard-jp.blogspot.com>
>>>>>>>>>  
> http://twitter.com/**lightguardjp<http://twitter.com/lightguardjp>
>>>>>>>>>
>>>>>>>>>    Software Engineer
>>>>>>>>>    Open Source Advocate
>>>>>>>>>    Author of Seam Catch - Next Generation Java
> Exception
>>>>>>>>>
>>>>>>>>  Handling
>>>>
>>>>>    PGP key id: 926CCFF5
>>>>>>>>>    PGP key available at: keyserver.net,
> pgp.mit.edu
>>>>>>>>>
>>>>>>>>>
>>>>>>>    --
>>>>>>>    Charles Moulliard
>>>>>>>    Apache Committer / Sr. Pr. Consultant at
> FuseSource.com
>>>>>>>    Twitter : @cmoulliard
>>>>>>>    Blog : http://cmoulliard.blogspot.com
>>>>>>>
>>>>>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: XML Config

Charles Moulliard-2
In reply to this post by Bernard Łabno
You can use Config-Source of DeltaSpike to override jndi location (see this
page : http://incubator.apache.org/deltaspike/features.html --> add custom
config sources).

Otherwise, you can always use Camel to create a route to send emails (
http://camel.apache.org/mail.html). As camel supports also CDI, this is
another elegant alternative.

On Mon, Sep 10, 2012 at 5:41 PM, Bernard Łabno <[hidden email]> wrote:

> Ok, what If I have library with CDI beans that send emails and need to have
> JNDI of mail session configured?
> When I attach this library to project A that is deployed on JBoss AS7 it
> may have different jndi then in some other project or server.
>
>
> 2012/9/10 Marius Bogoevici <[hidden email]>
>
> > Spring supports it, but in practice you'd want to stay away from it. I
> > thought more along the lines of a script that is interpreted at startup.
> >
> >
> > On 2012-09-10 10:15 AM, Mark Struberg wrote:
> >
> >> hmm 'scriptable' imo implies that it can be changed at runtime. But
> >> that's by design not possible with CDI. Spring supports this, we do not.
> >> Otoh this allows us to be much faster in all 'static' use cases.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >>
> >> ----- Original Message -----
> >>
> >>> From: Marius Bogoevici <[hidden email]>
> >>> To: deltaspike-dev@incubator.**apache.org<
> [hidden email]>
> >>> Cc: Romain Manni-Bucau <[hidden email]>
> >>> Sent: Monday, September 10, 2012 3:20 PM
> >>> Subject: Re: XML Config
> >>>
> >>> G enerally speaking, I think it would be good to have a mechanism for
> >>> configuring beans that does not require re-compilation - may be of
> >>> limited use in greenfield applications, but above all with
> >>> brownfield/legacy code. In fairness, for the latter one could use
> >>> producers and such, but it may still be a PITA in some cases.
> >>>
> >>> Now, the key here IMO would be to have a scriptable (no recompilation)
> >>> and toolable DSL outside the annotation system. It so happens that of
> >>> all the options, XML is IMO the most common and better understood by
> the
> >>> average developer. If we manage to define a proper intermediate model
> >>> for this mechanism, then there could be plenty of other options (yaml,
> >>> or even Groovy or Ruby if one so wishes) to add on later.
> >>>
> >>>
> >>> On 2012-09-10 3:50 AM, Romain Manni-Bucau wrote:
> >>>
> >>>>   what does bring xml? i think that's the point
> >>>>
> >>>>   if it is only to get a format with hierarchy  you can use yaml for
> >>>> instance
> >>>>
> >>>>   *Romain Manni-Bucau*
> >>>>   *Twitter: @rmannibucau*
> >>>>   *Blog: http://rmannibucau.wordpress.**com<
> http://rmannibucau.wordpress.com>
> >>>> *
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>   2012/9/10 Bernard Łabno <[hidden email]>
> >>>>
> >>>>    If you find elegant way to do everything that can be currently done
> >>>>>
> >>>> then
> >>>
> >>>>   it's cool not to use XML, but if we won't be able to i.e.
> >>>>>
> >>>> configure bean
> >>>
> >>>>   properties between compilation and deployment then it will be great
> >>>>>   disappointment.
> >>>>>
> >>>>>   2012/9/10 Charles Moulliard <[hidden email]>
> >>>>>
> >>>>>    I would prefer that we avoid to use XML. Otherwise, end users will
> >>>>>>
> >>>>> be
> >>>
> >>>>   confused about what a CDI / CDI Extension should looks like and why
> >>>>>>
> >>>>> we
> >>>
> >>>>   are
> >>>>>
> >>>>>>   moving one step down to do what Spring / Xbean are doing.
> >>>>>>
> >>>>>>   On Fri, Sep 7, 2012 at 11:31 PM, Romain Manni-Bucau
> >>>>>>   <[hidden email]>wrote:
> >>>>>>
> >>>>>>    Why i would like to use files (i find xml too verbose) is for
> >>>>>>>
> >>>>>> constants
> >>>
> >>>>   (uri for instance) or alternative/interceptor (as mentionned)
> >>>>>>>
> >>>>>>>   Today i find other use case the translation of bad design
> >>>>>>>
> >>>>>>>   ...just my opinion maybe
> >>>>>>>   Le 7 sept. 2012 23:01, "Jason Porter"
> >>>>>>>
> >>>>>> <[hidden email]> a
> >>>
> >>>>   écrit
> >>>>>
> >>>>>>   :
> >>>>>>
> >>>>>>>   Mark, Pete and I discussed a little bit about the XML
> >>>>>>>>
> >>>>>>> config (from
> >>>
> >>>>   Solder)
> >>>>>>>
> >>>>>>>>   on IRC today. We quickly decided that we needed to move
> >>>>>>>>
> >>>>>>> over to the
> >>>
> >>>>   mailing
> >>>>>>>
> >>>>>>>>   list for more input, and to make things official.
> >>>>>>>>
> >>>>>>>>   As things currently exist in the Solder XML Config,
> >>>>>>>>
> >>>>>>> it's probably not
> >>>
> >>>>   portable and would really need some of the changes in CDI
> >>>>>>>>
> >>>>>>> 1.1 to work
> >>>
> >>>>   properly. We also discussed throwing out the idea of
> >>>>>>>>
> >>>>>>> completely
> >>>
> >>>>   configuring
> >>>>>>>
> >>>>>>>>   beans via XML and using the XML config for other tasks such
> >>>>>>>>
> >>>>>>> as
> >>>
> >>>>   applying
> >>>>>
> >>>>>>   interceptors and the like via regex or similar ideas, in
> >>>>>>>>
> >>>>>>> other words
> >>>
> >>>>   having
> >>>>>>>
> >>>>>>>>   it being a subset of what currently exists today. What is
> >>>>>>>>
> >>>>>>> in Solder
> >>>
> >>>>   is
> >>>>>
> >>>>>>   very
> >>>>>>>
> >>>>>>>>   similar to configuring beans via XML in Spring, and we feel
> >>>>>>>>
> >>>>>>> that
> >>>
> >>>>   paradigm
> >>>>>>
> >>>>>>>   has sailed.
> >>>>>>>>
> >>>>>>>>   I'm starting this thread to get some other ideas about
> >>>>>>>>
> >>>>>>> what we should
> >>>
> >>>>   do
> >>>>>>
> >>>>>>>   for XML config and also see what people think.
> >>>>>>>>
> >>>>>>>>   --
> >>>>>>>>   Jason Porter
> >>>>>>>>   http://lightguard-jp.blogspot.**com<
> http://lightguard-jp.blogspot.com>
> >>>>>>>>   http://twitter.com/**lightguardjp<
> http://twitter.com/lightguardjp>
> >>>>>>>>
> >>>>>>>>   Software Engineer
> >>>>>>>>   Open Source Advocate
> >>>>>>>>   Author of Seam Catch - Next Generation Java Exception
> >>>>>>>>
> >>>>>>> Handling
> >>>
> >>>>   PGP key id: 926CCFF5
> >>>>>>>>   PGP key available at: keyserver.net, pgp.mit.edu
> >>>>>>>>
> >>>>>>>>
> >>>>>>   --
> >>>>>>   Charles Moulliard
> >>>>>>   Apache Committer / Sr. Pr. Consultant at FuseSource.com
> >>>>>>   Twitter : @cmoulliard
> >>>>>>   Blog : http://cmoulliard.blogspot.com
> >>>>>>
> >>>>>>
> >
>



--
Charles Moulliard
Apache Committer / Sr. Pr. Consultant at FuseSource.com
Twitter : @cmoulliard
Blog : http://cmoulliard.blogspot.com
Reply | Threaded
Open this post in threaded view
|

Re: XML Config

Romain Manni-Bucau
using projectstage or portable jndi name should be possible too

*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*




2012/9/10 Charles Moulliard <[hidden email]>

> You can use Config-Source of DeltaSpike to override jndi location (see this
> page : http://incubator.apache.org/deltaspike/features.html --> add custom
> config sources).
>
> Otherwise, you can always use Camel to create a route to send emails (
> http://camel.apache.org/mail.html). As camel supports also CDI, this is
> another elegant alternative.
>
> On Mon, Sep 10, 2012 at 5:41 PM, Bernard Łabno <[hidden email]>
> wrote:
>
> > Ok, what If I have library with CDI beans that send emails and need to
> have
> > JNDI of mail session configured?
> > When I attach this library to project A that is deployed on JBoss AS7 it
> > may have different jndi then in some other project or server.
> >
> >
> > 2012/9/10 Marius Bogoevici <[hidden email]>
> >
> > > Spring supports it, but in practice you'd want to stay away from it. I
> > > thought more along the lines of a script that is interpreted at
> startup.
> > >
> > >
> > > On 2012-09-10 10:15 AM, Mark Struberg wrote:
> > >
> > >> hmm 'scriptable' imo implies that it can be changed at runtime. But
> > >> that's by design not possible with CDI. Spring supports this, we do
> not.
> > >> Otoh this allows us to be much faster in all 'static' use cases.
> > >>
> > >> LieGrue,
> > >> strub
> > >>
> > >>
> > >>
> > >>
> > >> ----- Original Message -----
> > >>
> > >>> From: Marius Bogoevici <[hidden email]>
> > >>> To: deltaspike-dev@incubator.**apache.org<
> > [hidden email]>
> > >>> Cc: Romain Manni-Bucau <[hidden email]>
> > >>> Sent: Monday, September 10, 2012 3:20 PM
> > >>> Subject: Re: XML Config
> > >>>
> > >>> G enerally speaking, I think it would be good to have a mechanism for
> > >>> configuring beans that does not require re-compilation - may be of
> > >>> limited use in greenfield applications, but above all with
> > >>> brownfield/legacy code. In fairness, for the latter one could use
> > >>> producers and such, but it may still be a PITA in some cases.
> > >>>
> > >>> Now, the key here IMO would be to have a scriptable (no
> recompilation)
> > >>> and toolable DSL outside the annotation system. It so happens that of
> > >>> all the options, XML is IMO the most common and better understood by
> > the
> > >>> average developer. If we manage to define a proper intermediate model
> > >>> for this mechanism, then there could be plenty of other options
> (yaml,
> > >>> or even Groovy or Ruby if one so wishes) to add on later.
> > >>>
> > >>>
> > >>> On 2012-09-10 3:50 AM, Romain Manni-Bucau wrote:
> > >>>
> > >>>>   what does bring xml? i think that's the point
> > >>>>
> > >>>>   if it is only to get a format with hierarchy  you can use yaml for
> > >>>> instance
> > >>>>
> > >>>>   *Romain Manni-Bucau*
> > >>>>   *Twitter: @rmannibucau*
> > >>>>   *Blog: http://rmannibucau.wordpress.**com<
> > http://rmannibucau.wordpress.com>
> > >>>> *
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>   2012/9/10 Bernard Łabno <[hidden email]>
> > >>>>
> > >>>>    If you find elegant way to do everything that can be currently
> done
> > >>>>>
> > >>>> then
> > >>>
> > >>>>   it's cool not to use XML, but if we won't be able to i.e.
> > >>>>>
> > >>>> configure bean
> > >>>
> > >>>>   properties between compilation and deployment then it will be
> great
> > >>>>>   disappointment.
> > >>>>>
> > >>>>>   2012/9/10 Charles Moulliard <[hidden email]>
> > >>>>>
> > >>>>>    I would prefer that we avoid to use XML. Otherwise, end users
> will
> > >>>>>>
> > >>>>> be
> > >>>
> > >>>>   confused about what a CDI / CDI Extension should looks like and
> why
> > >>>>>>
> > >>>>> we
> > >>>
> > >>>>   are
> > >>>>>
> > >>>>>>   moving one step down to do what Spring / Xbean are doing.
> > >>>>>>
> > >>>>>>   On Fri, Sep 7, 2012 at 11:31 PM, Romain Manni-Bucau
> > >>>>>>   <[hidden email]>wrote:
> > >>>>>>
> > >>>>>>    Why i would like to use files (i find xml too verbose) is for
> > >>>>>>>
> > >>>>>> constants
> > >>>
> > >>>>   (uri for instance) or alternative/interceptor (as mentionned)
> > >>>>>>>
> > >>>>>>>   Today i find other use case the translation of bad design
> > >>>>>>>
> > >>>>>>>   ...just my opinion maybe
> > >>>>>>>   Le 7 sept. 2012 23:01, "Jason Porter"
> > >>>>>>>
> > >>>>>> <[hidden email]> a
> > >>>
> > >>>>   écrit
> > >>>>>
> > >>>>>>   :
> > >>>>>>
> > >>>>>>>   Mark, Pete and I discussed a little bit about the XML
> > >>>>>>>>
> > >>>>>>> config (from
> > >>>
> > >>>>   Solder)
> > >>>>>>>
> > >>>>>>>>   on IRC today. We quickly decided that we needed to move
> > >>>>>>>>
> > >>>>>>> over to the
> > >>>
> > >>>>   mailing
> > >>>>>>>
> > >>>>>>>>   list for more input, and to make things official.
> > >>>>>>>>
> > >>>>>>>>   As things currently exist in the Solder XML Config,
> > >>>>>>>>
> > >>>>>>> it's probably not
> > >>>
> > >>>>   portable and would really need some of the changes in CDI
> > >>>>>>>>
> > >>>>>>> 1.1 to work
> > >>>
> > >>>>   properly. We also discussed throwing out the idea of
> > >>>>>>>>
> > >>>>>>> completely
> > >>>
> > >>>>   configuring
> > >>>>>>>
> > >>>>>>>>   beans via XML and using the XML config for other tasks such
> > >>>>>>>>
> > >>>>>>> as
> > >>>
> > >>>>   applying
> > >>>>>
> > >>>>>>   interceptors and the like via regex or similar ideas, in
> > >>>>>>>>
> > >>>>>>> other words
> > >>>
> > >>>>   having
> > >>>>>>>
> > >>>>>>>>   it being a subset of what currently exists today. What is
> > >>>>>>>>
> > >>>>>>> in Solder
> > >>>
> > >>>>   is
> > >>>>>
> > >>>>>>   very
> > >>>>>>>
> > >>>>>>>>   similar to configuring beans via XML in Spring, and we feel
> > >>>>>>>>
> > >>>>>>> that
> > >>>
> > >>>>   paradigm
> > >>>>>>
> > >>>>>>>   has sailed.
> > >>>>>>>>
> > >>>>>>>>   I'm starting this thread to get some other ideas about
> > >>>>>>>>
> > >>>>>>> what we should
> > >>>
> > >>>>   do
> > >>>>>>
> > >>>>>>>   for XML config and also see what people think.
> > >>>>>>>>
> > >>>>>>>>   --
> > >>>>>>>>   Jason Porter
> > >>>>>>>>   http://lightguard-jp.blogspot.**com<
> > http://lightguard-jp.blogspot.com>
> > >>>>>>>>   http://twitter.com/**lightguardjp<
> > http://twitter.com/lightguardjp>
> > >>>>>>>>
> > >>>>>>>>   Software Engineer
> > >>>>>>>>   Open Source Advocate
> > >>>>>>>>   Author of Seam Catch - Next Generation Java Exception
> > >>>>>>>>
> > >>>>>>> Handling
> > >>>
> > >>>>   PGP key id: 926CCFF5
> > >>>>>>>>   PGP key available at: keyserver.net, pgp.mit.edu
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>   --
> > >>>>>>   Charles Moulliard
> > >>>>>>   Apache Committer / Sr. Pr. Consultant at FuseSource.com
> > >>>>>>   Twitter : @cmoulliard
> > >>>>>>   Blog : http://cmoulliard.blogspot.com
> > >>>>>>
> > >>>>>>
> > >
> >
>
>
>
> --
> Charles Moulliard
> Apache Committer / Sr. Pr. Consultant at FuseSource.com
> Twitter : @cmoulliard
> Blog : http://cmoulliard.blogspot.com
>
Reply | Threaded
Open this post in threaded view
|

Re: XML Config

Stuart Douglas
In reply to this post by Mark Struberg


11 September 2012 1:59 AM
One of the credos is that you MUST NOT repackage for just moving to a new server.
Either this is in JNDI (same location) or just use @Inject ProjectStage ps; to check on which server you are running.

I see no benefit of moving config to XML if it's not picked up from a really changable location.
I kinda agree with this, and in AS7 upstream you can now use deployment overlays to modify an individual descriptor without having to open up the archive (I am pretty sure some other servers also support this). I think
we should also support reading the external config (wether XML or not) from an outside location somehow. Just using the ProjectStage is not really sufficient for all use cases IMHO, as you may have multiple production servers with different configurations. 

To me this just means to replace hardcoding in java sources with hardcoding in some XML which gots scanned by java sources.
Personally I think there are quite a few advantages of configuring via XML:

- It is obvious to new developers where your configuration settings are (META-INF or WEB-INF)
- You can inspect any pre-built archive and see what settings are in effect
- You can also potentially modify those settings with just zip and a text editor (I know this is not ideal, but if your fighting fires and just need to get your app back online this is a lot better than having to do a full re-build).
- Servers that support modification of descriptors at deployment time can modify the config
- There are lots of editors with XML support
- There are lots of developers that know XML

I really don't think that hard coding configuration via annotations is a good idea. Configuration should be plain text, and I think a lot of the push back against XML is more because of the Spring/J2EE overuse of it in the past has made a lot of developers hate XML.

Stuart

LieGrue
strub




----- Original Message -----
11 September 2012 1:41 AM
Ok, what If I have library with CDI beans that send emails and need to have
JNDI of mail session configured?
When I attach this library to project A that is deployed on JBoss AS7 it
may have different jndi then in some other project or server.


2012/9/10 Marius Bogoevici [hidden email]


11 September 2012 12:20 AM
Spring supports it, but in practice you'd want to stay away from it. I thought more along the lines of a script that is interpreted at startup.



11 September 2012 12:15 AM
hmm 'scriptable' imo implies that it can be changed at runtime. But that's by design not possible with CDI. Spring supports this, we do not. Otoh this allows us to be much faster in all 'static' use cases.

LieGrue,
strub




----- Original Message -----
10 September 2012 11:20 PM
Generally speaking, I think it would be good to have a mechanism for configuring beans that does not require re-compilation - may be of limited use in greenfield applications, but above all with brownfield/legacy code. In fairness, for the latter one could use producers and such, but it may still be a PITA in some cases.

Now, the key here IMO would be to have a scriptable (no recompilation) and toolable DSL outside the annotation system. It so happens that of all the options, XML is IMO the most common and better understood by the average developer. If we manage to define a proper intermediate model for this mechanism, then there could be plenty of other options (yaml, or even Groovy or Ruby if one so wishes) to add on later.




Reply | Threaded
Open this post in threaded view
|

Re: XML Config

Romain Manni-Bucau

I hate xml simply because it is too verbose.

Imo config on top of cdi is not the right place. It will often be over engineered.

Properties will often be enough IMO (class name. Attribute = value for instance)

Le 11 sept. 2012 01:31, "Stuart Douglas" <[hidden email]> a écrit :


11 September 2012 1:59 AM
One of the credos is that you MUST NOT repackage for just moving to a new server.
Either this is in JNDI (same location) or just use @Inject ProjectStage ps; to check on which server you are running.

I see no benefit of moving config to XML if it's not picked up from a really changable location.
I kinda agree with this, and in AS7 upstream you can now use deployment overlays to modify an individual descriptor without having to open up the archive (I am pretty sure some other servers also support this). I think
we should also support reading the external config (wether XML or not) from an outside location somehow. Just using the ProjectStage is not really sufficient for all use cases IMHO, as you may have multiple production servers with different configurations. 

To me this just means to replace hardcoding in java sources with hardcoding in some XML which gots scanned by java sources.
Personally I think there are quite a few advantages of configuring via XML:

- It is obvious to new developers where your configuration settings are (META-INF or WEB-INF)
- You can inspect any pre-built archive and see what settings are in effect
- You can also potentially modify those settings with just zip and a text editor (I know this is not ideal, but if your fighting fires and just need to get your app back online this is a lot better than having to do a full re-build).
- Servers that support modification of descriptors at deployment time can modify the config
- There are lots of editors with XML support
- There are lots of developers that know XML

I really don't think that hard coding configuration via annotations is a good idea. Configuration should be plain text, and I think a lot of the push back against XML is more because of the Spring/J2EE overuse of it in the past has made a lot of developers hate XML.

Stuart

LieGrue
strub




----- Original Message -----
11 September 2012 1:41 AM
Ok, what If I have library with CDI beans that send emails and need to have
JNDI of mail session configured?
When I attach this library to project A that is deployed on JBoss AS7 it
may have different jndi then in some other project or server.


2012/9/10 Marius Bogoevici [hidden email]


11 September 2012 12:20 AM
Spring supports it, but in practice you'd want to stay away from it. I thought more along the lines of a script that is interpreted at startup.



11 September 2012 12:15 AM
hmm 'scriptable' imo implies that it can be changed at runtime. But that's by design not possible with CDI. Spring supports this, we do not. Otoh this allows us to be much faster in all 'static' use cases.

LieGrue,
strub




----- Original Message -----
10 September 2012 11:20 PM
Generally speaking, I think it would be good to have a mechanism for configuring beans that does not require re-compilation - may be of limited use in greenfield applications, but above all with brownfield/legacy code. In fairness, for the latter one could use producers and such, but it may still be a PITA in some cases.

Now, the key here IMO would be to have a scriptable (no recompilation) and toolable DSL outside the annotation system. It so happens that of all the options, XML is IMO the most common and better understood by the average developer. If we manage to define a proper intermediate model for this mechanism, then there could be plenty of other options (yaml, or even Groovy or Ruby if one so wishes) to add on later.




Reply | Threaded
Open this post in threaded view
|

Re: XML Config

Marius Bogoevici
In reply to this post by Pete Muir
On 2012-09-10 8:25 AM, Pete Muir wrote:
> This is what I would use non-compiled resources for as well.
>
> If I needed to CDI-enable some code without using annotations, I would use the portable extension API directly.
Yes and no. In my opinion this is generic enough to warrant a
configurable implementation, rather than producing a code template that
would be copied and pasted around. I understand that all of us can
master the fine points of writing an extension, but a configurable
solution may be easier for the average developer.

>
> On 7 Sep 2012, at 22:31, Romain Manni-Bucau wrote:
>
>> Why i would like to use files (i find xml too verbose) is for constants
>> (uri for instance) or alternative/interceptor (as mentionned)
>>
>> Today i find other use case the translation of bad design
>>
>> ...just my opinion maybe
>> Le 7 sept. 2012 23:01, "Jason Porter" <[hidden email]> a écrit :
>>
>>> Mark, Pete and I discussed a little bit about the XML config (from Solder)
>>> on IRC today. We quickly decided that we needed to move over to the mailing
>>> list for more input, and to make things official.
>>>
>>> As things currently exist in the Solder XML Config, it's probably not
>>> portable and would really need some of the changes in CDI 1.1 to work
>>> properly. We also discussed throwing out the idea of completely configuring
>>> beans via XML and using the XML config for other tasks such as applying
>>> interceptors and the like via regex or similar ideas, in other words having
>>> it being a subset of what currently exists today. What is in Solder is very
>>> similar to configuring beans via XML in Spring, and we feel that paradigm
>>> has sailed.
>>>
>>> I'm starting this thread to get some other ideas about what we should do
>>> for XML config and also see what people think.
>>>
>>> --
>>> Jason Porter
>>> http://lightguard-jp.blogspot.com
>>> http://twitter.com/lightguardjp
>>>
>>> Software Engineer
>>> Open Source Advocate
>>> Author of Seam Catch - Next Generation Java Exception Handling
>>>
>>> PGP key id: 926CCFF5
>>> PGP key available at: keyserver.net, pgp.mit.edu
>>>

Reply | Threaded
Open this post in threaded view
|

Re: XML Config

Mehdi Heidarzadeh
We have some developers who like xml and some who hate xml and that might
be because of different tastes or background when working with XML in the
past or what ever.
I think configuration with both xml and property files are ok, because some
developers like property files and some like annotations and some xml and
some of them like combination of them like me ;)
I hate *writing* *code* using  XML (like mapping entities, it's kind of
writing code using xml) but I like configuring *application
configuration*with xml or property files, because I can change them in
deploy time
depending on deployment environment without any compilation.
when you ask someone about XML vs annotation vs ...? I think the answer
will depend on the taste and background of that developer.

Since seam3 has xml configuration and DS  can reuse it, why not providing
xml configuration feature too, and letting the developer to choose which
one to use? producer methods vs xml vs property file?


On Tue, Sep 11, 2012 at 6:40 AM, Marius Bogoevici <
[hidden email]> wrote:

> On 2012-09-10 8:25 AM, Pete Muir wrote:
>
>> This is what I would use non-compiled resources for as well.
>>
>> If I needed to CDI-enable some code without using annotations, I would
>> use the portable extension API directly.
>>
> Yes and no. In my opinion this is generic enough to warrant a configurable
> implementation, rather than producing a code template that would be copied
> and pasted around. I understand that all of us can master the fine points
> of writing an extension, but a configurable solution may be easier for the
> average developer.
>
>
>> On 7 Sep 2012, at 22:31, Romain Manni-Bucau wrote:
>>
>>  Why i would like to use files (i find xml too verbose) is for constants
>>> (uri for instance) or alternative/interceptor (as mentionned)
>>>
>>> Today i find other use case the translation of bad design
>>>
>>> ...just my opinion maybe
>>> Le 7 sept. 2012 23:01, "Jason Porter" <[hidden email]> a écrit
>>> :
>>>
>>>  Mark, Pete and I discussed a little bit about the XML config (from
>>>> Solder)
>>>> on IRC today. We quickly decided that we needed to move over to the
>>>> mailing
>>>> list for more input, and to make things official.
>>>>
>>>> As things currently exist in the Solder XML Config, it's probably not
>>>> portable and would really need some of the changes in CDI 1.1 to work
>>>> properly. We also discussed throwing out the idea of completely
>>>> configuring
>>>> beans via XML and using the XML config for other tasks such as applying
>>>> interceptors and the like via regex or similar ideas, in other words
>>>> having
>>>> it being a subset of what currently exists today. What is in Solder is
>>>> very
>>>> similar to configuring beans via XML in Spring, and we feel that
>>>> paradigm
>>>> has sailed.
>>>>
>>>> I'm starting this thread to get some other ideas about what we should do
>>>> for XML config and also see what people think.
>>>>
>>>> --
>>>> Jason Porter
>>>> http://lightguard-jp.blogspot.**com <http://lightguard-jp.blogspot.com>
>>>> http://twitter.com/**lightguardjp <http://twitter.com/lightguardjp>
>>>>
>>>> Software Engineer
>>>> Open Source Advocate
>>>> Author of Seam Catch - Next Generation Java Exception Handling
>>>>
>>>> PGP key id: 926CCFF5
>>>> PGP key available at: keyserver.net, pgp.mit.edu
>>>>
>>>>
>


--
Mehdi Heidarzadeh Ardalani
Independent JEE Consultant, Architect and Developer.
http://www.TheBigJavaBlog.com
12