I think we need to take a step back and define some requirements. One
that I'm aware of is the ability to wire up beans, something that Drools
(in particular, though this is a generally useful feature) needs to be
able to provide proper CDI support.
On 18/09/12 07:17, Jason Porter wrote:
Though it doesn't seem like everyone is in agreement as to what this
feature should include, it certainly sounds like we can move forward with
what was in Seam 3 and add / remove features as needed. Does that sound
about right?
On Tue, Sep 11, 2012 at 4:24 AM, Romain Manni-Bucau
<[email protected]>wrote:
yes but code will become harder if you are not a weld/candi or owb dev
since you'll not know where you beans comes from.
you'll not be able to grep java files as expected
Another point is the format is not logical since inject doesnt decorate the
bean but is nested into it
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
2012/9/11 Bernard Łabno <[email protected]>
Ok, let's consider
http://it-crowd.com.pl/svn/seam3-persistence-framework/trunk/framework/src/main/java/pl/com/it_crowd/seam/framework/converter/EntityConverter.java
It's part of seam3-persistence-framework (itcrowd's port of seam2
persistence framework).
Entity converter needs EntityManager to load entity from DB by id.
Currently all I need to do is to attach seam3-persistence-framewor.jar to
my application and
add following lines to seam-beans.xml:
<pf-converter:EntityConverter>
<pf-converter:entityManager>
<s:Inject/>
</pf-converter:entityManager>
<s:modifies/>
</pf-converter:EntityConverter>
I know that I could write @Produces method, but I like this way. It's
also
cool to turn some bean from non CDI library into CDI bean simply with 1
line of XML config.
Other sample:
<app-config:PBESpecImpl
algorithmJNDI="java:/appName/encryption/algorithm"
iterationCountJNDI="java:/appName/encryption/iterationCount"
passwordJNDI="java:/appName/encryption/password"
saltJNDI="java:/appName/encryption/salt">
<s:modifies/>
</app-config:PBESpecImpl>
Do all servers have same JNDI patterns so I could hardcode it? Even if so
PBESpecImpl is part of library that is being attached to many projects
where each project wants different JNDI locations for particular config.
2012/9/11 Mehdi Heidarzadeh <[email protected]>
We have some developers who like xml and some who hate xml and that
might
be because of different tastes or background when working with XML in
the
past or what ever.
I think configuration with both xml and property files are ok, because
some
developers like property files and some like annotations and some xml
and
some of them like combination of them like me ;)
I hate *writing* *code* using XML (like mapping entities, it's kind of
writing code using xml) but I like configuring *application
configuration*with xml or property files, because I can change them in
deploy time
depending on deployment environment without any compilation.
when you ask someone about XML vs annotation vs ...? I think the answer
will depend on the taste and background of that developer.
Since seam3 has xml configuration and DS can reuse it, why not
providing
xml configuration feature too, and letting the developer to choose
which
one to use? producer methods vs xml vs property file?
On Tue, Sep 11, 2012 at 6:40 AM, Marius Bogoevici <
[email protected]> wrote:
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
implementation, rather than producing a code template that would be
copied
and pasted around. I understand that all of us can master the fine
points
of writing an extension, but a configurable solution may be easier
for
the
average developer.
On 7 Sep 2012, at 22:31, Romain Manni-Bucau 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
--
Mehdi Heidarzadeh Ardalani
Independent JEE Consultant, Architect and Developer.
http://www.TheBigJavaBlog.com
