Alan D. Cabrera wrote: > > Steve Brewin wrote: > > Stefano Bagnara wrote: > > It seems that if there is one thing that stirs us up it is > container issues. > > > > At their most basic, containers provides the glue to wire > application > > specific objects together and provide them with the service > they require. > > Application objects are simple POJOs that are both > container and service > > agnostic. > > > > Most current James code is indeed like this, but this isn't > the end of the > > story. > > > > 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. > > > > Having worked on projects with much larger code bases than > James that have > > made this transition I would say there are enormous > benefits, if and only > > if, the effort can be justified. On these commercial > projects much of the > > justification came from our increased agility and the > increased quality that > > stemmed from being able to unit test individual classes in > isolation by > > injecting mock objects. Perhaps the most key thing here is > that we had the > > resources, developer and management buy in to make it > happen. Or to put it > > the other way, sufficient pain had been endured for > everyone to see the > > light. > > > > Given the limited resources of the James community, my > guess is that we > > aren't likely to take such a step any time soon. Moreover, > there are more > > important things we can spend our time on, such as IMAP > support. It would be > > good to develop such code follow these new paradigms, but > old-style code is > > preferable to none. > > > > 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? > > > > Sounds great, so long as no Avalon, or other container code for that > matter, goes into James' core code and that the Avalon, or other > container code for that matter, goes into a separate jar.
Yep! 1..* james specific jars 1 container adapter jar ? Don't care and don't need to care about the container environment -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
