gavin.king@gmail.com wrote on 12/24/2008 07:01:21 PM:

> On Wed, Dec 24, 2008 at 12:23 PM, Michael Keith
> <MICHAEL.KEITH@oracle.com> 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 forbeginners,
> > 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

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.

I would hate to have to use one methodology for web apps and another
for EJBs and something completely different again for this spec.

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

Possibly, though many enterprise customers I know are looking at
continuing to use XML DDs for their own component libs because it
ensures they understand and have control over their metadata (e.g.
some maintenance defect won't change security roles by accident).

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

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.

Thanks,
Jim Knutson
WebSphere J2EE Architect