FulcrumContainer is based on ECM. My intention is to use a released container and concentrate on converting the individual pieces. I assume switching to Plexus or any of the other next-gen containers will be reasonably straightforward from there. One possible problem is the use of the ThreadSafe interface, which is used with ECM to get singleton-like behavior. This matches fairly well with how fulcrum's TurbineServices worked. I've seen that this interface is deprecated, but I don't know why.
john mcnally On Mon, 2002-11-04 at 11:09, Peter Courcoux wrote: > John, > > Which container are you using, ECM. Plexus? > > Peter > > On Mon, 2002-11-04 at 18:48, John McNally wrote: > > I have committed several "services" coverted to avalon components. I > > have converted all but schedule, upload, xslt, and xmlrpc. I have > > modified TurbineServices so that it will work with the new component > > versions. I have also retained the old property file style > > configuration along with the ability to configure using an xml file. > > The reason for following this path is to allow current fulcrum users to > > update with as little change to their application as possible. If your > > application uses services where you have subclassed fulcrum services > > they will now be avalon components. If your application has its own > > fulcrum services, they can still be used alongside the converted > > components. The only rule is that the avalon components and services > > must be independent. So if you have a service that uses the factory > > component for example, you will have to convert that service > > immediately. > > > > I will commit some changes to t3 that will use allow it to use the > > latest fulcrum as soon as a fulcrum version is available for download by > > maven. I'm not sure how we should mark milestones on this path. > > Fulcrum is currently tagged 3.0-b2-dev. The beta's assumed little > > change before a release to go with t2.2. I'm not sure that we want to > > continue the beta numbering. Something like fulcrum-avalon-x where > > x=1,2,3,... might be better. Since the components might eventually move > > to a different repo, I don't know that there will be an official > > release, but I still think it will be useful to have a few milestone's > > as the conversion continues and before the components are possibly made > > independent. Anyone have an opinion here? > > > > I tagged the repo with PRE_AVALON for anyone wishing to grab a snapshot > > prior to the conversion or branch to continue the beta's if that is > > desired. > > > > Other than the few services left, one thing that I have not sorted out > > is logging, so the logging is now going to standard out. > > > > john mcnally > > > > > > -- > > To unsubscribe, e-mail: <mailto:turbine-dev-unsubscribe@;jakarta.apache.org> > > For additional commands, e-mail: <mailto:turbine-dev-help@;jakarta.apache.org> > > -- > Peter Courcoux > > PGP key ID : 2E50A3C8 > Telephone : 01923 661488 > Mobile : 07880 605626 > > > > -- > To unsubscribe, e-mail: <mailto:turbine-dev-unsubscribe@;jakarta.apache.org> > For additional commands, e-mail: <mailto:turbine-dev-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:turbine-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:turbine-dev-help@;jakarta.apache.org>
