Didn't have the time to get back to this thread sooner, sorry.
more inline... Bernd On 10/3/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Bernd Fondermann wrote: > On 10/2/06, Stefano Bagnara <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
