RE: Make status code attribute of seriailzers expandable
Hello, > > Don't you have two distinct pipelines for rendering pages with forms > included and without? I don't details of your use case but IMO it is > good practice to have two distinct pipelines and decide in flow which > one should be used. we rely on repository sources where the customer (the cms user) defines wether or not a form is on the page, so, no...we cannot know in our main pipeline what the headers should be > Nevertheless, if you know in flow how headers should be set, why don't > set them there? Then they only are set on the pipeline calling this flow, and according [1] these are lost in the main pipeline Ard [1] https://issues.apache.org/jira/browse/COCOON-1619 > > -- > Grzegorz Kossakowski > http://reflectingonthevicissitudes.wordpress.com/ > >
RE: Make status code attribute of seriailzers expandable
>
> I'm sorry, but I can't spot a difference between these two options:
>
> cache-control="{cache}"/>
>
> and:
>
>
>
>
>
>
>
> In both cases, sitemap parameter expansion will happen while
> sitemap is executed
> and pipeline is built. In first case you'd presumable set
> response headers in
> Serializer.setOutputStream() method, which is happening a bit
> later comparing
> with Action.act() of the second case, but still it should be
> the same effect,
> isn't it?
In this example, there is really no difference in output indeed, but if you
have one catch all matcher with one single serializer which is always used for
every request (I always use https://issues.apache.org/jira/browse/COCOON-1619
Ard
>
> Vadim
>
[jira] Closed: (COCOON-2022) broken URI handling in ZipSource
[
https://issues.apache.org/jira/browse/COCOON-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jörg Heinicke closed COCOON-2022.
-
Resolution: Fixed
next try ...
> broken URI handling in ZipSource
>
>
> Key: COCOON-2022
> URL: https://issues.apache.org/jira/browse/COCOON-2022
> Project: Cocoon
> Issue Type: Bug
> Components: * Cocoon Core
>Affects Versions: 2.1.10
>Reporter: Jörg Heinicke
> Assigned To: Jörg Heinicke
>Priority: Minor
> Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN)
>
>
> On behalf of Leonid Geller:
> http://marc.theaimsgroup.com/?t=11733727554&r=1&w=4:
> 1. Bug in org.apache.cocoon.components.source.impl.ZipSourceFactory, on this
> line:
> // Get protocol. Protocol is configurable via cocoon.xconf
> final String protocol = location.substring(0, protocolEnd - 1);
> Obviously it should be location.substring(0, protocolEnd). This is what
> causes zip to be truncated to "zi".
> 2. When using a SYSTEM identifier with relative DTD path, the XML parser will
> look for the file relative to the URI of the zipped source,
> zip:archive.zip!/source.xml which is obviously going to fail.
> Here, the solution is to have the source implementation class (in this case
> org.apache.cocoon.components.source.impl.ZipSource) to change getURI method
> to return source.xml based on archive.zip location, w/o the zip protocol.
> Current implementation:
> return this.protocol + this.archive.getURI() + "!/" + this.filePath;
> is not going to work. Something like this will:
> int iZipIdx = this.archive.getURI().lastIndexOf("/");
> if (iZipIdx < 0) iZipIdx = 0;
> return this.archive.getURI().substring(0,iZipIdx)+"/"+ this.filePath;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2034) Configure servlet prefix for link rewriting automatically
[ https://issues.apache.org/jira/browse/COCOON-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2034. Resolution: Fixed Daniel, thanks for reminder! :) I've implemented new input module and removed old crap. Tested and works like a charm! PS. I'm glad you are still bustling around Cocoon... :) > Configure servlet prefix for link rewriting automatically > - > > Key: COCOON-2034 > URL: https://issues.apache.org/jira/browse/COCOON-2034 > Project: Cocoon > Issue Type: Task > Components: - Servlet service framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Grzegorz Kossakowski > > Currently prefix at which Cocoon's servlet dispatcher is mounted is hardcoded > in > /cocoon-servlet-service-components/src/main/resources/META-INF/cocoon/avalon/cocoon-servlet-complete-path-resolver.xconf > file. We should find some way setting it automatically. > Do you know any way how to get value from in web.xml? Or maybe > any other clever idea how to resolve this? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r522901 - in /cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-impl/src/main: java/org/apache/cocoon/caching/impl/CacheImpl.java resources/META-INF/cocoon/spring/cocoon-pipeline-impl-
Carsten Ziegeler wrote: Vadim Gritsenko wrote: Last I checked, and since 2.2, it is impossible (or just really hard?) to start up cocoon without servlet context and related objects, which means it gotta be deployed and started as part of the webapp. If that is the case, IMHO there is no good reason to have it as part of the shared classloader. Yes, that's true for "the framework Cocoon" - but perhaps not for the various parts/components. Ok, that's good reason. As most of our components are singletons anyway, there isn't any memory problem here. There are some generated poolable wrappers, IIRC - those aren't singletons and do represent good chunk of components (pipelines and all direct sitemap components). Yes, sooner or later we hopefully get rid of these, too :) Until then those wrapper could use static logger (if they need any), for efficiency :) Vadim
Re: Make status code attribute of seriailzers expandable
Ard Schrijvers wrote:
Ard Schrijvers wrote:
I missed the discussion before the vote, but have one more question:
Is it also possible to add extra optional http headers in
the serializer, like:
cache-control="{cache}">
I would like to store in a variable wether I am dealing
with something that is not allowed to be cached by mod_cache,
like a cforms with continuation. We had a discussion before
on this list, but cannot find the thread ATM
I do not know about the serializers, but is this possible
and/or desirable?
Please see HttpHeaderAction, can set any response header you want
I know. But, it does not work when you set the response header in a subpipeline,
so you *have* to do this in the pipeline which contains the serializer,
but quite normally, I have one main catch all matcher with the xhtml serialzer.
I'm sorry, but I can't spot a difference between these two options:
and:
In both cases, sitemap parameter expansion will happen while sitemap is executed
and pipeline is built. In first case you'd presumable set response headers in
Serializer.setOutputStream() method, which is happening a bit later comparing
with Action.act() of the second case, but still it should be the same effect,
isn't it?
Vadim
Re: svn commit: r522901 - in /cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-impl/src/main: java/org/apache/cocoon/caching/impl/CacheImpl.java resources/META-INF/cocoon/spring/cocoon-pipeline-impl-
Vadim Gritsenko wrote: > > Last I checked, and since 2.2, it is impossible (or just really hard?) to > start > up cocoon without servlet context and related objects, which means it gotta > be > deployed and started as part of the webapp. If that is the case, IMHO there > is > no good reason to have it as part of the shared classloader. > Yes, that's true for "the framework Cocoon" - but perhaps not for the various parts/components. >> As most of our components are singletons anyway, there isn't any memory >> problem here. > > There are some generated poolable wrappers, IIRC - those aren't singletons > and > do represent good chunk of components (pipelines and all direct sitemap > components). > Yes, sooner or later we hopefully get rid of these, too :) Carsten -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/
[jira] Commented: (COCOON-2034) Configure servlet prefix for link rewriting automatically
[ https://issues.apache.org/jira/browse/COCOON-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485261 ] Daniel Fagerstrom commented on COCOON-2034: --- I have a "clever" idea about how to solve it ;) We discussed the problem in http://marc.info/?l=xml-cocoon-dev&m=117009688607351&w=2. And I implemented the solution as you can see in /cocoon-servlet-service/cocoon-servlet-service-impl/src/main/java/org/apache/cocoon/servletservice/DynamicProxyRequestHandler.java#invoke. You just use the context path module instead of the hard coded path and the it should work. This is because: contextPath = wrapped.getContextPath() + wrapped.getServletPath() which is the prefix of the servlet dispatcher. > Configure servlet prefix for link rewriting automatically > - > > Key: COCOON-2034 > URL: https://issues.apache.org/jira/browse/COCOON-2034 > Project: Cocoon > Issue Type: Task > Components: - Servlet service framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Grzegorz Kossakowski > > Currently prefix at which Cocoon's servlet dispatcher is mounted is hardcoded > in > /cocoon-servlet-service-components/src/main/resources/META-INF/cocoon/avalon/cocoon-servlet-complete-path-resolver.xconf > file. We should find some way setting it automatically. > Do you know any way how to get value from in web.xml? Or maybe > any other clever idea how to resolve this? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Make status code attribute of seriailzers expandable
On 3/29/07, Ard Schrijvers <[EMAIL PROTECTED]> wrote: >... Please see HttpHeaderAction, can set any response header you want I know. But, it does not work when you set the response header in a subpipeline, so you *have* to do this in the pipeline which contains the serializer... See also https://issues.apache.org/jira/browse/COCOON-1619, we discussed a possible solution a while ago. -Bertrand
[jira] Created: (COCOON-2034) Configure servlet prefix for link rewriting automatically
Configure servlet prefix for link rewriting automatically - Key: COCOON-2034 URL: https://issues.apache.org/jira/browse/COCOON-2034 Project: Cocoon Issue Type: Task Components: - Servlet service framework Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Currently prefix at which Cocoon's servlet dispatcher is mounted is hardcoded in /cocoon-servlet-service-components/src/main/resources/META-INF/cocoon/avalon/cocoon-servlet-complete-path-resolver.xconf file. We should find some way setting it automatically. Do you know any way how to get value from in web.xml? Or maybe any other clever idea how to resolve this? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Make status code attribute of seriailzers expandable
Ard Schrijvers napisał(a): > > I am not in favor of this. When you only create a form with a continuation > based on the contents of some xml file, you do not know which pipelines do, > and which do not contain a form. You do know in flow when you are creating a > form/continuation. Setting a variable at that point and be able to use it in > the serializer as an extra http header is IMO the only way > Don't you have two distinct pipelines for rendering pages with forms included and without? I don't details of your use case but IMO it is good practice to have two distinct pipelines and decide in flow which one should be used. Nevertheless, if you know in flow how headers should be set, why don't set them there? -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
RE: Make status code attribute of seriailzers expandable
> Ard Schrijvers napisał(a):
> > I missed the discussion before the vote, but have one more question:
> >
> > Is it also possible to add extra optional http headers in
> the serializer, like:
> >
> > cache-control="{cache}">
> >
> > I would like to store in a variable wether I am dealing
> with something that is not allowed to be cached by mod_cache,
> like a cforms with continuation. We had a discussion before
> on this list, but cannot find the thread ATM
> >
> I'm -1 for setting this in a serializer.
> > I do not know about the serializers, but is this possible
> and/or desirable?
> >
>
> I was going to propose the same but set on pipeline level. Then one
> would group pipelines sharing the same caching
> characteristics. We have
> already "expires" parameter for pipelines so I think it fits into
> current design.
I am not in favor of this. When you only create a form with a continuation
based on the contents of some xml file, you do not know which pipelines do, and
which do not contain a form. You do know in flow when you are creating a
form/continuation. Setting a variable at that point and be able to use it in
the serializer as an extra http header is IMO the only way
Ard
> As servlet sevice stuff demands high conformity with HTTP
> specification
> I'm all +1 on such addition.
>
> --
> Grzegorz Kossakowski
> http://reflectingonthevicissitudes.wordpress.com/
>
>
RE: Make status code attribute of seriailzers expandable
> Ard Schrijvers wrote:
> > I missed the discussion before the vote, but have one more question:
> >
> > Is it also possible to add extra optional http headers in
> the serializer, like:
> >
> > cache-control="{cache}">
> >
> > I would like to store in a variable wether I am dealing
> with something that is not allowed to be cached by mod_cache,
> like a cforms with continuation. We had a discussion before
> on this list, but cannot find the thread ATM
> >
> > I do not know about the serializers, but is this possible
> and/or desirable?
>
> Please see HttpHeaderAction, can set any response header you want
I know. But, it does not work when you set the response header in a
subpipeline, so you *have* to do this in the pipeline which contains the
serializer, but quite normally, I have one main catch all matcher with the
xhtml serialzer. In this catch all matcher, I do not know wether or not I will
have a form with continuation, and I only want to set the header no-cache when
there actually is a continuation for example. The problem is way more subtle
then just a HttpHeaderAction and currently there is not a really easy solution
for having continuation in forms behind mod_cache (let alone a balanced
environment, where the sticky sessions come in)
Ard
>
> Vadim
>
Re: Make status code attribute of seriailzers expandable
Ard Schrijvers wrote: I missed the discussion before the vote, but have one more question: Is it also possible to add extra optional http headers in the serializer, like: I would like to store in a variable wether I am dealing with something that is not allowed to be cached by mod_cache, like a cforms with continuation. We had a discussion before on this list, but cannot find the thread ATM I do not know about the serializers, but is this possible and/or desirable? Please see HttpHeaderAction, can set any response header you want Vadim
Re: Make status code attribute of seriailzers expandable
Ard Schrijvers napisał(a): > I missed the discussion before the vote, but have one more question: > > Is it also possible to add extra optional http headers in the serializer, > like: > > > > I would like to store in a variable wether I am dealing with something that > is not allowed to be cached by mod_cache, like a cforms with continuation. We > had a discussion before on this list, but cannot find the thread ATM > I'm -1 for setting this in a serializer. > I do not know about the serializers, but is this possible and/or desirable? > I was going to propose the same but set on pipeline level. Then one would group pipelines sharing the same caching characteristics. We have already "expires" parameter for pipelines so I think it fits into current design. As servlet sevice stuff demands high conformity with HTTP specification I'm all +1 on such addition. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Make status code attribute of seriailzers expandable
I missed the discussion before the vote, but have one more question:
Is it also possible to add extra optional http headers in the serializer, like:
I would like to store in a variable wether I am dealing with something that is
not allowed to be cached by mod_cache, like a cforms with continuation. We had
a discussion before on this list, but cannot find the thread ATM
I do not know about the serializers, but is this possible and/or desirable?
Ard
>
> Reinhard Poetz wrote:
> > Vadim Gritsenko wrote:
> >> Reinhard Poetz wrote:
> >>>
> >>> Is there a specific reason why this patch
> (http://issues.apache.org/jira/browse/COCOON-1354) has never
> been applied?
> >>
> >> Technically, other than rewriting the last chunk of the
> patch, it looks Ok.
> From procedure POV, I don't recall a VOTE on that. Previous
> decision on what
> can be expandable in the sitemap was VOTEd upon.
> >
> > I will start a vote on this then. Any opinions in the meantime?
>
> I don't see reason why not, even if not needed often.
>
> Vadim
>
> > My usecase is that I want to provide REST-style
> webservices with Cocoon and
> knowing which status code to set is part of the business logic.
>
>
>- o -
>
>
> I propose making the status code attribute of serializers
> expandable. This makes
> it easier to provide REST style services with Cocoon that
> make use of the
> different meanings of status codes.
>
> --
> Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
>
> {Software Engineering, Open Source, Web Applications, Apache Cocoon}
>
> web(log): http://www.poetz.cc
>
>
RE: [vote] Make status code attribute of seriailzers expandable
> Reinhard Poetz wrote: > > > > I propose making the status code attribute of serializers > expandable. > > This makes it easier to provide REST style services with Cocoon that > > make use of the different meanings of status codes. > > +1. Should have actually been there right from the start! big +1 because I have needed it quite some times before! > > Sylvain > > -- > Sylvain Wallez - http://bluxte.net > >
[jira] Reopened: (COCOON-2022) broken URI handling in ZipSource
[
https://issues.apache.org/jira/browse/COCOON-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Kossakowski reopened COCOON-2022:
--
Unfortunately the issues is still not resolved, but this time I guess that is
only string offset calculation mistake. I'm not 100% sure so I bring it here.
My report:
---
Test set: org.apache.cocoon.components.source.impl.ZipSourceTestCase
---
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec <<<
FAILURE!
testURIHandling(org.apache.cocoon.components.source.impl.ZipSourceTestCase)
Time elapsed: 0.014 sec <<< FAILURE!
junit.framework.ComparisonFailure: Uri is wrong.
expected: but
was:
at junit.framework.Assert.assertEquals(Assert.java:81)
at
org.apache.cocoon.components.source.impl.ZipSourceTestCase.testURIHandling(ZipSourceTestCase.java:37)
> broken URI handling in ZipSource
>
>
> Key: COCOON-2022
> URL: https://issues.apache.org/jira/browse/COCOON-2022
> Project: Cocoon
> Issue Type: Bug
> Components: * Cocoon Core
>Affects Versions: 2.1.10
>Reporter: Jörg Heinicke
> Assigned To: Jörg Heinicke
>Priority: Minor
> Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN)
>
>
> On behalf of Leonid Geller:
> http://marc.theaimsgroup.com/?t=11733727554&r=1&w=4:
> 1. Bug in org.apache.cocoon.components.source.impl.ZipSourceFactory, on this
> line:
> // Get protocol. Protocol is configurable via cocoon.xconf
> final String protocol = location.substring(0, protocolEnd - 1);
> Obviously it should be location.substring(0, protocolEnd). This is what
> causes zip to be truncated to "zi".
> 2. When using a SYSTEM identifier with relative DTD path, the XML parser will
> look for the file relative to the URI of the zipped source,
> zip:archive.zip!/source.xml which is obviously going to fail.
> Here, the solution is to have the source implementation class (in this case
> org.apache.cocoon.components.source.impl.ZipSource) to change getURI method
> to return source.xml based on archive.zip location, w/o the zip protocol.
> Current implementation:
> return this.protocol + this.archive.getURI() + "!/" + this.filePath;
> is not going to work. Something like this will:
> int iZipIdx = this.archive.getURI().lastIndexOf("/");
> if (iZipIdx < 0) iZipIdx = 0;
> return this.archive.getURI().substring(0,iZipIdx)+"/"+ this.filePath;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [release] Prepare RC1 from trunk (core + many blocks + achetypes + rcl-maven-plugin)
Jorg Heymans wrote:
Reinhard Poetz wrote:
- the cforms block still depends on a xreporter library which isn't
available at the central Maven repo. I'm -1 on shipping anything as RC
or final, that has a depenency on some artifact that is not
available at the central Maven repo.
what is blocking this? If its just that someone needs to put the jar
into maven2 jira for upload then i'll do it.
I remember having already answered to this mail ... anyway.
The limiting factor is that nobody has done it yet. It would be great if you
create the artifact and put it into the Apache snapshot repo. Then we have some
time to test it and if everything works fine, Marc will release it officially.
It's important that the release comes from the xreporter core developer team and
not from us.
Thanks Jorg for picking up this issue!
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: svn commit: r523580 - /cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-impl/src/main/java/org/apache/cocoon/caching/impl/CacheImpl.java
Felix Knecht wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vadim Gritsenko schrieb:
[EMAIL PROTECTED] wrote:
Make method getLogger() visible for extending
-private Log getLogger() { +protected Log getLogger() {
Felix,
As far as commons logging usage pattern goes, extending classes
should create own instances of the log, otherwise log will get
really confusing, with class name of one class and message from
another class.
I see. But in this case we also can avoid the private method
'getLogger()' and use the defined class logger directly without going
the long way round getLogger() ?
I think reason getLogger() was added simply to avoid many small changes to the
file.
Vadim
Re: svn commit: r523580 - /cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-impl/src/main/java/org/apache/cocoon/caching/impl/CacheImpl.java
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vadim Gritsenko schrieb:
> [EMAIL PROTECTED] wrote:
>> Make method getLogger() visible for extending
>
>> -private Log getLogger() { +protected Log getLogger() {
>
> Felix,
>
> As far as commons logging usage pattern goes, extending classes
> should create own instances of the log, otherwise log will get
> really confusing, with class name of one class and message from
> another class.
I see. But in this case we also can avoid the private method
'getLogger()' and use the defined class logger directly without going
the long way round getLogger() ?
Felix
>
> Vadim
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGC7Au2lZVCB08qHERAg7uAJ91PlNkdvStwzTN17pm2p9ztMk6twCgpjzl
vMFTmpE+iQXdhrreK/BZ4ZI=
=yy1O
-END PGP SIGNATURE-
Re: svn commit: r523580 - /cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-impl/src/main/java/org/apache/cocoon/caching/impl/CacheImpl.java
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
[EMAIL PROTECTED] wrote:
Make method getLogger() visible for extending
-private Log getLogger() {
+protected Log getLogger() {
Felix,
As far as commons logging usage pattern goes, extending classes should
create own instances of the log, otherwise log will get really
confusing, with class name of one class and message from another class.
if the getClass() method is used, then extending classes should be safe.
It's only problematic when static logging is used, then you're right,
that you would log into the category of the parent object.
Yep, thanks for correction, I was still assuming static logger :)
Vadim
RE: [vote] Move CachingSource to cocoon-core
> > several requests on the users list) I want to propose to move it to
> > cocoon-core.
>
+1
Ard
> --
> Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
>
> {Software Engineering, Open Source, Web Applications, Apache Cocoon}
>
> web(log): http://www.poetz.cc
>
>
Re: svn commit: r523580 - /cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-impl/src/main/java/org/apache/cocoon/caching/impl/CacheImpl.java
Vadim Gritsenko wrote:
[EMAIL PROTECTED] wrote:
Make method getLogger() visible for extending
-private Log getLogger() {
+protected Log getLogger() {
Felix,
As far as commons logging usage pattern goes, extending classes should
create own instances of the log, otherwise log will get really
confusing, with class name of one class and message from another class.
if the getClass() method is used, then extending classes should be safe. It's
only problematic when static logging is used, then you're right, that you would
log into the category of the parent object.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: svn commit: r523580 - /cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-impl/src/main/java/org/apache/cocoon/caching/impl/CacheImpl.java
[EMAIL PROTECTED] wrote:
Make method getLogger() visible for extending
-private Log getLogger() {
+protected Log getLogger() {
Felix,
As far as commons logging usage pattern goes, extending classes should create
own instances of the log, otherwise log will get really confusing, with class
name of one class and message from another class.
Vadim
Re: svn commit: r522901 - in /cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-impl/src/main: java/org/apache/cocoon/caching/impl/CacheImpl.java resources/META-INF/cocoon/spring/cocoon-pipeline-impl-
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
Torsten Curdt wrote:
On 28.03.2007, at 20:14, Vadim Gritsenko wrote:
[EMAIL PROTECTED] wrote:
-public class CacheImpl
-extends AbstractLogEnabled
-implements Cache, ThreadSafe, Serviceable, Disposable,
Parameterizable {
+public class CacheImpl implements Cache {
+private Log logger = LogFactory.getLog(getClass());
Is there a reason why logger can not be static?
http://wiki.apache.org/jakarta-commons/Logging/StaticLog
So since Cocoon is not and should not be deployed in container's shared class
loader, usage of 'static' is preferred.
Hmm, why do you think "is not and should not"? Why not (I'm talking
about 2.2+ here)?
Last I checked, and since 2.2, it is impossible (or just really hard?) to start
up cocoon without servlet context and related objects, which means it gotta be
deployed and started as part of the webapp. If that is the case, IMHO there is
no good reason to have it as part of the shared classloader.
In addition, with 2.2+ we provide separate artifacts for "common"
components which might be used outside of Cocoon and might then be used
via a shared class loader. So I think we should not use "static" here.
For reusable components - yes, I agree.
As most of our components are singletons anyway, there isn't any memory
problem here.
There are some generated poolable wrappers, IIRC - those aren't singletons and
do represent good chunk of components (pipelines and all direct sitemap components).
Vadim
Re: [vote] Make status code attribute of seriailzers expandable
Reinhard Poetz wrote: > > I propose making the status code attribute of serializers expandable. > This makes it easier to provide REST style services with Cocoon that > make use of the different meanings of status codes. +1. Should have actually been there right from the start! Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [vote] Make status code attribute of seriailzers expandable
Reinhard Poetz wrote: I propose making the status code attribute of serializers expandable. This makes it easier to provide REST style services with Cocoon that make use of the different meanings of status codes. +1 Jeroen
