Re: Jira: better use of the Priority field
I wonder if people just missed this topic in the volume of recent discussions. And two days before the silly season is probably not a good time to try to revive it :-) -David David Crossley wrote: At Apache Forrest we have discovered some problems with the ASF Jira. Cocoon is going to hit these same issues. So i wonder if we can address it together. There are evidently some people on cocoon-dev who have used Jira extensively. Perhaps we need customised screens. Jira has a field called Priority which has the values Blocker, Critical, Major, Minor, Trivial. ASF Bugzilla has a different concept. It has a field called Severity with those same values. It has another called Priority which has values like p1, p2, p3, etc. The Buzilla Severity means the impact of the issue (e.g. Blocker means that it prevents development). The Priority means the importance and order in which it should be fixed. [1] http://issues.apache.org/bugzilla/page.cgi?id=fields.html#bug_severity In my opinion Jira has these two concepts mixed up together. Some other project (Xalan?) has already added a custom field called fix-priority. Should we add that field to our issue screens and reports? This becomes confusing at the front page of a project e.g. http://issues.apache.org/jira/browse/FOR where By Priority is listed in the bottom-right. They are not actually our priority for fixing the issues, but a list of the perceived severity. There is an additional problem. Forrest has separate Plugins and Cocoon has separate Blocks. A Blocker in a Plugin is not necessarily a Blocker for the project as a whole. This makes it difficult for the developers to plan what to work on next and which issues need to be fixed for the upcoming release. It also gives an unrealistic view of the state of the project. So do people here agree with those problems? Do you see a workaround? Perhaps rename Priority to Severity and also list fix-priority on the front page and on the issue screens. Ross recently asked at ASF Infrastructure about the wider issue of separate sub-projects. See the answer and other discussion about this topic at forrest-dev [2] http://marc.theaimsgroup.com/?t=11321309431 http://marc.theaimsgroup.com/?l=forrest-devm=113334665915625 -David
Re: Jira: better use of the Priority field
Le 22 déc. 05, à 09:10, David Crossley a écrit : I wonder if people just missed this topic in the volume of recent discussions. And two days before the silly season is probably not a good time to try to revive it :-) I think you're right about the need for separate Severity and Priority fields, whatever the exact names. I don't have experience with Jira to tell you if it's easy to implement, but if it is I like the idea. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Jira: better use of the Priority field
David Crossley wrote:
I wonder if people just missed this topic in the
volume of recent discussions. And two days before
the silly season is probably not a good time to
try to revive it :-)
Recently I came across those two articles [1][2] and I think some points of the
author are interesting for OS projects too. Especially I refer to the
distinction between priority and serverity (more or less the same as you do in
your mail).
David Crossley wrote:
At Apache Forrest we have discovered some problems with
the ASF Jira. Cocoon is going to hit these same issues.
So i wonder if we can address it together. There are
evidently some people on cocoon-dev who have used
Jira extensively. Perhaps we need customised screens.
Jira has a field called Priority which has the values
Blocker, Critical, Major, Minor, Trivial.
ASF Bugzilla has a different concept. It has a field
called Severity with those same values. It has another
called Priority which has values like p1, p2, p3, etc.
The Buzilla Severity means the impact of the issue
(e.g. Blocker means that it prevents development).
The Priority means the importance and order in which
it should be fixed.
[1] http://issues.apache.org/bugzilla/page.cgi?id=fields.html#bug_severity
In my opinion Jira has these two concepts mixed up
together.
yes, I agree here
Some other project (Xalan?) has already added a custom
field called fix-priority. Should we add that field
to our issue screens and reports?
This becomes confusing at the front page of a project
e.g. http://issues.apache.org/jira/browse/FOR
where By Priority is listed in the bottom-right.
They are not actually our priority for fixing the
issues, but a list of the perceived severity.
There is an additional problem. Forrest has separate
Plugins and Cocoon has separate Blocks. A Blocker
in a Plugin is not necessarily a Blocker for the project
as a whole.
right, this is one of our goals with splitting up Cocoon into blocks
This makes it difficult for the developers to plan what
to work on next and which issues need to be fixed for
the upcoming release. It also gives an unrealistic view
of the state of the project.
So do people here agree with those problems?
I agree
Do you see a workaround? Perhaps rename Priority to
Severity and also list fix-priority on the front page
and on the issue screens.
I think JIRA should be flexible enough.
Ross recently asked at ASF Infrastructure about the
wider issue of separate sub-projects. See the answer
and other discussion about this topic at forrest-dev
[2] http://marc.theaimsgroup.com/?t=11321309431
http://marc.theaimsgroup.com/?l=forrest-devm=113334665915625
Each block is a component in JIRA and I can get a summary of all open issues for
a component. Hmm, I think that I don't understand completly the problem that you
want to solve ...
[1] http://www.onlamp.com/pub/a/onlamp/2005/08/11/fixingbugs.html
[2] http://www.onlamp.com/pub/a/onlamp/2005/08/11/fixingbugs2.html
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
[jira] Created: (COCOON-1721) Performance Issue / FS Checks
Performance Issue / FS Checks - Key: COCOON-1721 URL: http://issues.apache.org/jira/browse/COCOON-1721 Project: Cocoon Type: Improvement Components: Blocks: Java Flow Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9-dev (current SVN) Reporter: Georg Hüttenegger Priority: Minor Attachments: CompilingInterpreter.java.diff, FOM_JavaScriptInterpreter.java.diff After a little bit of analyzing I found out that cocoon does a lot of file system checks for the last modification time (of java script files) even if reload scripts is turned off. I have made two small changes in org\apache\cocoon\components\flow CompilingInterpreter.java and org\apache\cocoon\components\flow\javascript\fom FOM_JavaScriptInterpreter.java that changed this. I hope that my changes look ok and can be incorporated in future versions. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[EMAIL PROTECTED]: Project cocoon (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon has an issue affecting its community integration. This issue affects 57 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon : Java XML Framework - cocoon-block-ajax : Ajax - Utilities and resources for Ajax applications. - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-captcha : Utilites to generate simple CAPTCHAs - cocoon-block-chaperon : Java XML Framework - cocoon-block-core-samples-additional : Additional core samples. - cocoon-block-core-samples-main : Main core samples. - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-faces : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jcr : A jcr: protocol for Cocoon - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-mail : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-scratchpad : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-spring-app : A demo for Spring and Cocoon - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-validation : In-pipeline validation of documents - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - forrest : Apache Forrest is an XML standards-oriented documentation fr... - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... - lenya : Content Management System Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon] -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: [cocoon-testcase] -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: [cocoon-deprecated] -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-21122005/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-21122005/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-21122005/test/output] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html Work Name: build_cocoon_cocoon (Type: Build) Work ended in a state of : Failed Elapsed: 60 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dlogkit.jar=/usr/local/gump/public/workspace/excalibur/containerkit/logkit/target/excalibur-logkit-21122005.jar -Dbuild=build/cocoon-21122005 gump-core [Working Directory:
[EMAIL PROTECTED]: Project cocoon (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon has an issue affecting its community integration. This issue affects 57 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon : Java XML Framework - cocoon-block-ajax : Ajax - Utilities and resources for Ajax applications. - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-captcha : Utilites to generate simple CAPTCHAs - cocoon-block-chaperon : Java XML Framework - cocoon-block-core-samples-additional : Additional core samples. - cocoon-block-core-samples-main : Main core samples. - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-faces : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jcr : A jcr: protocol for Cocoon - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-mail : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-scratchpad : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-spring-app : A demo for Spring and Cocoon - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-validation : In-pipeline validation of documents - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - forrest : Apache Forrest is an XML standards-oriented documentation fr... - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... - lenya : Content Management System Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon] -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: [cocoon-testcase] -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: [cocoon-deprecated] -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-21122005/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-21122005/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-21122005/test/output] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html Work Name: build_cocoon_cocoon (Type: Build) Work ended in a state of : Failed Elapsed: 60 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dlogkit.jar=/usr/local/gump/public/workspace/excalibur/containerkit/logkit/target/excalibur-logkit-21122005.jar -Dbuild=build/cocoon-21122005 gump-core [Working Directory:
[jira] Updated: (COCOON-1709) Speedup portal loading
[ http://issues.apache.org/jira/browse/COCOON-1709?page=all ] Jean-Baptiste Quenot updated COCOON-1709: - Attachment: 20051222-MapProfileLS.java Update the patch: * check the validity of profiles * clone layout like what is done for copletinstancedata Updated patch contributed by Philippe Gassmann [EMAIL PROTECTED] Speedup portal loading -- Key: COCOON-1709 URL: http://issues.apache.org/jira/browse/COCOON-1709 Project: Cocoon Type: Improvement Components: Blocks: Portal Versions: 2.1.9-dev (current SVN) Reporter: Jean-Baptiste Quenot Attachments: 20051212-portal-MapProfileLS, 20051222-MapProfileLS.java Portal loads user profiles (when using eg AuthenticationProfileManager) with Castor every time the user logs in and this is very slow. This patch allows to cache the result for further invocations. However the coplet instance profiles are handled in a special way, after being obtained by mapping the CopletInstanceDataManager they are cloned to ensure that every user gets its own copy of the coplets. Thus this bug depends on http://issues.apache.org/jira/browse/COCOON-1708 Allow CopletInstanceDataManager to be cloneable. An improvement would be to store cached objects in Cocoon Store, the provided patch currently uses a simple HashMap to store profiles. Note that the key of the object is the URI returned by the source. This is important because different values of uri in resolver.resolveURI(uri) could return the same source, ie source.getURI() could be the same, so only different objects are stored in the Map. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1709) Speedup portal loading
[ http://issues.apache.org/jira/browse/COCOON-1709?page=all ] Jean-Baptiste Quenot updated COCOON-1709: - Attachment: 20051222-MapProfileLS.java Update patch: prevent NPE if source has null validity Speedup portal loading -- Key: COCOON-1709 URL: http://issues.apache.org/jira/browse/COCOON-1709 Project: Cocoon Type: Improvement Components: Blocks: Portal Versions: 2.1.9-dev (current SVN) Reporter: Jean-Baptiste Quenot Attachments: 20051212-portal-MapProfileLS, 20051222-MapProfileLS.java, 20051222-MapProfileLS.java Portal loads user profiles (when using eg AuthenticationProfileManager) with Castor every time the user logs in and this is very slow. This patch allows to cache the result for further invocations. However the coplet instance profiles are handled in a special way, after being obtained by mapping the CopletInstanceDataManager they are cloned to ensure that every user gets its own copy of the coplets. Thus this bug depends on http://issues.apache.org/jira/browse/COCOON-1708 Allow CopletInstanceDataManager to be cloneable. An improvement would be to store cached objects in Cocoon Store, the provided patch currently uses a simple HashMap to store profiles. Note that the key of the object is the URI returned by the source. This is important because different values of uri in resolver.resolveURI(uri) could return the same source, ie source.getURI() could be the same, so only different objects are stored in the Map. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[vote] Jean-Baptiste Quenot as new Cocoon committer (was Re: Problem with CachingPointProcessingPipeline)
Hi, On 20 Dec 2005, at 15:56, Jean-Baptiste Quenot wrote: See patch attached. WDYT? I think you should become a committer, so you can work on these things without patches :-) Everyone: Jean-Baptiste is becoming more and more active on the dev list, and has been diligently filing bugs and patches for the last few months. The first post about his activity is from July, 2004 [1]. He seems to have a good grasp of the guts of Cocoon. I think it's time for him to become a committer. [1] http://marc.theaimsgroup.com/?a=10893038224r=3w=2 Please cast your votes! Here's mine: +1 Thanks, Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
Re: [vote] Jean-Baptiste Quenot as new Cocoon committer (was Re: Problem with CachingPointProcessingPipeline)
Le 22 déc. 05, à 14:42, Andrew Savory a écrit : ...I think it's time for him to become a committer... So do I, thanks Andrew for your suggestion. (and...I'm all for more French-speaking committers ;-) ...Please cast your votes! +1 -Bertrand smime.p7s Description: S/MIME cryptographic signature
[jira] Updated: (COCOON-1722) Testing...
[ http://issues.apache.org/jira/browse/COCOON-1722?page=all ] Pier Fumagalli updated COCOON-1722: --- Urgency: Blocker Testing... -- Key: COCOON-1722 URL: http://issues.apache.org/jira/browse/COCOON-1722 Project: Cocoon Type: Test Reporter: Pier Fumagalli -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1722) Testing...
Testing... -- Key: COCOON-1722 URL: http://issues.apache.org/jira/browse/COCOON-1722 Project: Cocoon Type: Test Reporter: Pier Fumagalli -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Deleted: (COCOON-1722) Testing...
[ http://issues.apache.org/jira/browse/COCOON-1722?page=all ] Pier Fumagalli deleted COCOON-1722: --- Testing... -- Key: COCOON-1722 URL: http://issues.apache.org/jira/browse/COCOON-1722 Project: Cocoon Type: Test Reporter: Pier Fumagalli -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [vote] Jean-Baptiste Quenot as new Cocoon committer (was Re: Problem with CachingPointProcessingPipeline)
Andrew Savory wrote: Hi, On 20 Dec 2005, at 15:56, Jean-Baptiste Quenot wrote: See patch attached. WDYT? I think you should become a committer, so you can work on these things without patches :-) Everyone: Jean-Baptiste is becoming more and more active on the dev list, and has been diligently filing bugs and patches for the last few months. The first post about his activity is from July, 2004 [1]. He seems to have a good grasp of the guts of Cocoon. I think it's time for him to become a committer. [1] http://marc.theaimsgroup.com/?a=10893038224r=3w=2 Please cast your votes! Jean-Baptiste being a coworker, I want to stay neutral and won't vote. But needless to say that will be more than happy that he stops bugging me with his patches :-) Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Jira: better use of the Priority field
On 22 Dec 2005, at 09:20, David Crossley wrote: Reinhard Poetz wrote: Each block is a component in JIRA and I can get a summary of all open issues for a component. Hmm, I think that I don't understand completly the problem that you want to solve ... Basically that it is difficult for people to get an idea of which are the urgent issues to be solved for a release. If they have some time, what should they solve next. Looking at the reports from http://issues.apache.org/jira/browse/COCOON We have Open Issues : By Priority but that is actually perceived severity. Looking at the FOR tracker is even worse. There are some issues listed as Blocker on that front-page listing and on our Roadmap, but they are only blockers for that particular plugin/Component. I want to add an extra field fix-priority to our issue entry/edit screens in Jira. Then we can create a report of Open issues : By fix-priority. It's called Urgency and it's there now (2 minutes job) :-) Pier smime.p7s Description: S/MIME cryptographic signature
[jira] Commented: (COCOON-1709) Speedup portal loading
[ http://issues.apache.org/jira/browse/COCOON-1709?page=comments#action_12361108 ] Carsten Ziegeler commented on COCOON-1709: -- I think this feature should at least be made configurable - during development I just want to change the profile xml, do a new login and use the new profile Speedup portal loading -- Key: COCOON-1709 URL: http://issues.apache.org/jira/browse/COCOON-1709 Project: Cocoon Type: Improvement Components: Blocks: Portal Versions: 2.1.9-dev (current SVN) Reporter: Jean-Baptiste Quenot Attachments: 20051212-portal-MapProfileLS, 20051222-MapProfileLS.java, 20051222-MapProfileLS.java Portal loads user profiles (when using eg AuthenticationProfileManager) with Castor every time the user logs in and this is very slow. This patch allows to cache the result for further invocations. However the coplet instance profiles are handled in a special way, after being obtained by mapping the CopletInstanceDataManager they are cloned to ensure that every user gets its own copy of the coplets. Thus this bug depends on http://issues.apache.org/jira/browse/COCOON-1708 Allow CopletInstanceDataManager to be cloneable. An improvement would be to store cached objects in Cocoon Store, the provided patch currently uses a simple HashMap to store profiles. Note that the key of the object is the URI returned by the source. This is important because different values of uri in resolver.resolveURI(uri) could return the same source, ie source.getURI() could be the same, so only different objects are stored in the Map. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [vote] Jean-Baptiste Quenot as new Cocoon committer (was Re: Problem with CachingPointProcessingPipeline)
Please cast your votes! +1 Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
[jira] Commented: (COCOON-1709) Speedup portal loading
[ http://issues.apache.org/jira/browse/COCOON-1709?page=comments#action_12361110 ] Jean-Baptiste Quenot commented on COCOON-1709: -- No need for this feature to be optional: with the updated patch, profiles are reloaded when changed because the validity object returned by the source is checked Speedup portal loading -- Key: COCOON-1709 URL: http://issues.apache.org/jira/browse/COCOON-1709 Project: Cocoon Type: Improvement Components: Blocks: Portal Versions: 2.1.9-dev (current SVN) Reporter: Jean-Baptiste Quenot Attachments: 20051212-portal-MapProfileLS, 20051222-MapProfileLS.java, 20051222-MapProfileLS.java Portal loads user profiles (when using eg AuthenticationProfileManager) with Castor every time the user logs in and this is very slow. This patch allows to cache the result for further invocations. However the coplet instance profiles are handled in a special way, after being obtained by mapping the CopletInstanceDataManager they are cloned to ensure that every user gets its own copy of the coplets. Thus this bug depends on http://issues.apache.org/jira/browse/COCOON-1708 Allow CopletInstanceDataManager to be cloneable. An improvement would be to store cached objects in Cocoon Store, the provided patch currently uses a simple HashMap to store profiles. Note that the key of the object is the URI returned by the source. This is important because different values of uri in resolver.resolveURI(uri) could return the same source, ie source.getURI() could be the same, so only different objects are stored in the Map. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [vote] Jean-Baptiste Quenot as new Cocoon committer (was Re: Problem with CachingPointProcessingPipeline)
Andrew Savory wrote: Please cast your votes! Here's mine: +1 +1 Ralph
Re: [vote] Jean-Baptiste Quenot as new Cocoon committer (was Re: Problem with CachingPointProcessingPipeline)
Andrew Savory wrote: Hi, On 20 Dec 2005, at 15:56, Jean-Baptiste Quenot wrote: See patch attached. WDYT? I think you should become a committer, so you can work on these things without patches :-) Everyone: Jean-Baptiste is becoming more and more active on the dev list, and has been diligently filing bugs and patches for the last few months. The first post about his activity is from July, 2004 [1]. He seems to have a good grasp of the guts of Cocoon. I think it's time for him to become a committer. [1] http://marc.theaimsgroup.com/?a=10893038224r=3w=2 Please cast your votes! Here's mine: +1 +1 :-) Best Regards, Antonio Gallardo.
Re: [vote] Jean-Baptiste Quenot as new Cocoon committer (was Re: Problem with CachingPointProcessingPipeline)
Andrew Savory wrote: Hi, On 20 Dec 2005, at 15:56, Jean-Baptiste Quenot wrote: See patch attached. WDYT? I think you should become a committer, so you can work on these things without patches :-) Everyone: Jean-Baptiste is becoming more and more active on the dev list, and has been diligently filing bugs and patches for the last few months. The first post about his activity is from July, 2004 [1]. He seems to have a good grasp of the guts of Cocoon. I think it's time for him to become a committer. [1] http://marc.theaimsgroup.com/?a=10893038224r=3w=2 Please cast your votes! Here's mine: +1 +1 and welcome! -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [vote] Jean-Baptiste Quenot as new Cocoon committer (was Re: Problem with CachingPointProcessingPipeline)
On Thu, Dec 22, 2005 at 01:42:50PM +, Andrew Savory wrote: He seems to have a good grasp of the guts of Cocoon. I think it's time for him to become a committer. ... Please cast your votes! +1 and welcome :) --Tim Larson
Re: JMX integration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hehe, there is someone who is intrested in JMX. On Thu, 22 Dec 2005, Carsten Ziegeler wrote: Date: Thu, 22 Dec 2005 01:01:46 +0100 From: Carsten Ziegeler [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: JMX integration Giacomo Pati wrote: I now do have a working implementation for JMX with the least impact (by added dependencies) to the core (so far only the javax.management interfaces). The discovery approach is simply looking whether there is a class which has the MBean suffix to the FQCN of the Component target for Management. This means you'll have to write your MBeans by hand (yes there are helper base classes available somewhere else and I will write about this below). The code I've written checks whether there is a MBeanServer available in the JVM and only adds JMX discovery support if there is one (doesn't create an MBeanServer on it's own so far like Commons-Modeler does). Awesome. Sounds great. One of my goals for 2.2 was to add JMX support to Cocoon, but I never really got time for it. Now I got it but needed some advice concerning the dependencies. snip/ The question I'd like to discuss is whether we wan't add a supporting package (Commons-Modeler or jetty/mortbay's ModelMBeanImpl) or should we just stay with the support to add MBeans (how ever those are implemented is up to the user) to a possibly running MBeanServer in the JVM? Hmm actually I don't care that much if we add another dependency. I rewrote the core of Cocoon and added ECM++ for being able to add JMX Yes, thanks. It was pretty easy to apply the JMX support in 2.2 whereas in 2.1 it is only possible that one can write JMX aware components under mentioned circumstances (ThreadSafe and Component). support somehow. Now, it thing depending on commons-modeler is a little bit easier as it's an Apache project - if there is something wrong for us we can fix it more easily. But apart from that, I think I just trust your decision which of the two is better suited for us. Well, commons-modeler don't has the JMX interfaces and thus another dependency on mx4j-jmx is needed as that jar is redistributable (whereas the one from sun is not IIRC). Comparing jetty's jmx helper calsses to the commons-modeler I see benefits for jetty's as that package supports MBean arrays whereas commons-modeler only supports primitive arrays. MBean array would make it possible to make array components implementing the same interface (ServiceSelector) directly registrable as MBean (for those which implements an MBean interface). So, big +1 for adding JMX support to 2.2 :) And what about 2.1? Ciao Giacomo - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDqt5SLNdJvZjjVZARAmDlAKCwkx9UB0ZMLfHiBhrjkX4vIKaLJQCgwvAf dXKE8hqTEu1zTwq5cFlx+58= =GO76 -END PGP SIGNATURE-
Re: JMX integration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 21 Dec 2005, Upayavira wrote: Date: Wed, 21 Dec 2005 16:00:41 -0800 From: Upayavira [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: JMX integration Carsten Ziegeler wrote: Giacomo Pati wrote: I now do have a working implementation for JMX with the least impact (by added dependencies) to the core (so far only the javax.management interfaces). The discovery approach is simply looking whether there is a class which has the MBean suffix to the FQCN of the Component target for Management. This means you'll have to write your MBeans by hand (yes there are helper base classes available somewhere else and I will write about this below). The code I've written checks whether there is a MBeanServer available in the JVM and only adds JMX discovery support if there is one (doesn't create an MBeanServer on it's own so far like Commons-Modeler does). Awesome. Sounds great. One of my goals for 2.2 was to add JMX support to Cocoon, but I never really got time for it. I was also asking myself (and now you guys) whether we should depend on Commons-Modeler which has some nice conveniences to add JMX ModelMBean support by xml configuration files and/or subclassing of their BaseModelMBean helper class. Other helper base classes I've found is the org.mortbay.util.jmx.ModelMBeanImpl which make writing MBean classes very easy (I think there is also some generating introstecting method like Commons-Modeler does) and also supports array of managed objects which would come handy for pools of manageable components (which Commons-Modeler base classes doesn't seem to support, only primitive data types). The ModelMBeanImpl base class supports resource properties file which respect the locale of the machine the JVM runs on for the descriptions of the mbean attributes/operations etc. which should be shown in the JMX-Console. A word to components targeted for Management: In 2.1 the support for JMX is quite limitted as we do not control the code of the Component Management parts (it's Excalibur code and I wouldn't take the effort to change it) and thus targets are only components which a ThreadSafe and implement the Component interface (maybe more components could be a traget for management but so far I've only choosen those). In 2.2 the situation is much more comfortable (as we control the component management code). There I'll have support ready for any ThreadSafe components as well as for the NonThreadSafePoolableComponentHandler (for the min/max values of the pools by use of the ModelMBeanImpl base class but this can be changed to Commons-Modeler). Adding management for pools of components will depend on which JMX supporting package we decide to choose. With Commons-Modeler I think it would be a more code to write thanwith the mortbay ModelMBeanImpl base class. The question I'd like to discuss is whether we wan't add a supporting package (Commons-Modeler or jetty/mortbay's ModelMBeanImpl) or should we just stay with the support to add MBeans (how ever those are implemented is up to the user) to a possibly running MBeanServer in the JVM? Hmm actually I don't care that much if we add another dependency. I rewrote the core of Cocoon and added ECM++ for being able to add JMX support somehow. Now, it thing depending on commons-modeler is a little bit easier as it's an Apache project - if there is something wrong for us we can fix it more easily. But apart from that, I think I just trust your decision which of the two is better suited for us. So, big +1 for adding JMX support to 2.2 :) So long as the new dependency isn't one for the core, but can be contained in a block. No, this is why I'm seeking for suggestions. JMX support has to be implemented in the core (CoreComponentManager IIRC) and thus will introduce new dependencies. Giacomo - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDqt/ELNdJvZjjVZARAskTAKCLBk8/zBohd/3dPYnOPorS93R7cQCfZvbM 3PjDM8pUiPdfhMFHzFYdVu8= =c8+W -END PGP SIGNATURE-
RE: [vote] Jean-Baptiste Quenot as new Cocoon committer (was Re: Problem with CachingPointProcessingPipeline)
Please cast your votes! +1, welcome! Best regards, Max Pfingsthorn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl -
Re: Cocoon 2.1.7 hang
We finally got some thread dumps from our production server. It shows something very different than what we were seeing in testing. First, this happens under light load after running for days. To summarize, many threads are waiting for the ResourceLimitingPool and several are waiting for the class loader. This system hasn't had the pools tuned so I'm not surprised about pool contention, but I don't believe that is the issue. That is because the thread holding the lock is simply waiting for the class loader. We took two traces and both were similar, but not identical. Different threads were holding the class loader lock in both. However, in both cases the threads holding the class loader lock were called from Castor while creating the portal layout. So far, we have been speculating that the problem is due to a problem with the NPTL threads on Enterprise Linux 3. However, I'm wondering if perhaps castor is having problems and simply calling the class loader over and over. I'd appreciate any ideas. We see many threads like this one... http-8080-Processor155 daemon prio=1 tid=0x083e3378 nid=0x1e8b waiting for monitor entry [22dc..22dc187c] at org.apache.avalon.excalibur.pool.ResourceLimitingPool.get(ResourceLimitingPool.java:262) - waiting to lock 0x60cd9970 (a java.lang.Object) at org.apache.avalon.excalibur.component.PoolableComponentHandler.doGet(PoolableComponentHandler.java:198) at org.apache.avalon.excalibur.component.ComponentHandler.get(ComponentHandler.java:381) at org.apache.avalon.excalibur.component.ExcaliburComponentSelector.select(ExcaliburComponentSelector.java:213) at org.apache.cocoon.components.ExtendedComponentSelector.select(ExtendedComponentSelector.java:260) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.addTransformer(AbstractProcessingPipeline.java:267) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.addTransformer(AbstractCachingProcessingPipeline.java:143) at org.apache.cocoon.components.treeprocessor.sitemap.TransformNode.invoke(TransformNode.java:59) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:138) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:89) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:240) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:180) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:243) at org.apache.cocoon.Cocoon.process(Cocoon.java:606) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1119) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929) at
Re: Jira: better use of the Priority field
Pier Fumagalli wrote: It's called Urgency and it's there now (2 minutes job) :-) Yeah, it is for someone who knows what they are up to. Thanks. However there is more to it. We need to redefine the instruction text for the existing Priority field. If no-one beats me to it, then i will try. And there are some procedural questions. For example, i presume that this Urgency field will be available to the person who enters the bug and that the committers will follow up and assign the project's actual Urgency. Alternatively it could be not available to the issue creation screen and is only something that people with Edit permissions can add. -David
Re: [vote] Jean-Baptiste Quenot as new Cocoon committer (was Re: Problem with CachingPointProcessingPipeline)
On 12/22/05, Andrew Savory [EMAIL PROTECTED] wrote: Everyone: Jean-Baptiste is becoming more and more active on the dev list, and has been diligently filing bugs and patches for the last few months. The first post about his activity is from July, 2004 [1]. He seems to have a good grasp of the guts of Cocoon. I think it's time for him to become a committer. Please cast your votes! +1 -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [vote] Jean-Baptiste Quenot as new Cocoon committer (was Re: Problem with CachingPointProcessingPipeline)
Andrew Savory wrote: Please cast your votes! +1 -David
Re: Jira: better use of the Priority field
On 22 Dec 2005, at 22:49, David Crossley wrote: Pier Fumagalli wrote: It's called Urgency and it's there now (2 minutes job) :-) Yeah, it is for someone who knows what they are up to. Thanks. However there is more to it. We need to redefine the instruction text for the existing Priority field. If no-one beats me to it, then i will try. That's a system wide issue, I don't think it can be changed on a project-by-project basis: I would have liked something like Gravity and Urgency (or Severity and Priority) but I didn't find a way to play around with global pre-defined fields in Jira (only show or hide them). And there are some procedural questions. For example, i presume that this Urgency field will be available to the person who enters the bug and that the committers will follow up and assign the project's actual Urgency. Alternatively it could be not available to the issue creation screen and is only something that people with Edit permissions can add. For now it's available to anyone (in other words, no security associated with it) but it can be restricted if you need to. Pier smime.p7s Description: S/MIME cryptographic signature
Re: Cocoon 2.1.7 hang
On 22 Dec 2005, at 18:16, Ralph Goers wrote: We finally got some thread dumps from our production server. It shows something very different than what we were seeing in testing. First, this happens under light load after running for days. To summarize, many threads are waiting for the ResourceLimitingPool and several are waiting for the class loader. This system hasn't had the pools tuned so I'm not surprised about pool contention, but I don't believe that is the issue. That is because the thread holding the lock is simply waiting for the class loader. We took two traces and both were similar, but not identical. Different threads were holding the class loader lock in both. However, in both cases the threads holding the class loader lock were called from Castor while creating the portal layout. So far, we have been speculating that the problem is due to a problem with the NPTL threads on Enterprise Linux 3. However, I'm wondering if perhaps castor is having problems and simply calling the class loader over and over. I'd appreciate any ideas. Ok, as far as I can see down the dumps you might have some problems with Catalina's classloader implementation locking up at 0x60b19148: at org.apache.catalina.loader.WebappClassLoader.loadClass (WebappClassLoader.java:1255) That seems odd though... I thought that code was debugged pretty thoroughly, unless, a seconday lock at 0x60cd9970 prevents the first one to be released... Anyhow, from my experience, NPTL don't cause any whatsoever problem under Linux, but that said, I'm running on Jetty 4 with BEA JRockit 1.4.2. What VM and what container are you actually using? Pier smime.p7s Description: S/MIME cryptographic signature
Re: Jira: better use of the Priority field
David Crossley wrote: Pier Fumagalli wrote: It's called Urgency and it's there now (2 minutes job) :-) Yeah, it is for someone who knows what they are up to. Thanks. However there is more to it. We need to redefine the instruction text for the existing Priority field. If no-one beats me to it, then i will try. I tweaked the notes below every field for the Cocoon Screen, to give (hopefully) better instructions for people who are reporting issues. It should help to clarify the Priority/Urgency. -David
[jira] Updated: (COCOON-1639) [patch] NekoHTMLTransformer
[ http://issues.apache.org/jira/browse/COCOON-1639?page=all ] David Crossley updated COCOON-1639: --- Bugzilla Id: (was: 37023) Other Info: [Patch available] [patch] NekoHTMLTransformer --- Key: COCOON-1639 URL: http://issues.apache.org/jira/browse/COCOON-1639 Project: Cocoon Type: Improvement Components: Blocks: HTML Versions: 2.1.8 Environment: Operating System: All Platform: All Reporter: Andrew Stevens Assignee: Cocoon Developers Team Priority: Minor Attachments: NekoHTMLTransformer.java, htmlblock.diff, neko.properties The html block contains HTMLGenerator, HTMLTransformer, NekoHTMLGenerator and... hey, where's the NekoHTMLTransformer? So, just to complete the set, here's one I prepared earlier :-) I've also included an (empty) neko.properties configuration file, and updated the neko generator's setup bits to allow for setting parser features as well as properties. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Jira: better use of the Priority field
While in configuration mode, i added another custom field called Other info. This is a multi-checkbox field. At the moment only one checkbox: Patch available. -David
Re: [vote] Jean-Baptiste Quenot as new Cocoon committer
Andrew Savory wrote:
Hi,
On 20 Dec 2005, at 15:56, Jean-Baptiste Quenot wrote:
See patch attached.
WDYT?
I think you should become a committer, so you can work on these things
without patches :-)
Everyone: Jean-Baptiste is becoming more and more active on the dev
list, and has been diligently filing bugs and patches for the last few
months. The first post about his activity is from July, 2004 [1]. He
seems to have a good grasp of the guts of Cocoon. I think it's time for
him to become a committer.
[1] http://marc.theaimsgroup.com/?a=10893038224r=3w=2
Please cast your votes!
Here's mine: +1
and my +1 too, welcome Jean-Baptiste! It's good to see another Portal expert
becoming a committer.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
RE: [vote] Jean-Baptiste Quenot as new Cocoon committer (was Re: Problem with CachingPointProcessingPipeline)
-Original Message- From: Andrew Savory [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 22. Dezember 2005 14:43 To: dev@cocoon.apache.org Subject: [vote] Jean-Baptiste Quenot as new Cocoon committer (was Re: Problem with CachingPointProcessingPipeline) Hi, On 20 Dec 2005, at 15:56, Jean-Baptiste Quenot wrote: See patch attached. WDYT? I think you should become a committer, so you can work on these things without patches :-) Everyone: Jean-Baptiste is becoming more and more active on the dev list, and has been diligently filing bugs and patches for the last few months. The first post about his activity is from July, 2004 [1]. He seems to have a good grasp of the guts of Cocoon. I think it's time for him to become a committer. [1] http://marc.theaimsgroup.com/?a=10893038224r=3w=2 Please cast your votes! Here's mine: +1 Thanks, Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/ This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: [vote] Jean-Baptiste Quenot as new Cocoon committer (was Re: Problem with CachingPointProcessingPipeline)
Please cast your votes! +1 Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
Re: [vote] Jean-Baptiste Quenot as new Cocoon committer (was Re: Problem with CachingPointProcessingPipeline)
On 22.12.2005 14:42, Andrew Savory wrote: I think you should become a committer, so you can work on these things without patches :-) +1 Jörg
Re: [vote] Jean-Baptiste Quenot as new Cocoon committer (was Re: Problem with CachingPointProcessingPipeline)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 22 Dec 2005, Andrew Savory wrote: Date: Thu, 22 Dec 2005 13:42:50 + From: Andrew Savory [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: [vote] Jean-Baptiste Quenot as new Cocoon committer (was Re: Problem with CachingPointProcessingPipeline) Hi, On 20 Dec 2005, at 15:56, Jean-Baptiste Quenot wrote: See patch attached. WDYT? I think you should become a committer, so you can work on these things without patches :-) Everyone: Jean-Baptiste is becoming more and more active on the dev list, and has been diligently filing bugs and patches for the last few months. The first post about his activity is from July, 2004 [1]. He seems to have a good grasp of the guts of Cocoon. I think it's time for him to become a committer. [1] http://marc.theaimsgroup.com/?a=10893038224r=3w=2 Please cast your votes! +1 - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDq6jELNdJvZjjVZARAsEGAJ93HAopFPkvr/Uk61duk7yolsmekgCfajcs Q71whHNGB5A8L50W6rL3V7E= =/u69 -END PGP SIGNATURE-
Re: JMX integration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 22 Dec 2005, Giacomo Pati wrote: So, big +1 for adding JMX support to 2.2 :) So long as the new dependency isn't one for the core, but can be contained in a block. No, this is why I'm seeking for suggestions. JMX support has to be implemented in the core (CoreComponentManager IIRC) and thus will introduce new dependencies. To be more precise. How do you see the core delegate the instantiation and registration of an MBean for i.e. PoolableComponentHandler to a separate (ev. classloader shielded) block without a dependency on it or on the JMX interfaces? - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDq6qYLNdJvZjjVZARAsJmAKDmfr1PwPq5ZcJGWQdzFf852txofQCg63wX l+lNbYS9bpc3z+e7XMX0DSM= =D9GF -END PGP SIGNATURE-
Re: Cocoon 2.1.7 hang
Ralph Goers wrote: We finally got some thread dumps from our production server. It shows something very different than what we were seeing in testing. First, this happens under light load after running for days. To summarize, many threads are waiting for the ResourceLimitingPool and several are waiting for the class loader. This system hasn't had the pools tuned so I'm not surprised about pool contention, but I don't believe that is the issue. That is because the thread holding the lock is simply waiting for the class loader. We took two traces and both were similar, but not identical. Different threads were holding the class loader lock in both. However, in both cases the threads holding the class loader lock were called from Castor while creating the portal layout. So far, we have been speculating that the problem is due to a problem with the NPTL threads on Enterprise Linux 3. However, I'm wondering if perhaps castor is having problems and simply calling the class loader over and over. I'd appreciate any ideas. Someone told me some months ago that they experienced several strange issues with castor under load - I think he mentioned class loading and synchronization problems. I still can't remember *who* it was :( So, chances are that this is really caused somehow by castor. I improved the the castor portal implementation for 2.1.8 slightly - the version in 2.1.7 parsed the mapping each time a profile is loaded. I guess that through this operation the classes are loaded as well. In 2.1.8 the mapping is only read once on startup. So my suggestion is to use the CastorSourceConverter from 2.1.8 in your 2.1.7 environment and see what happens. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
