You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Jeremy Quinn <je...@media.demon.co.uk> on 2003/11/17 22:11:35 UTC
web.xml init-params
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?
thanks
regards Jeremy
Re: web.xml init-params
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
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
Re: web.xml init-params
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On 18 Nov 2003, at 13:04, Upayavira wrote:
> 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.
>
With the help of the changes to XConfPatchTask, allowing it to use Ant
Properties, I have changed my builds so that my projects are run from
their checkout folder, not copied into Cocoon.
I have attempted to document our build process here :
http://wiki.cocoondev.org/Wiki.jsp?page=ProjectBuilding
HTH
regards Jeremy
Re: web.xml init-params
Posted by Upayavira <uv...@upaya.co.uk>.
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?
>
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 '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.
>
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.
Upayavira
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: web.xml init-params
Posted by Vadim Gritsenko <va...@verizon.net>.
Geoff Howard wrote:
> Currently there is only one other environment
... in the CVS ...
> - the CLI (command line). But in theory one could create an SMTP
> environment, a JMS environment, an IM environment, etc. etc.
We have working JSR168 environment.
> 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?
As I mentioned in other email, it's already there:
org.apache.cocoon.environment.Context.getInitParameter()
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: web.xml init-params
Posted by Geoff Howard <co...@leverageweb.com>.
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.
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_
environment.
WDOT?
Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: web.xml init-params
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On 18 Nov 2003, at 12:53, Vadim Gritsenko wrote:
> Jeremy Quinn wrote:
>
>>
>> Incidentally, attempting to access *any* standard init-param from
>> flowscript eg. :
>>
>> cocoon.context.getInitParameter ("configurations");
>
>
> Why don't you use
> org.apache.cocoon.environment.Context.getInitParameter()? It's
> implementation, HttpContext, delegates to the
> javax.servlet.ServletContext.
>
> (are you trying to use Avalon context instead of environment
> (==Servlet) context?)
Many thanks for pointing this out Vadim.
regards Jeremy
Re: web.xml init-params
Posted by Vadim Gritsenko <va...@verizon.net>.
Jeremy Quinn wrote:
>
> Incidentally, attempting to access *any* standard init-param from
> flowscript eg. :
>
> cocoon.context.getInitParameter ("configurations");
Why don't you use
org.apache.cocoon.environment.Context.getInitParameter()? It's
implementation, HttpContext, delegates to the javax.servlet.ServletContext.
(are you trying to use Avalon context instead of environment (==Servlet)
context?)
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: web.xml init-params
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
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
Re: web.xml init-params
Posted by Upayavira <uv...@upaya.co.uk>.
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.
>
> Sorry.
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.
Regards, Upayavira
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: web.xml init-params
Posted by Upayavira <uv...@upaya.co.uk>.
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.
Sorry.
Upayavira
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org