On Mon, 2003-01-27 at 10:37, Quinton McCombs wrote: > To summarize what has been discussed so far....
One thing I would like clarified is where exactly Fulcrum is planned for usage. I hope not in turbine-2 as I feel this would probably be a bad idea mixing new usage with old and will just create problems. In that whacky work-arounds will be required to accommodate the use of static accessors. If people choose to use Fulcrum with turbine-2 then the standard form of composing and acquiring resources should be used and not static accessors. > > 1) Drop stratum lifecycle interfaces. They will be replaced with the > Avalon lifecycle interfaces. These are the same as Avalons and there is really no use for them other than I felt I didn't want to be dependent directly on Avalon. But I don't see this as a bad thing now. If they can be removed then they should be removed. > 2) We need to decide if Fulcrum will have it's own container or if it > will just be a collection of components. Note: I am not talking about > writing a container. We would simply use ECM or some other like > product. I think the best solution is to rid Fulcrum of any service/composition management code and leave that to the container which is chosen. I have made two huge sweeps over the Fulcrum code (first to separate it from Turbine 2, and another cleanup and couple months later) and it's not worth keeping. It really isn't. > 3) The entire services layer will be deprecated. A new method of > accessing the components will be used to replace the old functionality > that the services layer provided. Then I assume you are talking about the use of Fulcrum in Turbine-2. If so the static accessor mode needs to go away. > 4) We will use a customized LoggerFactory component that uses > commons-logging. Newer containers like Plexus, Merlin and Fortress have mechanisms already. No need to write something else. I have also gone through some humming and hawing about using log4j directly or commons logging. In Plexus I have a loggers which use log4j and commons-logging but I haven't decided. There are some pros and cons to weigh, but I can post a summary of those issues later. > 5) We will create a conversion program to convert the existing service > configuration into an Avalon compatible XMl format. You could simply make something to process the stream on the fly. Probably easier for users. The XML format configuration is also not that difficult, certainly more clear and definitely easier to validate. For t3 usage or above the properties format could probably just be tossed. I've been using XML format for 6 months now and benefits can't be overlooked given all the tools there are for working with XML like validating editors, tranformation tools and the like. > 6) All of the components should be compatible with ECM and Plexus. We > really need more discussion on this goal to determine what this will > require and if there are other containers that we want to be compatible > with. The new containers like Plexus, Merlin and Fortress can deal with different lifecycles. If you pick the older ECM style that's fine. But if you're porting the services anyway you could use the Serviceable over Composable. Plexus also has some facilities to make composition by configuration easier. This problem arises due to the fact that the compose/service method is before the configure() method in the lifecycle. > We have already discussed having the ability to load Avalon components > as being part of the plan for Turbine 2.3. Perhaps if we can get > Fulcrum ready, it can be released at the same time?? If you use one of the newer containers then you can certainly do that. With Plexus I plan to be able to load EMC, Plexux, and Phoenix components and I believe Merlin can do the same. > I will try to get a Tiki page created for all of this sometime today or > the next. Cool. > > > -----Original Message----- > > From: Quinton McCombs > > Sent: Monday, January 27, 2003 9:20 AM > > To: Turbine Developers List > > Subject: RE: Turbine, Fulcrum, and Avalon > > > > > > > > > > > -----Original Message----- > > > From: Gonzalo Diethelm [mailto:[EMAIL PROTECTED]] > > > Sent: Monday, January 27, 2003 7:17 AM > > > To: Turbine Developers List > > > Subject: RE: Turbine, Fulcrum, and Avalon > > > > > > > > > > On Sun, 2003-01-26 at 16:20, Quinton McCombs wrote: > > > > > I would like to propose that we drop stop using the > > > stratum lifecyle > > > > > interfaces altogether in favor of Avalon's interfaces. > > > > > > +1 (although I think I'm still a committer, I consider my vote > > > to be non-binding, since it's been REALLY long since I have > > > contributed anything to Turbine). > > > > > > >From what little I understand about all the issues here, I > > > would try to go with Fortress as a single, unified container > > > for Turbine; initially, I would keep the static accessors as > > > a facade, for compatibility reasons, but I think those should > > > eventually be deprecated. > > > > > > > +1 I say deprecate them as soon as we have a DOCUMENTED method of > > accessing the components without going through the services layer. > > > > > Regards, > > > > > > > > > -- > > > Gonzalo A. Diethelm > > > [EMAIL PROTECTED] > > > > > > > > > -- > > > To unsubscribe, e-mail: > > > <mailto:turbine-dev-> [EMAIL PROTECTED]> > > > For > > > additional commands, > > > e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:turbine-dev-> [EMAIL PROTECTED]> > > For > > additional commands, > > e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
