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* > > > > > 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 > > 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://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
