You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Peter Klotz <pe...@blue-elephant-systems.com> on 2006/03/06 17:55:26 UTC
Cocoon forms binding and XML namespaces
Hi,
we are using Cocoon 2.1.8 and have a form for creating a new object.
That means there is no data loaded into the form but only saved from the
form to a XML document.
The binding using a binding file uses XML namespaces, which seems to be
the only difference to some of the samples, where one (dynamic repeater)
also creates a new document and then only saves the form.
The problem that we get is
Caused by: org.apache.commons.jxpath.JXPathException: Exception trying
to create xpath /ovo:policy; Cannot map non-null prefix when creating a
document element
at
org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.createPath(JXPathContextReferenceImpl.java:450)
at
org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.createPath(JXPathContextReferenceImpl.java:427)
at
org.apache.cocoon.forms.binding.ContextJXPathBinding.doSave(ContextJXPathBinding.java:101)
at
org.apache.cocoon.forms.binding.JXPathBindingBase.saveFormToModel(JXPathBindingBase.java:250)
at
org.apache.cocoon.forms.binding.JXPathBindingBase.saveFormToModel(JXPathBindingBase.java:264)
at sun.reflect.GeneratedMethodAccessor152.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:230)
at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244)
at
org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:1134)
at
org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:190)
at
org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:138)
at
org.mozilla.javascript.continuations.InterpretedFunctionImpl.call(InterpretedFunctionImpl.java:121)
at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244)
at
org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.java:1591)
at
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.handleContinuation(FOM_JavaScriptInterpreter.java:853)
... 61 more
Also the method of previously loading a existing empty or full XML
document and trying to save to this does not work with even worse
exceptions.
I can't but assume that the reason is namespaces because the sample does
exactly the same as we do and does work.
flow script function:
---
function newPolicy()
{
var definitionURI = cocoon.parameters["newDefinitionURI"];
var bindingURI = cocoon.parameters["newBindingURI"];
var form = new Form(definitionURI);
form.createBinding(bindingURI);
form.showForm("newPolicy-display");
var policy =
Packages.javax.xml.parsers.DocumentBuilderFactory.newInstance();
factory.setNamespaceAware(true);
var policy = factory.newDocumentBuilder().newDocument();
//policy.appendChild(policy.createElementNS("http://blue-elephant-systems.com/midas/ovo/1.0",
"ovo:policy"));
// var policy = loadDocument("logfile.xml");
// get the basic policy from the form
form.save(policy);
// just for debugging
saveDocument(policy, "output.xml");
// go into edit phase
form = getPolicyForm(policy);
cocoon.request.setAttribute("formMode", "edit");
form.showForm("editPolicy-display");
form.save(policy);
saveDocument(policy, "output.xml");
}
---
sample simple binding
---
<?xml version="1.0"?>
<fb:context xmlns:fb="http://apache.org/cocoon/forms/1.0#binding"
xmlns:fd="http://apache.org/cocoon/forms/1.0#definition"
xmlns:ovo="http://blue-elephant-systems.com/midas/ovo/1.0"
path="/ovo:policy">
<fb:value id="type" path="@type"/>
<fb:value id="name" path="@name"/>
</fb:context>
---
any idea what one could do to get this to work?
Thanks, Peter
Re: Cocoon forms binding and XML namespaces
Posted by Suzan Foster <su...@nerocmediaware.nl>.
Hi Peter,
This looks like you're using the wrong version of Xerces. I have seen
this error reported with Xerces 2.6. Seeing as Cocoon 2.1.8 is packaged
with Xerces 2.7.1 i expect you have mutiple parsers on your classpath.
If you are running Cocoon with Tomcat you can put it's version of Xerces
in the endorsed folder ($TOMCAT_HOME/common/endorsed). Otherwise get rid
of the conflicting parser.
Regards,
Suzan.
--
Peter Klotz wrote:
>Hi Suzan,
>
>Suzan Foster wrote:
>
>
>>Hi Peter,
>>
>>To get namespaces to bind in 2.1.8 i found you need to set
>>namespace-prefixes to true for the xml-parser in your cocoon.xconf file.
>>2.1.8 also has some bugs in the repeater binding which prevents the
>>propagation of namespaces in the binding file.
>>See : http://issues.apache.org/jira/browse/COCOON-1671
>>
>>
>
>Thanks, I did set namespace-prefixes to true as you suggested but when I try to
>load the form I get the following exception now:
>
>Caused by: org.apache.avalon.framework.CascadingException: Could not parse form
>definition from
>file:/home/pak/sandbox/midas_cocoon218/tomcat/webapps/midas/content/ovo/policyedit/forms/newPolicy_model.xml
> at
>org.apache.cocoon.forms.DefaultFormManager.getFormDefinition(DefaultFormManager.java:162)
> at
>org.apache.cocoon.forms.DefaultFormManager.createForm(DefaultFormManager.java:109)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:230)
> at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244)
> at
>org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:1134)
> at
>org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:190)
> at
>org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:138)
> at
>org.mozilla.javascript.continuations.InterpretedFunctionImpl.call(InterpretedFunctionImpl.java:121)
> at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244)
> at
>org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.callFunction(FOM_JavaScriptInterpreter.java:758)
> ... 103 more
>Caused by: org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create
>or change an object in a way which is incorrect with regard to namespaces.
> at org.apache.xml.utils.DOMBuilder.startElement(DOMBuilder.java:354)
> at
>org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1042)
> at org.apache.cocoon.xml.AbstractXMLPipe.startElement(AbstractXMLPipe.java:94)
> at
>org.apache.cocoon.util.location.LocationAttributes$Pipe.startElement(LocationAttributes.java:318)
> at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
> at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
> at
>org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown
>Source)
> at
>org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
>Source)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
>Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> at org.apache.excalibur.xml.impl.JaxpParser.parse(JaxpParser.java:315)
> at org.apache.excalibur.xml.impl.JaxpParser.parse(JaxpParser.java:334)
> at org.apache.cocoon.forms.util.DomHelper.parse(DomHelper.java:308)
> at
>org.apache.cocoon.forms.DefaultFormManager.getFormDefinition(DefaultFormManager.java:160)
> ... 116 more
>Caused by: org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create
>or change an object in a way which is incorrect with regard to namespaces.
> at org.apache.xerces.dom.CoreDocumentImpl.checkDOMNSErr(Unknown Source)
> at org.apache.xerces.dom.AttrNSImpl.setName(Unknown Source)
> at org.apache.xerces.dom.AttrNSImpl.<init>(Unknown Source)
> at org.apache.xerces.dom.CoreDocumentImpl.createAttributeNS(Unknown Source)
> at org.apache.xerces.dom.ElementImpl.setAttributeNS(Unknown Source)
> at org.apache.xml.utils.DOMBuilder.startElement(DOMBuilder.java:339)
> ... 132 more
>
>I cannot see a problem with namespaces in the mentioned form model though:
>
><fd:form
> xmlns:fd="http://apache.org/cocoon/forms/1.0#definition"
> xmlns:i18n="http://apache.org/cocoon/i18n/2.1">
>
> <fd:widgets>
>...
>
>I must admit that I do not understand the problem really as I usually do not use
>this lowlevel DOM but JDOM instead. I know that DOM v1 has problem with
>namespaces but that should be done with DOM 2, shouldn't it?
>
>
>Peter
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>For additional commands, e-mail: users-help@cocoon.apache.org
>
--
Met vriendelijke groet,
Suzan Foster
Software Engineer
*NEROC'MEDIAWARE *
De Run 1131
5503 LB Veldhoven
T +31 (0)40 258 66 66
F +31 (0)40 258 66 77
E suzan.foster@nerocmediaware.nl <ma...@nerocmediaware.nl>
================================================
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en
is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht
onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en
de afzender direct te informeren door het bericht te retourneren.
================================================
The information contained in this message may be confidential
and is intended to be exclusively for the addressee. Should you
receive this message unintentionally, please do not use the contents
herein and notify the sender immediately by return e-mail.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon forms binding and XML namespaces
Posted by Peter Klotz <pe...@blue-elephant-systems.com>.
Hi Suzan,
Suzan Foster wrote:
> Hi Peter,
>
> To get namespaces to bind in 2.1.8 i found you need to set
> namespace-prefixes to true for the xml-parser in your cocoon.xconf file.
> 2.1.8 also has some bugs in the repeater binding which prevents the
> propagation of namespaces in the binding file.
> See : http://issues.apache.org/jira/browse/COCOON-1671
Thanks, I did set namespace-prefixes to true as you suggested but when I try to
load the form I get the following exception now:
Caused by: org.apache.avalon.framework.CascadingException: Could not parse form
definition from
file:/home/pak/sandbox/midas_cocoon218/tomcat/webapps/midas/content/ovo/policyedit/forms/newPolicy_model.xml
at
org.apache.cocoon.forms.DefaultFormManager.getFormDefinition(DefaultFormManager.java:162)
at
org.apache.cocoon.forms.DefaultFormManager.createForm(DefaultFormManager.java:109)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:230)
at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244)
at
org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:1134)
at
org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:190)
at
org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:138)
at
org.mozilla.javascript.continuations.InterpretedFunctionImpl.call(InterpretedFunctionImpl.java:121)
at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244)
at
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.callFunction(FOM_JavaScriptInterpreter.java:758)
... 103 more
Caused by: org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create
or change an object in a way which is incorrect with regard to namespaces.
at org.apache.xml.utils.DOMBuilder.startElement(DOMBuilder.java:354)
at
org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1042)
at org.apache.cocoon.xml.AbstractXMLPipe.startElement(AbstractXMLPipe.java:94)
at
org.apache.cocoon.util.location.LocationAttributes$Pipe.startElement(LocationAttributes.java:318)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at
org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.excalibur.xml.impl.JaxpParser.parse(JaxpParser.java:315)
at org.apache.excalibur.xml.impl.JaxpParser.parse(JaxpParser.java:334)
at org.apache.cocoon.forms.util.DomHelper.parse(DomHelper.java:308)
at
org.apache.cocoon.forms.DefaultFormManager.getFormDefinition(DefaultFormManager.java:160)
... 116 more
Caused by: org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create
or change an object in a way which is incorrect with regard to namespaces.
at org.apache.xerces.dom.CoreDocumentImpl.checkDOMNSErr(Unknown Source)
at org.apache.xerces.dom.AttrNSImpl.setName(Unknown Source)
at org.apache.xerces.dom.AttrNSImpl.<init>(Unknown Source)
at org.apache.xerces.dom.CoreDocumentImpl.createAttributeNS(Unknown Source)
at org.apache.xerces.dom.ElementImpl.setAttributeNS(Unknown Source)
at org.apache.xml.utils.DOMBuilder.startElement(DOMBuilder.java:339)
... 132 more
I cannot see a problem with namespaces in the mentioned form model though:
<fd:form
xmlns:fd="http://apache.org/cocoon/forms/1.0#definition"
xmlns:i18n="http://apache.org/cocoon/i18n/2.1">
<fd:widgets>
...
I must admit that I do not understand the problem really as I usually do not use
this lowlevel DOM but JDOM instead. I know that DOM v1 has problem with
namespaces but that should be done with DOM 2, shouldn't it?
Peter
Re: Cocoon forms binding and XML namespaces
Posted by Suzan Foster <su...@islief.nl>.
Hi Peter,
To get namespaces to bind in 2.1.8 i found you need to set
namespace-prefixes to true for the xml-parser in your cocoon.xconf
file. 2.1.8 also has some bugs in the repeater binding which prevents
the propagation of namespaces in the binding file.
See : http://issues.apache.org/jira/browse/COCOON-1671
Regards,
Suzan Foster.
--
On Mar 6, 2006, at 5:55 PM, Peter Klotz wrote:
> Hi,
>
> we are using Cocoon 2.1.8 and have a form for creating a new object.
> That means there is no data loaded into the form but only saved from
> the
> form to a XML document.
>
> The binding using a binding file uses XML namespaces, which seems to be
> the only difference to some of the samples, where one (dynamic
> repeater)
> also creates a new document and then only saves the form.
>
> The problem that we get is
>
> Caused by: org.apache.commons.jxpath.JXPathException: Exception trying
> to create xpath /ovo:policy; Cannot map non-null prefix when creating a
> document element
> at
> org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.createPath(JXPa
> thContextReferenceImpl.java:450)
> at
> org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.createPath(JXPa
> thContextReferenceImpl.java:427)
> at
> org.apache.cocoon.forms.binding.ContextJXPathBinding.doSave(ContextJXPa
> thBinding.java:101)
> at
> org.apache.cocoon.forms.binding.JXPathBindingBase.saveFormToModel(JXPat
> hBindingBase.java:250)
> at
> org.apache.cocoon.forms.binding.JXPathBindingBase.saveFormToModel(JXPat
> hBindingBase.java:264)
> at sun.reflect.GeneratedMethodAccessor152.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso
> rImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:
> 230)
> at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244)
> at
> org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(
> ContinuationInterpreter.java:1134)
> at
> org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(
> ContinuationInterpreter.java:190)
> at
> org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(
> ContinuationInterpreter.java:138)
> at
> org.mozilla.javascript.continuations.InterpretedFunctionImpl.call(Inter
> pretedFunctionImpl.java:121)
> at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244)
> at
> org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.jav
> a:1591)
> at
> org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpre
> ter.handleContinuation(FOM_JavaScriptInterpreter.java:853)
> ... 61 more
>
> Also the method of previously loading a existing empty or full XML
> document and trying to save to this does not work with even worse
> exceptions.
>
> I can't but assume that the reason is namespaces because the sample
> does
> exactly the same as we do and does work.
>
> flow script function:
> ---
> function newPolicy()
> {
> var definitionURI = cocoon.parameters["newDefinitionURI"];
> var bindingURI = cocoon.parameters["newBindingURI"];
>
> var form = new Form(definitionURI);
> form.createBinding(bindingURI);
>
> form.showForm("newPolicy-display");
>
> var policy =
> Packages.javax.xml.parsers.DocumentBuilderFactory.newInstance();
> factory.setNamespaceAware(true);
> var policy = factory.newDocumentBuilder().newDocument();
>
> //policy.appendChild(policy.createElementNS("http://blue-elephant-
> systems.com/midas/ovo/1.0",
> "ovo:policy"));
> // var policy = loadDocument("logfile.xml");
> // get the basic policy from the form
> form.save(policy);
>
> // just for debugging
> saveDocument(policy, "output.xml");
>
> // go into edit phase
> form = getPolicyForm(policy);
> cocoon.request.setAttribute("formMode", "edit");
>
> form.showForm("editPolicy-display");
>
> form.save(policy);
> saveDocument(policy, "output.xml");
> }
> ---
>
> sample simple binding
> ---
> <?xml version="1.0"?>
> <fb:context xmlns:fb="http://apache.org/cocoon/forms/1.0#binding"
> xmlns:fd="http://apache.org/cocoon/forms/1.0#definition"
> xmlns:ovo="http://blue-elephant-systems.com/midas/ovo/1.0"
> path="/ovo:policy">
>
> <fb:value id="type" path="@type"/>
> <fb:value id="name" path="@name"/>
>
> </fb:context>
> ---
>
> any idea what one could do to get this to work?
>
>
> Thanks, Peter
> <peter.klotz.vcf>------------------------------------------------------
> ---------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org