gelo1234 | 2 Apr 11:00 2012
Picon

C3 and XSP equivalent

Hello,

We've been using Cocoon framework for years and are very happy with its simplicity and RAD features.
Although we use very old version of Cocoon (2.0.5), it still satisfies us.
Unfortunately there are some bugs inside those old framework libs that we cannot fix as well as some memory leaks
from libraries that are no longer in use. That's why we soon plan to upgrade to the newest release of Cocoon. 
And i have few questions related to that topic:

1. Is C3 stable enough to give it a try in a production ?

2. Is there any equivalent of XSP in C3 ?

The flexibility of XSP is very important to us in terms of introducing many new/short changes
very fast to our web application. We just make a change and that's all - cocoon engine recompiles the java-related
class and it is instantly available to us - no recompiling from our dev team, no deployment, no app server restart no fuss at all!
It allows us for very rapid changes! That's exactly the kind of flexibility we want to have in our dev environment.
And we were much worried when in next Cocoon releases the support for XSP was abandoned. As far as i know
XSP became deprecated in C2.1.11 to be totally removed in C2.2.x and i suppose in C3.
I didn't dig much into all the features of new Cocoon but it seems like in C2.1/2.2 the best thing to use on the "controller" side
is Flowscript code. We were hesitating to switch from pure Java controller code to Javascript/Flowscript
code because in my opinion the continuation mechanism is error-prone, yet the developer must take care of many intricacies
around session/continuation expire times and so on. But the main reason for us not to go for it was the language -
Javascript - NOT Java. Although if i get it right, you can just instantiate any Java object and get access to any Java library available
around from Javascript, it is not as much flexible as java was in XSP. Though it still doesn't require any recompiling!/redeployment phase
from  the dev team as i assume.
In C3 you can have Java controllers called and that is Good, but it does require recompiling the Java
class and redeploy it on the server (and restart app server?). So it will be much much SLOWER than just dynamic-recompiling by cocoon engine without any server restart.
So i wonder if there is any mechanism on the controller side available in C3 that enabled us to still use Java but doesn't require from us recompiling java code/making redeployment/restarting the application server ?

3. Is Flowscript using some separate javascript engine like V8 ? Is it run inside JVM as a dynamic language feature ?
Whats is a preferred method to be used as a logic controller in C3 - Flowscript or Java ?

4. We don't want to go yet with C3 alpha-3 because it still uses old Xerces and XML-API libs. We found out there are some issues with those old libs under Tomcat 7 while working with "bloated" XML namespaces or handling some SAX errors. They had led to some memory leaks in our environment.
I spotted on the changelog that you have just updated C3 beta to the newest Xerces/XML-APIs. Thank you very much for this. I really appreciate that important change. Can we have some light on when the beta is released ?

Greetings,
Greg

Francesco Chicchiriccò | 4 Apr 11:56 2012
Picon

Re: C3 and XSP equivalent

Hi Greg,
sorry for the delay: you will find my reply embedded below.

Regards.

On 02/04/2012 11:00, gelo1234 wrote:
Hello,

We've been using Cocoon framework for years and are very happy with its simplicity and RAD features.
Although we use very old version of Cocoon (2.0.5), it still satisfies us.
Unfortunately there are some bugs inside those old framework libs that we cannot fix as well as some memory leaks
from libraries that are no longer in use. That's why we soon plan to upgrade to the newest release of Cocoon. 
And i have few questions related to that topic:

1. Is C3 stable enough to give it a try in a production ?

Stable enough to give a try? Yes.
Ready for production? No, unless you have enough skills to dive inside the source code. There are C3-based projects in production out there, but latest release is alpha [1], and development version is still beta1.

2. Is there any equivalent of XSP in C3 ?

Not really. As you say below, XSP were already deprecated in C2.1.
The only template mechanism available in C3 is StringTemplate [2] which is way less flexible (and error-prone) than XSP.

