You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Remy Maucherat <re...@apache.org> on 2003/10/15 16:23:52 UTC
[5.0] System properties in server.xml (and elsewhere)
Hi,
I think it would be possible, using a new rule, to allow system
properties inside server.xml (and possibly elsewhere) for attribute
values. This is the same as what is being done by Ant in its build
scripts. This would add an additional degree of configurability to Tomcat.
Actually, I wonder why this feature is not available in the digester
itself (I really got used to that feature over the years by using Ant).
Comments ?
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] System properties in server.xml (and elsewhere)
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Hi,
>
> I think it would be possible, using a new rule, to allow system
> properties inside server.xml (and possibly elsewhere) for attribute
> values. This is the same as what is being done by Ant in its build
> scripts. This would add an additional degree of configurability to Tomcat.
> Actually, I wonder why this feature is not available in the digester
> itself (I really got used to that feature over the years by using Ant).
>
> Comments ?
+1, of course.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] System properties in server.xml (and elsewhere)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Remy Maucherat wrote:
> Hi,
>
> I think it would be possible, using a new rule, to allow system
> properties inside server.xml (and possibly elsewhere) for attribute
> values. This is the same as what is being done by Ant in its build
> scripts. This would add an additional degree of configurability to
> Tomcat.
Makes sense to me.
>
> Actually, I wonder why this feature is not available in the digester
> itself (I really got used to that feature over the years by using Ant).
Because nobody ever asked, or contributed a patch to make it so :-).
>
> Comments ?
>
> Remy
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] System properties in server.xml (and elsewhere)
Posted by Henri Gomez <hg...@apache.org>.
Remy Maucherat a écrit :
> Henri Gomez wrote:
>
>>>> Do you speak about the ${xxx} properties as present in Tomcat 3.3.x ?
>>>
>>>
>>>
>>>
>>> Possibly. Basically, if you have a "foo.bar" sys property, you can
>>> put "${foo.bar}" in server.xml, and it will be replaced with the
>>> property value (like in Ant). I didn't know this was present in 3.3.
>>
>>
>>
>> Yes it was in TC 3.3.1 and you could also set the properties in the
>> command line if I recall well ;)
>>
>> http://jakarta.apache.org/tomcat/tomcat-3.3-doc/tomcat-ug.html#configuring_tomcat
>>
>>
>> ...
>>
>> In Tomcat 3.3.1, each attribute value may use the ant-style variable
>> substitution by using "${variable}" in the attribute string, i.e.
>> attribute="text${variable}text".
>
>
> Let me guess. James did code all that stuff aeons ago, right ? :-D
James ?
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] System properties in server.xml (and elsewhere)
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Wednesday, October 15, 2003 8:31 AM
Subject: Re: [5.0] System properties in server.xml (and elsewhere)
> Henri Gomez wrote:
>
> >>> Do you speak about the ${xxx} properties as present in Tomcat 3.3.x ?
> >>
> >>
> >>
> >> Possibly. Basically, if you have a "foo.bar" sys property, you can put
> >> "${foo.bar}" in server.xml, and it will be replaced with the property
> >> value (like in Ant). I didn't know this was present in 3.3.
> >
> >
> > Yes it was in TC 3.3.1 and you could also set the properties in the
> > command line if I recall well ;)
> >
> >
http://jakarta.apache.org/tomcat/tomcat-3.3-doc/tomcat-ug.html#configuring_t
omcat
> >
> >
> > ...
> >
> > In Tomcat 3.3.1, each attribute value may use the ant-style variable
> > substitution by using "${variable}" in the attribute string, i.e.
> > attribute="text${variable}text".
>
> Let me guess. James did code all that stuff aeons ago, right ? :-D
>
Well, the aeons ago part is right ;-). But it was the other ant person
(Costin).
The guts of the 3.3 replacement is
o.a.t.u.IntrospectionUtils.replaceProperties, so most of the code is already
in Tomcat 5.
> Remy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: [5.0] No sessions purged in Context with backgroundProcessorDelay
> 0?
Posted by Jan Luehe <Ja...@Sun.COM>.
Thanks for confirming, Remy!
I'll make these changes.
Jan
Remy Maucherat wrote:
> Jan Luehe wrote:
>
>> I may be totally wrong here, but it seems that if the
>> backgroundProcessorDelay property on a StandardContext is set to
>> something greater than zero (default is -1, inherited from
>> ContainerBase), the context's sessions are never purged.
>>
>> This is because in ContainerBase$ContainerBackgroundProcessor,
>> processChildren() is implemented as follows:
>>
>> for (int i = 0; i < children.length; i++) {
>> if (children[i].getBackgroundProcessorDelay() <= 0) {
>> processChildren(children[i], cl);
>> }
>> }
>>
>> So when invoked from the ContainerBackgroundProcessor of a
>> StandardHost, only the sessions of those StandardContexts with a
>> backgroundProcessorDelay <=0 will get purged.
>>
>> I think the assumption is that if a StandardContext has a
>> backgroundProcessorDelay > 0, it would have its own
>> ContainerBackgroundProcessor spawn at startup. However, unlike
>> StandardEngine/Host/Wrapper, StandardContext.start() does not invoke
>> super.start(), and therefore a ContainerBackgroundProcessor is never
>> created for a StandardContext.
>
>
> Arg, stupid me, I forgot about that. We need to add the code which
> starts the backgroud thread in StandardContext.start.
> So we need to call super.startThread() and super.stopThread. This
> doesn't seem too hard.
>
> Remy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] No sessions purged in Context with backgroundProcessorDelay
> 0?
Posted by Remy Maucherat <re...@apache.org>.
Jan Luehe wrote:
> I may be totally wrong here, but it seems that if the
> backgroundProcessorDelay property on a StandardContext is set to
> something greater than zero (default is -1, inherited from
> ContainerBase), the context's sessions are never purged.
>
> This is because in ContainerBase$ContainerBackgroundProcessor,
> processChildren() is implemented as follows:
>
> for (int i = 0; i < children.length; i++) {
> if (children[i].getBackgroundProcessorDelay() <= 0) {
> processChildren(children[i], cl);
> }
> }
>
> So when invoked from the ContainerBackgroundProcessor of a
> StandardHost, only the sessions of those StandardContexts with a
> backgroundProcessorDelay <=0 will get purged.
>
> I think the assumption is that if a StandardContext has a
> backgroundProcessorDelay > 0, it would have its own
> ContainerBackgroundProcessor spawn at startup. However, unlike
> StandardEngine/Host/Wrapper, StandardContext.start() does not invoke
> super.start(), and therefore a ContainerBackgroundProcessor is never
> created for a StandardContext.
Arg, stupid me, I forgot about that. We need to add the code which
starts the backgroud thread in StandardContext.start.
So we need to call super.startThread() and super.stopThread. This
doesn't seem too hard.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
[5.0] No sessions purged in Context with backgroundProcessorDelay > 0?
Posted by Jan Luehe <Ja...@Sun.COM>.
I may be totally wrong here, but it seems that if the
backgroundProcessorDelay property on a StandardContext is set to
something greater than zero (default is -1, inherited from
ContainerBase), the context's sessions are never purged.
This is because in ContainerBase$ContainerBackgroundProcessor,
processChildren() is implemented as follows:
for (int i = 0; i < children.length; i++) {
if (children[i].getBackgroundProcessorDelay() <= 0) {
processChildren(children[i], cl);
}
}
So when invoked from the ContainerBackgroundProcessor of a
StandardHost, only the sessions of those StandardContexts with a
backgroundProcessorDelay <=0 will get purged.
I think the assumption is that if a StandardContext has a
backgroundProcessorDelay > 0, it would have its own
ContainerBackgroundProcessor spawn at startup. However, unlike
StandardEngine/Host/Wrapper, StandardContext.start() does not invoke
super.start(), and therefore a ContainerBackgroundProcessor is never
created for a StandardContext.
Am I missing something here?
Thanks,
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] System properties in server.xml (and elsewhere)
Posted by Remy Maucherat <re...@apache.org>.
Henri Gomez wrote:
>>> Do you speak about the ${xxx} properties as present in Tomcat 3.3.x ?
>>
>>
>>
>> Possibly. Basically, if you have a "foo.bar" sys property, you can put
>> "${foo.bar}" in server.xml, and it will be replaced with the property
>> value (like in Ant). I didn't know this was present in 3.3.
>
>
> Yes it was in TC 3.3.1 and you could also set the properties in the
> command line if I recall well ;)
>
> http://jakarta.apache.org/tomcat/tomcat-3.3-doc/tomcat-ug.html#configuring_tomcat
>
>
> ...
>
> In Tomcat 3.3.1, each attribute value may use the ant-style variable
> substitution by using "${variable}" in the attribute string, i.e.
> attribute="text${variable}text".
Let me guess. James did code all that stuff aeons ago, right ? :-D
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] System properties in server.xml (and elsewhere)
Posted by Henri Gomez <hg...@apache.org>.
>> Do you speak about the ${xxx} properties as present in Tomcat 3.3.x ?
>
>
> Possibly. Basically, if you have a "foo.bar" sys property, you can put
> "${foo.bar}" in server.xml, and it will be replaced with the property
> value (like in Ant). I didn't know this was present in 3.3.
Yes it was in TC 3.3.1 and you could also set the properties in the
command line if I recall well ;)
http://jakarta.apache.org/tomcat/tomcat-3.3-doc/tomcat-ug.html#configuring_tomcat
...
In Tomcat 3.3.1, each attribute value may use the ant-style variable
substitution by using "${variable}" in the attribute string, i.e.
attribute="text${variable}text".
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] System properties in server.xml (and elsewhere)
Posted by Remy Maucherat <re...@apache.org>.
Henri Gomez wrote:
> Remy Maucherat a écrit :
>
>> Hi,
>>
>> I think it would be possible, using a new rule, to allow system
>> properties inside server.xml (and possibly elsewhere) for attribute
>> values. This is the same as what is being done by Ant in its build
>> scripts. This would add an additional degree of configurability to
>> Tomcat.
>> Actually, I wonder why this feature is not available in the digester
>> itself (I really got used to that feature over the years by using Ant).
>
> Do you speak about the ${xxx} properties as present in Tomcat 3.3.x ?
Possibly. Basically, if you have a "foo.bar" sys property, you can put
"${foo.bar}" in server.xml, and it will be replaced with the property
value (like in Ant). I didn't know this was present in 3.3.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] System properties in server.xml (and elsewhere)
Posted by Henri Gomez <hg...@apache.org>.
Remy Maucherat a écrit :
> Hi,
>
> I think it would be possible, using a new rule, to allow system
> properties inside server.xml (and possibly elsewhere) for attribute
> values. This is the same as what is being done by Ant in its build
> scripts. This would add an additional degree of configurability to Tomcat.
> Actually, I wonder why this feature is not available in the digester
> itself (I really got used to that feature over the years by using Ant).
Do you speak about the ${xxx} properties as present in Tomcat 3.3.x ?
A big +1
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] System properties in server.xml (and elsewhere)
Posted by Tim Funk <fu...@joedog.org>.
+0 (I'd be +1 if I could actually be of help - but love the idea)
-Tim
Remy Maucherat wrote:
> Hi,
>
> I think it would be possible, using a new rule, to allow system
> properties inside server.xml (and possibly elsewhere) for attribute
> values. This is the same as what is being done by Ant in its build
> scripts. This would add an additional degree of configurability to Tomcat.
> Actually, I wonder why this feature is not available in the digester
> itself (I really got used to that feature over the years by using Ant).
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org