> > I'd rather start hacking on the sources instead of chasing them around,
> > so I'd appreciate some pointers....

> here is the info...

CVS worked OK. I checed out the latest WebMacro and it worked fine
for me (standard WebMacroSite stuff).

Instead of starting hacking right away, I took a litle time to think (which
is usualy a good thing to do) and I figured out, that we could get the 
desired behaviour (WebMacro.properties in an arbitrary location inside
webapp and template path relative to webapp root) without modyfing
WebMacro at all!
This can be done by modyfing TurbineWebMacroService init. 
We could use WM(String config) to pass WebMacro the location
of the config file, reading the path from the init arg and translating
using getRealPath, exactly the same way as we do with our
config file. Then we could use
ResourceMap rm = ((ResourceBroker)broker).getProvider(Broker.CONFIG);
to get access to WebMacro's config.
Then, we could get() TempatesPath, split it, translate each part with
getRealPath, concatenate and put() it back into the config.
We could also define an additional parameter in WebMacro.properties,
which would indicate if this translation should be performed or not.
All I need to know right now is how do I access Turbine servlet's ServletConfig
object inside TurbineWebMacroService.init() method. 

> > One more thing - if we consider giving the location of 
> WebMarco properties
> > to Turbine servlet, shouldn't we provide the parametrs as
> > Turbine.properites and WebMacro properties respectively?
> 
> I'm still not sure what you are getting at here. would you 
> want the name to
> look for be "Turbine.properties" because you have 
> "WebMacro.properties"???
> 
> We had some strange problem in the past with having a servlet 
> named Turbine
> and Turbine.properties as well. I forget the entire nature of 
> the problem,
> but we renamed Turbine.properties to 
> TurbineResources.properties a long time
> ago and I don't see a reason to go back now.

Right now have single init parameter called 'properties'. If we wish to have
two parametrs now, we should give them meaningful names. I named 
the parameter 'Turbine.properties' and it worked fine under Tomcat. 
Please note that it doesn't affect the name of the config file itself.
How should we name these parameters then?

Rafal



------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
Problems?:           [EMAIL PROTECTED]

Reply via email to