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).
My thinking was that by introducing this compatability layer no changes would be required to an Avalon application. The responsibility for adapation is solely that of the adapter. Where a host container lacks the equivalent states to Avalon, it must synthesise them (possible by borrowing elements of the Phoenix code). Where the XML is exposed in a custom manner, the adapter must synthesise this too. > What do you think of this 2 "real" changes? Is this the right > direction > to be able to move to another container? If we are going to make these kinds of changes, we are beginning to decide on a new API for James, rather than simply introducing a compatability layer. I'ld rather avoid this right now. Besides, a compatability layer is of benefit to all Avalon applications. <snipped> > > 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. Agreed. > > Stefano Cheers Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
