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 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(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org

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 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(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org

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(a)gmail.com > http://in.relation.to/Bloggers/Gavin > http://hibernate.org > http://seamframework.org > >

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

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.

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

On Thu, Jan 8, 2009 at 11:01 AM, Jim Knutson <knutson(a)us.ibm.com&gt; wrote: > 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

> metadata is handled. This is not what we've defined currently.

On Thu, Jan 8, 2009 at 8:16 AM, Jim Knutson <knutson(a)us.ibm.com&gt; wrote: > * Any Java-XML mappings should not be defined by this spec. JAXB

> 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. JAXB is not appropriate for the problem of component configuration and is not intended for that usecase. It's two different things. The XML format defined by web beans fills the same ecological niche as Spring configuration files - which, whether you love 'em or hate 'em are a phenomenally successful species of XML.

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.

Just to give a bit more context to this issue: One of the big advantages that Java EE has over the collective set of random technology bits and pieces that some people cobble together and use to write applications with, is that it is a consistent group of cohesive technologies that share common terminology, resource definitions, development and configuration practices, and many other aspects of application development. This is a huge strength, and contributes to increased portability of both applications and developer experience.

Keeping the platform consistent does not imply stagnancy because of the way "older" technologies work. New technologies may still emerge to join the EE fold, but if they introduce something new in an area that existing EE specs already participate in and make use of then the new and more useful approach should be introduced to the existing specs as well. Annotations is a good example, where they began being used in the EJB 3.0 round, but were soon pushed up into the platform and EE spec, and are now in every other EE sub-spec as well. So, while I see that there are strengths and weaknesses to the XML style that is currently described in the spec, it is so different from every other existing XML descriptor in Java EE that the platform suffers and there is no sharing of experience. On the contrary, it requires learning new and different conventions, all in the context of trying to make this a bona fide Java EE technology. On the other hand, if the options are weighed and the majority of the platform stakeholders are in agreement with this group that Java-driven XML really is a better approach, then these rules and styles should be propagated to the entire platform, with an agreed-upon plan to bring that about. -Mike > -----Original Message----- > From: Gavin King [mailto:gavin@hibernate.org] > Sent: Sunday, December 21, 2008 1:13 AM > To: Java Community Process JSR #299 Expert List; Jim Knutson; Michael > Keith; Matt Drees; Scott Ferguson; WebBeans > Subject: XML configuration format > > > 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 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(a)gmail.com > http://in.relation.to/Bloggers/Gavin > http://hibernate.org > http://seamframework.org >

Scott, I'm sorry, but I think you missed the point. My intent was not to offer a technical criticism of the currently specified XML format. There are some things that I like and dislike about it, but I purposely did not mention them so that I could focus on the architectural issues of creating such a different XML schema design. That is also why I needed to clarify Gavin's message, which tended people toward a technical evaluation.

> -----Original Message----- > From: Scott Ferguson [mailto:ferg@caucho.com] > Sent: Tuesday, December 23, 2008 12:26 PM > To: Michael Keith > Cc: Gavin King; Java Community Process JSR #299 Expert List; Jim > Knutson; Matt Drees; WebBeans > Subject: Re: XML configuration format > > > > On Dec 22, 2008, at 10:01 AM, Michael Keith wrote: > >> >> Just to give a bit more context to this issue: >> >> One of the big advantages that Java EE has over the > collective set of >> random technology bits and pieces that some people cobble together >> and use >> to write applications with, is that it is a consistent group of >> cohesive >> technologies that share common terminology, resource definitions, >> development >> and configuration practices, and many other aspects of application >> development. This is a huge strength, and contributes to increased >> portability >> of both applications and developer experience. > > Can you give a specific example of Java EE XML configuration > that you > think is superior to the WebBeans format? Or a specific > change in the > WebBeans syntax that you prefer? > > Historically, the XML syntax has been the weakest part of > JavaEE. The > JCA ra.xml is terrible. The ejb-jar.xml is bad from top to bottom. > The <*-ref> are essentially pointless. It's not clear what > the value > is of following poor design. > > The cleanest XML configuration in JavaEE is the web.xml from > servlets > (minus the JavaEE <*-ref> cruft), and even that is extremely dated > because the servlet spec was designed before schema, and the > designers > were apparently unaware that XML has an attribute syntax. > > If a servlet configuration were rewritten in a WebBeans style, it > would look like the following: > > <quercus:QuercusServlet> > <servlet:ServletMapping url-pattern="*.php"/> > > <quercus:compile>true</quercus:compile> > </quercus:QuercusServlet> > > I'd argue that the WebBeans-style servlet configuration is > superior to > the traditional JavaEE in every way: > > 1) The package and class of the servlet itself are prominent; > they're the first thing you scan. Since that class name is the most > important aspect of the servlet, having it as the tag name greatly > enhances readability. The traditional JavaEE configuration > hides the > most important information deep in an XML tree, buried by > boilerplate > XML tags. > > 2) Zero housekeeping cruft. Every element and attribute in my > example is meaningful. > > 3) Full DI/IoC configuration, i.e. the servlet is no longer > limited > to the decade-old init-param limitations. I used a boolean, but > could have configured any arbitrarily complex configuration. In > addition, because the configuration is injected to the servlet, the > old getConfigAttribute(...) cruft in the servlet code goes away. > > 4) Tight mirroring between the annotation view and XML view (the > "type safety" of WebBeans). The servlet:ServletMapping tells you > exactly where to look in the JavaDoc to understand the code. The > quercus:QuercusServlet and quercus:compile are also in their JavaDoc. > > If you've got specific criticisms of this model, it would be > interesting to hear. Unfortunately, your previous comment was vague > and lacking in any specifics, so not particularly useful. > > -- Scott > >> >> >> Keeping the platform consistent does not imply stagnancy > because of >> the way >> "older" technologies work. New technologies may still > emerge to join >> the EE fold, >> but if they introduce something new in an area that existing EE >> specs already >> participate in and make use of then the new and more useful > approach >> should be >> introduced to the existing specs as well. Annotations is a good >> example, where >> they began being used in the EJB 3.0 round, but were soon > pushed up >> into the >> platform and EE spec, and are now in every other EE > sub-spec as well. >> >> So, while I see that there are strengths and weaknesses to the XML >> style that >> is currently described in the spec, it is so different from every >> other existing >> XML descriptor in Java EE that the platform suffers and > there is no >> sharing of >> experience. On the contrary, it requires learning new and > different >> conventions, >> all in the context of trying to make this a bona fide Java EE >> technology. >> >> On the other hand, if the options are weighed and the majority of >> the platform >> stakeholders are in agreement with this group that Java-driven XML >> really is a better >> approach, then these rules and styles should be propagated to the >> entire platform, >> with an agreed-upon plan to bring that about. >> >> -Mike >> >>> -----Original Message----- >>> From: Gavin King [mailto:gavin@hibernate.org] >>> Sent: Sunday, December 21, 2008 1:13 AM >>> To: Java Community Process JSR #299 Expert List; Jim > Knutson; Michael >>> Keith; Matt Drees; Scott Ferguson; WebBeans >>> Subject: XML configuration format >>> >>> >>> 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 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(a)gmail.com >>> http://in.relation.to/Bloggers/Gavin >>> http://hibernate.org >>> http://seamframework.org >>> >> >> > >

I really assumed that members of this group (that were supposed to be integrating 2 Java EE technologies) knew what Java EE XML descriptors looked like, but for Scott and any others that either don't know them, or don't recognize what the differences are, here is a short list:

Java EE - standard pre-defined namespaces and schemas WebBeans - application-defined namespaces (and possibly schemas) Java EE - standard XML styled element names WebBeans - Java class/code-based elements Java EE - pre-defined structure WebBeans - open-ended structure based on application Java EE - all elements are assigned specific semantics WebBeans - context and extensive rule set governs what an element means Java EE - values typically stored as element content WebBeans - elements themselves are data (so are often empty)

> Without any reference point about what bothers you with the WebBeans > format, it's difficult to have any meaningful discussion. I > gave you > an example to allow a concrete discussion about the major problems > that are bothering you. Again, it has nothing to do with what is good and what isn't, it is all about the fact that if this is to be a platform technology then it needs to be developed with the platform in mind. >> >> >>> -----Original Message----- >>> From: Scott Ferguson [mailto:ferg@caucho.com] >>> Sent: Tuesday, December 23, 2008 12:26 PM >>> To: Michael Keith >>> Cc: Gavin King; Java Community Process JSR #299 Expert List; Jim >>> Knutson; Matt Drees; WebBeans >>> Subject: Re: XML configuration format >>> >>> >>> >>> On Dec 22, 2008, at 10:01 AM, Michael Keith wrote: >>> >>>> >>>> Just to give a bit more context to this issue: >>>> >>>> One of the big advantages that Java EE has over the >>> collective set of >>>> random technology bits and pieces that some people cobble together >>>> and use >>>> to write applications with, is that it is a consistent group of >>>> cohesive >>>> technologies that share common terminology, resource definitions, >>>> development >>>> and configuration practices, and many other aspects of application >>>> development. This is a huge strength, and contributes to increased >>>> portability >>>> of both applications and developer experience. >>> >>> Can you give a specific example of Java EE XML configuration >>> that you >>> think is superior to the WebBeans format? Or a specific >>> change in the >>> WebBeans syntax that you prefer? >>> >>> Historically, the XML syntax has been the weakest part of >>> JavaEE. The >>> JCA ra.xml is terrible. The ejb-jar.xml is bad from top to bottom. >>> The <*-ref> are essentially pointless. It's not clear what >>> the value >>> is of following poor design. >>> >>> The cleanest XML configuration in JavaEE is the web.xml from >>> servlets >>> (minus the JavaEE <*-ref> cruft), and even that is extremely dated >>> because the servlet spec was designed before schema, and the >>> designers >>> were apparently unaware that XML has an attribute syntax. >>> >>> If a servlet configuration were rewritten in a WebBeans style, it >>> would look like the following: >>> >>> <quercus:QuercusServlet> >>> <servlet:ServletMapping url-pattern="*.php"/> >>> >>> <quercus:compile>true</quercus:compile> >>> </quercus:QuercusServlet> >>> >>> I'd argue that the WebBeans-style servlet configuration is >>> superior to >>> the traditional JavaEE in every way: >>> >>> 1) The package and class of the servlet itself are prominent; >>> they're the first thing you scan. Since that class name > is the most >>> important aspect of the servlet, having it as the tag name greatly >>> enhances readability. The traditional JavaEE configuration >>> hides the >>> most important information deep in an XML tree, buried by >>> boilerplate >>> XML tags. >>> >>> 2) Zero housekeeping cruft. Every element and attribute in my >>> example is meaningful. >>> >>> 3) Full DI/IoC configuration, i.e. the servlet is no longer >>> limited >>> to the decade-old init-param limitations. I used a boolean, but >>> could have configured any arbitrarily complex configuration. In >>> addition, because the configuration is injected to the servlet, the >>> old getConfigAttribute(...) cruft in the servlet code goes away. >>> >>> 4) Tight mirroring between the annotation view and XML view (the >>> "type safety" of WebBeans). The servlet:ServletMapping tells you >>> exactly where to look in the JavaDoc to understand the code. The >>> quercus:QuercusServlet and quercus:compile are also in > their JavaDoc. >>> >>> If you've got specific criticisms of this model, it would be >>> interesting to hear. Unfortunately, your previous comment > was vague >>> and lacking in any specifics, so not particularly useful. >>> >>> -- Scott >>> >>>> >>>> >>>> Keeping the platform consistent does not imply stagnancy >>> because of >>>> the way >>>> "older" technologies work. New technologies may still >>> emerge to join >>>> the EE fold, >>>> but if they introduce something new in an area that existing EE >>>> specs already >>>> participate in and make use of then the new and more useful >>> approach >>>> should be >>>> introduced to the existing specs as well. Annotations is a good >>>> example, where >>>> they began being used in the EJB 3.0 round, but were soon >>> pushed up >>>> into the >>>> platform and EE spec, and are now in every other EE >>> sub-spec as well. >>>> >>>> So, while I see that there are strengths and weaknesses to the XML >>>> style that >>>> is currently described in the spec, it is so different from every >>>> other existing >>>> XML descriptor in Java EE that the platform suffers and >>> there is no >>>> sharing of >>>> experience. On the contrary, it requires learning new and >>> different >>>> conventions, >>>> all in the context of trying to make this a bona fide Java EE >>>> technology. >>>> >>>> On the other hand, if the options are weighed and the majority of >>>> the platform >>>> stakeholders are in agreement with this group that Java-driven XML >>>> really is a better >>>> approach, then these rules and styles should be propagated to the >>>> entire platform, >>>> with an agreed-upon plan to bring that about. >>>> >>>> -Mike >>>> >>>>> -----Original Message----- >>>>> From: Gavin King [mailto:gavin@hibernate.org] >>>>> Sent: Sunday, December 21, 2008 1:13 AM >>>>> To: Java Community Process JSR #299 Expert List; Jim >>> Knutson; Michael >>>>> Keith; Matt Drees; Scott Ferguson; WebBeans >>>>> Subject: XML configuration format >>>>> >>>>> >>>>> 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 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(a)gmail.com >>>>> http://in.relation.to/Bloggers/Gavin >>>>> http://hibernate.org >>>>> http://seamframework.org >>>>> >>>> >>>> >>> >>> >> >> > >

-----Original Message----- From: Gavin King [mailto:gavin.king@gmail.com] Sent: Tuesday, December 23, 2008 6:44 PM To: Scott Ferguson Cc: Michael Keith; Gavin King; Java Community Process JSR #299 Expert List; Jim Knutson; Matt Drees; WebBeans Subject: Re: XML configuration format What I think we should focus on here is whether the difference in styles is going to be confusing to users, and whether the web beans style of descriptor is more difficult to understand and use.

I dont think that the fact that the XML format proposed by the PDR is a different style is, alone, a good enough reason to reject it. EE already has a number of metadata formats, both XML and annotations, and each requires the user to learn it individually. There's not really anything much in the way of portable knowledge/skills between writing web.xml and orm.xml and faces-config.xml.

What I want to know is whether there are specific reasons why the current proposal is going to cause serious confusion or ease of use issues.

On Dec 24, 2008, at 9:41 AM, Scott Ferguson <ferg(a)caucho.com&gt; wrote: > > On Dec 23, 2008, at 2:16 PM, Michael Keith wrote: > >> >> I really assumed that members of this group (that were supposed to be >> integrating 2 Java EE technologies) knew what Java EE XML descriptors >> looked like, but for Scott and any others that either don't know >> them, >> or don't recognize what the differences are, here is a short list: > >> Java EE - standard pre-defined namespaces and schemas >> WebBeans - application-defined namespaces (and possibly schemas) >> >> Java EE - standard XML styled element names >> WebBeans - Java class/code-based elements >> >> Java EE - pre-defined structure >> WebBeans - open-ended structure based on application >> >> Java EE - all elements are assigned specific semantics >> WebBeans - context and extensive rule set governs what an element >> means >> >> Java EE - values typically stored as element content >> WebBeans - elements themselves are data (so are often empty) > > Thank you. > > FYI, since I've implemented a good chunk of the JavaEE specs over > the last decade, including multiple EJB and Servlet versions, I'm > fully aware of the content of the current XML descriptors. The main > question was which differences you were concerned about. > > -- Scott > >> >> >>> Without any reference point about what bothers you with the WebBeans >>> format, it's difficult to have any meaningful discussion. I >>> gave you >>> an example to allow a concrete discussion about the major problems >>> that are bothering you. >> >> Again, it has nothing to do with what is good and what isn't, it is >> all about the fact that if this is to be a platform technology then >> it needs to be developed with the platform in mind. >> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Scott Ferguson [mailto:ferg@caucho.com] >>>>> Sent: Tuesday, December 23, 2008 12:26 PM >>>>> To: Michael Keith >>>>> Cc: Gavin King; Java Community Process JSR #299 Expert List; Jim >>>>> Knutson; Matt Drees; WebBeans >>>>> Subject: Re: XML configuration format >>>>> >>>>> >>>>> >>>>> On Dec 22, 2008, at 10:01 AM, Michael Keith wrote: >>>>> >>>>>> >>>>>> Just to give a bit more context to this issue: >>>>>> >>>>>> One of the big advantages that Java EE has over the >>>>> collective set of >>>>>> random technology bits and pieces that some people cobble >>>>>> together >>>>>> and use >>>>>> to write applications with, is that it is a consistent group of >>>>>> cohesive >>>>>> technologies that share common terminology, resource definitions, >>>>>> development >>>>>> and configuration practices, and many other aspects of >>>>>> application >>>>>> development. This is a huge strength, and contributes to >>>>>> increased >>>>>> portability >>>>>> of both applications and developer experience. >>>>> >>>>> Can you give a specific example of Java EE XML configuration >>>>> that you >>>>> think is superior to the WebBeans format? Or a specific >>>>> change in the >>>>> WebBeans syntax that you prefer? >>>>> >>>>> Historically, the XML syntax has been the weakest part of >>>>> JavaEE. The >>>>> JCA ra.xml is terrible. The ejb-jar.xml is bad from top to >>>>> bottom. >>>>> The <*-ref> are essentially pointless. It's not clear what >>>>> the value >>>>> is of following poor design. >>>>> >>>>> The cleanest XML configuration in JavaEE is the web.xml from >>>>> servlets >>>>> (minus the JavaEE <*-ref> cruft), and even that is extremely dated >>>>> because the servlet spec was designed before schema, and the >>>>> designers >>>>> were apparently unaware that XML has an attribute syntax. >>>>> >>>>> If a servlet configuration were rewritten in a WebBeans style, it >>>>> would look like the following: >>>>> >>>>> <quercus:QuercusServlet> >>>>> <servlet:ServletMapping url-pattern="*.php"/> >>>>> >>>>> <quercus:compile>true</quercus:compile> >>>>> </quercus:QuercusServlet> >>>>> >>>>> I'd argue that the WebBeans-style servlet configuration is >>>>> superior to >>>>> the traditional JavaEE in every way: >>>>> >>>>> 1) The package and class of the servlet itself are prominent; >>>>> they're the first thing you scan. Since that class name >>> is the most >>>>> important aspect of the servlet, having it as the tag name greatly >>>>> enhances readability. The traditional JavaEE configuration >>>>> hides the >>>>> most important information deep in an XML tree, buried by >>>>> boilerplate >>>>> XML tags. >>>>> >>>>> 2) Zero housekeeping cruft. Every element and attribute in my >>>>> example is meaningful. >>>>> >>>>> 3) Full DI/IoC configuration, i.e. the servlet is no longer >>>>> limited >>>>> to the decade-old init-param limitations. I used a boolean, but >>>>> could have configured any arbitrarily complex configuration. In >>>>> addition, because the configuration is injected to the servlet, >>>>> the >>>>> old getConfigAttribute(...) cruft in the servlet code goes away. >>>>> >>>>> 4) Tight mirroring between the annotation view and XML view (the >>>>> "type safety" of WebBeans). The servlet:ServletMapping tells you >>>>> exactly where to look in the JavaDoc to understand the code. The >>>>> quercus:QuercusServlet and quercus:compile are also in >>> their JavaDoc. >>>>> >>>>> If you've got specific criticisms of this model, it would be >>>>> interesting to hear. Unfortunately, your previous comment >>> was vague >>>>> and lacking in any specifics, so not particularly useful. >>>>> >>>>> -- Scott >>>>> >>>>>> >>>>>> >>>>>> Keeping the platform consistent does not imply stagnancy >>>>> because of >>>>>> the way >>>>>> "older" technologies work. New technologies may still >>>>> emerge to join >>>>>> the EE fold, >>>>>> but if they introduce something new in an area that existing EE >>>>>> specs already >>>>>> participate in and make use of then the new and more useful >>>>> approach >>>>>> should be >>>>>> introduced to the existing specs as well. Annotations is a good >>>>>> example, where >>>>>> they began being used in the EJB 3.0 round, but were soon >>>>> pushed up >>>>>> into the >>>>>> platform and EE spec, and are now in every other EE >>>>> sub-spec as well. >>>>>> >>>>>> So, while I see that there are strengths and weaknesses to the >>>>>> XML >>>>>> style that >>>>>> is currently described in the spec, it is so different from every >>>>>> other existing >>>>>> XML descriptor in Java EE that the platform suffers and >>>>> there is no >>>>>> sharing of >>>>>> experience. On the contrary, it requires learning new and >>>>> different >>>>>> conventions, >>>>>> all in the context of trying to make this a bona fide Java EE >>>>>> technology. >>>>>> >>>>>> On the other hand, if the options are weighed and the majority of >>>>>> the platform >>>>>> stakeholders are in agreement with this group that Java-driven >>>>>> XML >>>>>> really is a better >>>>>> approach, then these rules and styles should be propagated to the >>>>>> entire platform, >>>>>> with an agreed-upon plan to bring that about. >>>>>> >>>>>> -Mike >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Gavin King [mailto:gavin@hibernate.org] >>>>>>> Sent: Sunday, December 21, 2008 1:13 AM >>>>>>> To: Java Community Process JSR #299 Expert List; Jim >>>>> Knutson; Michael >>>>>>> Keith; Matt Drees; Scott Ferguson; WebBeans >>>>>>> Subject: XML configuration format >>>>>>> >>>>>>> >>>>>>> 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 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(a)gmail.com >>>>>>> http://in.relation.to/Bloggers/Gavin >>>>>>> http://hibernate.org >>>>>>> http://seamframework.org >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> >

On Wed, Dec 24, 2008 at 12:23 PM, Michael Keith <MICHAEL.KEITH(a)oracle.com&gt; wrote:

> I would say that writing web beans XML, which is more > like code, requires a rather different mindset than what is applied when > writing traditional Java EE descriptors. Again, I disagree. For a developer configuring a pre-packaged library, the "traditional" XML style requires a lot more knowledge of the code (Java class, method names, etc) than the "web beans" style does. With the web beans style, the configuration author doesn't see anything about Java - everything they need to know is completely encapsulated in the schema for the library.

On Wed, Dec 24, 2008 at 12:23 PM, Michael Keith <MICHAEL.KEITH(a)oracle.com&gt; wrote: >> What I think we should focus on here is whether the difference in >> styles is going to be confusing to users, and whether the web beans >> style of descriptor is more difficult to understand and use. > > My personal opinion is that it is more difficult to understand for beginners, > and that there is a steeper learning curve. Once you understand the rules > then it has more value than the existing Java EE style because not only is > it more terse and descriptive but it is easier to map to Java code. Yes, I would more or less go along with that, except for one important quibble: * yes, it is probably a bit more difficult for beginners to understand how to configure their own web beans, since it requires a couple of new concepts * but it is *not* more difficult for beginners to understand how to configure a third-party library containing web beans - in fact it is much easier since they don't need to go off and look at the Java code So from the point of view of beginner, it depends upon what they have as the primary usecase for the XML configuration: is it configuration of their own web beans, or configuration of somebody else's? I would say that beginners (and most other web bean developers) are going to be using annotations to config their own classes, and XML to configure pre-packaged libraries created by someone else. However, I'm aware that there are some developers who still prefer to use XML for everything. I'm not sure exactly how many of them there are, nor to what extent we should to cater to their needs, nor which of the XML formats they prefer. >> There's not >> really anything much in the way of portable knowledge/skills between >> writing web.xml and orm.xml and faces-config.xml. > > In fact, there *are* commonalities between these 3, with simple assumptions > that do not hold true in web beans. For example, the ability to look at a > schema to know the complete set of elements that may possibly be specified > in a given XML file. Well, I disagree with you there, Mike. The idea is that we have a Processor running, generating a schema when the Java code is compiled. So both styles of XML are schema-driven. In fact the web beans style is much *more* schema driven, and the schema captures much more about what the developer can and cannot write in their XML document. When authoring the XML, the developer will get a *lot* more assistance from their tool when using the web beans style. The difference is that in the case of web.xml or orm.xml, there is exactly one document that contains the whole schema, and the developer does not need to use XML namespaces. Whereas in web beans, the schema is partitioned between multiple files, and there is a requirement that the XML author understand namespaces. I can well believe that there are developers who have never used namespaces before, but the experience we have from Seam (and also from Spring, I suppose) is that in practice people don't find this to be a barrier. > I would say that writing web beans XML, which is more > like code, requires a rather different mindset than what is applied when > writing traditional Java EE descriptors. Again, I disagree. For a developer configuring a pre-packaged library, the "traditional" XML style requires a lot more knowledge of the code (Java class, method names, etc) than the "web beans" style does. With the web beans style, the configuration author doesn't see anything about Java - everything they need to know is completely encapsulated in the schema for the library. >> What I want to know is whether there are specific reasons why the >> current proposal is going to cause serious confusion or ease of use >> issues. > > Learning a whole new way of writing XML is an ease of use issue. I don't know what you mean. How is it a "whole new way of writing XML"? Because it uses namespaces? Say I'm using a library written by someone else, that can be configured using a web beans XML schema. How is this schema any different from any other XML schema that is used by developers today to configure stuff? Remember, the XML author is not required to know anything at all about the underlying Java classes and methods to author this configuration document. They get a schema, and they write XML using the elements defined by that schema. They don't know that the element names are actually Java class and method names. > If you don't know the rules then this new style of XML is definitely confusing. How? Again, you don't need to know the rules to author the document. If you're a *user* of the XML schema, a document author, you don't need to know anything at all about how the Java classes relate to the XML schema. If you're the provider of the XML schema, you also don't need to know much about the rules, since the schema will be generated for you. The only people who really need to know the rules in great detail are the folks implementing Web Beans and implementing the schema generation tool :-) That's the real beauty of this mechanism! > Is it a better way going forward? Probably, but if web beans is being advertised > as a layer of services over existing Java EE technologies then one would assume > that it will be specified in a way that is natural and easily understood by the users > of those technologies. That "naturalness" is worth more than what is gained by a > slightly improved XML style that is limited to one specific area. I don't believe that the additional typesafety and tool-ability (authoring support) amounts to only a slight improvement, though of course this view is influenced by the fact that I, like most Java developers, always use an IDE for everything. Developers who don't use an IDE won't see the same level of improvement. In fact, for developers who don't use tools, there is no great advantage to the web beans style of XML. This stuff was designed for IDE users. > Of course, consistency can be achieved from either direction, and the alternative to > web beans adopting the style of those technologies is for the technologies to adopt > the web beans style of XML. As I mentioned, for that direction to change there must > be a platform-level directive. I will ask Roberto and Bill about this, but in the past I have not heard from them that there was a platform-level requirement for consistency here. Certainly they've both read the spec and have not yet raised this as an issue with me. So, again, I would like to focus on the question of ease-of-use and reuse. -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org

(3) web beans competes with proprietary solutions such as Spring and Seam, and must offer competitive functionality

Beginning from these assumptions I find it difficult to avoid the conclusion that we should be offering the schema-driven, IDE-friendly style of XML configuration that Spring and Seam offer.

Certainly *some* other EE DDs could benefit from the namespaced- based approach: * ejb-jar.xml, certainly * perhaps some of the WS DDs, but I've never used this stuff so I'm not

but most of the other DDs are just fine as they are: * application.xml * web.xml * jsf-config.xml * taglib.tld None of these would really benefit much from the new-style XML, because they aren't being used to configure third-party components (at least, not any more in EE 6!) Finally, the following two "DD"s, which *are* used to configure third-party components *already* use the "new" style: * JSP pages * JSF pages

> * JSP pages > * JSF pages Can you elaborate?

When I look at faces-config.xml, I see something that looks like the typical DD elements we've seen in the past: <managed-bean> <managed-bean-name>TestBean</managed-bean-name> <managed-bean-class>test.TestBean</managed-bean-class> <managed-bean-scope>request</managed-bean-scope> </managed-bean> That's not a new style and given that JSPs are defined in the web.xml, I'm not sure what "new" style you are talking about. Note, we're talking about metadata syntax, not the JSP/JSF page source. Thanks, Jim Knutson WebSphere J2EE Architect

-----Original Message----- From: Gavin King [mailto:gavin@hibernate.org] Sent: Wednesday, December 24, 2008 8:01 PM To: Michael Keith Cc: Scott Ferguson; Java Community Process JSR #299 Expert List; Jim Knutson; Matt Drees; WebBeans Subject: Re: XML configuration format On Wed, Dec 24, 2008 at 12:23 PM, Michael Keith <MICHAEL.KEITH(a)oracle.com&gt; wrote: >> What I think we should focus on here is whether the difference in >> styles is going to be confusing to users, and whether the web beans >> style of descriptor is more difficult to understand and use. > > My personal opinion is that it is more difficult to understand for beginners, > and that there is a steeper learning curve. Once you understand the rules > then it has more value than the existing Java EE style because not only is > it more terse and descriptive but it is easier to map to Java code. Yes, I would more or less go along with that, except for one important quibble: * yes, it is probably a bit more difficult for beginners to understand how to configure their own web beans, since it requires a couple of new concepts * but it is *not* more difficult for beginners to understand how to configure a third-party library containing web beans - in fact it is much easier since they don't need to go off and look at the Java code

So from the point of view of beginner, it depends upon what they have as the primary usecase for the XML configuration: is it configuration of their own web beans, or configuration of somebody else's? I would say that beginners (and most other web bean developers) are going to be using annotations to config their own classes, and XML to configure pre-packaged libraries created by someone else. However, I'm aware that there are some developers who still prefer to use XML for everything. I'm not sure exactly how many of them there are, nor to what extent we should to cater to their needs, nor which of the XML formats they prefer.

>> There's not >> really anything much in the way of portable knowledge/skills between >> writing web.xml and orm.xml and faces-config.xml. > > In fact, there *are* commonalities between these 3, with simple assumptions > that do not hold true in web beans. For example, the ability to look at a > schema to know the complete set of elements that may possibly be specified > in a given XML file. Well, I disagree with you there, Mike. The idea is that we have a Processor running, generating a schema when the Java code is compiled. So both styles of XML are schema-driven. In fact the web beans style is much *more* schema driven, and the schema captures much more about what the developer can and cannot write in their XML document. When authoring the XML, the developer will get a *lot* more assistance from their tool when using the web beans style.

The difference is that in the case of web.xml or orm.xml, there is exactly one document that contains the whole schema, and the developer does not need to use XML namespaces. Whereas in web beans, the schema is partitioned between multiple files, and there is a requirement that the XML author understand namespaces.

I can well believe that there are developers who have never used namespaces before, but the experience we have from Seam (and also from Spring, I suppose) is that in practice people don't find this to be a barrier.

> I would say that writing web beans XML, which is more > like code, requires a rather different mindset than what is applied when > writing traditional Java EE descriptors. Again, I disagree. For a developer configuring a pre-packaged library, the "traditional" XML style requires a lot more knowledge of the code (Java class, method names, etc) than the "web beans" style does. With the web beans style, the configuration author doesn't see anything about Java - everything they need to know is completely encapsulated in the schema for the library.

>> What I want to know is whether there are specific reasons why the >> current proposal is going to cause serious confusion or ease of use >> issues. > > Learning a whole new way of writing XML is an ease of use issue. I don't know what you mean. How is it a "whole new way of writing XML"? Because it uses namespaces? Say I'm using a library written by someone else, that can be configured using a web beans XML schema. How is this schema any different from any other XML schema that is used by developers today to configure stuff? Remember, the XML author is not required to know anything at all about the underlying Java classes and methods to author this configuration document. They get a schema, and they write XML using the elements defined by that schema. They don't know that the element names are actually Java class and method names.

> If you don't know the rules then this new style of XML is definitely confusing. How? Again, you don't need to know the rules to author the document. If you're a *user* of the XML schema, a document author, you don't need to know anything at all about how the Java classes relate to the XML schema. If you're the provider of the XML schema, you also don't need to know much about the rules, since the schema will be generated for you. The only people who really need to know the rules in great detail are the folks implementing Web Beans and implementing the schema generation tool :-)

