Paul,
I don't really understand all the implications of Composable vs.
Serviceable, but problems of mailets or matchers tied to the Avalon
model aren't really a concern to me... the ones with James can be
changed easily enough, and then we just need to notify users of the
change from James 2.0.x to James 2.1.x so they can adjust if they've
tied their code to Avalon.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
Paul Hammant wrote:
> 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]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
