Paul Hammant wrote: > Folks, > > OK, so perhaps this idea is not as controversial as the subj > line would > indicate. Is there any interest (beyond me) for refactoring the James > server implementation to allow non-Merlin/Avalon use ? > > We're finding that Constructor Dependency Injection (CDI) is pretty > popular now. There is a way for most Serviceable/Configurable/etc > components to split into AbstractFoo, AvalonFoo and SimpleFoo type > classes that would facilitate a non-Avalon capability for James. > > This refactoring would also give standalone capability > (without all the > JMX management of course). > > Thoughts? > > Regards, > > - Paul
James relies on a set of interfaces to provide container services. Currently these are the Avalon interfaces. I see no benefit in replacing those interfaces with another set which would need to provide equivalent functionality. That just seems to be a lot or work for what exactly? What are the killer benefits? How a container fulfils the requirements of the existing interfaces is open. They could be mapped to a wide variety of deployment environments. Rather than port James to a new set of "Foo" interfaces, why not implement Avalon's "Serviceable/Configurable/etc" interfaces to your own "Foo" environment, enabling you to port all apps. conforming to the Avalon interfaces? Still, like any large body of code, James could probably benefit from refactoring to better isolate dependencies, such as those on the Avalon interfaces. This would make it more flexible, both within and without Avalon. This is more important if James is viewed as a toolkit of mail server components, whereas the declared view, as stated on the web pages, is that James is an application. -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
