james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject Re: Serviceable to Composable changeover
Date Sun, 02 Jun 2002 08:10:27 GMT
Folks,

> Thanks for the votes of confidence guys.  The reluctance driven from 
> finishing the job and getting permission for an exceeded brief.
> I've emailed Giacomo about his use of AbstractService.  I'll switch it 
> over if he has no objections, then we have a perfect-world change
> to Serviceable from Composable.

I've not heard back from Giacomo, but have remembered one of the other 
reasons why I am nerveous about this : It changes the way maillet impls 
interoperate with the container :

Here is a typical init section for a maillet :-

    public void init() {
        ComponentManager compManager = 
(ComponentManager)getMailetContext().getAttribute(Constants.AVALON_COMPONENT_MANAGER);
        usersStore = 
(UsersStore)compManager.lookup("org.apache.james.services.UsersStore");
        ....
    }

Post change to Servicable this look like :-

    public void init() {
        ServiceManager serviceManager = 
(ServiceManager)getMailetContext().getAttribute(Constants.AVALON_SERVICE_MANAGER);
        usersStore = 
(UsersStore)serviceManager.lookup("org.apache.james.services.UsersStore");
        ....
    }

That is clearly not backwards compatible.  It might be nice to try to 
invent a way of having a fake component manager that is a delagate to 
service manager to solve this.  This would be just for maillets.  It 
could be permanent or in addition to the availablity of service manager 
for maillets (dual mode).  

Interestingly, this overlaps with some pattern/design issues.  I'll 
discuss them, but perhaps it is all pointless as you have a published 
API and you are supporting a user community.

For EOB, I decided that beans could just implement Avalon-Framework 
interfaces ( thus making A-F interfaces some grand unifying set of 
interfaces for hosted components ).  Thus a bean in EOB could optional 
implement Serviceable & Initializable and have a methods like so :

    public void service(ServiceManager serviceManager) throws 
ServiceException {
        usersStore = (UsersStore) 
serviceManager.lookup("org.apache.james.services.UsersStore");
        .....
    }
    public void initialize() throws Exception {
        .....
    }

Points of note -  service() from Servicable throws a suitable exception 
to commnicate problems to the core.  Initialization happens, in terms of 
lifecycle after servicing and also can communicate (more general issues) 
to the core.  The way it is done presently in some init() method, 
exceptions are gobbled, and there is a possibility for invalid state for 
a maillet that

Anyway, unless you know or are in easy contact with your entire dev 
community, this is all a pointless thinking excercise.  Something 
perhaps for Maillet2 API.

Regards,

- Paul H


--
To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>


Mime
View raw message