6:26 p.m.
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@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(a)gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
>