Giacomo Pati wrote:
Giacomo Pati wrote:
Reinhard Poetz wrote:
Giacomo Pati wrote:
Reinhard Poetz wrote:
The second one allows "patching" the web.xml by adding snippets from
META-INF/cocoon/xpatch to it. It also supports a feature that reverses
the classloader hierarchy in a web application by using a shielding
classloader.
But can only be used if packaging of the project is war!
I ported the patching functionality to cocoon:rcl too. In order to be
consistent with our other directory names, the plugins search for patch
files in /COB-INF/cocoon/xpatch/*.xweb.
What was the reason to change the path from
/META-INF/cocoon/xpatch/*.xweb to
/COB-INF/cocoon/xpatch/*.xweb? It's confusing to me to change that.
sorry, my paths were wrong: Perviously the path was /META-INF/xpatch and
now it is /META-INF/cocoon/xpatch
I'll set it back to /META-INF/xpatch and now it seems to find the patches and
applies them.
Is it ok to set the path back to what it was or did you had some reason to
change it?
some time ago we decided to have all or stuff under META-INF/cocoon. I don't
think that this should be an exception, shouldn't it?
Sure, and I'll do my best to find the missings ;-)
Now, next thing I stumbled over is an exception that says:
2007-05-02 12:11:11 [ERROR] btpool0-3 cocoon - Internal Cocoon Problem
org.apache.cocoon.ProcessingException: Failed to process pipeline
at [TransformerException] -
resource://org/apache/cocoon/forms/resources/forms-field-styling.xsl:86:69
...
Caused by: org.apache.xml.utils.WrappedRuntimeException: Could not find
variable with the name of
dojo-resources
at
org.apache.xpath.operations.Variable.fixupVariables(Variable.java:146)
...
Did any change messed up with the variable dojo-resources?
Grek, could you comment on this please?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
