Initialization API & Improved WebMacro - summary
this code is not yet in CVS, the patch is available at:
http://suokong.e-point.pl/turbine/download/InitAPI_WebMacro.diff.gz
(new version uploaded 8 Aug, 1200GMT)
* existing instalations
- this patch should not break any existing instalations. Patch the source, build
turbine.jar
drop it into your webapp WEB-INF/lib, and you are running!
- taking advantage of imporved WebMacro support requires changes to properties files
(see below)
- improved WebMacro support doesn't require any changes to webmacro.jar (tested with
CVS WM)
* new foundation of services in Trubine
- clean layout, emphasising diffrent aspects of servies in different
classes/interfaces
(see javadocs for org.apache.turbnie.services package)
- multi-phase service initialization (on startup and/or before first use)
- possibility to send differnt object that services could need to initialize
(currently Turbine class sends ServletConfig and RunData)
- ease of implementation ServiceBrokers that allow use of Turbine services outside
of running Turbine servlet (you need to override two methods, one for creatting
mapping between service names and implementing classes, and another for providing
services with their properties)
* changes to specification of services in TurbineResources.properties
- to install a service add the following entry:
service.MyService.classname=com.mycompany.myapp.MyServiceImpl
- to define properties for your service add the following entires:
service.MyService.greeting=Hello! I'm Jan B.
service.MyService.defaultAction=beep
* changes to existing Services
- Service interfaces define a constant containing the name used in
TurbineResources.properties
for the classes requesting instantiation of the service. These names were not
consitent,
for example FreeMarkerService.SERVICE_NAME, WebMacroService.WEBMACRO,
XmlRpcService.XMLRPC_SERVICE_NAME
all these names were changed to SERVICE_NAME
- *PROPOSAL* I suggest that we should change these constants, and the settings in
TR.p, that the names
of services don't contain the prefix 'Turbine'. My reasoning for that is: when I
use
TurbineServices.getService(WebMacroService.SERVICE_NAME), I request SOME
implementation of WebMacroService,
not neccesserily TurbineWebMacro class, therefore WebMacroService.SERVICE_NAME
should read 'WebMacroService'
not 'TurbineWebMacroService'. Additionaly it would make entries in TR.p shorter :)
This change is a bit problematic, because it doesn't give much gain, and would
break existing instalations,
because people would have to update their properties files.
- initialization of JNDI contexts is now performed in
TurbineNamingService.init(RunData), thus making
InitContextsAction module obsolete.
* changes to WebMacro support
- Old style WebMacro (WebMacro.properties in the classpath, and absoulte path in
WM.p/TemplatePath) continues
to work
- To specify the location of WebMacro.properites inside TurbineResources.properties
add a following entry:
service.TurbineWebMacroService.properties=/WEB-INF/etc/WebMacro.properties
Note that the path is relative to webapp root when running under Tomcat!
- To specify the paths to your templates in TurbineResources.properties add the
following entries:
service.TurbineWebMacroService.templates=/WEB-INF/templates
service.TurbineWebMacroService.templates.provider=org.apache.turbine.services.webmacro.TurbineTemplateProvider
you should also remove org.webmacro.resource.TemplateProvider from Providers entry
in WebMacro.properties file.
The path is alos relative to webapp root when running under Tomcat.
* checking in
- I'm waiting on any comments / criticism / patches !
- Unless there are any serious problems, I'm going to check this code in on friday.
Rafal
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
