deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: XML Config
Date Mon, 10 Sep 2012 15:59:21 GMT
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 <s4237@pjwstk.edu.pl>
> To: deltaspike-dev@incubator.apache.org
> 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 <marius.bogoevici@gmail.com>
> 
>>  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 <marius.bogoevici@gmail.com>
>>>>  To: 
> deltaspike-dev@incubator.**apache.org<deltaspike-dev@incubator.apache.org>
>>>>  Cc: Romain Manni-Bucau <rmannibucau@gmail.com>
>>>>  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 <s4237@pjwstk.edu.pl>
>>>>> 
>>>>>     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 <ch007m@gmail.com>
>>>>>> 
>>>>>>     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
>>>>>>>    <rmannibucau@gmail.com>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"
>>>>>>>> 
>>>>>>>  <lightguard.jp@gmail.com> 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
>>>>>>> 
>>>>>>> 
>> 
> 

Mime
View raw message