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