Am 20.07.2011 15:24, schrieb Michael Glavassevich:
Thomas,
Not sure if there's a better way to fix XERCESJ-809, but agree that
what was done is trading one problem for another.
If you're stuck, you could always build Xerces from source, reversing
the patch for XERCESJ-809.
Yeah this is open source. I could do that. But I definitively like to
see that fixed upstream. So maybe the best is to file a bug on that issue.
Thank you for pointing me to the report.
regards,
Thomas
Thanks.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrgla...@ca.ibm.com
E-mail: mrgla...@apache.org
Thomas Scheffler <thomas.scheff...@uni-jena.de> wrote on 07/20/2011
08:30:28 AM:
> Am 20.07.2011 13:26, schrieb Michael Glavassevich:
> >
> > Thomas,
> >
> > Have you read this thread [1]? What you're observing for
> > EntityResolver2 is probably due to the same change.
>
> Hi,
>
> yes this is exactly the same issue I ran to it here. Don't know if
it is
> a good idea to change the behavior here. I use the EntityResolver2
> interface as this allows systemId to be relative and be interpreted by
> the implementation as opposed to the EntityResolver interface, where it
> is always expanded to an absolute URI. If xerces as no clue about the
> baseURI (source is inputstream, e.g. blob from database), it expands it
> to the current directory, where the Java process is started. Or else it
> uses the baseURI to expand it by itself.
> For example the standard parser of Oracle Java 6 SDK, does not do that.
> It is extremely sad, that Xerces 2.11.0 puts some logic into it, when
> this is expected to handled by the implementation of EntityResolver2.
> What makes this even more inconsistent is the fact, that XML Schema
> documents requested by other XML Schema documents are indeed requested
> as a relative URI.
> Until 2.11.0 I could trust that a absolute URI is valid and that
> relative URIs could be loaded as a resource from the classpath of my
> implementation. Now I have to restore the "relative information" by
> guessing it from the supplied URI. And guessing is most times a bad
thing.
>
> I wonder if there is no other way to fix XERCESJ-809, without breaking
> compatibility. Apart of that I could not understand the description of
> the mentioned bug.
>
> regards
>
> Thomas Scheffler
>
> > [1] http://xerces.markmail.org/thread/zpazk5bukquyijan
> > > Hi,
> > >
> > > after an upgrade from xerces 2.9 to 2.11.0 I noticed a different
> > > behavior with a EntityResolver2 implementation.
> > >
> > > If I parse an XML file with a schema defined with a relative
> > > systemId, Xerces always resolves the systemId to an absolute one.
> > > This is the behavior of the EntityResolver interface and should not
> > > be the same with EntityResolver2, where the implementation should
> > > resolve relative systemIds.
> > >
> > > Should I file a bug for this? This is a rather urgent problem and
> > > I cannot move back to 2.9.0, as this version cannot validate MODS
> > > documents correctly.
> > >
> > > regards
> > >
> > > Thomas Scheffler
> > >
> > >
---------------------------------------------------------------------
> >
> > >
> > To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org
> > > For additional commands, e-mail: j-users-h...@xerces.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org
> For additional commands, e-mail: j-users-h...@xerces.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org
For additional commands, e-mail: j-users-h...@xerces.apache.org
