[webbeans-dev] RE: XML configuration format

[Michael Keith]

Scott, 

I'm sorry, but I think you missed the point. My intent was not to offer a 
technical criticism of the currently specified XML format. There are some
things that I like and dislike about it, but I purposely did not mention
them so that I could focus on the architectural issues of creating such a 
different XML schema design. That is also why I needed to clarify Gavin's 
message, which tended people toward a technical evaluation.

> -----Original Message-----
> From: Scott Ferguson [mailto:ferg at caucho.com]
> Sent: Tuesday, December 23, 2008 12:26 PM
> To: Michael Keith
> Cc: Gavin King; Java Community Process JSR #299 Expert List; Jim
> Knutson; Matt Drees; WebBeans
> Subject: Re: XML configuration format
> 
> 
> 
> On Dec 22, 2008, at 10:01 AM, Michael Keith wrote:
> 
> >
> > Just to give a bit more context to this issue:
> >
> > One of the big advantages that Java EE has over the 
> collective set of
> > random technology bits and pieces that some people cobble together  
> > and use
> > to write applications with, is that it is a consistent group of  
> > cohesive
> > technologies that share common terminology, resource definitions,  
> > development
> > and configuration practices, and many other aspects of application
> > development. This is a huge strength, and contributes to increased  
> > portability
> > of both applications and developer experience.
> 
> Can you give a specific example of Java EE XML configuration 
> that you  
> think is superior to the WebBeans format?  Or a specific 
> change in the  
> WebBeans syntax that you prefer?
> 
> Historically, the XML syntax has been the weakest part of 
> JavaEE.  The  
> JCA ra.xml is terrible.  The ejb-jar.xml is bad from top to bottom.   
> The <*-ref> are essentially pointless.  It's not clear what 
> the value  
> is of following poor design.
> 
> The cleanest XML configuration in JavaEE is the web.xml from 
> servlets  
> (minus the JavaEE <*-ref> cruft), and even that is extremely dated  
> because the servlet spec was designed before schema, and the 
> designers  
> were apparently unaware that XML has an attribute syntax.
> 
> If a servlet configuration were rewritten in a WebBeans style, it  
> would look like the following:
> 
>    <quercus:QuercusServlet>
>      <servlet:ServletMapping url-pattern="*.php"/>
> 
>      <quercus:compile>true</quercus:compile>
>    </quercus:QuercusServlet>
> 
> I'd argue that the WebBeans-style servlet configuration is 
> superior to  
> the traditional JavaEE in every way:
> 
>   1) The package and class of the servlet itself are prominent;  
> they're the first thing you scan.  Since that class name is the most  
> important aspect of the servlet, having it as the tag name greatly  
> enhances readability.  The traditional JavaEE configuration 
> hides the  
> most important information deep in an XML tree, buried by 
> boilerplate  
> XML tags.
> 
>   2) Zero housekeeping cruft.  Every element and attribute in my  
> example is meaningful.
> 
>   3) Full DI/IoC configuration, i.e. the servlet is no longer 
> limited  
> to the decade-old init-param limitations.   I used a boolean, but  
> could have configured any arbitrarily complex configuration. In  
> addition, because the configuration is injected to the servlet, the  
> old getConfigAttribute(...) cruft in the servlet code goes away.
> 
>   4) Tight mirroring between the annotation view and XML view (the  
> "type safety" of WebBeans).  The servlet:ServletMapping tells you  
> exactly where to look in the JavaDoc to understand the code.   The  
> quercus:QuercusServlet and quercus:compile are also in their JavaDoc.
> 
> If you've got specific criticisms of this model, it would be  
> interesting to hear.  Unfortunately, your previous comment was vague  
> and lacking in any specifics, so not particularly useful.
> 
> -- Scott
> 
> >
> >
> > Keeping the platform consistent does not imply stagnancy 
> because of  
> > the way
> > "older" technologies work. New technologies may still 
> emerge to join  
> > the EE fold,
> > but if they introduce something new in an area that existing EE  
> > specs already
> > participate in and make use of then the new and more useful 
> approach  
> > should be
> > introduced to the existing specs as well. Annotations is a good  
> > example, where
> > they began being used in the EJB 3.0 round, but were soon 
> pushed up  
> > into the
> > platform and EE spec, and are now in every other EE 
> sub-spec as well.
> >
> > So, while I see that there are strengths and weaknesses to the XML  
> > style that
> > is currently described in the spec, it is so different from every  
> > other existing
> > XML descriptor in Java EE that the platform suffers and 
> there is no  
> > sharing of
> > experience. On the contrary, it requires learning new and 
> different  
> > conventions,
> > all in the context of trying to make this a bona fide Java EE  
> > technology.
> >
> > On the other hand, if the options are weighed and the majority of  
> > the platform
> > stakeholders are in agreement with this group that Java-driven XML  
> > really is a better
> > approach, then these rules and styles should be propagated to the  
> > entire platform,
> > with an agreed-upon plan to bring that about.
> >
> > -Mike
> >
> >> -----Original Message-----
> >> From: Gavin King [mailto:gavin at hibernate.org]
> >> Sent: Sunday, December 21, 2008 1:13 AM
> >> To: Java Community Process JSR #299 Expert List; Jim 
> Knutson; Michael
> >> Keith; Matt Drees; Scott Ferguson; WebBeans
> >> Subject: XML configuration format
> >>
> >>
> >> I would like to open up a discussion about the XML format
> >> defined in chapter 10.
> >>
> >> Mike is concerned that the XML format is different to the 
> style used
> >> in other Java EE specifications, where class/method names are
> >> generally specified as strings in the body of XML 
> elements, and that
> >> the XML format may turn out to be confusing to users.
> >>
> >> On the other hand, the format currently defined by the 
> specification
> >> is typesafe, allowing tooling to provide validation and
> >> auto-completion of all class/method names, and is also 
> less verbose.
> >> It's also consistent with the approach used by existing 
> solutions in
> >> the spec (Spring, Seam).
> >>
> >> I've recently discovered that it's possible to write a Java 6
> >> Processor that would generate the XML schema for a package 
> containing
> >> web beans as part of the compilation process. (This is an 
> awesome new
> >> feature of javac, that used to be provided by the APT plugin.)
> >>
> >> One possible path to take would be to use hyphenated names 
> in the XML
> >> (i.e. <foo-bar> instead of <FooBar>) to make the XML more visually
> >> consistent with other EE descriptors.
> >>
> >> I would like to get everyone's thoughts on this issue:
> >>
> >> Do you like the existing format?
> >> Do you find it confusing? In what way?
> >> Have you used this approach in Spring or Seam? If so, how did
> >> it compare?
> >> How important is typesafety?
> >>
> >> -- 
> >> Gavin King
> >> gavin.king at gmail.com
> >> http://in.relation.to/Bloggers/Gavin
> >> http://hibernate.org
> >> http://seamframework.org
> >>
> >
> >
> 
>