That's the real beauty of this mechanism! > Is it a better way going forward? Probably, but if web beans is being advertised > as a layer of services over existing Java EE technologies then one would assume > that it will be specified in a way that is natural and easily understood by the users > of those technologies. That "naturalness" is worth more than what is gained by a > slightly improved XML style that is limited to one specific area. I don't believe that the additional typesafety and tool-ability (authoring support) amounts to only a slight improvement, though of course this view is influenced by the fact that I, like most Java developers, always use an IDE for everything. Developers who don't use an IDE won't see the same level of improvement. In fact, for developers who don't use tools, there is no great advantage to the web beans style of XML. This stuff was designed for IDE users.

> Of course, consistency can be achieved from either direction, and the alternative to > web beans adopting the style of those technologies is for the technologies to adopt > the web beans style of XML. As I mentioned, for that direction to change there must > be a platform-level directive. I will ask Roberto and Bill about this, but in the past I have not heard from them that there was a platform-level requirement for consistency here. Certainly they've both read the spec and have not yet raised this as an issue with me. So, again, I would like to focus on the question of ease-of-use and reuse.

> * but it is *not* more difficult for beginners to understand how to > configure a third-party library containing web beans - in fact it is > much easier since they don't need to go off and look at the Java code I think we could look at what the servlet EG is doing for web.xml fragments and do something similar. I don't think they require unique namespaces to handle that. If this is something we really need, then we should push the EJB EG for something similar and utilize it.

