> -----Original Message----- > From: Jason van Zyl [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 27, 2003 9:57 AM > To: Turbine Developers List > Subject: RE: Turbine, Fulcrum, and Avalon > > > 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. >
I just want to make it easy for users to adopt the next version of Turbine without being forced to make code changes as part of the upgrade process. We had this problem when moving between 2.1 and 2.2. This caused many users to put off the migration as long as possible. We still have users trying to work around problems in 2.1 because moving to 2.2 is such a painful process. Maybe there is a better way. > > > > 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. This should be possible. The componentservice, Fulcrum, and Torque should be the only areas affected. This should have no impact on the users at all. > > > 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. I have no objections to this. > > > 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. > Not really. We have users that have written their own services. I would like for these services to continue to function in Turbine 2.3. We could deprecate all of the services layer though. The next version of Turbine *might* have the services layer completely removed. Fulcrum could have its services layer along with the static accessors completely removed. If Fulcrum is going to be strictly a collection of components, this would make sense. Optionally, we could just deprecate the services layer in Turbine to prevent breaking any existing code. The second release of Fulcrum could have the services layer removed. I know this is just keeping a problem around longer than we might have to. Personally, I don't use Fulcrum and I suggest to users that they not use fulcrum at this time. Changing Fulcrum like this might not be an issue. I am sure that by the time this discussion is over, we will have heard from anyone that has an issue with this idea. > > 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. I would certainly rather not have to write anything. We will just leave this as "logging needs to be addressed". > > > 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. I like the idea on conversion on the fly much better. If we are going to write logic that will be able to convert it once, we can certainly use that same logic to convert it on the fly. Of course, it would just be a temporary solution. > > > 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. > I only picked ECM because it is released. I am fairly new to Avalon (less than a week). If there is a better solution, I am all for it! We just need to pick a direction. > > 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 take a look at Merlin. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
