Dan Diephouse wrote:
>> See [1] for what's going on behind the scene. The problem is really in
>> the JAXP RI.
>>
> *Dan mutters bad bad things about Java and XML under his breath...*
:-)
This bug has been biting JAXB users hard enough that maybe I should go
in and fix the JAXP RI. I have some experience working in the JAXP RI,
so I can't entirely just blame the JAXP RI and be done with it.
And to be fair, this bug has been in Xerces and the JAXP RI simply
inherited it.
>> Since the import statement doesn't contain schemaLocation, JAXP is
>> failing to resolve them (unless your EntityResolver is resolving them
>> for us.) That's why you see all sort sof "undefined declaration" error.
>
> A couple questions about that. First, I already have the schema adding
> to the schema compiler. You think I should just return an InputSource
> with a systemId referring to that schema - i.e.
> http://..../Service.wsdl#types?schema1? Second, what if there are
> multiple schemas with that same namespace in that wsdl. It would seem to
> me (because I'm lazy ;-)) that JAXB should be able to determine that a
> schema is importing all the schemas of that namespace and work accordingly.
If those schemas are already submitted to XJC, then you don't have to do
anything with those import statements or entity resolvers. XJC will find
out that there are definitions available, and even if they are not
referenced each other, it will resolve to the right definition.
Ah, you know what, but the JAXP RI might not do that. It might still
complain, even though it found those definitions (!), because there's no
corresponding <xs:import> from the referer schema. If you ask me, they
put focus on a wrong thing, but anyway...
The other thing worth trying is to tell JAXB to bypass the JAXP RI
altogether. Try setting the
com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.noCorrectnessCheck
system property to true and see if that makes a difference. This is an
escape hatch I left in the code for cases just like this.
If this turns out to be useful we can enhance the API to expose it.
>> Have your entity resolver resolve them, or XFire WSDL compiler should
>> allow additional schema files to be specified via command-line option,
>> so that the JAXP RI (and XJC) can read all of them and find references
>> accordingly.
>>
> I don't think this is the issue, its more that I've added all the
> schemas and it seems that JAXB requires a System Id for the <import> or
> it won't know what to do. Is this correct?
I suspect it's the JAXP RI that's requiring it.
>>
>> This is off topic, but I see that you are parsing WSDL into something
>> that doesn't retain line numbers (DOM?) It would be nice if you can
>> keep line numbers around so that users see error messages with line
>> numbers. A lot of effort is spent in the JAXB RI to retain line
>> numbers and point to them, so you got to fix your side so that my
>> effort will see the light of the day :-)
>>
> Hehe, OK, the issue is we already have our WSDL parsed into a DOM from
> WSDL4J, so I didn't really want to reparse. Any suggestions?
I build DOM from SAX by myself and retain location information on the
side. See [1].
This is another thing that I've been asking the JAXP API to address. But
somehow this has never been fixed. DOM API is defined in W3C and the
WG disbanded, it's tricky to rev, I guess. But it's the users and
developers who suffer.
[1]
http://fisheye5.cenqua.com/browse/jaxb2-sources/jaxb-ri/xjc/src/com/sun/tools/xjc/reader/internalizer/DOMBuilder.java?r=1.2
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com