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 <[email protected]> > To: [email protected] > 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 <[email protected]> > >> 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 <[email protected]> >>>> To: > deltaspike-dev@incubator.**apache.org<[email protected]> >>>> Cc: Romain Manni-Bucau <[email protected]> >>>> 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 <[email protected]> >>>>> >>>>> 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 <[email protected]> >>>>>> >>>>>> 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 >>>>>>> <[email protected]>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" >>>>>>>> >>>>>>> <[email protected]> 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 >>>>>>> >>>>>>> >> >
