axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "R J Scheuerle Jr" <sc...@us.ibm.com>
Subject Re: WSDL generation bug / architectural problem
Date Tue, 15 Jan 2002 23:17:35 GMT
Comments embedded as <RJS>

Rich Scheuerle
XML & Web Services Development
512-838-5115  (IBM TL 678-5115)


                                                                                         
                                        
                      Glen Daniels                                                       
                                        
                      <gdaniels@macrome        To:       "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
                   
                      dia.com>                 cc:                                    
                                           
                                               Subject:  WSDL generation bug / architectural
problem                              
                      01/15/2002 04:07                                                   
                                        
                      PM                                                                 
                                        
                      Please respond to                                                  
                                        
                      axis-dev                                                           
                                        
                                                                                         
                                        
                                                                                         
                                        




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.

<RJS> I don't understand why the deployment doesn't contain the proper bean
mappings.  Isn't this an error?<?RJS>

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.

<RJS> I believe that the WSDL generation code is integrated with the
TypeMappingRegistry.  For the
stand-alone case, Java2WSDL should not care.  For ?wsdl on the client side,
the assumption is that the
user will use the ?wsdl output to build stubs, etc.  so this is not a
problem.  On the server-side, ?wsdl
should either fail or deploy the requested beanmappings. Does this make
sense? </RJS>



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.

<RJS> I prefer getting the framework to match JAX-RPC before making more
changes. </RJS>

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.

<RJS> I agree, but even these serializers should be JAX-RPC compliant and
easily extended by users. </RJS>

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

--Glen




Mime
View raw message