james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: OSGi: First steps with Knopflerfish
Date Mon, 02 Oct 2006 19:58:29 GMT
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message