I went through your list of service and marked which ones I have ported and any notes about them. I wasn't trying to improve functionality at all, they should be pretty backwards compatible.
Sounds good.
The big change is in the configuration. Right now, the configuration is done via XML properties, not a .properties file. However, something that would be nice would be something that handed Avalon a commons-configuration Configuration object, or was backed by that, so that configuration could come from anywhere. I don't think that the Avalon configuration class is very "rich" in functionality.
I agree, but I thought that someone (John?) had already implemented an Avalon facade for the Commons Configuration API. The properties file strikes me as a very important place to attempt to maintain backwards compatibility.
In the list below, is the left hand column where you took the code from? If so, are cells labelled "Tubine" from the 2.3 series?
FactoryService Fulcrum
PoolService Fulcrum No functional changes, however maybe convert to using
commons-pool?
MimeTypeService Fulcrum No functional changes
SchedulerService Fulcrum Only the in memory version done. I don't
really
want to keep the turbine/torque version of scheduler. I would
rather quit reinventing the wheel on
this one and use Quartz. There
is a quartz scheduler in plexus-components that
we could look at. I changed the API
to be more generic, but it needs
work. I don't really like it. It does have
unit tests though!
I'm +1 on dumping the old SchedulerService. I've used it on a couple occasions and been quite unhappy with API and implemention. JDK 1.3+ TimerTask APIs and Quartz appear to more than do the job.
UploadService Not Ported
Any particular snafus in porting UploadService?
SecurityService Fulcrum Lots of changes. However, via the Adapters, I
am
able to use it, backed by Hibernate in my Turbine app. The torque
stuff is really raw though.
Everything but the torque stuff has unit
tests.
GlobalCacheService Fulcrum No functional changes, but maybe should use JCS
as the engine?
Hrm. My experience with JCS to date leaves me feeling that it's overcomplex and underdocumented (an unhealthly combination). That doesn't mean there isn't useful code there, of course, I'd simply hesitate to base more code around it without some work (which I'm not willing to put in).
TemplateService Turbine
RunDataService Turbine
LocalizationService Fulcrum No functional changes
PullService Turbine
IntakeService Not Ported I have seen quite a few posts about using intake
outside of Turbine, so getting this properly packaged as an avalon
component would I think be very
popular.
I agree. This is for sure a popular one.
VelocityService Turbine EmailService n/a ScarabSecurity n/a ScarabCache n/a TorqueService Torque There is now a Torque component for Avalon that should be used. DatabaseInitializer n/a
I hope this helps clarify the differences. I think that anywhere where the API differences are too much to make all at once, you could write an adapter to handle those differences.
The last thing I'd want to see is adapters around adapters. :-) *kiss*
At a minimum, the use of Avalon is going to require some significant changes to how Scarab starts up. But, I think ditching the service broker for Avalon will pay off as more people understand avalon, and more components are available!
Yes, I'm very excited about dropping maintainence of our own service broker framework. My ideal vision is that all we're left with is an opportunity to contribute back design suggestions or bug fixes to the Avalon folks.
Can you describe what makes ScarabCache and ScarabSecurity special/different from their corresponding ilk in turbine/fulcrum land? Maybe we could take the best of both and merge them? One of the premises of rewriting the Security service was to be more flexible and provide most of the functionality needed for what ever custom Security model you need.
Of the above areas, I suppose I'm most familiar with use of the SecurityService. I try to avoid dealing with Scarab's caching. =)
I am on vacation till monday, (going to Madrid!), but I will try and get a nightly tarball of scarab and pore through it.
Sweet! My wife and her family have a place in Jijona (near Alicante on the southeast coast of Spain) which I dearly enjoy hanging out at. Have a good time in Madrid?
Assuming you'll eventually have time to look at Scarab's use of Fulcrum, I will make time to chat about any changes which should be made (especially simplifying changes).
- Dan
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 27, 2003 3:35 AM To: Turbine Developers List Cc: [EMAIL PROTECTED] Subject: Re: Need to deprecate services in T2.3?
"Eric Pugh" <[EMAIL PROTECTED]> writes:
I have made a lot of progress in the conversion process. Obviously things are done yet, but I would be very curious which services Scarab and Sourcecast use..
Scarab uses the following services:
FactoryService PoolService MimeTypeService SchedulerService UploadService SecurityService GlobalCacheService TemplateService RunDataService LocalizationService PullService IntakeService VelocityService EmailService ScarabSecurity ScarabCache TorqueService DatabaseInitializer
EmailService is basically a copy of VelocityService, but we needed a different configuration. I'm hoping that this is something that an Avalon container can help with.
The remaining 4 are custom Service implementations used in Scarab.
SourceCast uses a similar set (including XML-RPC), also with some of its own custom impls.
One of the services, BSF, I was thinking of ditching, as I can repackage it, but don't know how to use it.. I think it was a one off that went no where.
Sounds fine to me.
At any rate, if you want to look at the repackage stuff, I wouldn't mind another set of eyes looking at the code.
I'm not particularly fond of the repacking, actually -- it strikes me as unnecessary complexity. However, so long as it doesn't take too much of my time up mucking with the build, I'm not going to complain with you doing so much good work. I'm very happy to see jakarta-turbine-2 using jakarta-turbine-fulcrum.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