The flexibility of XSP is very important to us in terms of introducing many new/short changes
very fast to our web application. We just make a change and that's all - cocoon engine recompiles the java-related
class and it is instantly available to us - no recompiling from our dev team, no deployment, no app server restart no fuss at all!
It allows us for very rapid changes! That's exactly the kind of flexibility we want to have in our dev environment.
And we were much worried when in next Cocoon releases the support for XSP was abandoned. As far as i know
XSP became deprecated in C2.1.11 to be totally removed in C2.2.x and i suppose in C3.
I didn't dig much into all the features of new Cocoon but it seems like in C2.1/2.2 the best thing to use on the "controller" side
is Flowscript code. We were hesitating to switch from pure Java controller code to Javascript/Flowscript
code because in my opinion the continuation mechanism is error-prone, yet the developer must take care of many intricacies
around session/continuation expire times and so on. But the main reason for us not to go for it was the language -
Javascript - NOT Java. Although if i get it right, you can just instantiate any Java object and get access to any Java library available
around from Javascript, it is not as much flexible as java was in XSP. Though it still doesn't require any recompiling!/redeployment phase
from  the dev team as i assume.
In C3 you can have Java controllers called and that is Good, but it does require recompiling the Java
class and redeploy it on the server (and restart app server?). So it will be much much SLOWER than just dynamic-recompiling by cocoon engine without any server restart.
So i wonder if there is any mechanism on the controller side available in C3 that enabled us to still use Java but doesn't require from us recompiling java code/making redeployment/restarting the application server ?

Sure: you can empower cocoon-maven-plugin [3] for this, or even setup something external like JRebel.

3. Is Flowscript using some separate javascript engine like V8 ? Is it run inside JVM as a dynamic language feature ?
Whats is a preferred method to be used as a logic controller in C3 - Flowscript or Java ?

There is no support at all for Flowscript / continuations in C3.

4. We don't want to go yet with C3 alpha-3 because it still uses old Xerces and XML-API libs. We found out there are some issues with those old libs under Tomcat 7 while working with "bloated" XML namespaces or handling some SAX errors. They had led to some memory leaks in our environment.
I spotted on the changelog that you have just updated C3 beta to the newest Xerces/XML-APIs. Thank you very much for this. I really appreciate that important change. Can we have some light on when the beta is released?

Nice question, indeed :-)
I'd suggest to send a separate e-mail about this topic to dev ML.

Regards.

[1] http://cocoon.apache.org/3.0/alpha-warning.html
[2] http://www.stringtemplate.org/
[3] http://cocoon.apache.org/2.2/maven-plugins/maven-plugin/1.0/1295_1_1.html -- Francesco Chicchiriccò Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/
gelo1234 | 4 Apr 12:39 2012
Picon

Re: C3 and XSP equivalent


Thank you Francesco for your reply. That clarified my Cocoon upgrade path plan for the future.
I will be looking forward to seeing C3 beta released :)

I must say that you guys are doing a really great job with Cocoon. I didnt find any other lightweight
XML/RESTful engine that is so flexible and easy to develop on.
jBoss 7 Community Edition is also in our consideration as an OSGi-based very lightweight/modular Web Services engine and has really small footprint but it still cannot beat C3 in terms of declarative way of handling XML chain processing.
We tried also Apache Camel / CXF as another possible candidate to meet our goals, but it
lacks some features. C3 looks like the best one.

We live in times when there is a tremendous pressure to deliver short-term results/fixes and the price of introducing a new change must be very low. In my opinion C3 fits that like anything else.
Thank you and please carry on with developing that wonderful piece of software. I hope to see OSGi support soon :)

Greetings,
Greg


2012/4/4 Francesco Chicchiriccò <ilgrosso <at> apache.org>
Hi Greg,
sorry for the delay: you will find my reply embedded below.

Regards.


On 02/04/2012 11:00, gelo1234 wrote:
Hello,

We've been using Cocoon framework for years and are very happy with its simplicity and RAD features.
Although we use very old version of Cocoon (2.0.5), it still satisfies us.
Unfortunately there are some bugs inside those old framework libs that we cannot fix as well as some memory leaks
from libraries that are no longer in use. That's why we soon plan to upgrade to the newest release of Cocoon. 
And i have few questions related to that topic:

1. Is C3 stable enough to give it a try in a production ?

Stable enough to give a try? Yes.
Ready for production? No, unless you have enough skills to dive inside the source code. There are C3-based projects in production out there, but latest release is alpha [1], and development version is still beta1.


2. Is there any equivalent of XSP in C3 ?

Not really. As you say below, XSP were already deprecated in C2.1.
The only template mechanism available in C3 is StringTemplate [2] which is way less flexible (and error-prone) than XSP.


