<html><body>
<p><tt>gavin.king@gmail.com wrote on 12/24/2008 07:01:21 PM:<br>
<br>
> On Wed, Dec 24, 2008 at 12:23 PM, Michael Keith<br>
> <MICHAEL.KEITH@oracle.com> wrote:<br>
> <br>
> >> What I think we should focus on here is whether the difference in<br>
> >> styles is going to be confusing to users, and whether the web beans<br>
> >> style of descriptor is more difficult to understand and use.<br>
> ><br>
> > My personal opinion is that it is more difficult to understand forbeginners,<br>
> > and that there is a steeper learning curve. Once you understand the rules<br>
> > then it has more value than the existing Java EE style because not only is<br>
> > it more terse and descriptive but it is easier to map to Java code.<br>
> <br>
> Yes, I would more or less go along with that, except for one <br>
> important quibble:<br>
> <br>
> * yes, it is probably a bit more difficult for beginners to understand<br>
> how to configure their own web beans, since it requires a couple of<br>
> new concepts<br>
></tt><br>
<tt>> * but it is *not* more difficult for beginners to understand how to<br>
> configure a third-party library containing web beans - in fact it is<br>
> much easier since they don't need to go off and look at the Java code<br>
</tt><br>
<tt>I think we could look at what the servlet EG is doing for web.xml fragments</tt><br>
<tt>and do something similar. I don't think they require unique namespaces</tt><br>
<tt>to handle that. If this is something we really need, then we should push</tt><br>
<tt>the EJB EG for something similar and utilize it.</tt><br>
<br>
<tt>I would hate to have to use one methodology for web apps and another</tt><br>
<tt>for EJBs and something completely different again for this spec.</tt><br>
<tt><br>
> So from the point of view of beginner, it depends upon what they have<br>
> as the primary usecase for the XML configuration: is it configuration<br>
> of their own web beans, or configuration of somebody else's?<br>
> <br>
> I would say that beginners (and most other web bean developers) are<br>
> going to be using annotations to config their own classes, and XML to<br>
> configure pre-packaged libraries created by someone else.<br>
</tt><br>
<tt>Possibly, though many enterprise customers I know are looking at</tt><br>
<tt>continuing to use XML DDs for their own component libs because it </tt><br>
<tt>ensures they understand and have control over their metadata (e.g.</tt><br>
<tt>some maintenance defect won't change security roles by accident).</tt><br>
<tt><br>
> However, I'm aware that there are some developers who still prefer to<br>
> use XML for everything. I'm not sure exactly how many of them there<br>
> are, nor to what extent we should to cater to their needs, nor which<br>
> of the XML formats they prefer.<br>
</tt><br>
<tt>Given they already have build tools in place for generating DDs, a</tt><br>
<tt>syntactical change of this magnitude would require significant rewrites</tt><br>
<tt>for them to take advantage of this spec. Adding elements is not as</tt><br>
<tt>big a deal.</tt><br>
<tt><br>
> > I would say that writing web beans XML, which is more<br>
> > like code, requires a rather different mindset than what is applied when<br>
> > writing traditional Java EE descriptors.<br>
> <br>
> Again, I disagree. For a developer configuring a pre-packaged library,<br>
> the "traditional" XML style requires a lot more knowledge of the code<br>
> (Java class, method names, etc) than the "web beans" style does. With<br>
> the web beans style, the configuration author doesn't see anything<br>
> about Java - everything they need to know is completely encapsulated<br>
> in the schema for the library.</tt><br>
<br>
<tt>I think the point is that you need to know XML Schema with this spec.</tt><br>
<tt>whereas you follow patterns for the platform DDs. Assuming you use</tt><br>
<tt>an IDE and get content assist, most IDE DD editors will preset the </tt><br>
<tt>DD namespaces so you can get content assist whereas generated XML schemas</tt><br>
<tt>require knowledge of how to add additional namespaces and configure</tt><br>
<tt>IDEs to use them. That's not exactly trivial if all you want to do</tt><br>
<tt>is develop and use business logic.</tt><br>
<br>
<tt>The only caveat to this is that this spec. is supposed to integrate</tt><br>
<tt>JSF and EJB, so JSF developers are more likely to be familiar with</tt><br>
<tt>dealing with namespaces. However, I got the impression that the</tt><br>
<tt>developers this spec. would be most targetted at would be the business</tt><br>
<tt>logic developers.</tt><br>
<tt><br>
> Say I'm using a library written by someone else, that can be<br>
> configured using a web beans XML schema. How is this schema any<br>
> different from any other XML schema that is used by developers today<br>
> to configure stuff? Remember, the XML author is not required to know<br>
> anything at all about the underlying Java classes and methods to<br>
> author this configuration document. They get a schema, and they write<br>
> XML using the elements defined by that schema. They don't know that<br>
> the element names are actually Java class and method names.<br>
</tt><br>
<tt>A typical component developer doesn't knowingly deal with XML schema</tt><br>
<tt>unless they are a web services component developer.</tt><br>
<tt><br>
> If you're a *user* of the XML schema, a document author, you don't<br>
> need to know anything at all about how the Java classes relate to the<br>
> XML schema. If you're the provider of the XML schema, you also don't<br>
> need to know much about the rules, since the schema will be generated<br>
> for you.<br>
</tt><br>
<tt>But either you need to have knowledge of how XML Schema translates into</tt><br>
<tt>a syntactically and semantically correct XML document instance or you </tt><br>
<tt>have to have knowledge of how to setup tools to use XML schema to do</tt><br>
<tt>that for you. Either way, you have to know more than the average </tt><br>
<tt>developer does today.</tt><br>
<tt><br>
Thanks,<br>
Jim Knutson<br>
WebSphere J2EE Architect</tt><br>
<br>
</body></html>