gavin.king(a)gmail.com wrote on 12/24/2008 07:01:21 PM:
On Wed, Dec 24, 2008 at 12:23 PM, Michael Keith
<MICHAEL.KEITH(a)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