Return-Path: 
 <dev-return-97370-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 38524 invoked from network); 2 Nov 2007 11:19:46 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 2 Nov 2007 11:19:46 -0000
Received: (qmail 68442 invoked by uid 500); 2 Nov 2007 11:19:32 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 68369 invoked by uid 500); 2 Nov 2007 11:19:32 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
List-Post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
List-Id: <dev.cocoon.apache.org>
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 68358 invoked by uid 99); 2 Nov 2007 11:19:32 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Nov 2007 04:19:32 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of grek@tuffmail.com designates
 216.86.168.179 as permitted sender)
Received: from [216.86.168.179] (HELO mxout-04.mxes.net) (216.86.168.179)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Nov 2007 11:19:54 +0000
Received: from [192.168.0.118] (unknown [89.174.40.60])
	by smtp.mxes.net (Postfix) with ESMTP id 8395ED05A1
	for <dev@cocoon.apache.org>; Fri,  2 Nov 2007 07:19:13 -0400 (EDT)
Message-ID: <472B07A9.1070808@tuffmail.com>
Date: Fri, 02 Nov 2007 12:19:05 +0100
From: Grzegorz Kossakowski <grek@tuffmail.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Abstract classes for Spring-based components (was: Logging of
 AbstractSAXTransformer)
References: <1193744600.6865.34.camel@localhost>
	 <1193761470.6865.70.camel@localhost>
  <47276985.1040909@apache.org>	 <1193771782.32165.16.camel@cartman>
  <4727C95E.3080507@apache.org>	 <1193820047.6865.98.camel@localhost>
  <4728ADE3.80401@apache.org> <1193989821.5867.34.camel@localhost>
In-Reply-To: <1193989821.5867.34.camel@localhost>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

Thorsten Scherler pisze:
>> AbstractSAXTransformer is not a component but just an abstract class assuming its descendants will
>> be Avalon-components. If you are extending such a class you must be careful because you must check
>> if your super class can work ok without assumption that Avalon-contracts are respected as they won't
>> be if your component is a Spring bean.
>>
>> For example, when extending AbstractSAXTransformer you may want to check why it implements
>> Serviceable interface. As you can see:
>>     public void service(ServiceManager aManager) throws ServiceException {
>>         this.manager = aManager;
>>     }
>>
>> It only stores a manager so you need to check if it is used somewhere. After bit of research you
>> figure out that manager is not used in AbstractSAXTransformer so this class can live without
>> ServiceManager at all. The same goes for other contracts.
> 
> Actually this is a very good example of some short comes in our current
> wrappers. The serviceable components are not initialized correctly. My
> custom transformer is using service(...) and had thrown a NPE. After
> debugging I found out that service(...) never got called. 
> 
> The solution is to implement:
> public void setManager(ServiceManager manager) throws ServiceException {
>   super.service(manager);
>   this.manager=manager;
> }
> 
> and add to your spring config:
> <property name="manager"
> ref="org.apache.avalon.framework.service.ServiceManager"/>

Yes, this is a valid solution but the question is: if you develop Spring 
bean why do you need a service manager at all?

>> Ok, this is bit tedious and hacky because you really need to examine *all* implementation details of
>> *all* super classes. 
> 
> I am lucky that I have lots of experience with cocoon < 2.2 so the
> interfaces and super classes are familiar to me but which strikes me
> awkward is that they do not work as they did in "before 2.2". 

Only if you try to use them as super classes for Spring beans. If you 
try to develop an Avalon component everything will work fine.

>> This process started to begin (see org.apache.cocoon.util.AbstractLogEnabled class for example) but
>> there is a work left. I would like to hear other's opinion on this.
>> Are we going to reimplement all of our abstract classes?
> 
> IMO we should otherwise avalon will be around forever and personally I
> do not see the need for 2 different IoC container.

Yes, I agree. This is a really good task for 2.3 that should appear 
shortly IMO.

> 
> Yeah, can do it, but then we need to define IMO as well a new interface
> for our components. I guess we still do 
> a) generate SAX
> b) transform SAX
> ...
> 
> meaning all components (except serializer and readers) are producing SAX
> events, right?

I can't follow this. What dod you want to explain here?

-- 
Grzegorz Kossakowski