Peter,
>As we've discussed before on the james-dev list, it's a little more
>indepth than this patch addresses.
>
>
>
>i) The Mailet API is to remain invariant - that is,
>mailets must be able to access the same components as previously using
>the component manager that was provided to them through the
>MailetContext.
>
>ii) Point (i) requires that all James services
>continue to implement the Component marker interface. No biggie, it's
>just a marker interface
>
True, but it has been eliminated from Cornerstone in Apache HEAD CVS.
>iii) Point (i) also requires that we use an
>AdaptingComponentManager (sic?) to wrap the ServiceManager and provide
>components to the mailets.
>
>
(wrapping) Perfectly possible. but .....
Take init() from org.apache.james.transport.mailets.ToRepository
ComponentManager compMgr =
(ComponentManager)getMailetContext().getAttribute(Constants.AVALON_COMPONENT_MANAGER);
try {
MailStore mailstore = (MailStore)
compMgr.lookup("org.apache.james.services.MailStore");
1) If MailStore extends Component this will work.
Well it does not anymore, it extends Cornerstone's store, but you have
the source for MailStore, so can to "extends Store, Component".
2) If all ComponentManager looked up things are in your codebase, then
you have a strategy in (1).
Well, that is not true, JDBCAlias (and JDBCListserv) returns
DataSourceSelector on lookup, which is in Cornerstone's CVS. You could
invent JamesDataSourceSelector which wraps the Cornerstone one and adds
an impl of Component, then it it will work fine, but it changes the
JDBCAlias source, which breaks the backwads compatible directive.
>If it weren't for these little issues, we'd probably have gotten to it a
>while back. If you'd like, you can update the patch to address these
>issues and resubmit. Thanks.
>
>
The patch can be fixed as per the strategy outlines in (1) and (2)
above. It will mean that the DataSourceSelector usage will end, but
that is only two mailets in your codebase.
If I were you I'd decomission ComponentManager completely for the sake
of ServiceManager (Component for Object, and Composable for
Serviceable). It is a brave step and does break backwars compatability,
but it is very nearly a word replacement issue for the user community.
If James mailets were distributed as shrink wrapped, then you'd have a
problem, but they are not.
You choice, I'm an honarary committer here (my capacity is limited to
Phoenix related issues).
Regards,
- Paul
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
