cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: A plague of DOMs
Date Tue, 24 Mar 2009 15:25:19 GMT
On Tue March 24 2009 7:00:16 am Benson Margulies wrote:
> 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.

There is a org.apache.cxf.catalog.OASISCatalogManager object on the bus that 
holds the catalogs.    It has a "Set<URL> loadedCatalogs", but I don't see a 
getter for it.   Feel free to add it.   :-)

THAT said, without a pluggable resolver, there are going to be other issues.   
For example, right now,  the resolver will delegate to our http conduit stuff 
for https so the https certs and truststores and stuff can get setup.    Just 
setting a catalog won't allow that.    

Thus, my "gut feeling" suggestion for now would be to add a flag to 
WSDLServiceBuilder to add the schema dom trees.   The tooling could just set 
that.   

Dan


>
> On Mon, Mar 23, 2009 at 8:32 PM, Benson Margulies 
<bimargulies@gmail.com>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 
<bimargulies@gmail.com>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 <dkulp@apache.org> 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
> >>> dkulp@apache.org
> >>> http://www.dankulp.com/blog

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog

Mime
View raw message