axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric.D.Fried...@wellsfargo.com
Subject RE: WSDL2Java code generation req'ts
Date Thu, 14 Aug 2003 21:47:15 GMT
Hi Tom,

Thanks for the helpful response.  Here are some additional notes in answer
to your questions:

re: validation -- web services clients typically need to assemble object
graphs that get sent out over the wire to do some useful work.  A well
behaved client will make an effort to avoid sending garbage to the server.
So, if the schema the two agreed to abide by says that a <person> must have
a <name>, a well-behaved client will not permit its invoker to send a
nameless person (Person p = new Person(); p.setName(null);) over the wire.
So, it would be useful to have the capability to check that such objects are
indeed valid before sending them to the server.  You could imagine that this
would be implemented as a Handler in the chain of handlers that precede the
transport-pivot in Axis and that users might only enable such a handler
during development.  This class of validation could be termed "content model
integrity" -- it would include checks for conformance to cardinality (don't
exceed maxOccurs) and composition (which branch of an xs:choice are you
sending?).

A simpler, but no less useful kind of validation would enforce facets on
member variables whose type is simple.  So, if the schema says that <foo>
bears an xs:short between -4 .. 63, you would expect public void
setFoo(short s); to throw an IllegalArgumentException when s doesn't fall in
the prescribed range.  Ditto for regex facets and the like.  You might
imagine that this kind of code would be optionally emitted by the code
generator -- useful during development; possibly undesirable in production
code.

re: xerces itself.  Unfortunately it's all in the same jar.  However, I
don't think (not sure) that the mere presence of Xerces in the classpath
causes it to usurp the place of, say, Crimson as the XML parser returned by
the JAXP apis. I think you have to specifically configure the runtime to
replace the "standard" parser as of java 1.4.  (again, not sure).  

Given that it's desirable to support most/all of Schema from within axis, I
wonder:  should we tackle this challenge again, ourselves?  Or should we
punt and point people to the schema -> java generators provided by Castor
and JAXB, both of which are quite complete but not licensed under Apache
licenses?

Eric

-----Original Message-----
From: Tom Jordahl [mailto:tomj@macromedia.com]
Sent: Thursday, August 14, 2003 2:16 PM
To: 'axis-dev@ws.apache.org'
Subject: RE: WSDL2Java code generation req'ts


Eric,
 
I think we have always wanted to support as much of XML Schema as we can.
The JAX-RPC list is a bare minimum and certainly we support more than that.

+1 to replacing the Schema parser in WSDL2Java.
+50 to adding support for more(all?) schema types in 1.2.

JAX-RPC is going to synchronize with JAXB at some point and get out of the
business of parsing XSD and mapping to Java. The problem is that they (and
we) need to go both ways Java->XSD and XSD->Java.  1+ years ago, JAXB wasn't
done with a single direction.  It would be awesome to throw out 99% of our
code and just use a jar file to do this work. :-)

I am confused about what validation (and when) you want to do.  Could you
clarify that?

Does using Xerces mean we will have a hard dependancy on it, or is the
Schema stuff in a different jar file?

--
Tom Jordahl

-----Original Message-----
From: Eric.D.Friedman@wellsfargo.com
To: axis-dev@ws.apache.org
Sent: 8/14/2003 1:05 PM
Subject: WSDL2Java code generation req'ts

Can someone please tell me what level of support WSDL2Java is required
to
have vis-a-vis XML schema?  Is it *just* what's described in the JAX-RPC
spec?  Do we want to tackle some/any/all of what's in the JAXB spec, or
is
that entirely out of scope?

I am asking as a follow-up to the recent discussion about the
performance of
WSDL2Java.  As I mentioned in that thread, I believe it's possible to
get
dramatically better performance using the schema parser in Xerces.
Indeed,
I know it's possible, as I've hacked together a working prototype to
generate java beans from complex types and it's a lot faster than
wsdl2java.

So, the question before you is what's the minimum level of schema
support
WSDL2Java is required to have?  Clearly JAX-RPC is included, but is that
it?
Or do we want to (need to) add support for xs:choice, substitution
groups,
and so forth?

Some nice-to-haves that I can think of are: (1) some degree of
validation
support; (2) transfer <xs:annotation> elements to the javadoc for the
corresponding types/instance variables.

Thanks,
Eric

Mime
View raw message