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 >> > >
