wasted enough time last week trying to make sieve work to finally
motivate me to take on phoenix. i think i'm now making progress. i'm
basically looking for ways to keep phoenix as a platform without such
a strong dependency on the avalon framework. i'm fine with the
excalibur components, and the dependency on avalon through them. i'm
fine with a container which supports avalon components but i want a
choice. i find avalon and phoenix too heavyweight and underdocumented.
i'm fed up of spending a day coding a POJO then another day fighting
with phoenix and avalon.
so, i've been discovering new ways to use an old container
my starting point was JSR 250 (Common Annotations for the Java
Platform) which is used to control service injection in ejb3. i hadn't
really studied in detail before but i took a better look and liked
what i saw. they're lightweight and not too strongly coupled to the
ejb model. it has the advantage of being a standard that plays well
with other containers.
to deploy a mailet (with a service dependency) on james using JSR250,
mark the setters with @Resource for example:
public class SieveMailet extends SieveMailboxMailet {
@Resource(name="imapserver")
@Override
public void setPoster(Poster arg0) {
super.setPoster(arg0);
}
}
this would then lookup the "imapserver" service. phoenix blocks have
names so just map imapserver resource -> imapserver block.
i quite like this idea but just doing mailet's isn't enough: the
mailet loader needs access to a service locator to resolve the
resource.
the avalon service manager could be used but has the limitation that
every resource has to be a block provided to James. this is the heart
of my issues so i'd like to avoid this. phoenix supports application
listeners so that can be used to collect every block and make them all
available by name to each mailet. that, i like: it's a lot less work.
this approach runs into a few problems with lifecycle order - events
are generated after service and initialization but that's ok: the same
trick can be used to replace the avalon service and initialization
interfaces. the listener can then init everything once every service
has been loaded from the assembly.xml. for example
@Resource(name="filesystem")
public void setFileSystem(FileSystem fileSystem)
@PostConfig
public void init() {
...
}
could probably approach configuration in a somwhat similar fashion
supporting custom mailets using avalon-based lookups might be tricky, though...
i might copy spoolmanager module so that people can take a look at the
idea in code.
still considering how to integrate with OSGi and spring, though. maybe
more later...
opinions? etc
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
