|
History
| Log In
|
|
|
|
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.
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:
I updated the wsdl4j library and it did not solve my problem. I'm still getting a duplicated jaxb declaration
OK, will reopen and investigate more. thanks
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. 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:
to this: for (int i = attributes.getLength() - 1; i >= 0; i--) 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.
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" 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. 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.
Arghh, that is a good point. I'm going to look into getting WSDL4J fixed or possibly writing our own extensibility elements...
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. 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:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Major
Generated WSDL elements: duplicate xmlns:jaxb attribute
'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.