Jeremy Quinn wrote:Don't really know. I'm kinda new to the web.xml and app context stuff.
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?
Haven't looked at the code, but from my understanding, I can't see how this would work. Could be wrong though.
Incidentally, attempting to access *any* standard init-param from flowscript eg. :
cocoon.context.getInitParameter ("configurations");
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.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.
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.
Upayavira
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
