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 Tue, 03 Oct 2006 16:19:09 GMT
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. ;-)

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

> The most
> difficult part is how we currently propagate the ServiceManager to the
> Mailets (via Mailet Context).
> How should we propagate such dependencies to Mailets?

For Mailets, I don't know. There has been a thread about it and no one
yet came up with a good solution, AFAIR.

> > 3. livecycle method of different containers are not neccessarily
> > compatible/interchangable
> And this is the bigger issue: "container agnostic components" are only
> an utopia. As soon as you write not-hello-world componets you will have
> requirements for the lifecycle and the dependencies behaviours and this
> will need lines of code or much lines of container configurations to be
> addressed. Saying that your component is container agnostic simply means
> that the component is not complete and will need much more work in order
> to make it working in any specific container.

ooh-kaay... do you consider the whole IoC approach,
separation-of-concerns, low coupling, ... as utopia(s)? Up to some
point it works quite well in reality, I think.

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

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

> I would like to keep the IoC style for Loggers: I always hated the
> static way to access loggers that 99% of projects out there use. One of
> the things because Avalon is great is for trying to enforce IoC for
> logging (IMO).

IoC loggers are good... never thought about hating those static
loggers, but will consider this for the future ;-)


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message