Steve Brewin wrote:
Stephen McConnell wrote:
Steve Brewin wrote:
<snipped>
As I understand it, different containers vary in their
depth of support for
the Avalon lifecycle. As I remember from way back, we could
dynamically
modify configurations if the container supported the requisite, but optional, lifecycle methods - suspend, resume, reconfigure, etc.
While I agree that we should be container neutral, it would
be good to
accommodate the extended, but optional, Avalon lifecycles
into a reworked
Mailet API so that it can be leveraged when available.
Just a quick note - you should not need to modify the mailet API because in effect the mailet api is a view on a container - the container is handling the deployment of mailets. The question you are raising concerns the semantics supported by the mailet container implementation as opposed to any computation constraints implied by the api.
The current Mailet lifecycle is init, service, destroy. To reconfigure, the container could simply send a destroy followed by an init to effect reconfiguration. Indeed for (1) backwards compatibility with existing Mailets and (2) 'cos the Mailet API is not bound to Avalon so should not be dependent on it, it would have to use this as the lowest common denominator.
This depends completely on the mailet container. It the mailet container supports configurable component then you home free (either via a static configuration or dynamically). To-date there has been a lot of attention of API purity, but no real discussion on the subject of a mailet SPI (Service Provider Interface). What would be *really* interesting would be the ability for a client to register a mailet factory class - and have the mailet container use that factory to instantiate mailet instances. This would keep the mailet free from pollution but at the same time enable comprehensive component-based mailet solutions.
Exposing more granular lifecycle events which Mailets may optionally support (possibly discovered through introspection) would enable efficiencies during reconfiguration, such as retaining expensive non-reconfigured resources, or resources which must maintain context. Is it worth the effort? Not sure. If there is another clean way of 'parking' resources during destroy and 'unparking' during 'init', then no, otherwise yes.
IMO its probably better to load a mailet that understands components and it basically mediates between the pure mailet container and functional component based mailets ... but to be honest - this is not an area I have explored in any detail - I would really need to dig into the container-side of the mailet management model.
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.
I'll email Albert directly and ask him to provide an overview of what he's been up to.
Cheers, Steve.
Cheers,
-- Steve
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
|---------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
