I think this is my #2 on my other reply on this subject.
I just reread the bug report. I'm still not sure what contract requires us
to propagate the EntityResolver. What about the features and properties?
Shouldn't they be propigated also?
Why can't they just create a SAXSource that holds their own XMLReader in
their SimpleURIResolver??
I just hate to get in the business of propagating things like
EntityResolver. Hell, maybe that is NOT what a given user wants. That's
why URIResolver and SAXSource are designed the way they are... to simplify
our life and give the control they need to the caller by letting them
directly control their XMLReader.
-scott
Gary L Peskin
<garyp@firste To: [EMAIL PROTECTED]
ch.com> cc: (bcc: Scott Boag/CAM/Lotus)
Subject: Re: Help re bugfix retrofit -
Ignore previous message
06/15/2001
01:19 AM
Please
respond to
xalan-dev
Aarrrgh! I spoke to soon. The primary reader is no longer available
which is fine. I now have a new idea. It's kind of hokey but it does
make a certain amount of sense. I'd appreciate any feedback.
The source is now associated with a DTM via the getDTM(5 argument) call
to the DTMManager. What I'm doing is adding a field into
DTMManagerDefault called m_lastEntityResolver that holds the last use
EntityResolver. Then, I'm adding the following logic which effectively
carries over to each getDTM call the EntityResolver in use on the
previous call. In getXMLReader():
EntityResolver currentEntityResolver = reader.getEntityResolver();
if (null != currentEntityResolver)
m_lastEntityResolver = currentEntityResolver;
else if (null != m_lastEntityResolver)
reader.setEntityResolver(m_lastEntityResolver);
Thus, within a single DTMManager, the EntityResolver will be carried
over from one reader to the next.
I promise this is my last post on the subject for now.
Thoughts?
Gary
Gary L Peskin wrote:
>
> Scott et al --
>
> I need to retrofit my fix for Bug 1830 into the DTM version of XalanJ.
> However, this will require a change to DTMManager and DTMManagerDefault
> so I wanted to check in with you and let you know what I'm doing and see
> if you think its okay or have an idea for another approach.
>
> The problem reported in this bug is that EntityResolvers set in the
> primary XMLReader are not propagated through to subsequent XMLReaders.
> For example, when the document() function is used, an XMLReader is
> created automatically in DTMManagerDefault.getXMLReader() but the
> EntityResolver is not propagated into the automatically created reader.
>
> In order to propagate the EntityResolver, I need to get the existing
> EntityResolver from the primary reader at the time that the new
> XMLReader is created. This is contained in the XPathContext but no
> context is currently available to the DTMManager, even though the
> DTMManager is created by the XPathContext and nowhere else. So, my idea
> is to add a field to the DTMManager for the creating XPath instance.
> Then, when the new XMLReader is created, the DTMManager implementation
> can call back to the XPathContext to get the primary reader and then get
> its EntityResolver and set that into the newly created reader.
>
> I don't really see another way to do it but I was interested in your
> thoughts. I hate to add a reference in the DTMManager to its creating
> XPathContext but I didn't think I had a choice.
>
> Thoughts?
>
> Gary
