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 suggestions
regards Jeremy
smime.p7s
Description: S/MIME cryptographic signature
