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 >
