axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Douglas Bitting <Douglas.Bitt...@agile.com>
Subject Java2WSDL problem with java.lang.Object...
Date Fri, 01 Nov 2002 23:10:48 GMT
Hi.

I recently filed a Bugzilla report (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14182)
on this issue.  I hope someone else can come up with a
fix faster than I can... however, it's rather a serious problem for me, so I'm trying to puzzle
through this myself.  Here's what I've found thus far.

In org.apache.axis.encoding.DefaultTypeMappingImpl, you find the following during default
type mapping initialization:

        // The closest match for anytype is Object
        myRegister(Constants.XSD_ANYTYPE,    java.lang.Object.class,
                   null, null);

This causes "xsd:anyType" to be bound to java.lang.Object.  This registration sets up a number
of mappings, including QName->JavaType and
JavaType->QName.  It's the latter of these which plays a part in this defect.

When registering a QName that is part of the XML Schema Namespace, Axis registers that mapping
for all versions of the XML Schema.  Thus, the above
will cause the following QName->JavaType mappings:

1) {http://www.w3.org/1999/XMLSchema}anyType -> java.lang.Object
2) {http://www.w3.org/2000/10/XMLSchema}anyType -> java.lang.Object
3) {http://www.w3.org/2001/XMLSchema}anyType ->java.lang.Object

The order of the above is the order in which this internal registering happens.  The "problemmatic"
portion of this is the setting up of the
JavaType->QName mapping.  In this case, since the same Java type is the key of the map,
only the first mapping is used.  This is ensured by the
following code, found in org.apache.axis.encoding.TypeMappingImpl#internalRegister (Line 290):

        if ((sf != null) || (class2Pair.get(javaType) == null))
            class2Pair.put(javaType, pair);

This code ensures that a JavaType->QName mapping is not overridden.  I don't know if this
is wrong behavior or not... but it's the current
functionality.

Later on in the WSDL-generation process, the actual WSDL Messages and Parts are constructed.
 As part of this construction, the ParameterDesc for the
java.lang.Object object is retrieved, and the getTypeQName method is called on this ParameterDesc.
 This always returns
{http://www.w3.org/1999/XMLSchema}anyType since that was the first type mapping registered
for java.lang.Object.

When Types.writeType for this QName is invoked, this is shortcircuited to always emit "xsd:anyType,"
where "xsd" presumably is supposed to be the
latest support XML Schema version (i.e., http://www.w3.org/2001/XMLSchema, right now).  I
think this might be meaningless data for this issue.

Finally, when handed off to WSDL4J in order to convert the generated WSDL to an XML Document,
WSDL4J will eventually call ParameterDesc.getTypeQName
for java.lang.Object and receive {http://www.w3.org/1999/XMLSchema}anyType.  However, this
XML Namespace has net been registered with the XML
Document, hence an exception is raised...

So, that's what I know.  I don't know if the solution is to be found somewhere in the above,
or if it is somewhere else.  However, the crux of the
issue seems to be that the JavaType->QName mapping is only accepting the first mapping
passed its way.  It seems that it should employ a
last-one-registered wins tactic when dealing with this... and in fact, that's the tactic employed
if a serialization factory is provided during
registration.  However, since java.lang.Object doesn't provide a serialization factory, it
ends up with this somewhat odd behavior.

Is the right thing simply to special case TypeMappingImpl#internalRegister so that java.lang.Object
employs a last-one-registered wins behavior?
Something else? 

Cheers,
--Doug

Doug Bitting
Agile Software
1 Almaden Blvd
San Jose, CA  95113
(408) 999-7120



Mime
View raw message