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 ch0...@gmail.com
I would prefer that
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*
2012/9/10 Bernard Łabno s4...@pjwstk.edu.pl
If you find elegant way to do
Generally 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
All,
Sorry for the late reply, but I was on vacation so I just got to catch
up with some of my emails.
Indeed, I would very much like us to include Spring/CDI integration in
v0.4. and, of course, start working on it some time in September (along
with anyone who is interested to contribute
It is prudent to provide something similar to what Seam Solder provided. As
Marius says, there needs to be a path for legacy apps to migrate to CDI
without recompilation of libraries.
The XML config can be a low priority task and probably the documentation
should be hidden away from the main
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
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
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
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
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
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 ch0...@gmail.com
You can use Config-Source of DeltaSpike to override jndi location (see this
page :
Mark Struberg
11 September 2012
1:59 AM
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
I hate xml simply because it is too verbose.
Imo config on top of cdi is not the right place. It will often be over
engineered.
Properties will often be enough IMO (class name. Attribute = value for
instance)
Le 11 sept. 2012 01:31, Stuart Douglas sdoug...@redhat.com a écrit :
Mark
On 2012-09-10 8:25 AM, Pete Muir wrote:
This is what I would use non-compiled resources for as well.
If I needed to CDI-enable some code without using annotations, I would use the
portable extension API directly.
Yes and no. In my opinion this is generic enough to warrant a
configurable
14 matches
Mail list logo
