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
