Bernd Fondermann wrote:
by just moving the codebase into the project? what would that change?
in my understanding, a class implementing container-specific lifecycle
interfaces like Servicable, Configurable, etc. is not a plain POJO anymore.
You could think to Startable, Disposable, Configureable as our own
interfaces. You can ignore those interfaces if you prefer to declare
that informations in xml files: you're not tied to the interfaces.
IMHO we should find a way to run our avalon based components in a
non-avalon container (remove Phoenix). Then we can also remove avalon,
but I don't think this would be a big step forward.
maybe its not a very big step in terms of code-changes. but it is in
terms of QA and testing (unless you have full unit test coverage). you
pull away the base and replace with something else. that sounds like
quite a bit could break here.
I agree, but we have this issue with every single step towards pojos, so
this is not an input variable in my considerations.
Eventually we could change the way "Serviceable" works now to remove
the Service Locator part of the Avalon framework by creating
specialized "Interfaces/Setter/Constructor parameters" for every james
component. I tend to think that Serviceable is the only thing our
components use that most container would not handle in a clean way. It
could be solved by publishing the Avalon ServiceManager as a component
but we would loose the wiring capabilities of the new container.
In James, the whole component lifecycle including configuration is
closely interwoven with the application-specific logic.
this is not a bad thing, but it makes the task of changing the container
more difficult.
I would like to see real world example on how to change a few James
classes so that we can change container without writing full length
configuration files and/or specific adapters/wrappers.
IMHO we should not fall in the Utopia of a POJO world: if you remove
wiring/configuration/logging/workflow/lifecycle from classes you have to
add the same information in container specific configuration files.
Sometime is faster to port to different containers applications with
much hardcoded behaviour/wiring than application with great granularity
of the components and big container configuration files.
IMHO porting container configurations is not easier than refactoring
java classes.
One more thing: I don't think that the "let's make POJOs and ship with
any container" is a winning strategy. In fact when you have POJOs
there is a lot of work to do to create container specific
configurations and I don't think that we'll ever ship james with more
that one container choice.
yes, i agree. but look at Tomcat: it's a very mature stand-alone server
and a highly embeddable servlet container. this is something I fancy a
lot for James -- just dreaming... ;-)
Tomcat is an "highly embeddable servlet container", yes, but I don't get
the point. Embeddable doesn't mean that you can wire tomcat components
using different containers: it simply means that you can embed the whole
tomcat into other systems. This is easier and doesn't need POJOs.
There are embeddable avalon containers around (fortress), but I don't
think the main goal is to improve embeddability.
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 read only 3 messages in the geronimo list, but I think this has not
been voted yet. They simply voted to accept the XBean codebase. They
could never use it.
A server container is much more than dependency management/component
wiring: component monitoring/management (JMX), logging services,
configuration (and re-configuration) services, component
deploy/undeploy, datasource/jdbcpool management, and more. All of this
are "Container Specific" and not "James Specific" but are part of the
final James distribution.
yeah, and probably improving all that is more user-friendly than
changing containers ;-).
but nevertheless, to make 'the whole James framework' more lean, more
testable, would help the project to improve its codebase. If this
requires a container change, someone of the modern containers would do
it, I reckon.
I don't uderstand what do you mean with "more testable": James is all
about IoC and you can test every component by assembly it the way you
prefer.
What kind of test you would be able to write with objects not extending
AbstractLogEnabled?
I really don't understand this point.
The tests you provided are the proof that James is testable. You did a
good job understanding what the dependencies between components was, and
providing mock implementations for that dependencies.
The main problem with tests is, IMHO, the multithreaded/multitier nature
of the server itself.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
