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.
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