The flexibility of XSP is very important to us in terms of introducing many new/short changes
very fast to our web application. We just make a change and that's all - cocoon engine recompiles the java-related
class and it is instantly available to us - no recompiling from our dev team, no deployment, no app server restart no fuss at all!
It allows us for very rapid changes! That's exactly the kind of flexibility we want to have in our dev environment.
And we were much worried when in next Cocoon releases the support for XSP was abandoned. As far as i know
XSP became deprecated in C2.1.11 to be totally removed in C2.2.x and i suppose in C3.
I didn't dig much into all the features of new Cocoon but it seems like in C2.1/2.2 the best thing to use on the "controller" side
is Flowscript code. We were hesitating to switch from pure Java controller code to Javascript/Flowscript
code because in my opinion the continuation mechanism is error-prone, yet the developer must take care of many intricacies
around session/continuation expire times and so on. But the main reason for us not to go for it was the language -
Javascript - NOT Java. Although if i get it right, you can just instantiate any Java object and get access to any Java library available
around from Javascript, it is not as much flexible as java was in XSP. Though it still doesn't require any recompiling!/redeployment phase
from  the dev team as i assume.
In C3 you can have Java controllers called and that is Good, but it does require recompiling the Java
class and redeploy it on the server (and restart app server?). So it will be much much SLOWER than just dynamic-recompiling by cocoon engine without any server restart.
So i wonder if there is any mechanism on the controller side available in C3 that enabled us to still use Java but doesn't require from us recompiling java code/making redeployment/restarting the application server ?

Sure: you can empower cocoon-maven-plugin [3] for this, or even setup something external like JRebel.


3. Is Flowscript using some separate javascript engine like V8 ? Is it run inside JVM as a dynamic language feature ?
Whats is a preferred method to be used as a logic controller in C3 - Flowscript or Java ?

There is no support at all for Flowscript / continuations in C3.


4. We don't want to go yet with C3 alpha-3 because it still uses old Xerces and XML-API libs. We found out there are some issues with those old libs under Tomcat 7 while working with "bloated" XML namespaces or handling some SAX errors. They had led to some memory leaks in our environment.
I spotted on the changelog that you have just updated C3 beta to the newest Xerces/XML-APIs. Thank you very much for this. I really appreciate that important change. Can we have some light on when the beta is released?

Nice question, indeed :-)
I'd suggest to send a separate e-mail about this topic to dev ML.

Regards.

[1] http://cocoon.apache.org/3.0/alpha-warning.html
[2] http://www.stringtemplate.org/
[3] http://cocoon.apache.org/2.2/maven-plugins/maven-plugin/1.0/1295_1_1.html -- Francesco Chicchiriccò Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/

Robby Pelssers | 11 Apr 15:38 2012

Cocoon2.2 maven jetty plugin issue

Hi guys,

 

I have been facing an issue related to the maven jetty plugin which is used to start a single C2.2 block.   Just for the record I have to mention that this has always worked in the past.  I have a strong suspicion that this is somehow related to our upgrade to Maven 3.

 

Did anybody else have similar issues and if so, were you able to resolve this?   I already tried switching to a newer jetty plugin but I could not get it working unfortunately.

 

2012-04-11 15:33:01.805:INFO:/:Initializing Spring root WebApplicationContext

2012-04-11 15:33:03.102:WARN::Failed startup of context org.mortbay.jetty.plugin.Jetty6PluginWebAppContext <at> dd0f87{/,C:\development\workspaces\intellij11\CTPI-PX\spider2\shared\target\rcl\webapp}

java.lang.RuntimeException: Cannot invoke listener org.springframework.web.context.ContextLoaderListener <at> 182752b

                at org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingListener.invoke(ReloadingListener.java:190)

                at org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingListener.contextInitialized(ReloadingListener.java:213)

                at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:549)

                at org.mortbay.jetty.servlet.Context.startContext(Context.java:136)

                at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1282)

                at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:518)

                at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:499)

                at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:115)

                at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)

                at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)

                at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)

                at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)

                at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)

                at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)

                at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)

                at org.mortbay.jetty.Server.doStart(Server.java:224)

                at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)

                at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132)

                at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:454)

                at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:396)

                at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:210)

                at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184)

                at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)

                at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)

                at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)

                at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)

                at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)

                at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)

                at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)

                at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)

                at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)

                at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)

                at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)

                at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)

                at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)

                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:597)

                at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)

                at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)

                at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)

                at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)

                at org.codehaus.classworlds.Launcher.main(Launcher.java:47)

                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:597)

                at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)

2012-04-11 15:33:03.116:INFO::Started SelectChannelConnector <at> 0.0.0.0:8888

[INFO] Started Jetty Server

Robby Pelssers | 11 Apr 15:51 2012

RE: Cocoon2.2 maven jetty plugin issue

