WSDL generation bug / architectural problem

[Glen Daniels <gd...@macromedia.com>]

Let's say I have this service:

public class TestService {
    public TestData method1() { return new TestData(); }
}

with this data class:

public class TestData {
    private int val;
    public int getVal() { return val; }
    public void setVal(int i) { val = i; }
}

I deploy it:

<service name="Foo" provider="java:RPC">
  <parameter name="className" value="TestService"/>
  <parameter name="allowedMethods" value="*"/>
</service>

Then I hit it with http://myhost/axis/services/Foo?wsdl

The WSDL generation code will happily produce a schema type for the TestData class, despite the fact that the service won't actually function without a type mapping (the engine doesn't know how to serialize a TestData).

So this points to several different issues:

1) We should never emit an XML type definition that isn't going to actually work when it gets sent back to us.

2) The short-term solution to (1) is probably to have the WSDL generation code use the engine's type mapping registry (it really should be integrated with the engine type mapping registry anyway).  If a type is found in the various method signatures which has no mapping in the engine registry, the WSDL generation should fail with a reasonable error message.

3) As we move towards (2), we should not be generating the schema for each type in the wsdl.toJava classes themselves, because it's very possible to have a custom serializer/deserializer that generates different XML than you might expect.  Therefore, the current "beany" schema-generating code should probably get moved into the BeanSerializer/BasicSerializer, and we should have a new method to ask a *serializer* to give us schema for the given type.

4) A potential longer-term solution (which we've discussed before) is to have "default" Java<->XML serializers which can introspect classes without the need for type mappings.  So first look for an explicit mapping, then if that fails, attempt to send the class in question through the default JavaSerializer, which may well work.  This would give us the ability to just deploy services with no type mappings, which could be really cool.

Thoughts on all this?  Anyone want to volunteer to do some of this work?

--Glen