You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jörn Heid <he...@fh-heilbronn.de> on 2001/06/27 13:56:41 UTC
WG: Bugs in XIncludeTransformer
-----Ursprüngliche Nachricht-----
Von: Jörn Heid [mailto:heid@fh-heilbronn.de]
Gesendet: Sonntag, 17. Juni 2001 01:34
An: cocoon-users@xml.apache.org
Betreff: Bugs in XIncludeTransformer
First Bug:
public void setDocumentLocator(Locator locator) {
try {
base_xmlbase_uri = urlFactory.getURL(locator.getSystemId());
if (current_xmlbase_uri == null) {
current_xmlbase_uri = base_xmlbase_uri;
}
} catch (MalformedURLException e)
{getLogger().debug("XincludeTransformer", e);}
super.setDocumentLocator(locator);
}
has to be changed to
public void setDocumentLocator(Locator locator) {
try {
base_xmlbase_uri = urlFactory.getURL(locator.getSystemId());
// if (current_xmlbase_uri == null) {
current_xmlbase_uri = base_xmlbase_uri;
// }
} catch (MalformedURLException e)
{getLogger().debug("XincludeTransformer", e);}
super.setDocumentLocator(locator);
The caching only works if the xml files can use the same base.
E.g. /test1.xml and /test2.xml work fine with href="included.xml" but
/a/test3.xml would use href="include.xml" instead of "../included.xml"
because of caching.
The second bug is more complicated.
The problem is that the current_xml_base is for example /test/test.xml. The
url with
url = urlFactory.getURL(current_xmlbase_uri,href);
will be /test/test.xml../included.xml instead of /test/../included.xml. I
think it's a bug in URLFactory, but I didn't fix it there. I implemented my
own Transformer and here's how I did it:
public void setDocumentLocator(Locator locator) {
try {
base_xmlbase_uri = urlFactory.getURL(locator.getSystemId());
if (current_xmlbase_uri == null) {
current_xmlbase_uri = base_xmlbase_uri;
}
} catch (MalformedURLException e)
{getLogger().debug("XincludeTransformer", e);}
super.setDocumentLocator(locator);
}
was changed to (the first bug is fixed here, too):
public void setDocumentLocator(Locator locator) {
try {
base_xmlbase_uri = urlFactory.getURL(locator.getSystemId());
//if (current_xmlbase_uri == null) {
current_xmlbase_uri = base_xmlbase_uri;
// }
// If url ends with .xxx then truncate to dir
if (current_xmlbase_uri.toExternalForm().lastIndexOf('.') >
current_xmlbase_uri.toExternalForm().lastIndexOf('/'))
current_xmlbase_uri = new
URL(current_xmlbase_uri.toExternalForm().substring(0,
current_xmlbase_uri.toExternalForm().lastIndexOf('/')+1));
} catch (MalformedURLException e) {
getLogger().debug("XincludeTransformer", e);
}
super.setDocumentLocator(locator);
}
and
protected void processXIncludeElement(String href, String parse) throws
SAXException,MalformedURLException,IOException {
getLogger().debug("Processing XInclude element: href="+href+",
parse="+parse);
URL url;
String suffix;
int index = href.indexOf('#');
if (index < 0) {
url = urlFactory.getURL(current_xmlbase_uri,href);
suffix = "";
was altered to
protected void processXIncludeElement(String href, String parse) throws
SAXException,MalformedURLException,IOException {
getLogger().debug("Processing XInclude element: href="+href+",
parse="+parse);
URL url;
String suffix;
int index = href.indexOf('#');
if (index < 0) {
url = urlFactory.getURL(current_xmlbase_uri,"/"+href);
suffix = "";
The caching is problematic. As the XInclude-Transformer does not have a
src-attribute it could not determine if a change has been made. I don't know
much about the caching in C2. If the caching is disabled if ONE component
says so, the XInclude-Transformer could always say ok to caching. If not,
the transformer should behave as the generator - if the generator has
changes the transformer should do so, too. But how can you implement that?
JOERN_HEID
-----Ursprüngliche Nachricht-----
Von: giacomo [mailto:giacomo@apache.org]
Gesendet: Samstag, 16. Juni 2001 20:55
An: Cocoon-Users
Betreff: Re: XIncludeTransformer not cacheable?
On Sat, 16 Jun 2001, Jörn Heid wrote:
> Why is the XIncludeTransformer not cacheable?
> I do not know how to implement it as it just transforms a xml file from
the
> pipeline.
Nobody has added the necessary methods and interfaces to that component.
If you'd like to enhance the XIncludeTransformer have a look at the
TraxTransformer.
>
> BTW I found two bugs in it. If there's a developer of Cocoon, please send
me
> your eMail. I will explain it.
Please explain the bugs you've found here on the list.
Giacomo
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: Bugs in XIncludeTransformer
Posted by Carsten Ziegeler <cz...@sundn.de>.
Thanks for your patch. I will apply it soon.
Regarding caching:
> The caching is problematic. As the XInclude-Transformer does not have a
> src-attribute it could not determine if a change has been made. I
> don't know
> much about the caching in C2. If the caching is disabled if ONE component
> says so, the XInclude-Transformer could always say ok to caching. If not,
> the transformer should behave as the generator - if the generator has
> changes the transformer should do so, too. But how can you implement that?
First, the XIncludeTransformer is not cacheable as it can not determine
the src (or the included documents) before the response is generated as
they are included in the xml sax stream.
A pipeline as cacheable (or better a part of a pipeline) even if one
component is not in this pipeline. If you have a cacheable generator,
followed by a cacheable transformer, followed by the XInlcudeTransformer
then the response of the first cacheable transformer is cached and
when again requested directly feed into the XInlcudeTransformer.
For more information on caching, you could refer to the caching
documentation
currently building up in the cvs xdocs tree.
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: cziegeler@sundn.de
================================================================
> Jörn Heid wrote:
>
> -----Ursprüngliche Nachricht-----
> Von: Jörn Heid [mailto:heid@fh-heilbronn.de]
> Gesendet: Sonntag, 17. Juni 2001 01:34
> An: cocoon-users@xml.apache.org
> Betreff: Bugs in XIncludeTransformer
>
>
> First Bug:
>
> public void setDocumentLocator(Locator locator) {
> try {
> base_xmlbase_uri = urlFactory.getURL(locator.getSystemId());
> if (current_xmlbase_uri == null) {
> current_xmlbase_uri = base_xmlbase_uri;
> }
> } catch (MalformedURLException e)
> {getLogger().debug("XincludeTransformer", e);}
> super.setDocumentLocator(locator);
> }
>
> has to be changed to
>
>
> public void setDocumentLocator(Locator locator) {
> try {
> base_xmlbase_uri = urlFactory.getURL(locator.getSystemId());
> // if (current_xmlbase_uri == null) {
> current_xmlbase_uri = base_xmlbase_uri;
> // }
> } catch (MalformedURLException e)
> {getLogger().debug("XincludeTransformer", e);}
> super.setDocumentLocator(locator);
>
> The caching only works if the xml files can use the same base.
> E.g. /test1.xml and /test2.xml work fine with href="included.xml" but
> /a/test3.xml would use href="include.xml" instead of
> "../included.xml"
> because of caching.
>
>
> The second bug is more complicated.
> The problem is that the current_xml_base is for example
> /test/test.xml. The
> url with
> url = urlFactory.getURL(current_xmlbase_uri,href);
> will be /test/test.xml../included.xml instead of /test/../included.xml. I
> think it's a bug in URLFactory, but I didn't fix it there. I
> implemented my
> own Transformer and here's how I did it:
>
> public void setDocumentLocator(Locator locator) {
> try {
> base_xmlbase_uri = urlFactory.getURL(locator.getSystemId());
> if (current_xmlbase_uri == null) {
> current_xmlbase_uri = base_xmlbase_uri;
> }
> } catch (MalformedURLException e)
> {getLogger().debug("XincludeTransformer", e);}
> super.setDocumentLocator(locator);
> }
>
> was changed to (the first bug is fixed here, too):
>
> public void setDocumentLocator(Locator locator) {
> try {
> base_xmlbase_uri = urlFactory.getURL(locator.getSystemId());
> //if (current_xmlbase_uri == null) {
> current_xmlbase_uri = base_xmlbase_uri;
> // }
>
> // If url ends with .xxx then truncate to dir
> if (current_xmlbase_uri.toExternalForm().lastIndexOf('.') >
> current_xmlbase_uri.toExternalForm().lastIndexOf('/'))
> current_xmlbase_uri = new
> URL(current_xmlbase_uri.toExternalForm().substring(0,
> current_xmlbase_uri.toExternalForm().lastIndexOf('/')+1));
> } catch (MalformedURLException e) {
> getLogger().debug("XincludeTransformer", e);
> }
> super.setDocumentLocator(locator);
> }
>
> and
>
> protected void processXIncludeElement(String href, String parse) throws
> SAXException,MalformedURLException,IOException {
> getLogger().debug("Processing XInclude element: href="+href+",
> parse="+parse);
> URL url;
> String suffix;
> int index = href.indexOf('#');
> if (index < 0) {
> url = urlFactory.getURL(current_xmlbase_uri,href);
> suffix = "";
>
> was altered to
>
> protected void processXIncludeElement(String href, String parse) throws
> SAXException,MalformedURLException,IOException {
> getLogger().debug("Processing XInclude element: href="+href+",
> parse="+parse);
> URL url;
> String suffix;
> int index = href.indexOf('#');
> if (index < 0) {
> url = urlFactory.getURL(current_xmlbase_uri,"/"+href);
> suffix = "";
>
>
>
> The caching is problematic. As the XInclude-Transformer does not have a
> src-attribute it could not determine if a change has been made. I
> don't know
> much about the caching in C2. If the caching is disabled if ONE component
> says so, the XInclude-Transformer could always say ok to caching. If not,
> the transformer should behave as the generator - if the generator has
> changes the transformer should do so, too. But how can you implement that?
>
> JOERN_HEID
>
>
> -----Ursprüngliche Nachricht-----
> Von: giacomo [mailto:giacomo@apache.org]
> Gesendet: Samstag, 16. Juni 2001 20:55
> An: Cocoon-Users
> Betreff: Re: XIncludeTransformer not cacheable?
>
>
> On Sat, 16 Jun 2001, Jörn Heid wrote:
>
> > Why is the XIncludeTransformer not cacheable?
> > I do not know how to implement it as it just transforms a xml file from
> the
> > pipeline.
>
> Nobody has added the necessary methods and interfaces to that component.
> If you'd like to enhance the XIncludeTransformer have a look at the
> TraxTransformer.
>
> >
> > BTW I found two bugs in it. If there's a developer of Cocoon,
> please send
> me
> > your eMail. I will explain it.
>
> Please explain the bugs you've found here on the list.
>
> Giacomo
>
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
>
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org