[webbeans-dev] Re: XML configuration format

[Jim Knutson]

Scott Ferguson <ferg at caucho.com> wrote on 01/07/2009 04:13:11 PM:
> 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

You have it backwards.  I was expecting that a schema describing this
spec's metadata be imported into the EJB JAR schema so that components
can be decorated with the metadata they need.  It is (was?) how web service
metadata is handled.

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

I think pretty much everything is moving to the JAXB rules.  The
JAXRPC rules were not sufficient for all cases.

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

I'm not understanding the nuances here, but I'll try to dig deeper
to see if I get it.  To me refs are refs and if some of them happen
to resolve to instances with a context based lifecycle, so be it.
It's how I would expect platform integration to work.  If there's
refs and then there's something else which is similar, but not the
same, then I think we have a problem.  It goes back to the
issue of perceiving arbitrary differences that is so frustrating
when trying to learn something.

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

If you consider all of JAXB, yes, it's solving a different problem,
but JAXB already defines a full Java-XML schema mapping based on
quite a bit of experience.  It would be a mistake not to consider
the JAXB mapping rules and come up with an arbitrarily different
set and different tools required to perform that mapping.

Thanks,
Jim Knutson
WebSphere J2EE Architect
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20090107/a6a0c5a4/attachment.html