On 9/30/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Bernd Fondermann wrote:
> On 9/30/06, Joachim Draeger <[EMAIL PROTECTED]> wrote:
>> Am Samstag, den 30.09.2006, 11:09 +0200 schrieb Bernd Fondermann:
>>
> 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.
I think, polluting the class hierarchy like this is another quality
than requiring interface implementations.
> 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.
Ok, for "component declarations"
But why do I have to declare the propagated components on both sides?
The wiring should then be done by the container, not by the
application, or the components themselfs.
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.
Why, if I have to do a lookup via ServiceManager with the full
qualifed classname anyway?
> 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.
The service() lifecycle method does all kinds of service lookups. If a
lookup cannot be resolved, the ServiceManager is throwing an
exception. So even if I don't want to test all dependent components
for the tested component, I have to provide them (or mocks) because I
want some code to be run/tested, which is enclosed between code using
all the other components. boo.
I think that we should change the container only when we have found a
new container that give us much more features for james.
I am not promoting to change the container for the "main James Server
distribution".
What I'd like to have though, is the shear possibility to deploy James
in a hosted environment, like a J2EE container.
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.
ok, hopefully I am able to get back to this thread sooner or later.
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.
mhh. the interesting question for me is: how is the configuration
propagated to the component?
a1. By using the container-specific data structures (James today)
a2. By using some other "generic" data structure or common
configuration framework
b. By component specific data structure
c. By injecting from configuration file into the component (see XBeans)
If you have a look at how components are interwoven with the
configuration datastructure currently, hot re-configuration is hard to
achieve. At first, all the Avalon Configuration stuff would have to be
pulled back into the configure() method and the (at some places quite
substantial) configuration logic be separated from that.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
