james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernd Fondermann" <bernd.fonderm...@googlemail.com>
Subject Re: OSGi: First steps with Knopflerfish
Date Mon, 02 Oct 2006 13:03:41 GMT
On 9/30/06, Joachim Draeger <jd@joachim-draeger.de> wrote:
> Am Samstag, den 30.09.2006, 12:07 +0200 schrieb Bernd Fondermann:
>
> > > 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
>
> What is the problem with them? In another container the Interface might
> be named Lifecycle and the methods activate() and deactive(). Just
> refactoring.  The question is how the things done in
> configure/start/stop/initialize/dispose fit into other frameworks.

Three problems:
1. component must import lifecycle stuff and becomes container aware
(_not_ IoC in the narrow sense!)
2. lifecycle methods cannot simply be "renamed" if there are
ServiceManagers stored in the component itself (bad. sometimes
difficult to refactor, when you get the SM in the first call (say:
initialize()) and need it in the second (say: configure()))
3. livecycle method of different containers are not neccessarily
compatible/interchangable

> > b. avalon configuration stuff
>
> Yes, some POJOification should be done here, too. Did we decide how to
> do this?

No, not yet. We have setters on most components, but much of the
configuration and intialization is still very very dependent on the
framework. some consider this as being ok, I don't.

> IMO classes with only a few configuration options should carry their
> attributes + getters/setters themselves. More complicated configs should
> be moved to separate pure POJO beans.

Exactly.

> > c. avalon/phoenix ServiceManager
>
> AFAIK POJOification in progress, or even finished?

in progress, sometimes delicate.

> > d. avalon logger (superclass)
>
> What do you suppose? I consider this as refactoring. :-)

Well, logging is not a semantical super-construct of a component, it
is a side-aspect.
By extending AbstractLogEnabled you hinder more semantically
beneficial class hierarchies. Bad.

> > e. verbose + redundant config in environment.xml, *.xinfo
>
> You mean assembly.xml?

Yes, sorry... should have checked that beforehand.

> Is there a possibility to avoid that redundancy
> in Avalon? Apart from that I find them both quite readable.

You have to do the following:
1. Declare a component
2. Declare for the component, which other components it references
3. Declare for the SM, which components it propagates to each component
4. Implement in the service() method a lookup and typecast.

This is not inversion of control, this is "all stages control".
It is redundant, since James uses full qualified class names everywhere.
With 4.) in place, 2) and 3) become uneccessary, no additional
information is added, being of any use for SM or the component.

> > 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 ;-)
>
> I completely agree, but I don't consider this as a blocker for
> evaluating different containers or even try to wire some James stuff
> together in order to try it inside an OSGi bundle.

Right. BTW, I am not opposing OSGi. There have other containers been
brought into the discussion, like Spring, xbeans, AFAIR. Stefano did a
poll which one should be preferred, with diverging opinions.

My take on this is: Let's fix our components at first, then decide
about switching containers.

  Bernd

---------------------------------------------------------------------
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