That works for me. I'll start another thread today to kick things off. Sent from my iPhone
On Sep 18, 2012, at 6:44, Mark Struberg <[email protected]> wrote: > 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> >>>>> >>>> >>>> >>>> >>>> >>> >>> >>
