cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: A plague of DOMs
Date Tue, 24 Mar 2009 11:00:16 GMT
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 <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
>>>
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message