In reply to my own question.  We don’t see consistent behaviour.  Some blocks startup properly so this might be caused by another issue.  It’s too bad from the stacktrace I don’t get any insight into the issue ;-(

 

Robby

 

From: Robby Pelssers [mailto:Robby.Pelssers <at> nxp.com]
Sent: Wednesday, April 11, 2012 3:39 PM
To: dev <at> cocoon.apache.org; users <at> cocoon.apache.org
Subject: Cocoon2.2 maven jetty plugin issue

 

Hi guys,

 

I have been facing an issue related to the maven jetty plugin which is used to start a single C2.2 block.   Just for the record I have to mention that this has always worked in the past.  I have a strong suspicion that this is somehow related to our upgrade to Maven 3.

 

Did anybody else have similar issues and if so, were you able to resolve this?   I already tried switching to a newer jetty plugin but I could not get it working unfortunately.

 

2012-04-11 15:33:01.805:INFO:/:Initializing Spring root WebApplicationContext

2012-04-11 15:33:03.102:WARN::Failed startup of context org.mortbay.jetty.plugin.Jetty6PluginWebAppContext <at> dd0f87{/,C:\development\workspaces\intellij11\CTPI-PX\spider2\shared\target\rcl\webapp}

java.lang.RuntimeException: Cannot invoke listener org.springframework.web.context.ContextLoaderListener <at> 182752b

                at org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingListener.invoke(ReloadingListener.java:190)

                at org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingListener.contextInitialized(ReloadingListener.java:213)

                at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:549)

                at org.mortbay.jetty.servlet.Context.startContext(Context.java:136)

                at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1282)

                at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:518)

                at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:499)

                at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:115)

                at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)

                at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)

                at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)

                at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)

                at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)

                at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)

                at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)

                at org.mortbay.jetty.Server.doStart(Server.java:224)

                at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)

                at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132)

                at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:454)

                at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:396)

                at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:210)

                at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184)

                at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)

                at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)

                at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)

                at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)

                at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)

                at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)

                at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)

                at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)

                at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)

                at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)

                at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)

                at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)

                at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)

                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:597)

                at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)

                at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)

                at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)

                at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)

                at org.codehaus.classworlds.Launcher.main(Launcher.java:47)

                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:597)

                at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)

2012-04-11 15:33:03.116:INFO::Started SelectChannelConnector <at> 0.0.0.0:8888

[INFO] Started Jetty Server

Andre Juffer | 11 Apr 16:05 2012
Picon
Picon

Re: Cocoon2.2 maven jetty plugin issue

About moving from Maven 2 to 3, I prepare everything with maven 3 (integrated into Netbeans). When testing an application with jetty, I start it up with maven2 on a Ubuntu) Linux box. I have never seen any issues with this. I do not think that the problem is caused by maven 2 or 3. Instead I would look at at the configuration of the application, as the error indicates that it basically cannot start up properly. Maybe there is XML error in one of the configuration files for Spring, or something like that.

On 04/11/2012 04:51 PM, Robby Pelssers wrote:
<!-- /* Font Definitions */ <at> font-face {font-family:PMingLiU; panose-1:2 2 5 0 0 0 0 0 0 0;} <at> font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} <at> font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} <at> font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} <at> font-face {font-family:"\ <at> PMingLiU"; panose-1:2 2 5 0 0 0 0 0 0 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:windowtext;} span.EmailStyle18 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} <at> page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} -->

In reply to my own question.  We don’t see consistent behaviour.  Some blocks startup properly so this might be caused by another issue.  It’s too bad from the stacktrace I don’t get any insight into the issue ;-(

 

Robby

 

From: Robby Pelssers [mailto:Robby.Pelssers <at> nxp.com]
Sent: Wednesday, April 11, 2012 3:39 PM
To: dev <at> cocoon.apache.org; users <at> cocoon.apache.org
Subject: Cocoon2.2 maven jetty plugin issue

 

Hi guys,

 

I have been facing an issue related to the maven jetty plugin which is used to start a single C2.2 block.   Just for the record I have to mention that this has always worked in the past.  I have a strong suspicion that this is somehow related to our upgrade to Maven 3.

 

Did anybody else have similar issues and if so, were you able to resolve this?   I already tried switching to a newer jetty plugin but I could not get it working unfortunately.

 

2012-04-11 15:33:01.805:INFO:/:Initializing Spring root WebApplicationContext

2012-04-11 15:33:03.102:WARN::Failed startup of context org.mortbay.jetty.plugin.Jetty6PluginWebAppContext <at> dd0f87{/,C:\development\workspaces\intellij11\CTPI-PX\spider2\shared\target\rcl\webapp}

java.lang.RuntimeException: Cannot invoke listener org.springframework.web.context.ContextLoaderListener <at> 182752b

                at org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingListener.invoke(ReloadingListener.java:190)

                at org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingListener.contextInitialized(ReloadingListener.java:213)

                at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:549)

                at org.mortbay.jetty.servlet.Context.startContext(Context.java:136)

                at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1282)

                at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:518)

                at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:499)

                at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:115)

                at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)

                at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)

                at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)

                at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)

                at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)

                at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)

                at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)

                at org.mortbay.jetty.Server.doStart(Server.java:224)

                at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)

                at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132)

                at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:454)

                at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:396)

                at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:210)

                at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184)

                at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)

                at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)

                at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)

                at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)

                at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)

                at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)

                at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)

                at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)

                at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)

                at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)

                at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)

                at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)

                at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)

                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:597)

                at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)

                at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)

                at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)

                at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)

                at org.codehaus.classworlds.Launcher.main(Launcher.java:47)

                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:597)

                at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)

