Jason van Zyl wrote:
> I would like to start a discussion on the feasibility
> of turning Turbine services into plugins, or blocks to
> to use Avalon terminology.
>
> The basic idea would be to have a directory where service
> plugins are picked up when a Turbine application is
> started. We would have to deal with dependencies among
> services and configuration issues, but I think we could
> borrow a lot from Avalon as this concept is already
> implemented and working in Avalon.
Hell, I have no idea what is the problem here.
Turbine services are perfectly pluggable as of today.
If your code depends on the service interface or the facade class
you can swap the implementation of the service changing only TR.props
file.
I thought that it was a really obvious fact, so I'm surprised that
nobody on the list reacted.
And yes, we are able to deal with service dependencies, no problem.
> Avalon has a set of core blocks, and in much the same
> way Turbine would have a set of core services that could be
> provided as standard fair in the Turbine distribution.
> But I think this would provide a great way to add
> third party functionality to Turbine in very easy
> manner. We could provide a clean set of build tools
> for making services which we could use for the core
> Turbine services as well.
In our project we use a bunch of our own services, as well
as custom replacements for Turbine ones.
I don't know the details of Avalon, but I understand that there is
a lot of convergence between Avalon and Turbine service framework.
Service framework has some rough edges (and will have some more
once I stuff the logging service in) but it's a decent piece of
software in itself. Of course it might be justifable to throw it away
and replace it with Avalon, but I don't know enough about Avalon
to judge it now.
Lately, I noticed that we need to introduce the ResourceService and
LoggingService interfaces into the service framework, because the
ServiceBroker classes depend on them.
The bootstraping of the service system should be cleaned up and moved
into BaseServiceBroker class.
There are some things related to old
TurbineResources.setPropertiesFilename()
(or whatnot) method, but they are badly broken. Using them will result
in
an incomplete/multiple startup and possibly other breakage. Using
TurbineConfig(dir, props) should work.
Another thought about Services:
Think about moving the Turbine.doGet() functionality into a service
called
WebService.
Turbine servlet would be reduced to initializing the service broker
using
ServletConfig object, and otherwise it would use the system's configured
WebService implementation to do the work.
> I think this would also help with the current layout
> of the packages. I'm personally not very keen on the
>
> org.apache.turbine.services.X
> org.apache.turbine.util.X
>
> layout that has evolved. I think all the code for
> service should be together. Utilities for a particular
> service, that are required for the service to work, are
> really part of the service and I think that code should
> the code should be grouped together.
>
> I think this organization would be easier to follow,
> as everything pertaining to a service would be together,
> and would definitely allow an easier migration to
> services as plugins.
+1. We have way too many packages.
--
Rafal Krzewski
Senior Internet Developer
mailto:[EMAIL PROTECTED]
+48 22 8534830 http://e-point.pl
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
