axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <gdani...@macromedia.com>
Subject WSDL generation bug / architectural problem
Date Tue, 15 Jan 2002 22:07:48 GMT

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

Mime
View raw message