Stefano Bagnara wrote:
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).
It's the last bit that I have an aversion to. We should have no
container specific code in James' core.
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.
Sorry, my opinion has not been swayed. Please note that this is not a
commentary on they way Avalon has been architected. It's just that I
strongly believe that container specific code should not be in a
project's core 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.
I don't think so. You do not have to move it to a specific container.
You can write simple POJOs then, in other jars, have container specific
adapters. If the container does not allow this paradigm then, IMO, it
is too invasive.
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.
I refer the readers of this thread to my experiences embedding OpenORB.
I would be interested in hearing other peoples' experiences embedding
Avalon servers into existing non-Avalon servers.
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
