Issue:
======
I'm currently tryng to package Jetspeed as a distributable WAR file
with a complete set of functionalities (most notably an embedded
Hypersonic DBMS).
After trying to fix all the components that use file properties
in order to be entirely WAR-relative, I found that what I was doing
was wrong and what I really needed was a different TurbineResources
implementation with run-time variable expansion capability.
Improved TR.props syntax
========================
In another word, what I'd like to have in TurbineResources is
the bility to use the following variables in the properties file
that would get expanded at runtime when reading the properties:
${webapp.url} = ServletContext.getResource("/");
${webapp.dir} = ServletContext.getResource("/") converted in a
java.io.File compatible syntax;
${web.root.dir} = ServletContext.getRealPath("/");
Thus I can have in my TR.prop file:
logfile=${webapp.dir}/WEB-INF/log/turbine.log
database.default.url=jdbc:HypersonicSQL:${webapp.url}/db/jetspeed
...
without trying to include portability workaround in every component.
The only trouble with this proposal is that it doesn't seem possible to
implement it in Turbine ! (At least I haven't found a way)
Analysis of the resources service
=================================
I looked at the existing resources service for a way to implement this
scheme. Unfortunately, the TurbineResourcesService is very peculiar since
it's not loaded by the TurbineServices but instead statically created
from the Turbine servlet init() with a setPropertiesFileName() call and
does not use the standard init(ServletConfig) call of the service API.
Without access to a ServletContext, I can't really implement my extended
Resources class.
Of course, the special status of the resources service is understandable
since TurbineResources must be accessible for TurbineServices to load
service implementation mappings...
Standard chicken and egg issue.
Proposal: Turbine properties initialization sequence
====================================================
In order to solve this issue and actually allow the resources package
to be used as a pluggable implementation service, I propose the following
changes in Turbine:
Add a new static TurbineServices.getInstance(Hashtable) method and a
new BaseServiceBroker(Hashtable) constructor. The argument Hashtable
would be used to initialize the mapping member of BaseServiceBroker.
Define a ResourcesService interface which would declare all
the getXXX() methods available in TurbineResources.
Modify TurbineResources so that it is only a static accessor on a
ResourcesService.
Reimplement a TurbineResourcesService to provide the combined
functionalities on TurbineResources and TurbineResourcesService
(keeping the static initialization method for backward compatibility)
Modify the Turbine servlet to adopt roughly this initialization
code :
public void init(ServletConfig config) throws ServletException
{
super.init(config);
String resources = config.getInitParameter("classname");
if ( resources == null ) {
resources = "org.apache.turbine.services.resources.TurbineResourcesService"
}
// create a bootstrap mapping for the TurbineServices class
Hashtable mappings = new Hashtable();
mappings.put("services.TurbineResourcesService.classname",resources);
TurbineServices.getInstance(mappings).initServices(config);
...
}
The initial mapping Hashtable should be enough to bootstrap
TurbineServices and load the TurbineResources implementation
selected which will use the ServletConfig object passed to its
early init method to retrieve any parameter needed.
Such a architecture allows the Turbine framework to have a pluggable
persistent config system. For example, other implementations may allow
properties retrieval from a JNDI repository, a DBMS, ...
If there are no objections to this proposal, I'll have patches
available next week.
--
Rapha�l Luta - [EMAIL PROTECTED]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
