axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Jordahl <t...@macromedia.com>
Subject RE: Java2WSDL problem with java.lang.Object...
Date Tue, 05 Nov 2002 20:26:18 GMT
Doug,

Thanks for doing such a great job on analyzing this problem.  I encountered this same error
from WSDL2Java/WSDL4J just the other day and had not had a chance to puzzle out why the 1999
Schema was getting referenced.

Dims, you are THE MAN! :-)

--
Tom Jordahl
Macromedia Server Development



-----Original Message-----
From: Davanum Srinivas [mailto:dims@yahoo.com]
Sent: Friday, November 01, 2002 8:42 PM
To: axis-dev@xml.apache.org
Cc: Douglas.Bitting@agile.com
Subject: Re: Java2WSDL problem with java.lang.Object...


Fixed. See http://marc.theaimsgroup.com/?l=axis-dev&m=103620074508590&w=2

Thanks,
dims

--- Douglas Bitting <Douglas.Bitting@agile.com> wrote:
> 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
> 
> 


=====
Davanum Srinivas - http://xml.apache.org/~dims/

__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/

Mime
View raw message