Stefano Bagnara wrote:
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 :-)
While my understanding as to the functionality of Avalon and Phoenix may
not be accurate, I've had plenty of experience with embedding
Avalon-ized servers and it has been horrible. Maybe it's the fault of
of the projects that used it. I just would not want to subject the
developers who want to embed James to the same thing I went through.
Please take a look at OpenORB. Maybe they abused Avalon. Maybe, my
wife says more likely, I didn't properly understand what's going on.
I buy the concepts that you mention above. I'm not sure that we have to
use Avalon to get the job done.
I'm going to take your advice and start tinkering w/ James.
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
