<html><body>
<p><tt>Scott Ferguson <ferg@caucho.com> wrote on 01/07/2009 04:13:11 PM:<br>
> On Jan 7, 2009, at 1:16 PM, Jim Knutson wrote:</tt><br>
<tt>> <br>
> As Mike has mentioned, I also prefer platform consistency and if there's<br>
> a problem with the platform view, we should fix it for the platform.<br>
> <br>
> Let me throw out some potentials here:<br>
> <br>
> * There is a general pattern existing in the platform today for sharing<br>
> schemas across the technologies. Web services, servlets, ejbs, and I<br>
> believe JCA Adapters all use this. Given that this metadata is likely<br>
> to be shared across multiple technologies, it might be worth looking<br>
> at reusing the platform schema sharing mechanism to encorporate the <br>
> metadata into existing platform DDs. This further emphasises the <br>
> fact that this spec. is using the existing platform component model<br>
> to enhance it. </tt><br>
<tt>> To be clear, the specifics that you're proposing are:</tt><br>
<tt>> <br>
> 1. <web-beans xmlns="http://java.sun.com/xml/ns/javaee"></tt><br>
<tt>> <br>
> 2. Import the <ejb-ref>, <message-ref>, etc. syntax into the web-beans.xml</tt><br>
<br>
<tt>You have it backwards. I was expecting that a schema describing this</tt><br>
<tt>spec's metadata be imported into the EJB JAR schema so that components</tt><br>
<tt>can be decorated with the metadata they need. It is (was?) how web service </tt><br>
<tt>metadata is handled.</tt><br>
<tt><br>
> For #1, it's important to remember that the official namespace has <br>
> changed in almost every version of the JavaEE specs. So it's not <br>
> accurate to say JavaEE has a history of consistent namespaces.</tt><br>
<tt>> <br>
> Long term, the reverse would be better, i.e. use the WebBeans <br>
> namespace style instead of the older JavaEE style. For JavaEE, a <br>
> big advantage would be making JavaEE configuration more modular and <br>
> extensible. For example:</tt><br>
<tt>> <br>
> <web-app xmlns="urn:java:javax.servlet" </tt><br>
<tt>> xmlns:javaee="urn:java:javax.javaee"</tt><br>
<tt>> xmlns:ejb="urn:java:javax.ejb"</tt><br>
<tt>> xmlns:jms="urn:java:javax.jms"></tt><br>
<tt>> <br>
> <javaee:resource-ref> ...</tt><br>
<tt>> <javaee:env-entry>...</tt><br>
<tt>> <ejb:ejb-ref> ...</tt><br>
<tt>> <jms:message-destination-ref> ...</tt><br>
<tt>> <br>
> </web-app></tt><br>
<tt>> <br>
> I'd love to see the above change happen in JavaEE 6 as a platform-<br>
> wide, consistent, modular naming scheme.</tt><br>
<br>
<tt>I think pretty much everything is moving to the JAXB rules. The</tt><br>
<tt>JAXRPC rules were not sufficient for all cases.</tt><br>
<tt><br>
> For #2, if the modularity in #1 were adopted, then you'd solve #2 <br>
> automatically. Otherwise, #2 is a bit odd, because those ejb-ref, <br>
> message-ref, etc really should be designed as a layer on top of <br>
> JavaEE IoC. The ejb-ref, etc should not be peers of WebBeans, they <br>
> should be layered on top of it.</tt><br>
<br>
<tt>I'm not understanding the nuances here, but I'll try to dig deeper</tt><br>
<tt>to see if I get it. To me refs are refs and if some of them happen</tt><br>
<tt>to resolve to instances with a context based lifecycle, so be it.</tt><br>
<tt>It's how I would expect platform integration to work. If there's</tt><br>
<tt>refs and then there's something else which is similar, but not the</tt><br>
<tt>same, then I think we have a problem. It goes back to the </tt><br>
<tt>issue of perceiving arbitrary differences that is so frustrating</tt><br>
<tt>when trying to learn something.</tt><br>
<tt><br>
> * Any Java-XML mappings should not be defined by this spec. JAXB already<br>
> covers appropriate Java-XML mappings and we shouldn't define anything<br>
> different. It's a pain to do and get it right for all cases.</tt><br>
<tt>> It would be a mistake to use JAXB, because JAXB is solving a <br>
> different problem: general XML/Java serialization as opposed to XML <br>
> configuration. A hammer is not appropriate for every task, and <br>
> specifically, the semantics of configuration do not match the <br>
> semantics of deserialization. No one is proposing that the XML <br>
> configuration be a general Java deserialization specification. In <br>
> this situation, the semantics are sufficiently different that each <br>
> spec should focus on its core needs and not try to overgeneralize.</tt><br>
<br>
<tt>If you consider all of JAXB, yes, it's solving a different problem,</tt><br>
<tt>but JAXB already defines a full Java-XML schema mapping based on</tt><br>
<tt>quite a bit of experience. It would be a mistake not to consider</tt><br>
<tt>the JAXB mapping rules and come up with an arbitrarily different</tt><br>
<tt>set and different tools required to perform that mapping.</tt><br>
<tt><br>
Thanks,<br>
Jim Knutson<br>
WebSphere J2EE Architect</tt><br>
<br>
</body></html>