Steve Brewin wrote:
[...]
What is a service? In James and many other early container oriented
applications it is something provided from outside of the application.
Application objects are assumed to be present and referenced directly from
within the code. They are treated as special cases, rather than being yet
another service that should be wired together and acquired using the
container.
Treating all objects as services is a step beyond this that gives further
levels of flexibility to easily introduce changes within the application.
Essentially providing the same dynamics for differing implementations of all
parts of the application as the application has in acquiring external
services.
Little James code is like this. To make it so would require a significant
effort.
Here are the Avalon "Enabling interfaces" we currently use (and the
provided services in brackets):
activity.Disposable
activity.Executable
activity.Initializable
activity.Startable
activity.Suspendable
configuration.Configurable (Configuration)
context.Contextualizable (Context)
logger.LogEnabled (Logger)
service.Serviceable (ServiceManager)
I think that most of them are not in conflict with any modern container.
The most "avalon specific" are the Configurable and the Serviceable.
Configurable provide a Configuration object that is a custom
representation of an XML (it's a tree of configuration objects).
Serviceable provide a ServiceManager that is used to lookup application
services and this is not how modern container manage the dependencies.
To solve the Serviceable problem we could probably create a
set<ApplicationServiceName>(<ApplicationServiceName>) in each component
that has dependencies and leave the service(ServiceManager) method as a
facility for Avalon while exposing direct setter for the dependencies:
does this make sense? (there are probably issues in the way we keep the
ServiceManager in the MailetContext and lookup services from the
mailets: any hint?)
The Configuration should probably be changed by creating Configuration
Beans: We already have a similar thing in the SMTP Service and it is the
SMTPHandlerConfigurationData. SMTPHandler is not Configurable but has,
instead, a setConfigurationData(SMTPHandlerConfigurationData).
What do you think of this 2 "real" changes? Is this the right direction
to be able to move to another container?
[...]
Many containers also support the notion of lifecycle states. Currently James
is built around those of Avalon. These are simply mapped to any other
containers lifecycle states. A simple adapter is all that is required.
Long ago I advocated that we declare our own lifecycle states, probably
symmetric with Avalon's, and then deliver adapters to work with chosen
containers. On reflection, perhaps we do not even need to do this.
Alan, how about an Avalon to XBean adapter?
This is exactly how I think we should move.
Not totally in context but I want to say again (and again) that Avalon
is not a container but a framework. Phoenix is the container we
currently use and it's limited to Avalon components.
We can move the avalon interfaces in our packages but I don't see
advantages right now: I will agree on this change when we will need
different interfaces/options.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
