RE: Default bean mappings

[Glen Daniels]

Title: Default bean mappings

I want to understand exactly what you're after here.  You're looking for transparent end-to-end Java->WSDL->Java, right?

 

First off, for services where you have an explicit mapping of a type, you should get whatever QName you've mapped.  In other words, the "model.address.myapp" pattern will only happen when there is NO mapping for a particular type.  Right now, I think we may not even emit unmapped types for dynamically generated WSDL on a running service (since the type has to be mapped to be useful, and this is really a broken deployment).

 

Into the future, I can see two ways of doing this, one of which we've been discussing and one of which we haven't yet.

 

1) Use a well-defined "java:" namespace by default for generated WSDL without explicit mappings.  In other words, we allow you to deploy services with NO typemappings even on the server side, and we'll generate WSDL with type QNames like "java:myapp.address.model.Address".  Then our stub generator does the right thing with auto-mapping these guys to the right classes when it sees one of those types.  The bonus here is that GLUE (and perhaps WASP as well) do something exactly like this, and assuming our default mappings are the same, we'd get seamless interoperability with those toolkits.

 

2) Optionally emit an extensibility element (axis-specific) for ALL generated types, which indicates a "suggested" Java class to use.  This would allow our stubgen to be smart about this as well.

 

Neither of these options rely on having to deconstruct a particular namespace generation scheme, which I think would be VERY brittle.

 

Cheers,

--Glen

-----Original Message-----
From: Sedukhin, Igor [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 08, 2002 8:55 AM
To: [EMAIL PROTECTED]
Subject: Default bean mappings

This bugs me for a while already. May be there is a reason it is happening this way, but please refresh me on it.

Here is what:
By default Emitter generates type namespaces and type declarations like this:
<wsdl:definitions ... xmlns:tns1="http://model.address.myapp" ...>
<types>
<schema targetNamespace="http://model.address.myapp" ...>
<complexType name="Address"> ...
This is basically for a class myapp.address.model.Address.

So, why is it that I had to explicitly declare beanMappings during the deployment for proper ser/deser to be selected by the RPCHandler? It seems it is very easy to try and reconstruct a class name from the default assumption about the namespace format and then check if the class is loadable, then only apply explicit beanMappings.

I'd really like to get it this simple.
It is possible to change DefaultTypeMappingImpl to implement getTypeQName, getSerializer and getDesearializer to take care of it as explained above.

Does anyone have objection or comments on this?

-- Igor Sedukhin .. ([EMAIL PROTECTED])
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788