Comments about 3
<Putting on my this is 'good thing for Axis cap'>
The problem is that you will wind up building an entire in-core schema
model for your meta data instead of just building the model for the
programatic information you care about.
For example, do you really want to build up your model to include things
like comments ? What about nested sequence and all blocks ?
The solution to use the xml-schema string is a clean way to capture the
definitions from the original wsdl.
</Putting on my 'good thing for Axis cap'
<Putting on my 'custom serializer cap' >
The TypeDesc information is necessary for 3 reasons: Serializing,
Deserializing and Writing Schema.
If someone wants to write their own custom serializer they may have another
format of meta data or may not need any meta data at all to do the
serializering and deserializing. In such cases they still need to provide
writeSchema. It would be useful if the Types class provided an interface
such as addType(String xmlString, Map ns2prefix). Whoever is providing the
custom serializer would then have a convenient way to pass information to
Types...either passing an emitter generated xmlString or passing an
xmlString that was generated from their meta data.
(Might be nice if TypeDesc could have a generateSchema method.)
</Putting on my 'custom serializer cap'>
Now comments on 1:
I don't mind coealesing ClassRep and TypeDesc for implementation purposes.
I do not want to expose this as the only meta data interface. I don't want
to be forced to build all of this stuff up on each of my Bean classes.
Now comments on 2:
Providing an addType(String xmlString, Map ns2prefix) signature would clean
this up.
The we could change writeSchema(...) to something like:
String getSchema(Map ns2prefix)
which would return prefix -> mappings and the actual text of the schema
elements. Thus the Serializer would not have a dependency on Types.
Seems like a useful interface to me.
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
Glen Daniels
<gdaniels@macrome To: "'[EMAIL PROTECTED]'"
<[EMAIL PROTECTED]>
dia.com> cc:
Subject: RE: how to choose bean
attributes to publish in WSDL
04/17/2002 02:59
PM
Please respond to
axis-dev
Hola Rich!
> 1. One of the primary reasons why I created ClassRep was to get around
> problems using BeanInfo.
> I am purposely being silent so that I can see if someone else
> provides some
> better ideas on this work. Good luck.
TypeDesc does a lot of the job that ClassRep does, and as I think we've
talked about, I'd like to coalesce them into one class which is modularized
nicely into our Schema<->Java subsystem.
> 2. Also I still don't understand why the writeSchema code is in the
> BeanSerializer and is not
> in the wsdl/fromJava package. It seems like a pretty strange
> dependency
> between the runtime
> and the tooling. Couldn't we design this so that the schema
> writing code
> is in wsdl/fromJava/Types
> and requests the TypeDesc (or other meta data) from the bean ?
The reason I did it the way that currently exists is that we needed to emit
the correct schema for the Map type (complex schema completely unrelated to
introspecting the class structure). It had been known for a while that the
Serializer was the "right" place to ask for the schema (since it knows how
its going to write things), but we hadn't hooked it up that way. Since we
didn't have a better schema-esque object model, I just passed in a
reference to the Types object as a quick solution.
I think the solution you propose is definitely the right way to do things
for default (i.e. bean) serialization, but the code to trigger this
technique still wants to live in the default (i.e. bean) serializer, since
not all mechanisms/serializers will necessarily use TypeDescs.
> 3. Alternatively I would wish the bean had an xml string in
> TypeDesc that
> could be used directly by Java2WSDL
> in these cases. I have thought about this quite a bit and
> makes a lot of
> sense. We new the xml construct when the
> bean was created...so why not shove it directly in the bean
> meta data so
> that Java2WSDL can use it.
Hm - I'm not sure how I feel about this. I think I might rather see our
metadata model expand to encompass more of what schema can do, rather than
actually keeping the schema XML text in memory. In other words, keep
things in a programatically useful form (which will eventually include
things like constraint validation, etc), which can be written out to actual
angle-brackets at any time.
--Glen
