Strange encoding problem using forms

2010-02-11 Thread Søren Krum
Hello!

I have a small problem with a cocoon application and forms.

The application runs fine on one machine, but for some reason we want to
have a mirror of that machine. Higg Avalability and failover...

And here some more details: The part failing is a simple form build up
via cocoon forms (we are using cocoon 2.2), where in the first screen
the user has some possibilities to enter data, and in the second screen,
these data get presented to confirm them before they are comitted. The
cocoon flow is used to transfer the data from first to second screen and
further on to the third.

Entering some special characters like ö or øæå works fine on the one
machine but not on the other. We tried to build up the two machines as
alike as possible, the locale is the same, the tomcat and java versions
are the same, the physical machine are the same, teh application is
packed as a war and deployed on the same way.

Anyone an idea what could be lead to the trouble? Even a guess is nice,
running out of ideas here... It looks like it caused by wrong
interpretation of the parameters send with the request, but why are they
interpreted differently?

The failure we get reads like the following:

org.apache.cocoon.ProcessingException: Failed to process pipeline
at map:serialize -
file:///site/apps/apache-tomcat-6.0.20/work/portalen-forms/aksessliste/sitemap.xmap:117:28
at map:transform type=xslt -
file:///site/apps/apache-tomcat-6.0.20/work/portalen-forms/aksessliste/sitemap.xmap:111:111
at map:transform type=xslt -
file:///site/apps/apache-tomcat-6.0.20/work/portalen-forms/aksessliste/sitemap.xmap:108:69
at map:generate type=jx -
file:///site/apps/apache-tomcat-6.0.20/work/portalen-forms/aksessliste/sitemap.xmap:107:68
at map:match -
file:///site/apps/apache-tomcat-6.0.20/work/portalen-forms/aksessliste/sitemap.xmap:106:50
at map:act type=cauth-is-logged-in -
file:///site/apps/apache-tomcat-6.0.20/work/portalen-forms/aksessliste/sitemap.xmap:42:42

at
org.apache.cocoon.ProcessingException.throwLocated(ProcessingException.java:143)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.handleException(AbstractProcessingPipeline.java:923)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:548)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:273)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:439)
at sun.reflect.GeneratedMethodAccessor178.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:71)
at $Proxy31.process(Unknown Source)
at
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:147)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:55)
at
org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:87)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:55)
at
org.apache.cocoon.components.treeprocessor.sitemap.ActTypeNode.invoke(ActTypeNode.java:123)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:78)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:143)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:78)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:81)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:239)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.handleCocoonRedirect(ConcreteTreeProcessor.java:316)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor$TreeProcessorRedirector.cocoonRedirect(ConcreteTreeProcessor.java:366)
at
org.apache.cocoon.environment.ForwardRedirector.redirect(ForwardRedirector.java:62)
at
org.apache.cocoon.components.flow.AbstractInterpreter.forwardTo(AbstractInterpreter.java:201)
at
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.forwardTo(FOM_JavaScriptInterpreter.java:724)
at
org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.forwardTo(FOM_Cocoon.java:717)
at

Re: Strange encoding problem using forms

2010-02-11 Thread Jos Snellings
The two tomcat versions on the machines are the same, but, can you
please make a diff between the two server.xml under $CATALINA_HOME/conf?
Just to be sure ...

Jos

