on 11/25/2000 2:44 PM, "Raphael Luta" <[EMAIL PROTECTED]>
wrote:
> 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).
Uh. Why are you not using the TDK as your basis? You really should be using
that.
> 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)
If you do this based on TOMCAT_HOME or some other variable to the webapp
directory it isn't an issue because you can use Ant to do the substitutions
for you during new application creation time in the TDK. We could add
something like this to the TDK very easily if it doesn't already exist.
> 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.
Right. The above solution that I suggest would work perfectly though.
> 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.
I like where you are going with that (having a pluggable config solution)
regardless of how I don't think it is the right overall solution to your
problem. :-)
-jon
--
twice of not very much is still a lot more than not very much
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
