I think that a more formal list like we had on the wiki for security,
exceptions or messages [1] might be the way to go. That way everyone
can contribute to it so that we have an authorative declaration of
requirements before proceeding with any development work.
[1] https://cwiki.apache.org/confluence/display/DeltaSpike/Drafts
On 18/09/12 09:06, Jason Porter wrote:
That works for me, shall we start a new thread or continue with this one?
On Mon, Sep 17, 2012 at 4:40 PM, Shane Bryzak <[email protected]
<mailto:[email protected]>> wrote:
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] <mailto:[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]
<mailto:[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]
<mailto:[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]
<mailto:[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]
<mailto:[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
<http://keyserver.net>,
pgp.mit.edu <http://pgp.mit.edu>
--
Mehdi Heidarzadeh Ardalani
Independent JEE Consultant, Architect and Developer.
http://www.TheBigJavaBlog.com
--
Jason Porter
http://lightguard-jp.blogspot.com
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 <http://keyserver.net>,
pgp.mit.edu <http://pgp.mit.edu>