On Thu, 2010-02-11 at 11:47 +0100, Søren Krum wrote:
 Hello!
 
 I have a small problem with a cocoon application and forms.
 
 The application runs fine on one machine, but for some reason we want to
 have a mirror of that machine. Higg Avalability and failover...
 
 And here some more details: The part failing is a simple form build up
 via cocoon forms (we are using cocoon 2.2), where in the first screen
 the user has some possibilities to enter data, and in the second screen,
 these data get presented to confirm them before they are comitted. The
 cocoon flow is used to transfer the data from first to second screen and
 further on to the third.
 
 Entering some special characters like ö or øæå works fine on the one
 machine but not on the other. We tried to build up the two machines as
 alike as possible, the locale is the same, the tomcat and java versions
 are the same, the physical machine are the same, teh application is
 packed as a war and deployed on the same way.
 
 Anyone an idea what could be lead to the trouble? Even a guess is nice,
 running out of ideas here... It looks like it caused by wrong
 interpretation of the parameters send with the request, but why are they
 interpreted differently?
 
 The failure we get reads like the following:
 
 org.apache.cocoon.ProcessingException: Failed to process pipeline
   at map:serialize -
 file:///site/apps/apache-tomcat-6.0.20/work/portalen-forms/aksessliste/sitemap.xmap:117:28
   at map:transform type=xslt -
 file:///site/apps/apache-tomcat-6.0.20/work/portalen-forms/aksessliste/sitemap.xmap:111:111
   at map:transform type=xslt -
 file:///site/apps/apache-tomcat-6.0.20/work/portalen-forms/aksessliste/sitemap.xmap:108:69
   at map:generate type=jx -
 file:///site/apps/apache-tomcat-6.0.20/work/portalen-forms/aksessliste/sitemap.xmap:107:68
   at map:match -
 file:///site/apps/apache-tomcat-6.0.20/work/portalen-forms/aksessliste/sitemap.xmap:106:50
   at map:act type=cauth-is-logged-in -
 file:///site/apps/apache-tomcat-6.0.20/work/portalen-forms/aksessliste/sitemap.xmap:42:42
 
   at
 org.apache.cocoon.ProcessingException.throwLocated(ProcessingException.java:143)
   at
 org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.handleException(AbstractProcessingPipeline.java:923)
   at
 org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:548)
   at
 org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:273)
   at
 org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:439)
   at sun.reflect.GeneratedMethodAccessor178.invoke(Unknown Source)
   at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at
 org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:71)
   at $Proxy31.process(Unknown Source)
   at
 org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:147)
   at
 org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:55)
   at
 org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:87)
   at
 org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:55)
   at
 org.apache.cocoon.components.treeprocessor.sitemap.ActTypeNode.invoke(ActTypeNode.java:123)
   at
 org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:78)
   at
 org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:143)
   at
 org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:78)
   at
 org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:81)
   at
 org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:239)
   at
 org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.handleCocoonRedirect(ConcreteTreeProcessor.java:316)
   at
 org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor$TreeProcessorRedirector.cocoonRedirect(ConcreteTreeProcessor.java:366)
   at
 org.apache.cocoon.environment.ForwardRedirector.redirect(ForwardRedirector.java:62)
   at
 org.apache.cocoon.components.flow.AbstractInterpreter.forwardTo(AbstractInterpreter.java:201)
   at
 

Re: Strange encoding problem using forms

2010-02-11 Thread Dominic Mitchell
On Thu, Feb 11, 2010 at 6:40 AM, Jos Snellings jos.snelli...@pandora.bewrote:

 The two tomcat versions on the machines are the same, but, can you
 please make a diff between the two server.xml under $CATALINA_HOME/conf?
 Just to be sure ...


The other thing to check are the system properties file.encoding and
sun.jnu.encoding.  I have seen the JVM take different values for
file.encoding depending on how it was started (by hand vs startup scripts).
You should be able to verify them using the StatusGenerator.

-Dom


Re: Strange encoding problem using forms

2010-02-11 Thread Søren Krum
Hi again!

:-) You see me smiling, the file encoding on the one machine is utf-8,
there it works, and the other is iso-8859-1. I am not sure if it fixes
the problem if i change it, but that i figure out soon (if i have
figured out why this differs at all, and how to change it.) :-) Thx for
this hint.


Med vennlig hilsen

Søren D. Krum


-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org



Re: Strange encoding problem using forms

2010-02-11 Thread Søren Krum
And that fixed the problem! Winner of the cake is Dominic Mitchell,
thanks a lot :-)

-- 
Med vennlig hilsen

Søren D. Krum

-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org