Alan D. Cabrera wrote:
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.
I don't know what is your knowledge about avalon/phoenix.
You can think at avalon like a set of interfaces. Avalon itself is not a
container, but only a set of (good) interfaces to promote certain
"patterns".
James does not have container specific code in its core. In fact, the
james code is build with no dependencies on phoenix.
We just include the avalon interfaces.
The fact that james objects implements interfaces should not be a
limitation otherwise it would mean that we have to change our object to
put them in a different container: this would mean that the new
container has requirements and doesn't handle agnostic components.
That said I'm +1 to remove the service locator pattern in favor of SDI
and changing the way we configure components.
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.
Again, I don't understand if you say this things having a good knowledge
of what avalon is and what phoenix is, or if you say this things only
because you know XBean and you don't know Avalon. (people always reject
things we don't know/understand)
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.
Take a POJO, let it implement and interface: is it a POJO ? Can't POJO
implement interfaces??
James objects simply implements interfaces. The AbstractLogEnabled
object we extends is really a simple object and we can move that in the
james core, if this make you feel better. (Avalon is all about IoC)
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.
I think that Avalon itself is not a problem and removing it is only time
lost if we don't have a good reason to remove it.
There is no such thing "Avalon servers": there are "avalon compliant"
objects. Phoenix is a server that handle "avalon compliant" objects.
Btw, if you are working on Maven2 or Xbean around James I'm sure you
will have a better understanding of james soon, and we can continue this
interesting thread with more "concrete" facts and less "pojo" words :-)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
