On Thu, Jan 09, 2003 at 01:09:57PM -0800, Daniel Rall wrote: > I'd also be a fan of seeing the TurbineXxx classes go. I'm +1 on > deprecating them today and removing them in a while. I'm unsure > about the interface classes -- I suppose that those should > probably stay.
Given that Fulcrum hasn't had a release and we're abandoning the singleton model of TurbineXxx classes, could we bump the version number to b3-dev and just remove them (them being the TurbineXxx singleton classes, the Service/BaseService and ServiceBroker/BaseServiceBroker)? (Hear me out below...a stark removal of them really does not place much burden on clients of Fulcrum) As I see it, there are three things the user sees when interacting with Fulcrum: 1) Properties-based configuration file 2) TurbineServices.getInstance().getService(name) lookup 3) Service interfaces So, when going to Avalon: 1) Changes to XML-based configuration, but we can probably set up an adaptor that reads in the services.xxx.yyy style and converts it to an Avalon Configuration object. So this would be transparent to users, e.g. TurbineResources.properties will still work just fine, but services would be converted completely over to the Avalon configuration style. 2) Changes to something like FulcrumContainer.lookup(ServiceInterface.ROLE). This would not be transparent, but it is a straight forward conversion. (Note that FulcrumContainer just composes ECM or Fortress and forwards the lookup to it; also note that FulcrumContainer would have methods like initialize(String newXmlFile) and initializeOldConfiguration(String oldPropertiesFile)). 3) Stay the same, except NAME is changed to ROLE. None of the changes involve architectural changes in the clients of Fulcrum. And so if these changes are well documented, e.g. on the wiki as UpgradingToAvalonizedFulcrum, I think it is safe to do a straight conversion instead of worrying about the baggage of deprecation and backwards compatibility (which removes a lot of the potential elegantness that Avalon promises). Also as a part of this stark conversion, service implementations would no longer have Service/BaseService to implement/inherit, but the conversion over to Avalon lifecycles interfaces is straightforward and is much easier to do in one step than implementing both the Fulcrum lifecycle and Avalon lifecycle interfaces. Alternatively, if this scares people, can I have a branch to do exactly this? I've been going through code and the itch to just do away with Service/BaseService/ServiceBroker/BaseServiceBroker and start with clean Avalon is just killing me. Thanks, Stephen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
