[webbeans-dev] Re: XML configuration format

[Scott Ferguson]

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