<html><body>
<p><tt>As Mike has mentioned, I also prefer platform consistency and if there's</tt><br>
<tt>a problem with the platform view, we should fix it for the platform.</tt><br>
<br>
<tt>Let me throw out some potentials here:</tt><br>
<br>
<tt>* There is a general pattern existing in the platform today for sharing</tt><br>
<tt> schemas across the technologies. Web services, servlets, ejbs, and I</tt><br>
<tt> believe JCA Adapters all use this. Given that this metadata is likely</tt><br>
<tt> to be shared across multiple technologies, it might be worth looking</tt><br>
<tt> at reusing the platform schema sharing mechanism to encorporate the </tt><br>
<tt> metadata into existing platform DDs. This further emphasises the </tt><br>
<tt> fact that this spec. is using the existing platform component model</tt><br>
<tt> to enhance it. </tt><br>
<tt>* The implication of the above doesn't preclude the use of a unique</tt><br>
<tt> namespaces, but the default should probably be a platform namespace</tt><br>
<tt> for the well known cases.</tt><br>
<tt>* Any Java-XML mappings should not be defined by this spec. JAXB already</tt><br>
<tt> covers appropriate Java-XML mappings and we shouldn't define anything</tt><br>
<tt> different. It's a pain to do and get it right for all cases.</tt><br>
<br>
<tt>I'm going to have to dig deeper to fully understand the metadata and</tt><br>
<tt>Java-XML mappings, but I'm assuming the only real need for this is to</tt><br>
<tt>encorporate extensibility into the XML instances for programmer defined</tt><br>
<tt>stereotypes.</tt><br>
<tt><br>
Thanks,<br>
Jim Knutson<br>
WebSphere J2EE Architect</tt><br>
<br>
<tt>Scott Ferguson <ferg@caucho.com> wrote on 12/21/2008 09:58:08 AM:<br>
<br>
> <br>
> On Dec 20, 2008, at 10:12 PM, Gavin King wrote:<br>
> <br>
> > I would like to open up a discussion about the XML format defined in <br>
> > chapter 10.<br>
> ><br>
> > Mike is concerned that the XML format is different to the style used<br>
> > in other Java EE specifications, where class/method names are<br>
> > generally specified as strings in the body of XML elements, and that<br>
> > the XML format may turn out to be confusing to users.<br>
> ><br>
> > On the other hand, the format currently defined by the specification<br>
> > is typesafe, allowing tooling to provide validation and<br>
> > auto-completion of all class/method names, and is also less verbose.<br>
> > It's also consistent with the approach used by existing solutions in<br>
> > the spec (Spring, Seam).<br>
> ><br>
> > I've recently discovered that it's possible to write a Java 6<br>
> > Processor that would generate the XML schema for a package containing<br>
> > web beans as part of the compilation process. (This is an awesome new<br>
> > feature of javac, that used to be provided by the APT plugin.)<br>
> ><br>
> > One possible path to take would be to use hyphenated names in the XML<br>
> > (i.e. <foo-bar> instead of <FooBar>) to make the XML more visually<br>
> > consistent with other EE descriptors.<br>
> <br>
> I love the new format. The urn:java:package namespace is brilliant, <br>
> to the extent that I'd go postal if it reverted to the earlier draft. <br>
> Among other advantages, it makes the XML so much more readable by <br>
> emphasizing the bean's name. The name change to <foo-bar> would be a <br>
> good change, for consistency.<br>
> <br>
> Specifically, I just went through the process of changing our security <br>
> tag/bean configuration to the new format, and the improvement is <br>
> dramatic. With the new format, the XML expresses exactly what the <br>
> configuration means, and with no extraneous verbiage. It's brilliant.<br>
> <br>
> There are a few things that I'd like tweaked, though:<br>
> <br>
> 1) The inline bean vs property needs to be simplified. (9.5 <br>
> injection point declarations), specifically the existence of a child <br>
> element should not affect the parsing. Instead, it should follow the <br>
> method model (9.2.6) where "has a direct child <Initializer>, ..., or <br>
> binding type." 9.5 should be rewritten as:<br>
> <br>
> a) If the Java type is a parameterized type .... is a type <br>
> declaration<br>
> b) Otherwise if ... binding type ... is a type declaration<br>
> c) Otherwise, the injection point declaration is an inline Web <br>
> Bean declaration, and the declared type ...<br>
> <br>
> i.e. removing the old 3rd rule because it was making things more <br>
> confusing. The slight extra verbosity by requiring <Current/> for an <br>
> injected type is outweighed by the simplification, and consistency <br>
> with 9.2.6.<br>
> <br>
> The specific problem is: when does an XML element refer to a type and <br>
> when does it refer to a bean to be instantiated (9.6 vs 9.7), which <br>
> isn't obvious from the spec (it's well-defined, but can be simplified.)<br>
> <br>
> 2) Property injection (bean-style setters) really need to be <br>
> supported. The bean pattern is historic and embedded in essentially <br>
> all specifications, so it's not really something WebBeans can avoid. <br>
> Aside from the historic value, property injection lets you validate <br>
> input easily at the configuration point, which is very nice.<br>
> <br>
> 3) Argument vs field is somewhat visually confusing. The spec <br>
> logic works, but it's easy to confuse a constructor arg for a field <br>
> and waste time. I'm not sure it needs to be changed, but something to <br>
> think about. You could have field/property as <myapp:foo-bar> and <br>
> types/annotations as <myapp:FooBar> or add an <arg> (I'm not sure <br>
> these are good ideas or even if there needs to be a change. I'm just <br>
> throwing the idea out.)<br>
> <br>
> 4) Annotation declaration is great. I would like the ability to <br>
> add non-webbeans annotations (for service declarations/introspection), <br>
> but that non-critical and could certainly be put off until a later spec.<br>
> <br>
> -- Scott<br>
> <br>
> ><br>
> ><br>
> > I would like to get everyone's thoughts on this issue:<br>
> ><br>
> > Do you like the existing format?<br>
> > Do you find it confusing? In what way?<br>
> > Have you used this approach in Spring or Seam? If so, how did it <br>
> > compare?<br>
> > How important is typesafety?<br>
> ><br>
> > -- <br>
> > Gavin King<br>
> > gavin.king@gmail.com<br>
> > <a href="http://in.relation.to/Bloggers/Gavin">http://in.relation.to/Bloggers/Gavin</a><br>
> > <a href="http://hibernate.org">http://hibernate.org</a><br>
> > <a href="http://seamframework.org">http://seamframework.org</a><br>
> ><br>
> ><br>
> <br>
</tt></body></html>