Bernd Fondermann wrote:
I've just downloaded sources from here:
http://svn.xbean.org/trunk/
Is this the current official/updated repository? I see no changes
after february.
that must have been the point in time where xbean moved to Apache
Geronimo and disappeared from the Codehaus projects list.
see: http://issues.apache.org/jira/browse/GERONIMO-1478
you can check it out from G's SVN. but the source code seems to be the
only thing you get.
Ok, I saw that.
I can't find messages/documentation on the integration plans between
XBean and Geronimo. I would like to read more about this.
I also don't understand what projects are currently using XBean or what
server components have been supported by writing wrappers on XBean.
wouldn't it be best to POJO-fy _first_ without a specific container in
mind (a larger task on its own) and then afterwards look at all the
mature containers to integrate with?
>
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.
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.
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.
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.
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.
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. I have a good knowledge of J2EE and Phoenix and I think Phoenix
is better to James than J2EE, but, as I already said, I think that
phenix is not actively supported and we should move forward. I still
consider other Avalon containers an option: unfortunately there are no
complete/updated/supported avalon containers around.
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.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
