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 Tue, 03 Oct 2006 16:51:44 GMT
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.

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.

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

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

I remember the same: I would like to use enabling interfaces for 
mailets, but it seems that at least Noel is on the opposite side 
proposing JNDI lookups.

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

Maybe I have not been clear enough: I'm a big fan of IoC, but Avalon is 
all about IoC (just think that it is the only framework enforcing IoC 
for logging). This is unfortunately enough to be container agnostic.
Being container agnostic means simply separate the container agnostic 
things from the container specific things: you will still have both in 
the resulting application/component and most times the container 
specific part is not trivial.

Btw this is a too much theoretical discussion: I think that we all know 
what is the real world out there.

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

I think that this is true for the first but I'm not yet sure about the 
Configuration thing: OSGi has 2 default services for Preferences and 
Configurations and they do not seem to have a direct mapping on 
Configurations used by other containers/framework.

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

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

>> 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 ;-)
>  Bernd

If you'll manage *static* loggers in environment with complex 
classloaders hierarchy you will hate them for sure.. you'll revert to 
non-static loggers with static factories, but I already hate this anyway ;-)


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

View raw message