Rafal Krzewski wrote:
>
> > The files are located at:
> > http://locus.apache.org/~raphael/turbine/
> >
> > This patch allows the resources service implementation to be selected
> > by a startup servlet parameter.
> > However, people wishing to implement new resources service implementation
> > should carefully read the limitations described in ResourcesService.java
> > because there a lot of Turbine functionalities are unavailable to this service
> > since it's initialized in a bootstrap mode.
> >
> > An alternate implementation of the resources services can be found in the
> > Jetspeed CVS.
>
> What is the difference? Do you think that Jetspeed's implementaition is
> generic
> enough to be included in Turbine, or can easily be made generic?
>
The Jetspeed implementation does run-time variable substitution for
the following variables:
${webapp.dir} - webapp root dir
${webroot.dir} - web document root dir
${jvm.dir} - jvm root dir
These variables values are resolved from the context but use Servlet 2.1 or 2.2
methods. So even though the class as such is quite generic it does not fit
with the servlet 2.0 support Turbine is still trying to provide.
> > I've taken great care to be backward compatible with the previous implementation
> > so the old TurbineResourceService.setPropertiesFileName() still works but is
> > deprecated.
>
> If there is a meaningful way of initializing Turbine both in Servlet
> environment
> and standalone (through org.apache.turbine.util.TurbineConfig class) we
> can
> safely remove this method.
>
Just have a look at how I implemented the setPropertiesFilenaem() method:
it uses the TurbineConfig to bootstrap the services.
> > One caveat:
> > In order to be backward compatible, I had to make the InvalidResourcesException
> > a RuntimeException so that exising code does not need to explicitely catch
> > this exception but the Turbine servlet can if it wants.
> >
> > This is not very good but I trust Rafal will make this service compliant
> > to the TurbineException model :)
>
> I find your approach perfectly valid. The application code has the right
> to expect
> that the system is correctly configured. The ResourcesService should
> throw a
> Runtime-flavour exception, and the Servlet will inform the administrator
> that
> something's screwed up.
> All I need to do is to introduce TurbineRuntimeExcption into your code,
> and wrap
> any underlying exceptions into that.
>
Yes and no. If you consider that the resources should be complete upon
the start of the application, then the use of RuntimeException is valid
but if you consider the cases we discussed with Jason where the resources
can be completed after the initialization (by querying an administrator to
provide the correct values), such an exception really becomes an
applicative exception and should be processed by any code using such a
service.
>
> I'm thinking about 'the great reanaming' of the services you recenlty
> proposed.
> Did you know that I proposed the very same thing a few months ago? I
> didn't
> quite have the nerve to do that, as it would break *all* Turbine apps
> around.
> This definetely needs to be done before the release, so I'll do that as
> a part
> of my current work on services framework.
>
I've tried to use it in Jetspeed and I thinks it works quite well, except for
one thing:
the static accessor class and service interface should not be in the package of
the implementation but in the services package.
For example, for a 'GlobalCache' service, the default service template
should be IMO:
org.apache.turbine.services.GlobalCache - static accessor
org.apache.turbine.services.GlobalCacheService - service definition
org.apache.turbine.services.globalcache - default service impl package
org.apache.turbine.services.globalcache.PersistentGlobalCacheService
- example impl of the service
Putting the accessor in services package allows user to write :
import org.apache.turbine.services.GlobalCache;
rather than
import org.apache.turbine.services.globalcache.GlobalCache;
which is redundant.
It allows people to use:
import org.apache.turbine.services.*;
and access any services they wish.
Also the accessor and the interface should work with any implementation,
whatever their package name so it makes sense to put them direcly under
the services package.
If the interfaces are all in the services package, introspection and
naming conventions can also be used to determine all the default available
services.
--
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]