> However, I'm aware that there are some developers who still prefer to > use XML for everything. I'm not sure exactly how many of them there > are, nor to what extent we should to cater to their needs, nor which > of the XML formats they prefer. Given they already have build tools in place for generating DDs, a syntactical change of this magnitude would require significant rewrites for them to take advantage of this spec. Adding elements is not as big a deal.

I think the point is that you need to know XML Schema with this spec. whereas you follow patterns for the platform DDs. Assuming you use an IDE and get content assist, most IDE DD editors will preset the DD namespaces so you can get content assist whereas generated XML schemas require knowledge of how to add additional namespaces and configure IDEs to use them. That's not exactly trivial if all you want to do is develop and use business logic.

The only caveat to this is that this spec. is supposed to integrate JSF and EJB, so JSF developers are more likely to be familiar with dealing with namespaces. However, I got the impression that the developers this spec. would be most targetted at would be the business logic developers.

> Say I'm using a library written by someone else, that can be > configured using a web beans XML schema. How is this schema any > different from any other XML schema that is used by developers today > to configure stuff? Remember, the XML author is not required to know > anything at all about the underlying Java classes and methods to > author this configuration document. They get a schema, and they write > XML using the elements defined by that schema. They don't know that > the element names are actually Java class and method names. A typical component developer doesn't knowingly deal with XML schema unless they are a web services component developer.

