You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Jeff Fassler (JIRA)" <ax...@ws.apache.org> on 2006/05/12 17:46:09 UTC
[jira] Commented: (AXIS-1720) Java2WSDL, repeated types
auto-mapping to xsd:anyType causes bad definition in schema
[ http://issues.apache.org/jira/browse/AXIS-1720?page=comments#action_12383215 ]
Jeff Fassler commented on AXIS-1720:
------------------------------------
If you replace the code:
if (!addToTypesList(qName) && !anonymous) {
if (containingElement != null) {
containingElement.setAttribute("type", getQNameString(qName));
}
return true;
}
with the following:
String namespaceUri = qName.getNamespaceURI();
String lastSixCharsOfUri = namespaceUri.substring(namespaceUri.length() - 6, namespaceUri.length());
String lastFiveCharsOfUri = namespaceUri.substring(namespaceUri.length() - 5, namespaceUri.length());
if (!addToTypesList(qName) && !anonymous && !lastSixCharsOfUri.equals(".javax") && !lastFiveCharsOfUri.equals(".java")) {
if (containingElement != null) {
containingElement.setAttribute("type", getQNameString(qName));
}
return true;
}
then the issue for .java and .java type is solved, plus you are not left with the problem of excess warnings being thrown. I haven't tested vs doc/lit wsdl generation. It is a big kludgy, but it solves the problem.
> Java2WSDL, repeated types auto-mapping to xsd:anyType causes bad definition in schema
> -------------------------------------------------------------------------------------
>
> Key: AXIS-1720
> URL: http://issues.apache.org/jira/browse/AXIS-1720
> Project: Apache Axis
> Type: Bug
> Components: WSDL processing
> Versions: 1.2RC2
> Environment: J2SDK 1.4.2_06, Win2k
> Reporter: Brett Randall
> Attachments: AXIS-1720.patch.txt
>
> org.apache.axis.wsdl.fromJava.Types
> When running Java2WSDL on a class, if a type appears in the hierarchy contains more than once, _and_ that type is one without a SerializerFactory mapped _and_ it is a class that fails the isBeanCompatible test, Java2WSDL will create an invalid schema, by creating a namespace and then referencing a non-existent type in that namespace.
> Test class: java.util.Locale. Such a class fails the isBeanCompatible test, due to its package.
> If a single field of type Locale exists in a type hierarchy, all is fine: Types can't find a serializer factory, so BeanSerializer defaults to XSD_ANYTYPE when types.writeType returns null.
> If two fields of the same type that fail isBeanCompatible occur in a type hierarchy, the first one is marked to be serialized as XSD_ANYTYPE, however the second one causes a problem, and is marked with a namespace, however the type is never defined in that namespace.
> The cause is the too-early adding-to-namespace-list of the qname, which is occuring before Types discovers that the type has no suitable factory. The next pass through Types for the same class type causes a false hit on the already-processed list, and a bad namespace is assigned as a result.
> My fix for this is to move this block of code from Types.makeTypeElement():
> // If we've already got this type (because it's a native type or
> // because we've already written it), just add the type="" attribute
> // (if appropriate) and return.
> if (!addToTypesList(qName) && !anonymous) {
> if (containingElement != null) {
> containingElement.setAttribute("type", getQNameString(qName));
> }
> return true;
> }
> ... down the method until after the point when a suitable SerializerFactory has been located, or not in the case of a class like java.util.Locale, in which case the false namespace mapping will not occur.
> If Java2WSDL is run against a class (or class hierarchy) with two fields of the same such type, the resulting schema will include a reference to a namespace:type that will not appear in the schema.
> Patch and very basic TestCase to follow (third method fails on 1.2RC2). TestCase is based on the current contract of Types.writeType(), which must return null if a schema could not be created.
> Feel free to query me on this bug, as it is a little unusual.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira