You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xerces.apache.org by Thomas Scheffler <th...@uni-jena.de> on 2011/07/20 11:59:36 UTC
EntityResolver2 interface and Xerces 2.11
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-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
Re: EntityResolver2 interface and Xerces 2.11
Posted by Dick Deneer <di...@donkeydevelopment.com>.
Hi Thomas,
One vote from me too solve this. It breaks down my compatibilty too.
Dick Deneer
Op 21-jul-2011, om 16:03 heeft Thomas Scheffler het volgende geschreven:
> Am 20.07.2011 15:53, schrieb Michael Glavassevich:
>> Thomas Scheffler <th...@uni-jena.de> wrote on 07/20/2011
>> 09:47:53 AM:
>>
>> > 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.
>>
>> Sure, feel free to open a JIRA issue.
>
> For the records:
> https://issues.apache.org/jira/browse/XERCESJ-1519
>
> regards,
>
> Thomas Scheffler
>
> --
> Thomas Scheffler
> Friedrich-Schiller-Universität Jena
> Thüringer Universitäts- und Landesbibliothek
> Bibliotheksplatz 2
> 07743 Jena
> Phone: ++49 3641 940027
> FAX: ++49 3641 940022
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-users-help@xerces.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
Re: EntityResolver2 interface and Xerces 2.11
Posted by Thomas Scheffler <th...@uni-jena.de>.
Am 20.07.2011 15:53, schrieb Michael Glavassevich:
> Thomas Scheffler <th...@uni-jena.de> wrote on 07/20/2011
> 09:47:53 AM:
>
> > 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.
>
> Sure, feel free to open a JIRA issue.
For the records:
https://issues.apache.org/jira/browse/XERCESJ-1519
regards,
Thomas Scheffler
--
Thomas Scheffler
Friedrich-Schiller-Universität Jena
Thüringer Universitäts- und Landesbibliothek
Bibliotheksplatz 2
07743 Jena
Phone: ++49 3641 940027
FAX: ++49 3641 940022
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
Re: EntityResolver2 interface and Xerces 2.11
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Thomas Scheffler <th...@uni-jena.de> wrote on 07/20/2011
09:47:53 AM:
> 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.
Sure, feel free to open a JIRA issue.
> Thank you for pointing me to the report.
>
> regards,
>
> Thomas
Thanks.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Re: EntityResolver2 interface and Xerces 2.11
Posted by Thomas Scheffler <th...@uni-jena.de>.
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: mrglavas@ca.ibm.com
> E-mail: mrglavas@apache.org
>
> Thomas Scheffler <th...@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-unsubscribe@xerces.apache.org
> > > > For additional commands, e-mail: j-users-help@xerces.apache.org
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
> > For additional commands, e-mail: j-users-help@xerces.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
Re: EntityResolver2 interface and Xerces 2.11
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
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.
Thanks.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Thomas Scheffler <th...@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-unsubscribe@xerces.apache.org
> > > For additional commands, e-mail: j-users-help@xerces.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-users-help@xerces.apache.org
Re: EntityResolver2 interface and Xerces 2.11
Posted by Thomas Scheffler <th...@uni-jena.de>.
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-unsubscribe@xerces.apache.org
> > For additional commands, e-mail: j-users-help@xerces.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
Re: EntityResolver2 interface and Xerces 2.11
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Thomas,
Have you read this thread [1]? What you're observing for EntityResolver2 is
probably due to the same change.
Thanks.
[1] http://xerces.markmail.org/thread/zpazk5bukquyijan
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Thomas Scheffler <th...@uni-jena.de> wrote on 07/20/2011
05:59:36 AM:
> 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-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-users-help@xerces.apache.org