agree.
We shall also identify all features which are non-portable in CDI-1.0 LieGrue, strub ----- Original Message ----- > From: Gerhard Petracek <[email protected]> > To: [email protected] > Cc: > Sent: Tuesday, September 18, 2012 10:38 AM > Subject: Re: XML Config > > @ shane: +1 > > regards, > gerhard > > > > 2012/9/18 Shane Bryzak <[email protected]> > >> Oh, and just to be clear I think we should by all means discuss the >> required features on the mailing list first, we just need to ensure that >> any features we agree upon are collated on the wiki. >> >> >> On 18/09/12 18:07, Shane Bryzak wrote: >> >>> 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<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<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<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:marius.bogoevici@**gmail.com > <[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:lightguard.jp@gmail.**com > <[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://lightguard-jp.blogspot.com> >>>> > >>>> >>>> http://twitter.com/****lightguardjp > <http://twitter.com/**lightguardjp>< >>>> >>>> > 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://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> >>>> >>> >>> >>> >>> >> >> >
