If you find elegant way to do everything that can be currently done then it's cool not to use XML, but if we won't be able to i.e. configure bean properties between compilation and deployment then it will be great disappointment.
2012/9/10 Charles Moulliard <[email protected]> > I would prefer that we avoid to use XML. Otherwise, end users will be > confused about what a CDI / CDI Extension should looks like and why we are > moving one step down to do what Spring / Xbean are doing. > > On Fri, Sep 7, 2012 at 11:31 PM, Romain Manni-Bucau > <[email protected]>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://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 > > > > > > > > > -- > Charles Moulliard > Apache Committer / Sr. Pr. Consultant at FuseSource.com > Twitter : @cmoulliard > Blog : http://cmoulliard.blogspot.com >
