Cocoon 2.1.5.1 and Windows Handle Leak
We have an application that is using Cocoon 2.1.5.1 (I know that's a wee bit old) When we run this on Tomcat 5.5.25.0 with Java 1.5.0_16 (although these versions do not seem to make any difference) and we use the -XX:+UseParallelGC option. With the application IDLE, no clients have even attempted to connect. We see on Windows a handle leak at a rate of approx 64 handles (32 Event and 32 Semaphore) every 5-6 seconds. Oh, and it's a Heisenbug... if we attach a profiler or even JConsole the leak stops while we're attached, only to resume when we detatch! Now the good news is that this seems to be fixed in 2.1.12-SNAPSHOT... and it's not present in 2.0.4 So... I searched the change-log for the 2.1 stream and I cannot see anyone having claimed to fix a windows handle leak, yet it is fixed! My problem is that we need to fix the handle leak in a service pack... so I really just want to patch the 2.1.5.1 we are using and remove the leaky code, as to get our app working with 2.1.12 requires too many changes for a service pack. By the way, I think the leak is also present without the -XX:+UserParallelGC but since the defauly garbage collection presumes that this is a short lived application and therefore garbage collection can be put off until really needed (since there's no need if you're a short lived app) Any thoughts? -Stephen -- View this message in context: http://www.nabble.com/Cocoon-2.1.5.1-and-Windows-Handle-Leak-tp19430635p19430635.html Sent from the Cocoon - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 3.0 overview statement error:
On Sep 10, 2008, at 4:06 PM, Marc Driftmeyer wrote: Apache Cocoon 3 Apache Cocoon 3 is a major rewrite of Cocoon 2.2. Like Cocoon 2 it is based around the concept of pipelines and sitemaps and it is very similar to Cocoon 2.2 in many respects but is slimed[slimmed] down :-) :-) and designed to be easily usable from[suggestion: manageable] suggestion: embeddable within plain Java environments. On top of this Cocoon 3 has the goal of becoming the best available platform for RESTful webservices and web applications. —ml—
sitemap, action flow
Hi, I am using cocoon 2.1 and i have a sitemap in my application in which i have a certain action, if the action succeeds, i need to transform a particular page. the action returns a map and i have verified its not null, but the generation doesnt happen,can anybody check if iam doing something wrong... map:match pattern=huid-login map:act type=HUIDAuthenticationAction !-- Loggin suceeded, request will be forwarded.to the summary page-- map:transform type=SubmitterGroupSummary/ map:serialize type=xml/ /map:act !-- Login failed, try again. -- map:transform type=HuidLogin/ map:serialize type=xml/ /map:match The HUIDAuthenticationAction is returning a new Map, in case of successful action, but the SubmitterGroupSummary is not transformed.. i have declared the transformer, and action in map:components inside sitemap. Any idea? rgds Flemion.
Re: Cocoon 2.1.5.1 and Windows Handle Leak
Stephen Connolly-2 stephen.alan.connolly at gmail.com writes: We have an application that is using Cocoon 2.1.5.1 (I know that's a wee bit old) With the application IDLE, no clients have even attempted to connect. We see on Windows a handle leak at a rate of approx 64 handles (32 Event and 32 Semaphore) every 5-6 seconds. Searching the archives I found COCOON-1305 [1]. Somewhere in the middle (around) discussion points to TPCThreadManager which was used by ContinuationsManager. Unfortunately, there is no fix/patch linked explicitly but on 12/Nov/04 it is confirmed that the issue is fixed: Migration from Excalibur Event to RunnableManager fixes this bug IMO. So I guess you can have look at the changes from around that time. Hope this helps, Joerg [1] http://issues.apache.org/jira/browse/COCOON-1305 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem with Cocoon i18n
Hi, I'm having problems with cocoon internationalisation. The following are snippets of my code: Portion of the sitemap: map:transformers default=xslt map:transformer name=i18n logger=sitemap.transformer.i18n src=org.apache.cocoon.transformation.I18nTransformer catalogues default=messages catalogue id=messages name=messages location=* actions/translations*/ /catalogues cache-at-startuptrue/cache-at-startup untranslated-textuntranslated text!/untranslated-text /map:transformer /map:transformers *Note: actions/translations is in the same folder as the sitemap* .. and then the pipeline for the page: map:match pattern=*.htm map:generate type=UserRequest/ map:transform src={1}.xsl/ map:transform type=i18n map:parameter name=locale value={locale}/ /map:transform map:serialize type=html/ /map:match The xsl page to be transformed has the following: i18n:textkey1/i18n:text and in my messages xml file I have: ?xml version=1.0 encoding=UTF-8? catalogue xml:lang=en message key=key1Message for Key 1/message message key=key2Message for Key 2 /message /catalogue However when i access the page it displays key1 instead of the value for key1 which is Message for Key 1. Whats is the problem with the above? Regards, Justice
Very early 2.1.12-dojo1_1-dev committed
Dear All, I have the great pleasure to announce that a *very* pre-alpha release of my re-working of the Ajax and CForms blocks for Dojo 1.1.1 has been committed to : BRANCH_2_1_X-dojo1_1. Although there are no circumstances whatever in which you should use this for production (), you are heavily encouraged to check it out so that you may see the direction I hope cforms is going, criticise, contribute fixes, discuss changes, help document etc. etc. You will find that a lot works already. You will find lots of bugs, specially I hope, ones that I have not found. You will find an enormous number of 'TODO:'s in the code. You will find design notes for un-implemented widgets if you want a go yourself. Lots and lots of stuff to do. If you have any questions, suggestions, fixes, contributions etc. I would be really grateful if we could discuss them on the Dev list. The scope of our Dojo Widgets, the APIs they are written to and the way they work has changed dramatically since Dojo 0.4.3, so please take your time to aquatint yourself with the code. Apart from all of the bugs and omissions, the move to Dojo 1.1.1 is very transitory, Dojo 1.2 is expected out very soon. I do not know yet how it will effect what is done so far (that's what I am looking at next) but I know it is supposed to contain fixes for a few things that we want, that don't work in Dojo 1.1.1. So please have a look, and provide feedback. Many thanks regards Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with Cocoon i18n
On 9/11/08, Justice Utete [EMAIL PROTECTED] wrote: I'm having problems with cocoon internationalisation. The following are snippets of my code: Portion of the sitemap: map:transformers default=xslt map:transformer name=i18n logger=sitemap.transformer.i18n src=org.apache.cocoon.transformation.I18nTransformer catalogues default=messages catalogue id=messages name=messages location=actions/translations/ /catalogues cache-at-startuptrue/cache-at-startup untranslated-textuntranslated text!/untranslated-text /map:transformer /map:transformers Note: actions/translations is in the same folder as the sitemap .. and then the pipeline for the page: map:match pattern=*.htm map:generate type=UserRequest/ map:transform src={1}.xsl/ map:transform type=i18n map:parameter name=locale value={locale}/ /map:transform map:serialize type=html/ /map:match The xsl page to be transformed has the following: i18n:textkey1/i18n:text and in my messages xml file I have: ?xml version=1.0 encoding=UTF-8? catalogue xml:lang=en message key=key1Message for Key 1/message message key=key2Message for Key 2 /message /catalogue However when i access the page it displays key1 instead of the value for key1 which is Message for Key 1. Whats is the problem with the above? Regards, Justice Which version of Cocoon? What is the value of {locale}? (Test as a parameter to the XSLT and display on the page.) Cocoon-2.1 does not have an InputModule named locale. Use the request: map:transform type=i18n map:parameter name=locale value={request:locale}/ /map:transform I have yet to find a list of InputModules provided with Cocoon-2.2. HTH, solprovider - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 2.1.5.1 and Windows Handle Leak
Thanks for that Jörg, Hopefully I can use this information to derive a patch for 2.1.5.1 -Stephen Joerg Heinicke wrote: Stephen Connolly-2 stephen.alan.connolly at gmail.com writes: We have an application that is using Cocoon 2.1.5.1 (I know that's a wee bit old) With the application IDLE, no clients have even attempted to connect. We see on Windows a handle leak at a rate of approx 64 handles (32 Event and 32 Semaphore) every 5-6 seconds. Searching the archives I found COCOON-1305 [1]. Somewhere in the middle (around) discussion points to TPCThreadManager which was used by ContinuationsManager. Unfortunately, there is no fix/patch linked explicitly but on 12/Nov/04 it is confirmed that the issue is fixed: Migration from Excalibur Event to RunnableManager fixes this bug IMO. So I guess you can have look at the changes from around that time. Hope this helps, Joerg [1] http://issues.apache.org/jira/browse/COCOON-1305 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Cocoon-2.1.5.1-and-Windows-Handle-Leak-tp19430635p19445551.html Sent from the Cocoon - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 3.0 overview statement error:
What exactly is a non-plain Java environment?- Marc --- On Thu, 9/11/08, Mark Lundquist [EMAIL PROTECTED] wrote: From: Mark Lundquist [EMAIL PROTECTED] Subject: Re: Cocoon 3.0 overview statement error: To: users@cocoon.apache.org Date: Thursday, September 11, 2008, 4:40 AM On Sep 10, 2008, at 4:06 PM, Marc Driftmeyer wrote: Apache Cocoon 3 Apache Cocoon 3 is a major rewrite of Cocoon 2.2. Like Cocoon 2 it is based around the concept of pipelines and sitemaps and it is very similar to Cocoon 2.2 in many respects but is slimed[slimmed] down :-) :-) and designed to be easily usable from[suggestion: manageable] suggestion: embeddable within plain Java environments. On top of this Cocoon 3 has the goal of becoming the best available platform for RESTful webservices and web applications. —ml—
Re: Cocoon 3.0 overview statement error:
On Sep 11, 2008, at 7:44 PM, Marc Driftmeyer wrote: What exactly is a non-plain Java environment? Yeah, it's not the greatest phrase. I didn't find fault with it, though, because I couldn't think of a better one. Maybe easily embeddable in other Java projects, or just plain old easily embeddable. —ml— - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]