Re: java 1.5 and cocoon
Hello Joerg! Some parts of my domainmodel rely on java-1.5 specific stuff like Generics and so on. Within my first cocoon steps I don't have changed the source=1.3 attribute and of course get the 'generics are not supported in -source 1.3'-build-error. Is this the only thing I have to change to use java 1.5? Depends on what you are using to build your project. In my ant projects I have both 'source' and 'target' attributes set to 1.5. See http://ant.apache.org/manual/CoreTasks/javac.html I am using maven to build my project and cocoon 2.2 as my web-tier. I've read that it is also necessary to change some cocoon src-files wich use 'enum' as identifier because since 1.5 it is a keyword. Is this right? So what do I actually have to change when using 1.5 and cocoon 2.2? Nothing except for the build configs mentioned above. Cocoon is Java 5 or even Java 6 compatible. I've build a fresh cocoon-trunk a couple of minutes ago. I've changed plugin artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration source1.5/source target1.5/target /configuration /plugin within the ./parent/pom.xml file. Then I wanted to test the result and created a new simple-block. I've then changed the MyBean.java so that it defines a generics ListString. I still get the error that generics are not supported with -source 1.3, so anything is missing. Any advice? Much thanks, Patrick -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java 1.5 and cocoon [SOLVED]
Well, it was my fault. I've just need to put this in my own parent.pom, of course : plugin artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration source1.5/source target1.5/target /configuration /plugin ;) Greetings, Patrick -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Javaflow - major memory issue: more info
Thanks for the reply. Yea, I'm not too worried about continuation expiry parameter although I'd like to experiment with shrinking it. I think you mean sendPage vs sendPageAndWait? I can't find sendPageAndContinue. Anyway, both those methods have exactly the same code. Let me try to explain my case more clearly. I have a main application with a flow that sets some values required for all pages (mainly in the header, footer, etc). Then I have a sub-application that uses the same header, footer, etc. so it needs the same variables set in the main flow. But it also requires its own flow to do some specific logic. So, in the sitemap for this sub-application, any *.html file goes through the main flow. Then, the sendPage method in the main flow changes the uri to something like *.html.xyz. This hits a pipeline that calls the entry method in the flow for the sub-application. The sendPage in this method then sends the page to a pipeline that aggregates, transforms and serializes. My objective behind this is to create an inheritance pattern where the sub-application inherits the logic from the main application. But apparently this doesn't work based on the profiling I've done. After two sendPage calls, the memory skyrockets and doesn't clean up well. I have some ideas of how to do things differently but I prefer the this way as it seems more object-oriented. --- Torsten Curdt [EMAIL PROTECTED] wrote: On Mar 20, 2008, at 20:14, footh wrote: So, it appears that the continuations eventually clean up nicely. Of course, a constant load would kill the system as the continuation clean-up is too slow to keep up. Two things to note: 1) The expiry parameter in cocoon.xconf did not work. It was always 10 minutes no matter what I set it to. I remember that was reported before. Should be an easy fix. 2) The bottom paragraph of this page: http://cocoon.apache.org/2.1/userdocs/flow/using.html states that when using the sendPage method, no continuation is created and memory resources are not used. This does not seem to be the case as my test case uses a one-line flow with a sendPage call. Did you check the SendPage vs the SendPageAndContinue implementation? BTW: What version are you using? Back to my specific case, I then went to test my full-blown application. After running a series of tests similar to the one described above, I discovered an area that appears to be a problem. I have a main application that uses a primary javaflow, and a sub- application of the main app that needs the general logic in the primary flow and then its own logic in its own flow. So, it runs through two javaflows and thus two sendPage calls. Not sure I get that ...I remember the limitation of javaflow not behaving if you call a sub pipeline with another javaflow as the continuation is (still) saved in a per-thread context. To make a long story short, this seemed to cause a memory leak. Running just the main flow seemed ok, running just the sub-flow worked ok as well (there appeared to be a bit of a leak, but inconclusive). However, running a page through both flows showed a clear loss of memory. The continuations did not clean up. So, this could very well be the source of my problems. Based on note 2) above, I must've figured this would be OK due since sendPage supposedly doesn't have a large memory footprint. However, it appears to cause a problem based on my tests. I'm hoping the experts can chime in here: is this as bad an idea as it appears to be (running one page through multiple flows)? Could you give an example here? I am still not sure what you mean exactly by running through two flows. Surely what is needed to make this all better and safer in a high load environment is to limit the max number of continuations and not just rely on the time based clean up. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java 1.5 and cocoon
On Mar 22, 2008, at 12:27 PM, Joerg Heinicke wrote: On 22.03.2008 11:07, Patrick Heiden wrote: Some parts of my domainmodel rely on java-1.5 specific stuff like Generics and so on. Within my first cocoon steps I don't have changed the source=1.3 attribute and of course get the 'generics are not supported in -source 1.3'-build-error. Is this the only thing I have to change to use java 1.5? Depends on what you are using to build your project. In my ant projects I have both 'source' and 'target' attributes set to 1.5. See http://ant.apache.org/manual/CoreTasks/javac.html I am using maven to build my project and cocoon 2.2 as my web-tier. I've read that it is also necessary to change some cocoon src-files wich use 'enum' as identifier because since 1.5 it is a keyword. Is this right? So what do I actually have to change when using 1.5 and cocoon 2.2? Nothing except for the build configs mentioned above. Cocoon is Java 5 or even Java 6 compatible. I think this is true for Cocoon 2.1 and above but not for 2.0 which has a package with enum in the namespace. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java 1.5 and cocoon
On 24.03.2008 21:03, Robert La Ferla wrote: Cocoon is Java 5 or even Java 6 compatible. I think this is true for Cocoon 2.1 and above but not for 2.0 which has a package with enum in the namespace. I'm tempted to say of course not thinking that this should be obvious. I mean when did we stop to support 2.0? Must have been at least 4 years ago (last release 2.0.4 was end of 2002). Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Compiled vs. Interpreted Sitemap Engine (Cocoon 2.0.4)
I am using Cocoon 2.0.4. Can someone please explain why the interpreted sitemap engine is faster than the compiled one? Also, is it the class attribute that determines whether Cocoon is using the compiled vs. the interpreted sitemap engine? Seems like if you omit the class attribute, it should use the interpreted engine but if you specify class=org.apache.cocoon.sitemap.SitemapManager, it uses the compiled engine?? !-- The sitemap == -- !-- Compiled sitemap engine. This is the original engine, that is now replaced by the interpreted engine (see above). If you want to use this engine, uncomment this element and comment the defaut one below. Reloading of the sitemap: The check-reload attribute determines if the sitemap is reloaded on change. Set to no, the sitemap is generated once at startup. Set to yes, the sitemap is regenerated if it changes. The reload-method specifies the method for the regeneration: asynchron: WARNING: this reload method is broken and won't be fixed. Synchron is now made default and preferred reload method. synchron: If the sitemap changes, the sitemap is regenerated at the next request. When the regeneration is finished, the request (and all subsequent ones) is served with the new sitemap. For development environment, set the check-reload to yes. For production environment, it is advisable to set the check-reload to no. -- sitemap check-reload=yes class=org.apache.cocoon.sitemap.SitemapManager file=sitemap.xmap logger=sitemap reload-method=synchron/ !-- New implementation of the sitemap. It is interpreted, so load times are super-fast, and request processing is slightly faster than with the compiled engine thanks to the HotSpot VM. To use this engine, comment the declaration above and uncomment the declaration below. -- !-- sitemap logger=sitemap/ -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to inject the result of an action into a generator
Hello,
This doesn't work for me for some reason. I get an error (see end of this
message).
My code snippet is:
public class XMLInjectAction extends AbstractAction {
public Map act (Redirector redirector,SourceResolver resolver, Map
objectModel, String source, Parameters params) {
Map sitemapParams = new HashMap();
String xml=contenth1Automatically Generated By Action:
Hello/h1/content;
sitemapParams.put(paramAction, xml);
return sitemapParams;
}
}
And my sitemap entry is:
map:match pattern=xmlaction
map:act type=xml-injection
map:generate
map:parameter name=param
value={paramAction}/
/map:generate
/map:act
map:transform src=demo/welcome.xslt/
map:serialize type=xhtml/
/map:match
The error I get is as follows:
2008-03-25 00:28:50,812 btpool0-1 ERROR cocoon - Internal Cocoon Problem
org.apache.cocoon.ProcessingException: Failed to process pipeline
at map:serialize type=xhtml -
file:///c:/1/skunk-neuvoip/neuvoip/./src/main/resources/COB-INF/sitemap.xmap:47:33
at map:transform -
file:///c:/1/skunk-neuvoip/neuvoip/./src/main/resources/COB-INF/sitemap.xmap:46:44
at map:generate -
file:///c:/1/skunk-neuvoip/neuvoip/./src/main/resources/COB-INF/sitemap.xmap:42:20
at map:match -
file:///c:/1/skunk-neuvoip/neuvoip/./src/main/resources/COB-INF/sitemap.xmap:40:34
at
org.apache.cocoon.ProcessingException.throwLocated(ProcessingException.java:143)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.handleException(AbstractProcessingPipeline.java:921)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline(AbstractProcessingPipeline.java:370)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.setupPipeline(AbstractCachingProcessingPipeline.java:727)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.preparePipeline(AbstractProcessingPipeline.java:464)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:409)
at sun.reflect.GeneratedMethodAccessor55.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:72)
at $Proxy8.process(Unknown Source)
at
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:144)
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:77)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:151)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:240)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:171)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:251)
at
org.apache.cocoon.servlet.RequestProcessor.process(RequestProcessor.java:357)
at
org.apache.cocoon.servlet.RequestProcessor.service(RequestProcessor.java:171)
at
org.apache.cocoon.sitemap.SitemapServlet.service(SitemapServlet.java:64)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:567)
at
org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:544)
at
org.apache.cocoon.servletservice.spring.ServletFactoryBean$ServiceInterceptor.invoke(ServletFactoryBean.java:230)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
at
