[webbeans-dev] Re: XML configuration format

Tue Dec 23 18:43:59 EST 2008

What I think we should focus on here is whether the difference in  
styles is going to be confusing to users, and whether the web beans  
style of descriptor is more difficult to understand and use.

I dont think that the fact that the XML format proposed by the PDR is  
a different style is, alone, a good enough reason to reject it. EE  
already has a number of metadata formats, both XML and annotations,  
and each requires the user to learn it individually. There's not  
really anything much in the way of portable knowledge/skills between  
writing web.xml and orm.xml and faces-config.xml.

What I want to know is whether there are specific reasons why the  
current proposal is going to cause serious confusion or ease of use  
issues.

Sent from my iPhone

On Dec 24, 2008, at 9:41 AM, Scott Ferguson <ferg at caucho.com> wrote:

>
> On Dec 23, 2008, at 2:16 PM, Michael Keith wrote:
>
>>
>> I really assumed that members of this group (that were supposed to be
>> integrating 2 Java EE technologies) knew what Java EE XML descriptors
>> looked like, but for Scott and any others that either don't know  
>> them,
>> or don't recognize what the differences are, here is a short list:
>
>> Java EE - standard pre-defined namespaces and schemas
>> WebBeans - application-defined namespaces (and possibly schemas)
>>
>> Java EE - standard XML styled element names
>> WebBeans - Java class/code-based elements
>>
>> Java EE - pre-defined structure
>> WebBeans - open-ended structure based on application
>>
>> Java EE - all elements are assigned specific semantics
>> WebBeans - context and extensive rule set governs what an element  
>> means
>>
>> Java EE - values typically stored as element content
>> WebBeans - elements themselves are data (so are often empty)
>
> Thank you.
>
> FYI, since I've implemented a good chunk of the JavaEE specs over  
> the last decade, including multiple EJB and Servlet versions, I'm  
> fully aware of the content of the current XML descriptors.  The main  
> question was which differences you were concerned about.
>
> -- Scott
>
>>
>>
>>> Without any reference point about what bothers you with the WebBeans
>>> format, it's difficult to have any meaningful discussion.  I
>>> gave you
>>> an example to allow a concrete discussion about the major problems
>>> that are bothering you.
>>
>> Again, it has nothing to do with what is good and what isn't, it is
>> all about the fact that if this is to be a platform technology then
>> it needs to be developed with the platform in mind.
>>
>>>>
>>>>
>>>>> -----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
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>