deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Moulliard <ch0...@gmail.com>
Subject Re: XML Config
Date Mon, 10 Sep 2012 19:35:32 GMT
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 <s4237@pjwstk.edu.pl> 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 <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
> >>>>>>
> >>>>>>
> >
>



-- 
Charles Moulliard
Apache Committer / Sr. Pr. Consultant at FuseSource.com
Twitter : @cmoulliard
Blog : http://cmoulliard.blogspot.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message