Bernd Fondermann wrote:
> 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.
I agree, we should try to promote every component to container managed
component.
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?
I've lost you: where do we need the fully qualified classname of our
implementations? In dependent code you lookup the service via the
service interface name...
> 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.
Yes, we already agreed that we have to refactor the service methods to
lookup services and call setters so that we can test components without
to call the service method: not sure this is easy for all of our
components, but we should do this everywhere we can.
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.
I never did this, but I think people already do this:
http://wiki.apache.org/james/Embedded
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.
Don't hurry, I think we can delay the discussion to the time someone
will find the time to really work on this: we already have plenty of
features to implement on the current 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.
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.
I think that now I have a great knowledge on how current components
configurations is propagated inside james, and I think this one was MY
QUESTION, so you really can't ask this to me :-P
I can give to you my feedback:
a1. well, as you noted we already do this.
a2. this currently does not give us anything: commons-configuration has
not great feature for us that avalon-configuration does not give us.
AFAIK there is an commons-configuration provider based
avalon-configuration: so a2 is not difficult, but what does this bring
to us?
b. This would mean that a parent object knows how to parse configuration
for the child object: this is false for current james. Configuration is
currently delegated to the child component and the parent has no clue on
how to parse it.
c. I don't know how it works.
Maybe we should introduce new avalon components for child-component
factories so that we separate the factory/container logic from the
parent<->child relationship and maybe it will be much more easy to
migrate to a container that supports this "factory" concept.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
