cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira>
Subject Re: web.xml init-params
Date Tue, 18 Nov 2003 13:04:49 GMT
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></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?
Don't really know. I'm kinda new to the web.xml and app context stuff.

>> Incidentally, attempting to access *any* standard init-param from 
>> flowscript eg. :
>>     cocoon.context.getInitParameter ("configurations");
Haven't looked at the code, but from my understanding, I can't see how 
this would work. Could be wrong though.

>> 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.
I would always consider the root sitemap to be a part of Cocoon's 
config, and put the global stuff there (I assume it is inherited). Thus 
this becomes a part of your Cocoon webapp creation.

Then I mount a site into that root sitemap which is in an entirely 
different place. It is this site that I would be sharing with others, 
not the Cocoon webapp itself. For that, I would share a build process 
that creates a Cocoon webapp with all the necessary libs, patches, etc 
ready done.

> 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).  

As it is at present, it is the responsibility of the user (the servlet, 
the bean, etc) to provide to Cocoon an AppContext with certain 
properties in it. One of the things that the cli.xconf does is to offer 
a way to supply these parameters to Cocoon. Quite a few get written into 
the AppContext.

The init-params are plain text. The AppContext can contain any Java 
object. How about having an init parameter that points to an XML file 
that is loaded into a Configuration object. That can then be accessed 
directly via the context. So your configuration is external from the 
web.xml, but pointed to by it. Just a thought.

> 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?

It is dependency upon parameters that is a problem, not access to them. 
If the servlet starts depending upon a particular parameter, it can 
break the CLI and other environments until they have a way to supply it.


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

View raw message