[webbeans-dev] RE: XML configuration format
Michael Keith
MICHAEL.KEITH at oracle.com
Tue Dec 23 13:42:46 EST 2008
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
> >>
> >
> >
>
>
More information about the weld-dev
mailing list