You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Sjur Moshagen <sj...@mac.com> on 2008/08/21 09:00:45 UTC
Strange XPath problems when aggregating module.properties.properties
Hello all,
I'm getting very strange errors after I aggregated the output from
module.properties.properties, as suggested by Ross in [1].
Here's briefly the history of my attempts, and the XPath behaviour:
- first aggregation (in o.a.f.p.output.pdf/output.xmap):
<map:aggregate element="site">
<map:part src="cocoon://skinconf.xml"/>
<map:part src="cocoon://module.properties.properties"/>
<map:part src="cocoon://{1}{2}.xml"/>
</map:aggregate>
(note, the properties module is the second part in the aggregation)
XSLT/XPath problems (in o.a.f.p.output.pdf/resources/stylesheets/
document-to-fo.xsl):
1)
<xsl:variable
name="properties"
select="//properties" />
Expected result: all properties available as daughters of $properties
Actual result: nothing assigned to the variable
2)
<xsl:variable
name="properties"
select="//@name[1]" />
Expected result: value of first @name in the document, which is found
in the skinconfig section (ie not a property from the properties
section)
Actual result: same as expected result
3)
<xsl:variable
name="properties"
select="//@name[2]" />
Expected result: value of *second* @name in the document
Actual result: empty string
Subsequent attempts at accessing any @name beyond the first one fail.
Conclusion: I'm not able to access anything in the properties section
of the aggregated document. But I can see all the properties if I look
at the aggregated output directly - it is all there!
- I then change the order of aggregation:
<map:aggregate element="site">
<map:part src="cocoon://module.properties.properties"/>
<map:part src="cocoon://skinconf.xml"/>
<map:part src="cocoon://{1}{2}.xml"/>
</map:aggregate>
(note, the properties module is now the *first* part in the aggregation)
The problems persist, except that I am now able to access the *first*
property of the properties section, by using an XPath expression as in
1) above.
4)
<xsl:variable
name="properties"
select="count(//@name)" />
Expected result: the number of @name attributes in the document
Actual result:
Internal Server Error
Message: null
Description: No details available.
Sender: org.apache.cocoon.servlet.CocoonServlet
Source: Cocoon Servlet
Request URI
index.pdf
cause
org.apache.xpath.objects.XNumber
From error.log:
Caused by: java.lang.ClassCastException:
org.apache.xpath.objects.XNumber
at
org
.apache
.xpath
.axes
.FilterExprIteratorSimple
.executeFilterExpr(FilterExprIteratorSimple.java:114)
at
org.apache.xpath.axes.FilterExprWalker.setRoot(FilterExprWalker.java:
129)
at
org.apache.xpath.axes.WalkingIterator.setRoot(WalkingIterator.java:154)
at
org.apache.xpath.axes.LocPathIterator.asNode(LocPathIterator.java:298)
at
org.apache.xpath.axes.LocPathIterator.bool(LocPathIterator.java:318)
at org.apache.xpath.XPath.bool(XPath.java:410)
This is a simple XPath expression! I really do not understand what is
going on.
Any help or clue would be greatly appreciated - my attempts at
improving the pdf plugin are stranded at the moment:(
Best regards,
Sjur
[1] http://marc.info/?l=forrest-dev&m=121520709107279&w=2
Re: Strange XPath problems when aggregating
module.properties.properties
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Thu, 2008-08-21 at 10:56 +0300, Sjur Moshagen wrote:
> Thanks man, you saved my day!
>
> Den 21. aug. 2008 kl. 10.16 skrev Thorsten Scherler:
>
> > On Thu, 2008-08-21 at 10:00 +0300, Sjur Moshagen wrote:
> >> Hello all,
> >>
> >> I'm getting very strange errors after I aggregated the output from
> >> module.properties.properties, as suggested by Ross in [1].
> >>
> >> Here's briefly the history of my attempts, and the XPath behaviour:
> >>
> >> - first aggregation (in o.a.f.p.output.pdf/output.xmap):
> >>
> >> <map:aggregate element="site">
> >> <map:part src="cocoon://skinconf.xml"/>
> >
> > Hmm, skinconf? You know my opinion about dependencies to skinconf. If
> > you use module.properties.properties the skinconf is obsolete. More
> > since this plugin should adopt the new properties system.
>
> This is the present setup of the pdf plugin. I'll try to find time to
> clean the pdf plugin for dependencies on skinconfig, as soon as I have
> the other issues working (ie proper i18n support, including font
> specification in the project config file).
Ok, thanks.
> ...
> >> This is a simple XPath expression! I really do not understand what is
> >> going on.
> >
> > Try the namespace. ;)
>
> That did it :)
>
> I was fooled by the xml returned by the properties module not having
> an explicit namespace declaration:
>
> <properties input-module="properties">
> <property name="conf" value="/Users/sjur/test/src/documentation/
> conf/"/>
> <property name="content" value="/Users/sjur/test/src/documentation/
> content/"/>
> <property name="content.xdocs" value="/Users/sjur/test/src/
> documentation/content/xdocs/"/>
> <property name="context.home" value="/usr/local/forrest/main/webapp"/>
> ...
> </properties>
>
> Thanks for the help:)
You are welcome, glad it helped.
salu2
>
> Best regards,
> Sjur
>
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
Re: Strange XPath problems when aggregating module.properties.properties
Posted by Sjur Moshagen <sj...@mac.com>.
Thanks man, you saved my day!
Den 21. aug. 2008 kl. 10.16 skrev Thorsten Scherler:
> On Thu, 2008-08-21 at 10:00 +0300, Sjur Moshagen wrote:
>> Hello all,
>>
>> I'm getting very strange errors after I aggregated the output from
>> module.properties.properties, as suggested by Ross in [1].
>>
>> Here's briefly the history of my attempts, and the XPath behaviour:
>>
>> - first aggregation (in o.a.f.p.output.pdf/output.xmap):
>>
>> <map:aggregate element="site">
>> <map:part src="cocoon://skinconf.xml"/>
>
> Hmm, skinconf? You know my opinion about dependencies to skinconf. If
> you use module.properties.properties the skinconf is obsolete. More
> since this plugin should adopt the new properties system.
This is the present setup of the pdf plugin. I'll try to find time to
clean the pdf plugin for dependencies on skinconfig, as soon as I have
the other issues working (ie proper i18n support, including font
specification in the project config file).
...
>> This is a simple XPath expression! I really do not understand what is
>> going on.
>
> Try the namespace. ;)
That did it :)
I was fooled by the xml returned by the properties module not having
an explicit namespace declaration:
<properties input-module="properties">
<property name="conf" value="/Users/sjur/test/src/documentation/
conf/"/>
<property name="content" value="/Users/sjur/test/src/documentation/
content/"/>
<property name="content.xdocs" value="/Users/sjur/test/src/
documentation/content/xdocs/"/>
<property name="context.home" value="/usr/local/forrest/main/webapp"/>
...
</properties>
Thanks for the help:)
Best regards,
Sjur
Re: Strange XPath problems when aggregating
module.properties.properties
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Thu, 2008-08-21 at 10:00 +0300, Sjur Moshagen wrote:
> Hello all,
>
> I'm getting very strange errors after I aggregated the output from
> module.properties.properties, as suggested by Ross in [1].
>
> Here's briefly the history of my attempts, and the XPath behaviour:
>
> - first aggregation (in o.a.f.p.output.pdf/output.xmap):
>
> <map:aggregate element="site">
> <map:part src="cocoon://skinconf.xml"/>
Hmm, skinconf? You know my opinion about dependencies to skinconf. If
you use module.properties.properties the skinconf is obsolete. More
since this plugin should adopt the new properties system.
> <map:part src="cocoon://module.properties.properties"/>
> <map:part src="cocoon://{1}{2}.xml"/>
> </map:aggregate>
>
> (note, the properties module is the second part in the aggregation)
>
> XSLT/XPath problems (in o.a.f.p.output.pdf/resources/stylesheets/
> document-to-fo.xsl):
>
> 1)
> <xsl:variable
> name="properties"
> select="//properties" />
>
> Expected result: all properties available as daughters of $properties
> Actual result: nothing assigned to the variable
Yes because you are not using the namespace. The result is:
<properties xmlns:forrest="http://apache.org/forrest/properties/1.0"
xmlns="http://apache.org/forrest/properties/1.0"
input-module="properties">
Meaning you would need to use something
like ...select="//forrest:properties" (do not forget to declare the ns)
...
> This is a simple XPath expression! I really do not understand what is
> going on.
Try the namespace. ;)
HTH
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions