cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <jer...@media.demon.co.uk>
Subject Re: web.xml init-params
Date Tue, 18 Nov 2003 13:03:51 GMT

On 18 Nov 2003, at 12:49, Geoff Howard wrote:

> Jeremy Quinn wrote:
>
>>
>> On 17 Nov 2003, at 21:27, Upayavira wrote:
>>
>>> Jeremy Quinn wrote:
>>>
>>>> Hi All
>>>>
>>>> I am trying to access init-params from web.xml, in a FlowScript, 
>>>> and all I get are nulls.
>>>>
>>>> I try this:
>>>>
>>>> var smtpHost = cocoon.context.getInitParameter ("smtp-host");
>>>>
>>>> with this in my web.xml:
>>>>
>>>>     <init-param>
>>>>       <param-name>smtp-host</param-name>
>>>>       <param-value>smtp.host.org</param-value>
>>>>     </init-param>
>>>>
>>>> I can't get any of the init-params from web.xml ....
>>>>
>>>> Any suggestions?
>>>
>>>
>>> 'Fraid it's not that simple. If you look at the code in the 
>>> CocoonServlet, I think you'll see that each init param is handled 
>>> independently, with the init parameters being put into the app 
>>> context within the init method. Unless you're prepared to subclass 
>>> the CocoonServlet, I think you're going to have to find another way 
>>> of getting hold of your initialisation parameters.
>>
>>
>> Thanks for your reply Upayavira.
>>
>> This sounds very odd .... is it really necessary for the selection of 
>> ALL parameters to be hard-coded into the CocoonServlet Class?
>>
>> I can understand that CocoonServlet needs to carefully marshal 
>> parameters it expects .... but why is it effectively blocking access 
>> to all other parameters?
>>
>> Incidentally, attempting to access *any* standard init-param from 
>> flowscript eg. :
>>
>>     cocoon.context.getInitParameter ("configurations");
>>
>> results in a 'null'. This seems very wrong to me .....
>>
>>> Upayavira wrote:
>>> You could use a global variable in the sitemap <global-variables/> 
>>> element, and then pass the value, using the global: input component, 
>>> into the flow as a parameter. Just a thought.
>>
>>
>> ( Yes, and/or we could use an input-module setup in cocoon.xconf .... 
>> etc. etc. )
>>
>> Even though it does not really matter in the end, where this is setup 
>> ..... I still think web.xml is the appropriate place for this kind of 
>> configuration .... AFAIU this is implied in the design of the Servlet 
>> spec.
>>
>>                     ---------------------->8----------------------
>>
>> Incidentally, this is what I am trying to do .... several people 
>> (it's a distributed workforce) work on developing the same webapp, 
>> which they run on their own machines, plus there is a development 
>> server generated from the same source.
>>
>> There is a set of properties that is always going to be different for 
>> each user (plus the server).
>> ie. the location of $COCOON_HOME, the SMTPHost to use etc. etc.
>>
>> The place to keep these individual properties for the build process 
>> is in each users' individualised 'local.build.properties'.
>>
>> A set of build scripts install (and copy updates of) the webapp into 
>> a cocoon instance (say $COCOON_HOME/build/webapp/blah).
>>
>> The build process uses these parameters to customise the webapp build 
>> (install/update) for each user. In the case of $COCOON_HOME, the 
>> parameter is read from the environment variable and used by Ant to 
>> decide where to copy stuff. In the case of the 'smtp-host' param, 
>> which needs to be patched into Cocoon (rather than just be used by 
>> Ant), we were going to use your recently modified XConfPatch Task, 
>> which can read Ant Properties to insert this into web.xml (as we do 
>> already, though unparameterised, to cocoon.xconf etc.).
>>
>> Let's say, some developers want to work directly within 
>> $COCOON_HOME/build/webapp/blah, to save making an Ant update for each 
>> modification .... they would use another build-target to copy changes 
>> back into the webapp's repository/sandbox.
>>
>> If we were writing build scripts that modify our own webapp files (as 
>> opposed to Cocoon's built files) we run the risk of copying (and 
>> subsequently committing) these localised changes.

Thanks for your feedback, Geoff.

> Perhaps I'm dense,

I strongly suspect you are NOT :)

> but I don't understand how editing web.xml is any different in this 
> scenario.

My feeling is that once the webapp is _deployed_ (and we walk away) the 
client would expect to be able to edit this particular parameter in 
web.xml, rather than cocoon.xconf. But this is just a gut-feeling ....

> Still, I'd love to hear if there is a specific reason web.xml 
> parameters were excluded from access.

Me too :)

> The biggest reason I can surmise is that Cocoon is not a servlet.  It 
> is accessible from a servlet environment, but the environment is 
> abstracted.

There is _some_ sense to that ....

> Currently there is only one other environment - the CLI (command 
> line).  But in theory one could create an SMTP environment, a JMS 
> environment, an IM environment, etc. etc.   As such web.xml and the 
> servlet spec shouldn't be hardcoded into the main environment 
> abstractions.  Now, givent that there doesn't seem to be a necessity 
> to exclude access to web.xml parameters in the _servlet_ environment. 
> WDOT?

Well ... you know what I think ;)

regards Jeremy

Mime
View raw message