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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
