cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject Re: web.xml init-params
Date Tue, 18 Nov 2003 12:49:36 GMT
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></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 ''.
> 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.

Perhaps I'm dense, but I don't understand how editing web.xml is any 
different in this scenario. 

Still, I'd love to hear if there is a specific reason web.xml parameters 
were excluded from access.  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.  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_ 


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message