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? Cheers, -- Steve > Alan D. Cabrera wrote: > > Bernd Fondermann wrote: > >> Stefano Bagnara wrote: > >> > >>> I currently don't have an opinion on what it is better > for us between > >>> j2ee, OSGi, XBean, Phoenix, <put what you want here>, but I think > >>> that we should choose one. This is way I'm really interested in > >>> pro/cons of XBean. > >> > >> AFAIK, XBean is to become the 'next generation core' for Geronimo > >> (can't find the thread over on geron-dev ATM). > > > > I want to add some color to this particular thread. > Getting James ready > > for XBean will make it totally container agnostic in that > it will not be > > dependent on any XBean code. What we will have are, > literally, POJOs > > that can be wired together by hand, if desired. The beauty > of this is > > that people can use and embed James w/out dragging in the > pantheon of > > server container jar dependencies that it currently requires. > > We don't depend on the container itself. > We don't have dependencies on phoenix in our code. > We depend on the avalon-framework: think at it as a set of mostly > interfaces and basic classes that helps starting up a new project (a > common way to define things). > > This is the same thing as ant vs maven2: maven2 power is because it > standardize the way you handle a project. > Well, IMHO, Avalon:POJO is like Maven2:ant. Just think to > them as a core > of James. We could have written our own org.apache.james.Startable > interface but we preferred to use an already existing > org.apache.avalon.framework.activity.Startable interface > already existing. > > I invite you to look at the avalon-framework-api-4.3.jar contents and > what interfaces are declared in that jar. I think this could > help this > conversation. > > The other depedencies excalibur+cornerstone jars are components, and > provide services to our code: they are not imposed by the > container but > needed by our code. > > > I will restate my opinion that I mentioned in an earlier > email. IMO, if > > you must decide ahead of time what container to choose > before you start > > coding, that container is too invasive. > > We already have code. So to move to another container we HAVE > TO write > wiring/configuration data and unfortunately this is container > specific. > > Stefano > > PS: please note that if you look at this archives I had the same > identical ideas you're defending now, then I looked at and understood > avalon and I now I think I was wrong. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
