XFire

Generated WSDL elements: duplicate xmlns:jaxb attribute

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.2-RC, 1.2, 1.2.1
  • Fix Version/s: 1.2.2
  • Component/s: Core
  • Labels:
    None
  • Environment:
    I'm not using Annotations, this is generated by an XFireExporter from within a Spring Configuration.
  • Number of attachments :
    2

Description

Still testing XFire 1.2RC1, it seems that my previously working configuration (xfire 1.1.1) no longer generates valid WSDL. The Wsdl generated throws the following error in my browser's XML Validator:
XML Parsing Error: duplicate attribute
Location: http://localhost:8081/warfile/MyService?wsdl

This is caused by the following excerpt of WSDL:
<xsd:element xmlns:xsd=" http://www.w3.org/2001/XMLSchema" name="allocateStuff" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:complexType>
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="1" name="in0" nillable="true" type="tns:Message"/>
<xsd:element maxOccurs="1" minOccurs="1" name="in1" nillable="true" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="allocateStuffResponse" xmlns:xsd=" http://www.w3.org/2001/XMLSchema">
<xsd:complexType>
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="1" name="out" nillable="true" type="tns:Message"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>

Dan tells me if there is a problem it will be around line 133 of WSDLBuilder.java , I've looked at this code and I can't immediately see why it wouldn't work as expected, there are no case-mismatch problems for example, very strange, but also very important to fix (for me at least) as my WSDL is completely invalid!

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Brad Davis added a comment -

I've reduced the problem to this small self contained tgz file. Using maven2 you should be able to issue the command
'mvn clean compile war:war' and it will generate a war file in the target directory. Tossing this into a container and trying to show the WSDL generates an error page in firefox due to the duplicate attribute.

Show
Brad Davis added a comment - I've reduced the problem to this small self contained tgz file. Using maven2 you should be able to issue the command 'mvn clean compile war:war' and it will generate a war file in the target directory. Tossing this into a container and trying to show the WSDL generates an error page in firefox due to the duplicate attribute.
Hide
Permalink
Brad Davis added a comment -

I'm having a similar problem that was not fixed as of 1.2.1. I'm using a set of JAXB classes with an annotated interface generating the WSDL. If I include the schema delcaration in my service.xml then I get a duplicate attribute jaxb attribute in my resulting WSDL. I really want to use the latest version since I need xfire to do validation on the incoming request.

Show
Brad Davis added a comment - I'm having a similar problem that was not fixed as of 1.2.1. I'm using a set of JAXB classes with an annotated interface generating the WSDL. If I include the schema delcaration in my service.xml then I get a duplicate attribute jaxb attribute in my resulting WSDL. I really want to use the latest version since I need xfire to do validation on the incoming request.
Hide
Permalink
Dan Diephouse added a comment -

Turns out this is a bug in WSDL4J. To fix, simply drop in a new version of WSDL4J. I've uploaded one here for convenience:

http://envoisolutions.com/~dan/wsdl4j-1.6.jar

Show
Dan Diephouse added a comment - Turns out this is a bug in WSDL4J. To fix, simply drop in a new version of WSDL4J. I've uploaded one here for convenience: http://envoisolutions.com/~dan/wsdl4j-1.6.jar
Hide
Permalink
Brad Davis added a comment -

I updated the wsdl4j library and it did not solve my problem. I'm still getting a duplicated jaxb declaration

Show
Brad Davis added a comment - I updated the wsdl4j library and it did not solve my problem. I'm still getting a duplicated jaxb declaration
Hide
Permalink
Dan Diephouse added a comment -

OK, will reopen and investigate more. thanks

Show
Dan Diephouse added a comment - OK, will reopen and investigate more. thanks
Hide
Permalink
Brad Davis added a comment -

this patch seems to resolve the problem. The problem arises in com.ibm.wsdl.util.xml.DOM2Writer.java. When the wsdlbuilder outputs the schema its printed out via this class. The schema at this point has the jaxb namespace declaration attribute, in addition to a number of jaxb prefixed attributes. When the printer outputs the first jaxb prefixed attribute it can't locate the jaxb namespace in the map, so it explicitly outputs a jaxb namespace declaration, which is then duplicated by a later attribute.

Ostensibly the class in question should be looking through the attributes and making sure it doesn't duplicate any namespace declarations already extant. It doesn't though. I don't know enough about the class to determine if its a bug. However, modifying the WSDL builder to remove all namspace declarations in teh types seems to resolve it.

Show
Brad Davis added a comment - this patch seems to resolve the problem. The problem arises in com.ibm.wsdl.util.xml.DOM2Writer.java. When the wsdlbuilder outputs the schema its printed out via this class. The schema at this point has the jaxb namespace declaration attribute, in addition to a number of jaxb prefixed attributes. When the printer outputs the first jaxb prefixed attribute it can't locate the jaxb namespace in the map, so it explicitly outputs a jaxb namespace declaration, which is then duplicated by a later attribute. Ostensibly the class in question should be looking through the attributes and making sure it doesn't duplicate any namespace declarations already extant. It doesn't though. I don't know enough about the class to determine if its a bug. However, modifying the WSDL builder to remove all namspace declarations in teh types seems to resolve it.
Hide
Permalink
Brad Davis added a comment -

I found that my patch only worked intermittently. I finally figured out that this was because the list of attributes is being changed while its being iterated through. So if I have 5 attributes and I examine and then remove item at index 0, the next attribute I look at, in index 1 is the one that was previously at index 2, and I never actually examine the attribute at index 1. To resolve this I'm now going through the attributes in reverse order by changing the for loop here:

http://svn.xfire.codehaus.org/browse/xfire/trunk/xfire/xfire-core/src/main/org/codehaus/xfire/wsdl11/builder/WSDLBuilder.java?r=1933#l137

to this:

for (int i = attributes.getLength() - 1; i >= 0; i--)

Show
Brad Davis added a comment - I found that my patch only worked intermittently. I finally figured out that this was because the list of attributes is being changed while its being iterated through. So if I have 5 attributes and I examine and then remove item at index 0, the next attribute I look at, in index 1 is the one that was previously at index 2, and I never actually examine the attribute at index 1. To resolve this I'm now going through the attributes in reverse order by changing the for loop here: http://svn.xfire.codehaus.org/browse/xfire/trunk/xfire/xfire-core/src/main/org/codehaus/xfire/wsdl11/builder/WSDLBuilder.java?r=1933#l137 to this: for (int i = attributes.getLength() - 1; i >= 0; i--)
Hide
Permalink
Dan Diephouse added a comment -

So it seems like we should just be removing any and all namespace declarations - that is bizarre. Stupid IBM crap code. Thank you so much for figuring out the underlying issue. I'll apply this ASAP.

Show
Dan Diephouse added a comment - So it seems like we should just be removing any and all namespace declarations - that is bizarre. Stupid IBM crap code. Thank you so much for figuring out the underlying issue. I'll apply this ASAP.
Hide
Permalink
Brad Davis added a comment -

I actually tried to remove all the namespace attributes and that still caused a problem. here is the header to my actual XSD

<xsd:schema version="1.0" elementFormDefault="qualified" targetNamespace="http://types.xml.cms.real.com"
xmlns:cms="http://types.xml.cms.real.com"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"
jaxb:extensionBindingPrefixes="xjc"
jaxb:version="1.0">

Now if I remove all the namespace prefixes then you get left, then the wsdl4j puts back in the ones that are used, in this case xsd and jaxb. However, because there are no instances of cms, or xjc in the attributes, they don't get added back in by wsdl4j, when they're encountered later in the XSD, they remain unresolved. The ideal solution would be for WSDL4J to parse the damn namespace attributes in the element and then not create duplicates of already extant ones.

Show
Brad Davis added a comment - I actually tried to remove all the namespace attributes and that still caused a problem. here is the header to my actual XSD <xsd:schema version="1.0" elementFormDefault="qualified" targetNamespace="http://types.xml.cms.real.com" xmlns:cms="http://types.xml.cms.real.com" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:jaxb="http://java.sun.com/xml/ns/jaxb" xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc" jaxb:extensionBindingPrefixes="xjc" jaxb:version="1.0"> Now if I remove all the namespace prefixes then you get left, then the wsdl4j puts back in the ones that are used, in this case xsd and jaxb. However, because there are no instances of cms, or xjc in the attributes, they don't get added back in by wsdl4j, when they're encountered later in the XSD, they remain unresolved. The ideal solution would be for WSDL4J to parse the damn namespace attributes in the element and then not create duplicates of already extant ones.
Hide
Permalink
Brad Davis added a comment -

oh, I don't know how generally applicable this solution is, but my end solution was to apply an XSLT transform to the incoming XSD before it goes into the WSDL. I have the transform as part of my build process now, but its possible XFire could do something similar when it generates the WSDL, stripping out anything that isn't strictly schema.

Show
Brad Davis added a comment - oh, I don't know how generally applicable this solution is, but my end solution was to apply an XSLT transform to the incoming XSD before it goes into the WSDL. I have the transform as part of my build process now, but its possible XFire could do something similar when it generates the WSDL, stripping out anything that isn't strictly schema.
Hide
Permalink
Dan Diephouse added a comment -

Arghh, that is a good point. I'm going to look into getting WSDL4J fixed or possibly writing our own extensibility elements...

Show
Dan Diephouse added a comment - Arghh, that is a good point. I'm going to look into getting WSDL4J fixed or possibly writing our own extensibility elements...
Hide
Permalink
James Sparrow added a comment -

I ran into this same issue, duplicate jxb namespace decl. I was able to patch the wsdl4j 1.6.1 code to fix it--see https://sourceforge.net/tracker/?func=detail&atid=712792&aid=1568015&group_id=128811. It appears like an ordering problem in the processing of attributes in wsdl4j's DOM2Writer.

Show
James Sparrow added a comment - I ran into this same issue, duplicate jxb namespace decl. I was able to patch the wsdl4j 1.6.1 code to fix it--see https://sourceforge.net/tracker/?func=detail&atid=712792&aid=1568015&group_id=128811. It appears like an ordering problem in the processing of attributes in wsdl4j's DOM2Writer.
Hide
Permalink
Dan Diephouse added a comment -

OK, I wrote a custom serializer for WSDL4J and things seem to be working fine. If you use a normal WSDL4J and this build, things should work:

http://snapshots.repository.codehaus.org/org/codehaus/xfire/xfire-all/1.2-SNAPSHOT/xfire-all-1.2-20061002.035146-25.jar

Show
Dan Diephouse added a comment - OK, I wrote a custom serializer for WSDL4J and things seem to be working fine. If you use a normal WSDL4J and this build, things should work: http://snapshots.repository.codehaus.org/org/codehaus/xfire/xfire-all/1.2-SNAPSHOT/xfire-all-1.2-20061002.035146-25.jar

People

Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.