Scott --
I didn't think you'd reply so quickly! Well, I implemented this change
to get them past their problem. I don't ever recall seeing anything
about a contract to propagate the EntityResolver. And I agree with you
that this also opens the question about the features and properties.
In this particular case, there was a URIResolver present. However, I
was also thinking about the case where -EntityResolver was used from the
command line without a -URIResolver. In this case, we'd be requiring
the user to write a URIResolver if they wanted their EntityResolver
specified on the command line to be used for anything other than the
initial document.
I agree with you that that's not so bad. I'm going to send an email to
the original reporter of the bug and propose that I back out the change
and that we -not- propagate the EntityResolver and that they enhance
their URIResolver if that's the behavior they want. Unless they can
think of something that we haven't thought of, I'll back out the change.
I've had a queasy feeling about this issue ever since it came to my
attention which is why I brought it up. You've clarified things for me,
as usual.
Thanks,
Gary
[EMAIL PROTECTED] wrote:
>
> 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
