Bernd Fondermann wrote:
On 9/30/06, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Am Samstag, den 30.09.2006, 11:09 +0200 schrieb Bernd Fondermann:
> I am very looking forward to trying some other container, but it is
> inevitable to decouple our components from the current container, at
> first.
Doing some POJOification can't be bad but I don't consider it a blocker.
How do you know HOW to decouple components when you don't know where to
go? When you decouple it from something you have to couple it to another
thing. Being a bit container dependent can make things clearer.
Agreed. But the situation as it is now is, that the components are
heavily coupled with
a. phoenix lifecycle interfaces
b. avalon configuration stuff
c. avalon/phoenix ServiceManager
d. avalon logger (superclass)
This is really easy to remove: just copy AbstractLogEnabled to a james
package and you're done ;-) . We can consider we depend on Avalon
LogEnabled/Logger, so this can be included in the "a" point.
e. verbose + redundant config in environment.xml, *.xinfo
This is the normal behaviour in component based development: you have
component declarations, and component wiring: component declaration is
part of the component sources, the wiring is part of your application.
You anyway need this: you can try framework that try to mix them up, or
try to autodiscover one or both of them, or uses interfaces or
annotations for them, but you'll need both anyway.
E.g: The xinfo could be generated by XDoclet and javadocs in the avalon
components.
This is bad (IMHO) even if you do _not_ want to change container.
For example, look at the unit tests and the setup() methods. much too
much has to be done there to execute a simple test. this is mock-up
hell ;-)
This complexity is not given by Avalon, but by the fact that we have
components with a lot of dependencies. I did a lot to reduce the
inter-component visibilities from 2.2.0 to 2.3.0 because of this, but
when you use many services you have to mock things.
When switching to another container there may be the need for some
bigger redesign. IMHO the pure decoupling from Avalon etc seems to be
only some kind of refactoring.
Right.
Right, but not so easy: we manually handle the lifecycle of fine grained
components (not managed by the container itself). We need to find an
alternative to this.
I think that we should change the container only when we have found a
new container that give us much more features for james.
Currently the hot reconfigurability/hot rewiring limits in james are
mostly in james code and not in the container itself, so we won't gain
anything with this.
Avalon interfaces are not a limit for hot reconfigurability and hot
rewiring.
About the removal of some part of avalon we already wrote many thread in
the last years. As an example I'm sure we had a thread in may about
JAMES-495 (remove Avalon Configuration).
Searching archives you should find a "Re: [jira] Commented: (JAMES-495)
Decide how to replace Avalon Configuration" where I asked what was the
proposed solution to some specific issue we have in our code.
I also remember that you made "[LONG]" reply "on a future configuration
architecture within James." but I never understood how the current
configuration delegation should have been replaced in your architecture.
Imho configuration will never be a container agnostic thing:
commons-configuration does not provide (the last time I checked it) all
the features we expect from the configurability while other solutions
are container specific (e.g: OSGi preference service). So my idea is
that we should identify the goal, understand wether this goal can be
achieved using phoenix or not, understand it switching to another
container without removing avalon can be a solution, understand if
another container would be a solution: for configuration (as an example)
imho we have not such a clear vision.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
