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 <[email protected]> > 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 <[email protected]> > 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 <[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 > > >>>>>> > > >>>>>> > > > > > > > > > -- > Charles Moulliard > Apache Committer / Sr. Pr. Consultant at FuseSource.com > Twitter : @cmoulliard > Blog : http://cmoulliard.blogspot.com >
