Jason van Zyl <[EMAIL PROTECTED]> writes: >>> I also feel that a service to pick off the locale is a bit of >>> overkill in that there is a requirement for a service framework to >>> process a header. >> >> There would not be a requirement for the complete service framework, >> only for a single service (though the framework sure does make things >> easier). > > I can't say I understand that sentence. To run the service you need the > service framework do you not?
The only thing that the service framework currently provides is semi-clean singleton access and Service ExtendedProperties. If it wasn't for the Service getConfiguration() method, one could do the following: LocalizationService localization = new TurbineLocalizationService(); localization.init(); Locale defaultLocale = localization.getLocale(null); Even using getConfiguration(), one can do Service.setServiceBroker() to provide a the ExtendedProperties data. Not that I'd actually do that, it's just possible, that's all (and it used to be eaiser, btw). > And how does placing into a service the processing of a header > easier? It's a useful place to stick code--a utility class would work just as well. You love utility classes, right? ;) > Users who choose to use DefaultTurbineRunData will have to use > Fulcrum in order to parse a header. For parsing a header, the LocaleTokenizer class which I added recently could be used instead. That would remove any dependency on the services framework. However, getDefaultLocale() doesn't parse a header--it just grabs fields from TR.props and creates a Locale object. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
