The xjc doc claims that there is a catalog resolver in there, so if we push in the catalog we have, it should work. I failed to find it in the API last night, I'll look some more.
On Mon, Mar 23, 2009 at 8:32 PM, Benson Margulies <[email protected]>wrote: > I am about to bail and rethink. > > Here's the bailout plan: > > The tooling code is just too damn much of a mess for me. If it wants a > bunch of DOM elements keyed by the post-resolved URLs, it can have them. We > just need to stop the WSDLServiceBuilder from bothering to build this when > we're operating for normal purposes, so that they don't hang around forever > and ever and use up memory. If someone else has the necessary gumption to > sort out the catfight between the WSDL reader that can use a catalog and XJC > that cannot, they are welcome to do so. > > > On Mon, Mar 23, 2009 at 7:57 PM, Benson Margulies > <[email protected]>wrote: > >> There seems to be a big mess here with the resolver. >> >> We use a resolver. I don't see any evidence that xjc can use a resolver. >> The result is near-comprehensive confusion with the schema locations. >> >> I'm continuing to compost. >> >> >> >> On Mon, Mar 23, 2009 at 11:08 AM, Daniel Kulp <[email protected]> wrote: >> >>> On Mon March 23 2009 8:13:44 am Benson Margulies wrote: >>> > I've been trying to figure out how to obliterate oft-maligned DOM >>> cache, >>> > and I've run into a complexity. >>> > >>> > The JAXB tooling down in wsdlto needs, apparently, to be fed all the >>> > schemas -- even the imported schemas -- as top level documents. It >>> expects >>> > the WSDLServiceBuilder to leave a property hanging about that is a map >>> from >>> > string to Element. The strings are a document base URIs. So, for a >>> schema >>> > embedded in a WSDL, they are the WSDL URI, no fragment. >>> > >>> > Does this surprise anyone? >>> >>> Not entirely, but also something I would LOVE to see changed. :-) >>> >>> One issue of feeding DOM's to JAXB is that you don't get ANY line number >>> information at all from JAXB if an error pops up. What I think I'd >>> prefer to >>> do is have XmlSchema hold onto the System URI (not sure if it already >>> does, it >>> might already) for each schema and feed them to JAXB as StreamSource >>> things. >>> That would allow us to get real line number error messages from it at the >>> expense of parsing speed. >>> >>> I also think that JAXB xjc can handle the wsdl directly. It just pulls >>> the >>> schema out of it itself. Thus, even the schemas embedded in the wsdl >>> wouldn't >>> need to be DOM. >>> >>> > How does the Dynamic client work? does it use >>> > this same horror? >>> >>> Probably. Not really sure though. >>> >>> >>> -- >>> Daniel Kulp >>> [email protected] >>> http://www.dankulp.com/blog >>> >> >> >
