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 Thu, 12 Oct 2006 06:21:33 GMT
Didn't have the time to get back to this thread sooner, sorry.

more inline...

  Bernd

On 10/3/06, Stefano Bagnara <apache@bago.org> wrote:
> Bernd Fondermann wrote:
> > On 10/2/06, Stefano Bagnara <apache@bago.org> wrote:
> >> Bernd Fondermann wrote:
> >> >> > 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!)
> >>
> >> THis is easy: don't implement interfaces in the main object, create an
> >> extension for that object implementing all of the lifecycle interfaces
> >> needed.
> >
> > :-) coming up with that solution strategy is easy. implementing this
> > solution isn't. ;-)
>
> The problem is not that the components are container aware: the problem
> is that the components do what the containers should do with
> child-components. So we have components that manually manage the
> lifecycle for the nested components. Removing this thing is not easy.

ok, I reviewed the lifecycle code and recognized those nested
components. I wasn't aware of this.

> If I find the time (I already have too much things in my todo list) I
> would like to elaborate something on component-factories to be used to
> be able to be container-agnostic when working on jspf: we started having
> a bunch of services (SPFChecker, DNSService, Logger, SPFParser) that
> could be used by child components.
> If I'll do this and I'll be happy with the result I will say something
> to get your opinions.

ok, fine.

> >> > 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()))
> >>
> >> Right. And we should try to isolate the service() call and the
> >> servicemanager references from our code: it should be easy.
> >
> > not always easy, but: yes.
>
> Can you point out a difficult scenario? I often think that trying to
> find a solution to one of the concrete (possibily one of the difficult
> issue) is much better than talking theoretically.

For example AbstractJamesService.
The service method receives the ServiceManager, which is then locally
stored and re-used in initialize().

Another case is the one you described above: when a component needs to
configure subcomponents, SM is stored locally and the component does
lifecycling on its own.

> >> >> > 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.
> >>
> >> I'm happy with avalon lifecycle dependencies: I would like to remove the
> >> Serviceable/ServiceManager stuff (in favor of setters/enabling
> >> interfaces). I would like to not be dependant on the
> >> Avalon-Configuration stuff (I don't know how).
> >
> > ok, that would be the base for a common goal. it would already be a
> > great achievement, even when still running under avalon lifecycle.
>
> I agree, and we can skip other container discussions until we have not
> fixed this starting points.
>
> I would like to know if you (and others) agree that the 2 points
> (Service / Configuration) are "must" steps anyway, indipendently from
> the final container we'll choose.

+1

> >> >> > 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.
> >>
> >> You simply have to remove "extends AbstractLogEnabled", add "implements
> >> LogEnabled" and add 2 methods copied from AbstractLogEnabled and you'll
> >> have fixed this. So this is a non-issue.
> >
> > a "non-issue"?? From writing unit test/mock up objects I am under the
> > impression it _is_ an issue, but I will have to have a look again to
> > come up with concrete examples.
>
> Yes please. Otherwise I fear I've not understood the problem.

Currently, for AbstractJamesServices, the class hierarchie is as follows:

o.a.j.core.AbstractJamesService
extends
o.a.a.cornerstone.services.connection.AbstractHandlerFactory
extends
o.a.a.framework.logger.LogEnabled

So in this case there is no _easy_ way to go from class
AbstractLogEnabled to interface LogEnabled.
And moving AbstractLogEnabled/LogEnabled from Avalon to James code is
not so simple, too. Because AbstractHandlerFactory is not from James.
AbstractJamesService is subclassed by NNTPServer, SMPTServer,
RemoteManager and POP3Server.

> Here is what I understood you want to do:
> 1) Search "extends AbstractLogEnabled" => 61 classes.
> 2) for each:
>    a. Remove "extends AbstractLogEnabled" add "implements LogEnabled"
>    b. add a "private Logger logger" field
>    c. add an enableLogging(Logger logger) method as the setter
>    d. add a Logger getLogger() method as the getter
> 3) Search "setupLogger" => 4 classes.
> 4) for each:
>    a. implement the setupLogger method that run a call a
> getLogger().getChildLogger() and call the enableLogging for the child
> component.
> 5) Champagne: we don't have an abstract root class (but Object) anymore.
>
> Is this what you want?
> What is the advantages you get from this change?

Champagne :-)
Plus the possibility to extend a super class which actually adds value
to the child class.

  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