Stefano Bagnara wrote:
Bernd Fondermann wrote:
for example the parent class hiearchie for core components like
org.apache.james.James is based on classes like
org.apache.avalon.framework.logger.LogEnabled.
LogEnabled provides functionality for what is called an 'aspect'
today. modern IoC frameworks weave those aspects into the components
by 'crosscutting' them - the component has no direct notion of it
happening.
this and similar refactoring steps would make James components much
more POJOs and thus more easily portable into new containers.
Bernd
AbstractLogEnabled is not a special class. Most james components already
are POJOs: they simply implements interfaces that declare the
dependencies (Interface injection). This is not so different from the
Settern Injection IOC style.
its not so very different (both is 'inversion of control') but it is
different. interface injection and subclassing has the downside of
making unit testing much more difficult.
The fact that we extends from an AbstractLogEnabled class doesn't make
them special classes: we can simply repackage the AbstractLogEnabled
from avalon to james and the dependency declaration interfaces from
avalon to james and they are pojos.
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 can safely ignore their interfaces if you add the needed code to
manually assembly the components in another container.
The problem with POJOification of James is not the LogEnabled interface
or the AbstractLogEnabled abstract class.
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.
(by the way, this was the original motivation behind me getting into
unit testing and end-to-end testing. first things first.)
Phoenix is old and unsupported code and we should get rid of it.
Avalon is a good set of "standard" interfaces that help standardizing a
set of components. If we remove the Avalon "startable" interface we'll
need to add a new convention or declare the call of the start() method
in the container way.
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.
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... ;-)
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).
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.
Stefano
---------------------------------------------------------------------
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]
