[webbeans-dev] Re: XML configuration format

Scott Ferguson ferg at caucho.com
Wed Jan 7 17:13:11 EST 2009 

On Jan 7, 2009, at 1:16 PM, Jim Knutson wrote:

> As Mike has mentioned, I also prefer platform consistency and if  
> there's
> a problem with the platform view, we should fix it for the platform.
>
> Let me throw out some potentials here:
>
> * There is a general pattern existing in the platform today for  
> sharing
>   schemas across the technologies.  Web services, servlets, ejbs,  
> and I
>   believe JCA Adapters all use this.  Given that this metadata is  
> likely
>   to be shared across multiple technologies, it might be worth looking
>   at reusing the platform schema sharing mechanism to encorporate the
>   metadata into existing platform DDs.  This further emphasises the
>   fact that this spec. is using the existing platform component model
>   to enhance it.
>
To be clear, the specifics that you're proposing are:

1. <web-beans xmlns="http://java.sun.com/xml/ns/javaee">

2. Import the <ejb-ref>, <message-ref>, etc. syntax into the web- 
beans.xml

For #1, it's important to remember that the official namespace has  
changed in almost every version of the JavaEE specs.  So it's not  
accurate to say JavaEE has a history of consistent namespaces.

Long term, the reverse would be better, i.e. use the WebBeans  
namespace style instead of the older JavaEE style.  For JavaEE, a big  
advantage would be making JavaEE configuration more modular and  
extensible.  For example:

   <web-app xmlns="urn:java:javax.servlet"
                      xmlns:javaee="urn:java:javax.javaee"
                      xmlns:ejb="urn:java:javax.ejb"
                      xmlns:jms="urn:java:javax.jms">

     <javaee:resource-ref> ...
     <javaee:env-entry>...
     <ejb:ejb-ref> ...
     <jms:message-destination-ref> ...

   </web-app>

I'd love to see the above change happen in JavaEE 6 as a platform- 
wide, consistent, modular naming scheme.

For #2, if the modularity in #1 were adopted, then you'd solve #2  
automatically.  Otherwise, #2 is a bit odd, because those ejb-ref,  
message-ref, etc really should be designed as a layer on top of JavaEE  
IoC.  The ejb-ref, etc should not be peers of WebBeans, they should be  
layered on top of it.
>
> * The implication of the above doesn't preclude the use of a unique
>   namespaces, but the default should probably be a platform namespace
>   for the well known cases.
>
Somewhat.  As in my example above, it would be even better if the  
shared JavaEE elements had their own namespace that didn't conflict  
with the servlet, ejb, jca, webbeans, etc namespaces.  That change  
would clean up the entire platform and make it more modular, without  
losing any generality or power.

And, since the JavaEE namespace does change with each version, there's  
no real barrier to this proposal.
> * Any Java-XML mappings should not be defined by this spec.  JAXB  
> already
>   covers appropriate Java-XML mappings and we shouldn't define  
> anything
>   different.  It's a pain to do and get it right for all cases.
>
It would be a mistake to use JAXB, because JAXB is solving a different  
problem: general XML/Java serialization as opposed to XML  
configuration.  A hammer is not appropriate for every task, and  
specifically, the semantics of configuration do not match the  
semantics of deserialization.  No one is proposing that the XML  
configuration be a general Java deserialization specification.  In  
this situation, the semantics are sufficiently different that each  
spec should focus on its core needs and not try to overgeneralize.

> I'm going to have to dig deeper to fully understand the metadata and
> Java-XML mappings, but I'm assuming the only real need for this is to
> incorporate extensibility into the XML instances for programmer  
> defined
> stereotypes.
>
No, it's far bigger than that.  It's central to the whole IoC concept  
and capabilities of the spec.

-- Scott
>
>
> Thanks,
> Jim Knutson
> WebSphere J2EE Architect
>
> Scott Ferguson <ferg at caucho.com> wrote on 12/21/2008 09:58:08 AM:
>
> >
> > On Dec 20, 2008, at 10:12 PM, Gavin King wrote:
> >
> > > 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 love the new format.  The urn:java:package namespace is brilliant,
> > to the extent that I'd go postal if it reverted to the earlier  
> draft.
> > Among other advantages, it makes the XML so much more readable by
> > emphasizing the bean's name.  The name change to <foo-bar> would  
> be a
> > good change, for consistency.
> >
> > Specifically, I just went through the process of changing our  
> security
> > tag/bean configuration to the new format, and the improvement is
> > dramatic.  With the new format, the XML expresses exactly what the
> > configuration means, and with no extraneous verbiage.  It's  
> brilliant.
> >
> > There are a few things that I'd like tweaked, though:
> >
> >    1) The inline bean vs property needs to be simplified.  (9.5
> > injection point declarations), specifically the existence of a child
> > element should not affect the parsing.  Instead, it should follow  
> the
> > method model (9.2.6) where "has a direct child <Initializer>, ...,  
> or
> > binding type."  9.5 should be rewritten as:
> >
> >       a) If the Java type is a parameterized type .... is a type
> > declaration
> >       b) Otherwise if ... binding type ... is a type declaration
> >       c) Otherwise, the injection point declaration is an inline Web
> > Bean declaration, and the declared type ...
> >
> > i.e. removing the old 3rd rule because it was making things more
> > confusing.  The slight extra verbosity by requiring <Current/> for  
> an
> > injected type is outweighed by the simplification, and consistency
> > with 9.2.6.
> >
> > The specific problem is: when does an XML element refer to a type  
> and
> > when does it refer to a bean to be instantiated (9.6 vs 9.7), which
> > isn't obvious from the spec (it's well-defined, but can be  
> simplified.)
> >
> >    2) Property injection (bean-style setters) really need to be
> > supported.  The bean pattern is historic and embedded in essentially
> > all specifications, so it's not really something WebBeans can avoid.
> > Aside from the historic value, property injection lets you validate
> > input easily at the configuration point, which is very nice.
> >
> >    3) Argument vs field is somewhat visually confusing.  The spec
> > logic works, but it's easy to confuse a constructor arg for a field
> > and waste time.  I'm not sure it needs to be changed, but  
> something to
> > think about.  You could have field/property as <myapp:foo-bar> and
> > types/annotations as <myapp:FooBar> or add an <arg> (I'm not sure
> > these are good ideas or even if there needs to be a change.  I'm  
> just
> > throwing the idea out.)
> >
> >    4) Annotation declaration is great.  I would like the ability to
> > add non-webbeans annotations (for service declarations/ 
> introspection),
> > but that non-critical and could certainly be put off until a later  
> spec.
> >
> > -- Scott
> >
> > >
> > >
> > > 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
> > >
> > >
> >
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20090107/d05bbcc9/attachment.html

More information about the weld-dev mailing list