Stefano Bagnara wrote:
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.
I do not agree w/ your ontological organization of Avalon and Phoenix,
jmho. If I embed James into another server, I will not be happy if I
have to drag Avalon w/ it.
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
