Scott Ferguson <ferg(a)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