> >>Albert Kwong recently sent to me a patch detailing
> a
> >>MailetRegistry that
> >>handles the registration of merlin based mailet
> >>implementations (without
> >>touching the mailet api). This is consistent with
> the ideas I've
> >>discussed with Alexis Agahi (Open IM) - basically
> that the really
> >>interesting scenario is the ability to move james
> from
> >>"application" to
> >>"service" and once that is achieved - to be able
> to use james as just
> >>another service available to any other component.
> >
> >
> > That would be something worth examining. Any links
> to the conversations?
>
> It was off-list so I can't quote anything but I have
> pinged Albert to
> let him know that I'm talking about him and this
> subject. What I can
> say is that he has come up with a modified james
> assembly model which
> ties in a mailet registry - which is kind of cool.
> It does not impact
> the mailet api but enables component based mailets.
> After looking at
> the code (which is based on Merlin 3.2 I think we
> can improve/simplify
> this using the composition spi in Merlin 3.3.
As Steve said, the proposed solution uses a mediator
with the following interfaces:
public interface RegistryService
{
public void register (String name, Object
plugin);
public Object resolve (String name);
public void addListener (String name, Listener
listener);
}
public interface Listener
{
public void registryReady () throws Exception;
}
A Mailet component will implement the standard Mailet
interface as well as Avalon lifecycle interfaces. In
particular, during service(), it looks up the
RegistryService and then registers itself during
initialize().
The JamesSpoolManager component will implement the
Listner interface and adds itself to the registry
during initialize(). When the RegistryService
confirms that all components are ready, it calls the
listener's registryReady() method, where actual
initialization can take place.
The block.xml will contain the following:
<component name='mailet-registry'
class='RegistryService'>
<plugin-type>org.apache.mailet.Mailet</plugin-type>
<plugin>CustomAvalonMailet</plugin>
<listener>JamesSpoolManager</listener>
</component>
<component name='custom-mailet'
class='CustomAvalonMailet'>
<configuration>...</configuration>
</component>
<component name='transport'
class='org.apache.james.transport.JamesSpoolManager'>
<!-- ... -->
<mailet name='CustomAvalonMailet' type='avalon'>
<!-- ... -->
</mailet>
</component>
When the JamesSpoolManager sees that a mailet is of
type avalon, it can use the RegistryService to lookup
the component instead of looking it up from the
predefined mailet packages.
Benefits: the CustomAvalonMailet can make use of any
avalon services, such as a datapath we have designed.
The datapath can be shared between the web tier and
the SMTP tier (and potentially many other tiers),
making code highly reusable. In our case, we did not
call any James Avalon services from our servlets.
Albert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
