@ 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> >>> >> >> >> >> > >
