[vote] Jeroen Reijn as a new Cocoon committer
Hi, I'd like to propose Jeroen Reijn as a Cocoon committer. Jeroen has been active on the lists since September 2006, and as well as a steady stream of bug reports and patches, he is busy answering questions on the users list and engaging in discussions on the dev list. He's been lively at recent GetTogethers, and he is also showing a willingness to contribute to the value of the community by talking at Apachecon Europe this year. Please cast your votes. 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/ Sourcesense: http://www.sourcesense.com/
Re: [vote] Jeroen Reijn as a new Cocoon committer
Andrew Savory said the following on 5/3/07 09:19: Hi, I'd like to propose Jeroen Reijn as a Cocoon committer. +1 Bye, Helma
Re: Reloading Classloader Plugin
Giacomo Pati wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reinhard Poetz wrote:
Giacomo Pati wrote:
How is the rcl-plugin related/overlapping with the deployer-plugin?
I've put some work making the deployer-plugin usable for block
development and now I'm asking
whether that work is becoming obsolete and I should migrate ev.
missing features into the rcl-plugin
I've started from scratch because the deployer-plugin contains some (a
lot of?) unused stuff and I want to clean up when we merge them.
What features of the deployer-plugin do you use?
applying xpatches
the ability to configure a custom log4j.xml
and probably others I cannot remember now.
and the optional use of the shielding classloader should complete the list.
- o -
The reloading classloader stuff becomes useful if you want to run a block, the
deployer if you want to create a web application. I propose that we start from
the reloading classloader stuff and merge the missing functionality from the
deployer modules into it.
The perfekt solution would even go one step further and abstract the deployer
from Maven so that somebody could write an Ant task. I'm not sure if I will have
time for this extra round.
As already said, I plan to have a first milestone release by the end of March,
provided that commons-jci will be propertly relased by then.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [vote] Jeroen Reijn as a new Cocoon committer
Andrew Savory wrote:
Hi,
I'd like to propose Jeroen Reijn as a Cocoon committer.
Jeroen has been active on the lists since September 2006, and as well as
a steady stream of bug reports and patches, he is busy answering
questions on the users list and engaging in discussions on the dev list.
He's been lively at recent GetTogethers, and he is also showing a
willingness to contribute to the value of the community by talking at
Apachecon Europe this year.
Please cast your votes.
+1
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: [vote] Jeroen Reijn as a new Cocoon committer
On 3/5/07, Andrew Savory [EMAIL PROTECTED] wrote: ...I'd like to propose Jeroen Reijn as a Cocoon committer... +1 -Bertrand
RunningModeDependentPipeline (was:RE: New stuff for Cocoon)
Hello, http://www.mindquarry.org/repos/mindquarry-jcr/trunk/mindquarr y-jcr-source/ I'd say add it to the cocoon-jcr block but maybe one of the original authors of the jcr block can give some comments. And various components: - RunningModeDependentPipeline: (Pipeline) to automatically use different pipelines depending on the running mode, eg. no caching in dev, full caching in prod, and optionally enabling profiling with a single system property (I know this is possible by putting two different xconf/spring bean files under dev/ or prod/, but this code is quite young in cocoon, so we don't have it available in our cocoon version) http://www.mindquarry.org/repos/mindquarry-webapp/trunk/mindqu arry-webapp-resources/src/main/java/com/mindquarry/webapp/pipelines/RunningModeDependentPipeline.java hey, I was thinking about something similar just some time ago. I guess this needs further discussions on this list. IMHO, I really do not like people developing in another mode regarding caching and switch to another caching strategy on production (regarding profiling, ok). I have been trying to persuade everybody to *not* develop against uncaching pipelines, and switch to caching when the project needs to go live. Inefficiencies regarding implementations won't be noticed, untill the project needs to go live, and you end up hacking around to get some performance. I have seen to many projects end up like big slow hacky (hacky to get it performing in the end) projects, which never perform the way they should. By far the best projects around, are the ones that kept performance and caching in mind from the very start, and monitored response times during development against a production mode implementation. OTH, why would you ever want a pipeline to be noncaching in development mode and caching in production? If you do everything right, changes in code would also directly work in caching pipelines. Certainly when you use eventcache, it is important to develop in evencaching pipelines, otherwise, you might end up with a production version in which some parts do not invalidate. Finding out the problems later on are much harder. So a -1 for me because it would make me having to persuade everybody around me even more, to not develop against a caching strategy that is different in production. Ard
Re: [vote] Jeroen Reijn as a new Cocoon committer
Hi, On 5 Mar 2007, at 08:19, Andrew Savory wrote: Please cast your votes. My +1, of course ;-) 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/ Sourcesense: http://www.sourcesense.com/
Re: [vote] Jeroen Reijn as a new Cocoon committer
Andrew Savory wrote: Hi, I'd like to propose Jeroen Reijn as a Cocoon committer. +1 Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Reloading Classloader Plugin
On 05.03.2007, at 07:31, Reinhard Poetz wrote: Torsten Curdt wrote: On 04.03.2007, at 18:40, Reinhard Poetz wrote: Torsten Curdt wrote: On 04.03.2007, at 17:59, Reinhard Poetz wrote: Grzegorz Kossakowski wrote: Reinhard Poetz napisał(a): Just a warning, AFAICS it's not a drop-in replacement because of some API changes. Thanks for fixing this. Unfortunately, nothing changed after replacing jci with the current trunk. Still class reloading does not work while running outside the Eclipse and still there is problem with Scheme change not implemented. I hope that Torsten will find some time to help us as soon as jci got released. Sure will try ...actually adopting to the API changes would be good to do before the release of jci. already done Seriously? That would be awesome! :) It wasn't that difficult because the API became cleaner and much easier to understand :-) Cool :) cheers -- Torsten
Re: [vote] Jeroen Reijn as a new Cocoon committer
On 3/5/07, Andrew Savory [EMAIL PROTECTED] wrote: Hi, I'd like to propose Jeroen Reijn as a Cocoon committer. +1 -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: SVN Source for Cocoon
Hi Reinhard, - SVN source: a source that reads a local subversion repository and provides the content, supports revisions etc. (read-only) http://www.mindquarry.org/repos/mindquarry-workspace/trunk/ mindquarry-dma-source/ how to you access SVN? Are you using a ASL-compatible base library? (http://people.apache.org/~cliffs/3party.html) We access SVN through the means of a Spring Bean. This Bean acts either as a wrapper to Subversion's native JavaHL API, which unfortunately requires native code or to SVNKit, which is not ASL- compatible. So while I see not much chances of integrating this into Cocoon, it sill might be interesting for projects using coocoon. -- Lars Trieloff visit http://www.mindquarry.com/
Re: [vote] Jeroen Reijn as a new Cocoon committer
Andrew Savory skrev: I'd like to propose Jeroen Reijn as a Cocoon committer. +1 /Daniel
Re: [vote] Jeroen Reijn as a new Cocoon committer
Andrew Savory wrote: Hi, I'd like to propose Jeroen Reijn as a Cocoon committer. Jeroen has been active on the lists since September 2006, and as well as a steady stream of bug reports and patches, he is busy answering questions on the users list and engaging in discussions on the dev list. He's been lively at recent GetTogethers, and he is also showing a willingness to contribute to the value of the community by talking at Apachecon Europe this year. Please cast your votes. +1 Carsten -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/
Re: [vote] Jeroen Reijn as a new Cocoon committer
Andrew Savory wrote: Hi, I'd like to propose Jeroen Reijn as a Cocoon committer. Definitely +1! Bye, max
Configuration of RunnableManager
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I wonder how to create/add my own configuration for the RunnableManager. At the moment, the given configuration is included in the deployed jar file (having configured 2 pools (default,daemon)). Changing this configuration seems not that easy as I need to 'patch' the existing configuration in the deployed jar file. Making configuration easier I'd prefer the the 'New Features for the spring configurator' and introduce a new bean just containing the configuration data for a pool which implementing a specific (helper) interface. Thus everybody can add his own threadpool configuration. The RunnableManager then will create thread pools for all found beans implementing this (helper) interface. Configuration could then look as following: bean name=org.apache.cocoon.components.thread.RunnableManager class=org.apache.cocoon.components.thread.DefaultRunnableManager scope=singleton init-method=init destroy-method=destroy property name=threadFactory value=org.apache.cocoon.components.thread.DefaultThreadFactory/ property name=threadPools configurator:bean-map type=org.apache.cocoon.components.thread.ThreadPoolConfig / /property /bean bean id=org.apache.cocoon.components.thread.ThreadPoolConfig/default class=org.apache.cocoon.components.thread.ThreadPoolConfigImpl property name=name value=default/ property name=priority value=NORM/ property name=daemon value=false/ property name=queue-size value=-1/ property name=max-pool-size value=5/ property name=min-pool-size value=5/ property name=keep-alive-time-ms value=6/ property name=block-policy value=ABORT/ property name=shutdown-graceful value=false/ property name=shutdown-wait-time-ms value=-1/ /bean bean id=org.apache.cocoon.components.thread.ThreadPoolConfig/daemon class=org.apache.cocoon.components.thread.ThreadPoolConfigImpl snip / /bean bean id=org.apache.cocoon.components.thread.ThreadPoolConfig/MyPool class=org.apache.cocoon.components.thread.ThreadPoolConfigImpl snip / /bean I will write a patch if I'm not the only one having this problem and I get a positive feedback on this. Regards Felix -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF7A3B2lZVCB08qHERAqy6AJwOENR7A+FhZWIEok1APe+hOk6oMgCfbsi9 tZT41dnSlTyv3P+4QN3C10Q= =Q/E6 -END PGP SIGNATURE-
Re: Sending CLA
Grzegorz Kossakowski wrote: Grzegorz Kossakowski napisał(a): Hello, I'm trying to figure out how to send CLA electronically as Vadim mentioned earlier[1]. I've tried to seek for instructions explaining in detail requirements and procedure but with no luck. I would like to kindly ask you for some information about. Especially: 1. Is e-mail signed by Thawte digital signature is sufficient? 2. What is expected resolution of scanned documents? If nobody comes with solution I'll try to find some fax machine. Ok, I was not patient enough and found fax machine. It wonders me how long I'll have to wait now... Your CLA has been recorded. Next step - nominator should fire an email to create your account. Vadim
Re: Sending CLA
Vadim Gritsenko skrev: Grzegorz Kossakowski wrote: Grzegorz Kossakowski napisał(a): Hello, I'm trying to figure out how to send CLA electronically as Vadim mentioned earlier[1]. I've tried to seek for instructions explaining in detail requirements and procedure but with no luck. I would like to kindly ask you for some information about. Especially: 1. Is e-mail signed by Thawte digital signature is sufficient? 2. What is expected resolution of scanned documents? If nobody comes with solution I'll try to find some fax machine. Ok, I was not patient enough and found fax machine. It wonders me how long I'll have to wait now... Your CLA has been recorded. Next step - nominator should fire an email to create your account. Yes, I'll do that as soon as Grzegorz gives his preferred user id and forward email address. /Daniel
Re: [vote] Jeroen Reijn as a new Cocoon committer
Andrew Savory wrote: Please cast your votes. +1
Strange behaviour during test phase
While trying to build trunk with the allblocks profile I came across something strange. When invoked from the top level directory, the unit tests in the repository-impl block fail while an invocation of mvn in the cocoon-repository directory runs the tests without any problems. Any clue? Carsten -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/
Re: [vote] Jeroen Reijn as a new Cocoon committer
Andrew Savory wrote: Hi, I'd like to propose Jeroen Reijn as a Cocoon committer. Please cast your votes. +1 Vadim
Re: [vote] Jeroen Reijn as a new Cocoon committer
Andrew Savory wrote: I'd like to propose Jeroen Reijn as a Cocoon committer. Please cast your votes. +1
Re: Sending CLA
Daniel Fagerstrom napisał(a): Yes, I'll do that as soon as Grzegorz gives his preferred user id and forward email address. I'm sorry, I missed your request for this information. Sending it now on priv. -- Grzegorz Kossakowski
Re: Strange behaviour during test phase
Carsten Ziegeler wrote:
While trying to build trunk with the allblocks profile I came across
something strange. When invoked from the top level directory, the unit
tests in the repository-impl block fail while an invocation of mvn in
the cocoon-repository directory runs the tests without any problems.
Any clue?
Are there any tests that load resources from the filesystem? If yes that could
be the cause for this behaviour because the $basedir variable always resolves to
the JVM working directory.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [vote] Jeroen Reijn as a new Cocoon committer
On 3/5/07, Andrew Savory [EMAIL PROTECTED] wrote: Hi, I'd like to propose Jeroen Reijn as a Cocoon committer. +1 -- Peter Hunsberger
Re: [vote] Jeroen Reijn as a new Cocoon committer
Andrew Savory wrote: Hi, I'd like to propose Jeroen Reijn as a Cocoon committer. Jeroen has been active on the lists since September 2006, and as well as a steady stream of bug reports and patches, he is busy answering questions on the users list and engaging in discussions on the dev list. He's been lively at recent GetTogethers, and he is also showing a willingness to contribute to the value of the community by talking at Apachecon Europe this year. Please cast your votes. +1, welcome! -- Leszek Gawron http://www.mobilebox.pl/krs.html CTO at MobileBox Ltd.
RE: [vote] Jeroen Reijn as a new Cocoon committer
Please cast your votes. my unbiased +1!! Ard 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/ Sourcesense: http://www.sourcesense.com/
Re: Configuration of RunnableManager
Felix Knecht wrote: I wonder how to create/add my own configuration for the RunnableManager. At the moment, the given configuration is included in the deployed jar file (having configured 2 pools (default,daemon)). Changing this configuration seems not that easy as I need to 'patch' the existing configuration in the deployed jar file. Making configuration easier I'd prefer the the 'New Features for the spring configurator' and introduce a new bean just containing the configuration data for a pool which implementing a specific (helper) interface. Thus everybody can add his own threadpool configuration. The RunnableManager then will create thread pools for all found beans implementing this (helper) interface. Configuration could then look as following: bean name=org.apache.cocoon.components.thread.RunnableManager class=org.apache.cocoon.components.thread.DefaultRunnableManager scope=singleton init-method=init destroy-method=destroy property name=threadFactory value=org.apache.cocoon.components.thread.DefaultThreadFactory/ property name=threadPools configurator:bean-map type=org.apache.cocoon.components.thread.ThreadPoolConfig / /property /bean bean id=org.apache.cocoon.components.thread.ThreadPoolConfig/default class=org.apache.cocoon.components.thread.ThreadPoolConfigImpl property name=name value=default/ property name=priority value=NORM/ property name=daemon value=false/ property name=queue-size value=-1/ property name=max-pool-size value=5/ property name=min-pool-size value=5/ property name=keep-alive-time-ms value=6/ property name=block-policy value=ABORT/ property name=shutdown-graceful value=false/ property name=shutdown-wait-time-ms value=-1/ /bean bean id=org.apache.cocoon.components.thread.ThreadPoolConfig/daemon class=org.apache.cocoon.components.thread.ThreadPoolConfigImpl snip / /bean bean id=org.apache.cocoon.components.thread.ThreadPoolConfig/MyPool class=org.apache.cocoon.components.thread.ThreadPoolConfigImpl snip / /bean I will write a patch if I'm not the only one having this problem and I get a positive feedback on this. This looks like a sensible approach to me. +1 Vadim
Re: Configuration of RunnableManager
Thanks Vadim, I'll go on with this. IIRC the interfaces of the core block are stable(freezed) because of RC1. Therefor I'm going to introduce a new RunnableManager called ConfigurableRunnableManager which is heavy based on the DefaultRunnableManager (otherwise I'd need to change the bean configuration/interface of the DefaultRunnableManager). Felix Felix Knecht wrote: I wonder how to create/add my own configuration for the RunnableManager. At the moment, the given configuration is included in the deployed jar file (having configured 2 pools (default,daemon)). Changing this configuration seems not that easy as I need to 'patch' the existing configuration in the deployed jar file. Making configuration easier I'd prefer the the 'New Features for the spring configurator' and introduce a new bean just containing the configuration data for a pool which implementing a specific (helper) interface. Thus everybody can add his own threadpool configuration. The RunnableManager then will create thread pools for all found beans implementing this (helper) interface. Configuration could then look as following: bean name=org.apache.cocoon.components.thread.RunnableManager class=org.apache.cocoon.components.thread.DefaultRunnableManager scope=singleton init-method=init destroy-method=destroy property name=threadFactory value=org.apache.cocoon.components.thread.DefaultThreadFactory/ property name=threadPools configurator:bean-map type=org.apache.cocoon.components.thread.ThreadPoolConfig / /property /bean bean id=org.apache.cocoon.components.thread.ThreadPoolConfig/default class=org.apache.cocoon.components.thread.ThreadPoolConfigImpl property name=name value=default/ property name=priority value=NORM/ property name=daemon value=false/ property name=queue-size value=-1/ property name=max-pool-size value=5/ property name=min-pool-size value=5/ property name=keep-alive-time-ms value=6/ property name=block-policy value=ABORT/ property name=shutdown-graceful value=false/ property name=shutdown-wait-time-ms value=-1/ /bean bean id=org.apache.cocoon.components.thread.ThreadPoolConfig/daemon class=org.apache.cocoon.components.thread.ThreadPoolConfigImpl snip / /bean bean id=org.apache.cocoon.components.thread.ThreadPoolConfig/MyPool class=org.apache.cocoon.components.thread.ThreadPoolConfigImpl snip / /bean I will write a patch if I'm not the only one having this problem and I get a positive feedback on this. This looks like a sensible approach to me. +1 Vadim
Re: [vote] Jeroen Reijn as a new Cocoon committer
On 05.03.2007 09:19, Andrew Savory wrote: I'd like to propose Jeroen Reijn as a Cocoon committer. +1, welcome. Jörg
Re: [vote] Jeroen Reijn as a new Cocoon committer
Andrew Savory wrote: Hi, I'd like to propose Jeroen Reijn as a Cocoon committer. +1 Jorg
[vote] Felix Knecht as a new Cocoon committer
Felix Knecht wrote: I will write a patch ... I think that Felix shouldn't write patches any longer but commit them himself. I want to propose Felix as a committer. Felix has been part of this community for more than 6! years. Recently he has provided about 10 patches which prove that he has a good unerstanding of how Cocoon works. And, as I was told, he was the initial author of the LDAPTransformer. Please cast your votes! -- Reinhard ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [vote] Felix Knecht as a new Cocoon committer
Reinhard Poetz wrote: Felix Knecht wrote: I will write a patch ... I think that Felix shouldn't write patches any longer but commit them himself. I want to propose Felix as a committer. Felix has been part of this community for more than 6! years. Recently he has provided about 10 patches which prove that he has a good unerstanding of how Cocoon works. And, as I was told, he was the initial author of the LDAPTransformer. Please cast your votes! +1 -- Reinhard
Re: Configuration of RunnableManager
Felix Knecht wrote:
Thanks Vadim, I'll go on with this.
IIRC the interfaces of the core block are stable(freezed) because of
RC1.
No, they will be freezed *after* RC1 was released. (At least that's my
understanding.)
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [vote] Jeroen Reijn as a new Cocoon committer
Andrew Savory escribió: Hi, I'd like to propose Jeroen Reijn as a Cocoon committer. +1 Best Regards, Antonio Gallardo
Re: [vote] Felix Knecht as a new Cocoon committer
On 3/5/07, Reinhard Poetz [EMAIL PROTECTED] wrote: ...I think that Felix shouldn't write patches any longer but commit them himself. I want to propose Felix as a committer... Enthusiastic +1 ! -Bertrand
Re: [vote] Jeroen Reijn as a new Cocoon committer
Andrew Savory napisał(a): Hi, I'd like to propose Jeroen Reijn as a Cocoon committer. Jeroen has been active on the lists since September 2006, and as well as a steady stream of bug reports and patches, he is busy answering questions on the users list and engaging in discussions on the dev list. He's been lively at recent GetTogethers, and he is also showing a willingness to contribute to the value of the community by talking at Apachecon Europe this year. Please cast your votes. +100 (100 factor for the activity on users list) -- Grzegorz Kossakowski
Re: [vote] Felix Knecht as a new Cocoon committer
Reinhard Poetz napisał(a): Felix Knecht wrote: I will write a patch ... I think that Felix shouldn't write patches any longer but commit them himself. I want to propose Felix as a committer. Felix has been part of this community for more than 6! years. Recently he has provided about 10 patches which prove that he has a good unerstanding of how Cocoon works. And, as I was told, he was the initial author of the LDAPTransformer. Please cast your votes! without any hesitation, +1 and welcome! -- Grzegorz Kossakowski
Re: Configuration of RunnableManager
Reinhard Poetz schrieb: Felix Knecht wrote: Thanks Vadim, I'll go on with this. IIRC the interfaces of the core block are stable(freezed) because of RC1. No, they will be freezed *after* RC1 was released. (At least that's my understanding.) If the API isn't freezed yet I suggest to change it. Felix
Re: [vote] Felix Knecht as a new Cocoon committer
On 3/5/07, Reinhard Poetz [EMAIL PROTECTED] wrote: I think that Felix shouldn't write patches any longer but commit them himself. I want to propose Felix as a committer. +1 -- Peter Hunsberger
Re: [vote] Felix Knecht as a new Cocoon committer
On 05.03.2007 20:38, Reinhard Poetz wrote: I want to propose Felix as a committer. +1 and welcome. Jörg
RE: [vote] Felix Knecht as a new Cocoon committer
Please cast your votes! +1! Ard -- Reinhard ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
[jira] Created: (COCOON-2019) Make DefaultRunnableManager custom configurable
Make DefaultRunnableManager custom configurable --- Key: COCOON-2019 URL: https://issues.apache.org/jira/browse/COCOON-2019 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Fix For: 2.2-dev (Current SVN) Attachments: DefaultRunnableManager.diff Introduce data beans for configuration of the DefaultRunnableManager. This will give the chance to add customized configurations without the need of patch the configuration deployed with the jar file. The new way of configuration uses a bean-map to get the configurations - Every bean implementing the interface ''org.apache.cocoon.components.thread.ThreadPoolConfiguration will be taken as single thread-pool configuration. The two (already existing) configurations default, daemon will still be deployed with the jar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2019) Make DefaultRunnableManager custom configurable
[ https://issues.apache.org/jira/browse/COCOON-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated COCOON-2019: - Attachment: DefaultRunnableManager.diff The patch Make DefaultRunnableManager custom configurable --- Key: COCOON-2019 URL: https://issues.apache.org/jira/browse/COCOON-2019 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Fix For: 2.2-dev (Current SVN) Attachments: DefaultRunnableManager.diff Introduce data beans for configuration of the DefaultRunnableManager. This will give the chance to add customized configurations without the need of patch the configuration deployed with the jar file. The new way of configuration uses a bean-map to get the configurations - Every bean implementing the interface ''org.apache.cocoon.components.thread.ThreadPoolConfiguration will be taken as single thread-pool configuration. The two (already existing) configurations default, daemon will still be deployed with the jar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [vote] Felix Knecht as a new Cocoon committer
Hi, On 5 Mar 2007, at 19:38, Reinhard Poetz wrote: Please cast your votes! A huge +1. Welcome aboard, Felix! 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/ Sourcesense: http://www.sourcesense.com/
Re: [vote] Jeroen Reijn as a new Cocoon committer
Andrew Savory wrote: Please cast your votes. +1 -David
Re: [vote] Felix Knecht as a new Cocoon committer
Reinhard Poetz wrote: Please cast your votes! +1 -David
Re: [vote] Jeroen Reijn as a new Cocoon committer
Andrew Savory andrew at luminas.co.uk writes: I'd like to propose Jeroen Reijn as a Cocoon committer. Jeroen has been active on the lists since September 2006 Wondering about this short time I had a look into the archives. And so, just for the records: Jeroen has been active quite regularly since November 2003: http://marc.theaimsgroup.com/?a=10686344733r=1w=4 (Nov 2003 - Apr 2004) http://marc.theaimsgroup.com/?a=10820541843r=3w=4 (Apr 2004, Aug 2004 - Mar 2007) http://marc.theaimsgroup.com/?a=10949040572r=5w=4 (Sep 2004, Sep 2005 - Mar 2007) Jörg
Re: [vote] Felix Knecht as a new Cocoon committer
Reinhard Poetz escribió: Felix Knecht wrote: I will write a patch ... I want to propose Felix as a committer. +1 Best Regards, Antonio Gallardo
Re: [vote] Felix Knecht as a new Cocoon committer
Reinhard Poetz wrote: Felix Knecht wrote: I will write a patch ... I think that Felix shouldn't write patches any longer but commit them himself. I want to propose Felix as a committer. Felix has been part of this community for more than 6! years. Recently he has provided about 10 patches which prove that he has a good unerstanding of how Cocoon works. And, as I was told, he was the initial author of the LDAPTransformer. Please cast your votes! +1
Re: [vote] Jeroen Reijn as a new Cocoon committer
On Monday 05 March 2007 16:19, Andrew Savory wrote: I'd like to propose Jeroen Reijn as a Cocoon committer. +1. Welcome! Cheers Niclas
Re: [vote] Felix Knecht as a new Cocoon committer
On Tuesday 06 March 2007 03:38, Reinhard Poetz wrote: +1 Welcome Cheers Niclas
Re: SVN Source for Cocoon
On Monday 05 March 2007 17:49, Lars Trieloff wrote: Hi Reinhard, - SVN source: a source that reads a local subversion repository and provides the content, supports revisions etc. (read-only) http://www.mindquarry.org/repos/mindquarry-workspace/trunk/ mindquarry-dma-source/ how to you access SVN? Are you using a ASL-compatible base library? (http://people.apache.org/~cliffs/3party.html) We access SVN through the means of a Spring Bean. This Bean acts either as a wrapper to Subversion's native JavaHL API, which unfortunately requires native code or to SVNKit, which is not ASL- compatible. So while I see not much chances of integrating this into Cocoon, it sill might be interesting for projects using coocoon. How does Maven2 access SVN remote repositories?? Doesn't whatever they use be able to help out in this case? Cheers Niclas
Re: [vote] Felix Knecht as a new Cocoon committer
Reinhard Poetz wrote: Felix Knecht wrote: I will write a patch ... I think that Felix shouldn't write patches any longer but commit them himself. I want to propose Felix as a committer. Felix has been part of this community for more than 6! years. Recently he has provided about 10 patches which prove that he has a good unerstanding of how Cocoon works. And, as I was told, he was the initial author of the LDAPTransformer. Please cast your votes! +1 Ralph
cocoon.processPipelineTo()
Hi, I seem to remember from a long time ago, some mention of something that could be used in place of processPipelineTo(). Something that might have been better, or... not sure. Anyway, does this ring any bells? I can't seem to find the reference now... best regards, —ml—
Re: Configuration of RunnableManager
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Felix Felix Knecht wrote: I wonder how to create/add my own configuration for the RunnableManager. At the moment, the given configuration is included in the deployed jar file (having configured 2 pools (default,daemon)). Changing this configuration seems not that easy as I need to 'patch' the existing configuration in the deployed jar file. Making configuration easier I'd prefer the the 'New Features for the spring configurator' and introduce a new bean just containing the configuration data for a pool which implementing a specific (helper) interface. Thus everybody can add his own threadpool configuration. The RunnableManager then will create thread pools for all found beans implementing this (helper) interface. I'd suggest instead of only breaking out the configuration of a thread pool, break out the hole thread pool itself into a bean. This would reduce the complexity of the RunnableManager and would make the ThreadPool beans have a little more responsability than just holding config values. WDYT? Ciao configurator:bean-map type=org.apache.cocoon.components.thread.ThreadPoolConfig / /property /bean bean id=org.apache.cocoon.components.thread.ThreadPoolConfig/default class=org.apache.cocoon.components.thread.ThreadPoolConfigImpl property name=name value=default/ property name=priority value=NORM/ property name=daemon value=false/ property name=queue-size value=-1/ property name=max-pool-size value=5/ property name=min-pool-size value=5/ property name=keep-alive-time-ms value=6/ property name=block-policy value=ABORT/ property name=shutdown-graceful value=false/ property name=shutdown-wait-time-ms value=-1/ /bean bean id=org.apache.cocoon.components.thread.ThreadPoolConfig/daemon class=org.apache.cocoon.components.thread.ThreadPoolConfigImpl snip / /bean bean id=org.apache.cocoon.components.thread.ThreadPoolConfig/MyPool class=org.apache.cocoon.components.thread.ThreadPoolConfigImpl snip / /bean I will write a patch if I'm not the only one having this problem and I get a positive feedback on this. Regards Felix - -- Otego AG Tel: +41 (0)1 240 00 55 Giacomo Pati, CTO Mobile:+41 (0)79 262 21 04 Apache Software Foundation Member Mailto:[EMAIL PROTECTED] Hohlstrasse 216 Mailto:[EMAIL PROTECTED] CH-8004 Zuerich http://www.otego.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.2 (GNU/Linux) iD8DBQFF7RPpLNdJvZjjVZARAmaxAKCu16RwJP9CiPDZ3NzH1a7buxiBpwCcCOmT 1uWov1o/rgnNy8f6guqeKss= =1ozv -END PGP SIGNATURE-