2012-04-11 15:33:03.116:INFO::Started SelectChannelConnector <at> 0.0.0.0:8888

[INFO] Started Jetty Server



-- Andre H. Juffer | Phone: +358-8-553 1161 Biocenter Oulu and | Fax: +358-8-553-1141 Department of Biochemistry | Email: andre.juffer <at> oulu.fi University of Oulu, Finland | WWW: www.biochem.oulu.fi/Biocomputing/ StrucBioCat | WWW: www.strucbiocat.oulu.fi Triacle Biocomputing | WWW: www.triacle-bc.com
Mika M Lehtonen | 11 Apr 21:05 2012
Picon

database action data types

Cocoon 2.11

What to modify in order to be able to insert datatypes outside of 
JDBCTypeConversion types when using modular database action? I am trying 
to insert (and only insert) to PostGIS geometry column. The error is:

2012-04-11 18:41:23 EEST ERROR:  column "arvo_geom" is of type geometry 
but expression is of type character varying at character 174
2012-04-11 18:41:23 EEST HINT:  You will need to rewrite or cast the 
expression.

Can I add handlers for geometry datatype (org.postgis...) into 
org.apache.cocoon.util.JDBCTypeConversions or what should I do? Java 
isn't my bread and butter..

- mika -
Alberto | 13 Apr 19:03 2012
Picon

Forms and maps


Hi,

I'm using cocoon 2.1.12-dev and I'm facing how to include a map in
cocoon forms.
I have to do simple things from flowscript: load a kml url and receive
the coordinates of an area selection.
I'm considering to use OpenLayers or Google Maps. Looking sources I
found already existing widget classes for GoogleMaps
(org.apache.cocoon.forms.formmodel.GoogleMap) but it is undocumented and
using it I have the following error: "Non-existing component for this
hint (Key='googlemap')". Moreover it seems it lacks methods to load a
kml file.

So, which is the best way to do it? The googlemap widget is working?
I have to write a new widget following the document
http://wiki.apache.org/cocoon/CocoonFormsCreatingWidgets?

Any suggest is welcome

Best regards

Alberto
Mika M Lehtonen | 13 Apr 19:18 2012
Picon

Re: Forms and maps

Interesting,
I am also integrating maps into sites produced with Cocoon 2.1x. I have 
no answer to you but maybe we could collaborate on this issue?
OpenLayers widget would be something!

cheers,
mika

13.4.2012 20:03, Alberto kirjoitti:
> Hi,
>
> I'm using cocoon 2.1.12-dev and I'm facing how to include a map in
> cocoon forms.
> I have to do simple things from flowscript: load a kml url and receive
> the coordinates of an area selection.
> I'm considering to use OpenLayers or Google Maps. Looking sources I
> found already existing widget classes for GoogleMaps
> (org.apache.cocoon.forms.formmodel.GoogleMap) but it is undocumented and
> using it I have the following error: "Non-existing component for this
> hint (Key='googlemap')". Moreover it seems it lacks methods to load a
> kml file.
>
> So, which is the best way to do it? The googlemap widget is working?
> I have to write a new widget following the document
> http://wiki.apache.org/cocoon/CocoonFormsCreatingWidgets?
>
> Any suggest is welcome
>
> Best regards
>
> Alberto
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe <at> cocoon.apache.org
> For additional commands, e-mail: users-help <at> cocoon.apache.org
>
Robby Pelssers | 16 Apr 13:54 2012

using proxy from flowscript in Cocoon2.2

Hi all,

 

I have a use case where I need to post data to an Alfresco service which returns JSON response.  Currently I just posted the page and showed the JSON data but ideally I want to stay on the same page and make an XMLhttpRequest from the client side.  As this is crossdomain I need to setup a proxy service in flowscript but I can’t seem to find an easy way to accomplish this.

 

Anyone who has a nice suggestion or some sample snippets laying around?

 

Robby


Gmane