You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Vadim Gritsenko <va...@reverycodes.com> on 2007/03/28 20:14:57 UTC

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-cache.xml

reinhard@apache.org 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?

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-cache.xml

Posted by Vadim Gritsenko <va...@reverycodes.com>.
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: 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-cache.xml

Posted by Carsten Ziegeler <cz...@apache.org>.
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/

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-cache.xml

Posted by Vadim Gritsenko <va...@reverycodes.com>.
Carsten Ziegeler wrote:
> Vadim Gritsenko wrote:
>> Torsten Curdt wrote:
>>> On 28.03.2007, at 20:14, Vadim Gritsenko wrote:
>>>
>>>> reinhard@apache.org 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: 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-cache.xml

Posted by Carsten Ziegeler <cz...@apache.org>.
Vadim Gritsenko wrote:
> Torsten Curdt wrote:
>> On 28.03.2007, at 20:14, Vadim Gritsenko wrote:
>>
>>> reinhard@apache.org 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)?
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.
As most of our components are singletons anyway, there isn't any memory
problem here.

Carsten


-- 
Carsten Ziegeler
http://www.osoco.org/weblogs/rael/

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-cache.xml

Posted by Vadim Gritsenko <va...@reverycodes.com>.
Torsten Curdt wrote:
> 
> On 28.03.2007, at 20:14, Vadim Gritsenko wrote:
> 
>> reinhard@apache.org 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.

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-cache.xml

Posted by Torsten Curdt <tc...@apache.org>.
On 28.03.2007, at 20:14, Vadim Gritsenko wrote:

> reinhard@apache.org 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

cheers
--
Torsten



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-cache.xml

Posted by Reinhard Poetz <re...@apache.org>.
Vadim Gritsenko wrote:
> reinhard@apache.org 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?

no (actually this line is the work some copy'n'paste action). thanks for 
spotting it.

-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------