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]> 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]>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]> >>> >>> 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]> >>>> >>>> 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://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, 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, pgp.mit.edu
