Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <460BAB3A.1010601@reverycodes.com>
Date: Thu, 29 Mar 2007 08:04:10 -0400
From: Vadim Gritsenko <vadim@reverycodes.com>
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: 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
References: <20070327132939.B88971A9838@eris.apache.org>
 <460AB0A1.3010503@reverycodes.com>
 <B0C02CBF-9BB1-4202-A07F-F92BD9591F97@apache.org>
 <460AFC46.4020309@reverycodes.com> <460B5D06.5030603@apache.org>
In-Reply-To: <460B5D06.5030603@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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