You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2005/05/20 12:39:09 UTC
JXTemplate initialization in non-flowscript scenarios
It took me hours to track down some weired behaviour of the jx-template
generator (template block). It took me more than 5 hours to find the cause :-/.
If there is no <map:flow/> declared in your sitemap and you want to use
jx-template, following exception will be thrown:
java.lang.NoClassDefFoundError: org/apache/commons/beanutils/ConvertUtils
at org.apache.commons.jxpath.util.BasicTypeConverter.canConvert(BasicTyp
eConverter.java:165)
at org.apache.commons.jxpath.util.BasicTypeConverter.canConvert(BasicTyp
eConverter.java:152)
at org.apache.commons.jxpath.util.BasicTypeConverter.canConvert(BasicTyp
eConverter.java:160)
at org.apache.commons.jxpath.util.TypeUtils.canConvert(TypeUtils.java:46
)
at org.apache.commons.jxpath.util.MethodLookupUtils.matchType(MethodLook
upUtils.java:285)
at org.apache.commons.jxpath.util.MethodLookupUtils.matchParameterTypes(
MethodLookupUtils.java:260)
at org.apache.commons.jxpath.util.MethodLookupUtils.lookupStaticMethod(M
ethodLookupUtils.java:144)
at org.apache.commons.jxpath.PackageFunctions.getFunction(PackageFunctio
ns.java:200)
at org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.getFunction(J
XPathContextReferenceImpl.java:638)
at org.apache.commons.jxpath.ri.axes.RootContext.getFunction(RootContext
.java:118)
at org.apache.commons.jxpath.ri.compiler.ExtensionFunction.computeValue(
ExtensionFunction.java:83)
at org.apache.commons.jxpath.ri.compiler.ExtensionFunction.compute(Exten
sionFunction.java:71)
at org.apache.commons.jxpath.ri.compiler.Expression.iteratePointers(Expr
ession.java:80)
at org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.iteratePointe
rs(JXPathContextReferenceImpl.java:533)
at org.apache.commons.jxpath.ri.JXPathCompiledExpression.iteratePointers
(JXPathCompiledExpression.java:113)
at org.apache.cocoon.components.expression.jxpath.JXPathExpression.getNo
de(JXPathExpression.java:105)
at org.apache.cocoon.template.expression.JXTExpression.getNode(JXTExpres
sion.java:170)
at org.apache.cocoon.template.instruction.Set.execute(Set.java:74)
at org.apache.cocoon.template.script.Invoker.execute(Invoker.java:72)
at org.apache.cocoon.template.instruction.Call.execute(Call.java:142)
at org.apache.cocoon.template.script.Invoker.execute(Invoker.java:69)
at org.apache.cocoon.template.JXTemplateGenerator.performGeneration(JXTe
mplateGenerator.java:122)
at org.apache.cocoon.template.JXTemplateGenerator.generate(JXTemplateGen
erator.java:111)
Any ideas how to fix it?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: JXTemplate initialization in non-flowscript scenarios
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Daniel Fagerstrom wrote:
> Reinhard Poetz wrote:
>
>> Daniel Fagerstrom wrote:
>>
>>> Ok, but I still need to know the content of the value attribute to
>>> the jx:set that creates the problem to be able to help. From the
>>> stacktrace it seem like something goes wrong when JXPath uses
>>> reflection on the value.
>>
>>
>>
>> The debugger showed that it's this line:
>> <jx:set var="cformsHelper"
>> value="#{org.apache.cocoon.forms.generation.JXMacrosHelper.createHelper($cocoon/consumer,$cocoon/request)}"/>
>>
>>
>> Unfortunatly my knowledge in jxtemplate isn't sufficient to see the
>> difference between the two cases (with/witout <map:flow/>).
>
>
> You are only supposed to have direct access to java.*, IIUC, packages
> from FOM for other packages you must have a "Package." prefix, i.e.
> value="#{Package.org.apache.cocoon.forms.generation.JXMacrosHelper.createHelper($cocoon/consumer,$cocoon/request)}
a typo: Packages.org...
>
>
> This is the behaviour that is implemented in
> o.a.c.environment.TemplateObjectModelHelper.addJavaPackages.
>
> In
> org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.setupPackages
> the packages javax.*, org.* and com.* where also setup so that you have
> direct access to them in rev 26848. The log says: "Also added
> experimental fix to provide direct access to javax, org, and com
> packages". Don't know if there was any discussions or decisions about this.
>
> Anyway, we have had the functionality for 16 months, so we should
> probably continue to support it.
>
> /Daniel
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: JXTemplate initialization in non-flowscript scenarios
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
>
>> Ok, but I still need to know the content of the value attribute to the
>> jx:set that creates the problem to be able to help. From the
>> stacktrace it seem like something goes wrong when JXPath uses
>> reflection on the value.
>
>
> The debugger showed that it's this line:
> <jx:set var="cformsHelper"
> value="#{org.apache.cocoon.forms.generation.JXMacrosHelper.createHelper($cocoon/consumer,$cocoon/request)}"/>
>
>
> Unfortunatly my knowledge in jxtemplate isn't sufficient to see the
> difference between the two cases (with/witout <map:flow/>).
You are only supposed to have direct access to java.*, IIUC, packages
from FOM for other packages you must have a "Package." prefix, i.e.
value="#{Package.org.apache.cocoon.forms.generation.JXMacrosHelper.createHelper($cocoon/consumer,$cocoon/request)}
This is the behaviour that is implemented in
o.a.c.environment.TemplateObjectModelHelper.addJavaPackages.
In
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.setupPackages
the packages javax.*, org.* and com.* where also setup so that you have
direct access to them in rev 26848. The log says: "Also added
experimental fix to provide direct access to javax, org, and com
packages". Don't know if there was any discussions or decisions about this.
Anyway, we have had the functionality for 16 months, so we should
probably continue to support it.
/Daniel
Re: JXTemplate initialization in non-flowscript scenarios
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Ok, but I still need to know the content of the value attribute to the
> jx:set that creates the problem to be able to help. From the stacktrace
> it seem like something goes wrong when JXPath uses reflection on the value.
The debugger showed that it's this line:
<jx:set var="cformsHelper"
value="#{org.apache.cocoon.forms.generation.JXMacrosHelper.createHelper($cocoon/consumer,$cocoon/request)}"/>
Unfortunatly my knowledge in jxtemplate isn't sufficient to see the difference
between the two cases (with/witout <map:flow/>).
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: JXTemplate initialization in non-flowscript scenarios
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
>
>> Need more info to be able to help. Somwhere in your script
>
>
> I don't use a custom macro, only jx-macro.xml
Ok.
> you access a
>
>> value in a jx:set that cannot be evaluated by jxpath, maybe you are
>> calling an extension function, not sure though. Can you isolate the
>> expression it happens for.
>>
>> It seem like commons-beanutils not is found, maybe you could add a
>> <library name="commons-beanutils"/> to the cocoon-block-template
>> definition in gump.xml. But if that is the case I don't know why it
>> work without it if you use flow.
>
>
> for me it looks like some fallback mechanism because if <map:flow/>
> has been declared, the problem disappears and *no* commons-beanutils
> are required.
Ok, but I still need to know the content of the value attribute to the
jx:set that creates the problem to be able to help. From the stacktrace
it seem like something goes wrong when JXPath uses reflection on the value.
/Daniel
Re: JXTemplate initialization in non-flowscript scenarios
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Need more info to be able to help. Somwhere in your script
I don't use a custom macro, only jx-macro.xml
you access a
> value in a jx:set that cannot be evaluated by jxpath, maybe you are
> calling an extension function, not sure though. Can you isolate the
> expression it happens for.
>
> It seem like commons-beanutils not is found, maybe you could add a
> <library name="commons-beanutils"/> to the cocoon-block-template
> definition in gump.xml. But if that is the case I don't know why it work
> without it if you use flow.
for me it looks like some fallback mechanism because if <map:flow/> has been
declared, the problem disappears and *no* commons-beanutils are required.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: JXTemplate initialization in non-flowscript scenarios
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Need more info to be able to help. Somwhere in your script you access a
value in a jx:set that cannot be evaluated by jxpath, maybe you are
calling an extension function, not sure though. Can you isolate the
expression it happens for.
It seem like commons-beanutils not is found, maybe you could add a
<library name="commons-beanutils"/> to the cocoon-block-template
definition in gump.xml. But if that is the case I don't know why it work
without it if you use flow.
/Daniel
Reinhard Poetz wrote:
>
> It took me hours to track down some weired behaviour of the
> jx-template generator (template block). It took me more than 5 hours
> to find the cause :-/. If there is no <map:flow/> declared in your
> sitemap and you want to use jx-template, following exception will be
> thrown:
>
> java.lang.NoClassDefFoundError: org/apache/commons/beanutils/ConvertUtils
> at
> org.apache.commons.jxpath.util.BasicTypeConverter.canConvert(BasicTyp
> eConverter.java:165)
> at
> org.apache.commons.jxpath.util.BasicTypeConverter.canConvert(BasicTyp
> eConverter.java:152)
> at
> org.apache.commons.jxpath.util.BasicTypeConverter.canConvert(BasicTyp
> eConverter.java:160)
> at
> org.apache.commons.jxpath.util.TypeUtils.canConvert(TypeUtils.java:46
> )
> at
> org.apache.commons.jxpath.util.MethodLookupUtils.matchType(MethodLook
> upUtils.java:285)
> at
> org.apache.commons.jxpath.util.MethodLookupUtils.matchParameterTypes(
> MethodLookupUtils.java:260)
> at
> org.apache.commons.jxpath.util.MethodLookupUtils.lookupStaticMethod(M
> ethodLookupUtils.java:144)
> at
> org.apache.commons.jxpath.PackageFunctions.getFunction(PackageFunctio
> ns.java:200)
> at
> org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.getFunction(J
> XPathContextReferenceImpl.java:638)
> at
> org.apache.commons.jxpath.ri.axes.RootContext.getFunction(RootContext
> .java:118)
> at
> org.apache.commons.jxpath.ri.compiler.ExtensionFunction.computeValue(
> ExtensionFunction.java:83)
> at
> org.apache.commons.jxpath.ri.compiler.ExtensionFunction.compute(Exten
> sionFunction.java:71)
> at
> org.apache.commons.jxpath.ri.compiler.Expression.iteratePointers(Expr
> ession.java:80)
> at
> org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.iteratePointe
> rs(JXPathContextReferenceImpl.java:533)
> at
> org.apache.commons.jxpath.ri.JXPathCompiledExpression.iteratePointers
> (JXPathCompiledExpression.java:113)
> at
> org.apache.cocoon.components.expression.jxpath.JXPathExpression.getNo
> de(JXPathExpression.java:105)
> at
> org.apache.cocoon.template.expression.JXTExpression.getNode(JXTExpres
> sion.java:170)
> at
> org.apache.cocoon.template.instruction.Set.execute(Set.java:74)
> at
> org.apache.cocoon.template.script.Invoker.execute(Invoker.java:72)
> at
> org.apache.cocoon.template.instruction.Call.execute(Call.java:142)
> at
> org.apache.cocoon.template.script.Invoker.execute(Invoker.java:69)
> at
> org.apache.cocoon.template.JXTemplateGenerator.performGeneration(JXTe
> mplateGenerator.java:122)
> at
> org.apache.cocoon.template.JXTemplateGenerator.generate(JXTemplateGen
> erator.java:111)
>
>
> Any ideas how to fix it?
>