> If you're a *user* of the XML schema, a document author, you don't > need to know anything at all about how the Java classes relate to the > XML schema. If you're the provider of the XML schema, you also don't > need to know much about the rules, since the schema will be generated > for you. But either you need to have knowledge of how XML Schema translates into a syntactically and semantically correct XML document instance or you have to have knowledge of how to setup tools to use XML schema to do that for you. Either way, you have to know more than the average developer does today.

> My IDE (Eclipse) automagically understands XML schema. There's no > configuration needed. Yes, I need to add the list of namespaces at the > top of my file but that's really not very difficult. I'm inclined to > think that pretty much everyone already knows how to do this. For one > thing, Spring uses the namespace-based approach, and a big chunk of EE > developers use Spring. I understand, but given that distinction, the EE DDs follow the same pattern and rules and get just as much help from the IDE. You still get content assist with documentation, etc. However, once you start creating new schemas and they aren't served by an internet location, you need to start managing your XML Catalog so the schemas for those new namespaces can be found.

> And the point is that the new-style XML gives you context assist and > validation for much more stuff than the old-style XML. With the old > style XML you get content assist for <class> and <method>, elements > that simply don't exist in the new-style XML! The old-style doesn't > help you at all when you start typing the actual class and method > names - which are more or less the *only* things you need to type in > the new-style XML (where they *can* be autocompleted). Ok, so what you are attempting to do is turn semantic content into syntax. I understand how this can help in some cases, but not all (e.g. defining method sets),

but I think that's beside the point. The point is that there's a platform pattern. To integrate with the platform, I think you need to conform to the platform pattern. If you don't like the platform pattern, then the entire pattern ought to be consistently changed, not just one portion of it.

> It's certainly true that the vast majority of developers don't > *define* schemas, but the whole point of this is that they don't need > to in web beans either: the schema can be generated by javac. Except for the fact that it IS new schema and they must be aware of it and the impact on the content. Anyway, my point remains that platform consistency needs to be maintained or we will lose the concept of a platform and degenerate into a bunch of piece parts. If we can get the platform to move to a more modern XML style, I'm ok with that too. I just want integrated consistency.

Trial "standards" are never a good idea. That's why open source plays an important role in understanding what the industry wants prior to nailing things down in a standard. I don't think the same could be said here. It's not a conscious effort that the platform as a whole is going to move to this XML style and just doesn't have the time. At least not yet it isn't.

dan.j.allen(a)gmail.com wrote on 01/09/2009 09:09:01 PM: > > Trial "standards" are never a good > > idea. That's why open source plays an important role in understanding > > what the industry wants prior to nailing things down in a standard. > > > > I don't think the same could be said here. It's not a conscious effort > > that the platform as a whole is going to move to this XML style and just > > doesn't have the time. At least not yet it isn't. > > I might be interpreting this wrong, but are you saying that extensible > XML authoring has not been proven in the open source world? That it > isn't now the defacto standard approach to XML configuration? That > developers are not excited about it? I think Spring, Seam, and Mule > all demonstrate that this is a viable approach and that people are not > only accepting it, but expecting it. Why would we want to hold back > progress? A statement was made that it was ok to "trial" the new syntax with WebBeans and not have the platform follow suit. I was arguing against "trial"s of anything in standards and that the platform needs to move or not as a whole. I think there have been "trials" in open source, as it should be. I'm only stating I don't want a mishmash platform of stuff. I want integration and consistency.

Learning a whole new way of writing XML is an ease of use issue. If you don't know the rules then this new style of XML is definitely confusing. Is it a better way going forward? Probably, but if web beans is being advertised as a layer of services over existing Java EE technologies then one would assume that it will be specified in a way that is natural and easily understood by the users of those technologies. That "naturalness" is worth more than what is gained by a slightly improved XML style that is limited to one specific area. Of course, consistency can be achieved from either direction, and the alternative to web beans adopting the style of those technologies is for the technologies to adopt the web beans style of XML. As I mentioned, for that direction to change there must be a platform-level directive.

The WebBeans architecture is richer, more modular, and more extensible than DTD-style syntax can handle cleanly.

So, while I see that there are strengths and weaknesses to the XML style that is currently described in the spec, it is so different from every other existing XML descriptor in Java EE that the platform suffers and there is no sharing of experience. On the contrary, it requires learning new and different conventions, all in the context of trying to make this a bona fide Java EE technology.