Re: OT: Question regarding the listeners in the upcoming releases.

[Christopher Schultz]

Jon,

On 7/7/23 15:46, jonmcalexan...@wellsfargo.com.INVALID wrote:

Thank you Chris. I will look into Manager + JMXProxyServlet. Dumb
question, but does this require the Manager.war to be deployed (Isn't
that just to get to the UI?)
Yes, the Manager application must be deployed. You do not have to allow 
any users to use the GUI, though, if you don't want to give users the 
required role(s).



or does it call the Catalina Manager servlet directly?

The servlet is in the Manager application. It's not in the Tomcat core.


Is there any documentation around this type of setup?


Yep: have a look at the Manager application docs and let me know if 
something isn't clear. The docs are kind of thin, so if you think there 
is room for improvement, I'd be happy to have you augment what's there 
and I can commit a docs-update.


-chris


-Original Message-
From: Christopher Schultz 
Sent: Friday, July 7, 2023 2:05 PM
To: users@tomcat.apache.org
Subject: Re: OT: Question regarding the listeners in the upcoming releases.

Jon,

On 7/7/23 1:06 PM, jonmcalexan...@wellsfargo.com.INVALID wrote:

Yes, I'm aware that JMX may be the easiest method, however to use it
means modifying the JAVA_OPTIONS as well as having a username and
password as well as to meet our internal requirements, an ssl
certificate for the jmx connection.

You can use Manager + JMXProxyServlet which IMHO is way better than
"regular JMX"... for all the reasons you mention above.


What I'm looking for, if possible, is the addition of a
connector/valve, whatever method, in the server.xml. My thinking would
be to have it only accessible via localhost and not on the general
network. Again, something that can query and put the results out for
Elastic to ingest and make use of.

You can do this with Manager + JMXProxyServlet and no new code needs to
be written (other than your script to request the data and push it to Elastic).

-chris


-Original Message-
From: Christopher Schultz 
Sent: Friday, July 7, 2023 8:39 AM
To: users@tomcat.apache.org
Subject: Re: OT: Question regarding the listeners in the upcoming

releases.


Jon,

On 7/6/23 16:22, jonmcalexan...@wellsfargo.com.INVALID wrote:

I have a question which is based around the idea of the new
Listeners that are being introduced in the upcoming releases. This
is based on something I’ve been thinking on for the last 6 to 9 mos.
Would it be possible to have a Listener that could output stats for
the Tomcat Instance, similar to what you would see in the Manager

application?

Not wanting any of the actual Manager functionality, just the status
reporting features. Something that could be consumed by Elastic to
go into a dashboard showing Instance/Application health? I really
don’t want to deploy the Manager Application just to get this type of

data.


Thanks. I know this is a long shot question and this is where NOT
being a developer blows. 


I would do this using JMX from a remote querying agent, at whatever
interval you want. No Listener required.

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: OT: Question regarding the listeners in the upcoming releases.

[jonmcalexander]

Thank you Chris. I will look into Manager + JMXProxyServlet. Dumb question, but 
does this require the Manager.war to be deployed (Isn't that just to get to the 
UI?), or does it call the Catalina Manager servlet directly? Is there any 
documentation around this type of setup?

Thanks again and have a great Weekend!

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

> -Original Message-
> From: Christopher Schultz 
> Sent: Friday, July 7, 2023 2:05 PM
> To: users@tomcat.apache.org
> Subject: Re: OT: Question regarding the listeners in the upcoming releases.
> 
> Jon,
> 
> On 7/7/23 1:06 PM, jonmcalexan...@wellsfargo.com.INVALID wrote:
> > Yes, I'm aware that JMX may be the easiest method, however to use it
> > means modifying the JAVA_OPTIONS as well as having a username and
> > password as well as to meet our internal requirements, an ssl
> > certificate for the jmx connection.
> You can use Manager + JMXProxyServlet which IMHO is way better than
> "regular JMX"... for all the reasons you mention above.
> 
> > What I'm looking for, if possible, is the addition of a
> > connector/valve, whatever method, in the server.xml. My thinking would
> > be to have it only accessible via localhost and not on the general
> > network. Again, something that can query and put the results out for
> > Elastic to ingest and make use of.
> You can do this with Manager + JMXProxyServlet and no new code needs to
> be written (other than your script to request the data and push it to 
> Elastic).
> 
> -chris
> 
> >> -Original Message-
> >> From: Christopher Schultz 
> >> Sent: Friday, July 7, 2023 8:39 AM
> >> To: users@tomcat.apache.org
> >> Subject: Re: OT: Question regarding the listeners in the upcoming
> releases.
> >>
> >> Jon,
> >>
> >> On 7/6/23 16:22, jonmcalexan...@wellsfargo.com.INVALID wrote:
> >>> I have a question which is based around the idea of the new
> >>> Listeners that are being introduced in the upcoming releases. This
> >>> is based on something I’ve been thinking on for the last 6 to 9 mos.
> >>> Would it be possible to have a Listener that could output stats for
> >>> the Tomcat Instance, similar to what you would see in the Manager
> application?
> >>> Not wanting any of the actual Manager functionality, just the status
> >>> reporting features. Something that could be consumed by Elastic to
> >>> go into a dashboard showing Instance/Application health? I really
> >>> don’t want to deploy the Manager Application just to get this type of
> data.
> >>>
> >>> Thanks. I know this is a long shot question and this is where NOT
> >>> being a developer blows. 
> >>
> >> I would do this using JMX from a remote querying agent, at whatever
> >> interval you want. No Listener required.
> >>
> >> -chris
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OT: Question regarding the listeners in the upcoming releases.

[Christopher Schultz]

Jon,

On 7/7/23 1:06 PM, jonmcalexan...@wellsfargo.com.INVALID wrote:

Yes, I'm aware that JMX may be the easiest method, however to use it
means modifying the JAVA_OPTIONS as well as having a username and
password as well as to meet our internal requirements, an ssl
certificate for the jmx connection.
You can use Manager + JMXProxyServlet which IMHO is way better than 
"regular JMX"... for all the reasons you mention above.



What I'm looking for, if possible, is the addition of a
connector/valve, whatever method, in the server.xml. My thinking
would be to have it only accessible via localhost and not on the
general network. Again, something that can query and put the results
out for Elastic to ingest and make use of.
You can do this with Manager + JMXProxyServlet and no new code needs to 
be written (other than your script to request the data and push it to 
Elastic).


-chris


-Original Message-
From: Christopher Schultz 
Sent: Friday, July 7, 2023 8:39 AM
To: users@tomcat.apache.org
Subject: Re: OT: Question regarding the listeners in the upcoming releases.

Jon,

On 7/6/23 16:22, jonmcalexan...@wellsfargo.com.INVALID wrote:

I have a question which is based around the idea of the new Listeners
that are being introduced in the upcoming releases. This is based on
something I’ve been thinking on for the last 6 to 9 mos. Would it be
possible to have a Listener that could output stats for the Tomcat
Instance, similar to what you would see in the Manager application?
Not wanting any of the actual Manager functionality, just the status
reporting features. Something that could be consumed by Elastic to go
into a dashboard showing Instance/Application health? I really don’t
want to deploy the Manager Application just to get this type of data.

Thanks. I know this is a long shot question and this is where NOT
being a developer blows. 


I would do this using JMX from a remote querying agent, at whatever interval
you want. No Listener required.

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: OT: Question regarding the listeners in the upcoming releases.

[jonmcalexander]

Hi Chris,

Yes, I'm aware that JMX may be the easiest method, however to use it means 
modifying the JAVA_OPTIONS as well as having a username and password as well as 
to meet our internal requirements, an ssl certificate for the jmx connection.

What I'm looking for, if possible, is the addition of a connector/valve, 
whatever method, in the server.xml. My thinking would be to have it only 
accessible via localhost and not on the general network. Again, something that 
can query and put the results out for Elastic to ingest and make use of.

Note, still just brainstorming, so I don't have all connections fully made here.

Thanks,

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

> -Original Message-
> From: Christopher Schultz 
> Sent: Friday, July 7, 2023 8:39 AM
> To: users@tomcat.apache.org
> Subject: Re: OT: Question regarding the listeners in the upcoming releases.
> 
> Jon,
> 
> On 7/6/23 16:22, jonmcalexan...@wellsfargo.com.INVALID wrote:
> > I have a question which is based around the idea of the new Listeners
> > that are being introduced in the upcoming releases. This is based on
> > something I’ve been thinking on for the last 6 to 9 mos. Would it be
> > possible to have a Listener that could output stats for the Tomcat
> > Instance, similar to what you would see in the Manager application?
> > Not wanting any of the actual Manager functionality, just the status
> > reporting features. Something that could be consumed by Elastic to go
> > into a dashboard showing Instance/Application health? I really don’t
> > want to deploy the Manager Application just to get this type of data.
> >
> > Thanks. I know this is a long shot question and this is where NOT
> > being a developer blows. 
> 
> I would do this using JMX from a remote querying agent, at whatever interval
> you want. No Listener required.
> 
> -chris
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OT: Question regarding the listeners in the upcoming releases.

[Christopher Schultz]

Jon,

On 7/6/23 16:22, jonmcalexan...@wellsfargo.com.INVALID wrote:

I have a question which is based around the idea of the new Listeners
that are being introduced in the upcoming releases. This is based on
something I’ve been thinking on for the last 6 to 9 mos. Would it be
possible to have a Listener that could output stats for the Tomcat
Instance, similar to what you would see in the Manager application?
Not wanting any of the actual Manager functionality, just the status
reporting features. Something that could be consumed by Elastic to go
into a dashboard showing Instance/Application health? I really don’t
want to deploy the Manager Application just to get this type of
data.

Thanks. I know this is a long shot question and this is where NOT
being a developer blows. 


I would do this using JMX from a remote querying agent, at whatever
interval you want. No Listener required.

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

OT: Question regarding the listeners in the upcoming releases.

[jonmcalexander]

I have a question which is based around the idea of the new Listeners that are 
being introduced in the upcoming releases. This is based on something I’ve been 
thinking on for the last 6 to 9 mos. Would it be possible to have a Listener 
that could output stats for the Tomcat Instance, similar to what you would see 
in the Manager application? Not wanting any of the actual Manager 
functionality, just the status reporting features. Something that could be 
consumed by Elastic to go into a dashboard showing Instance/Application health? 
I really don’t want to deploy the Manager Application just to get this type of 
data.

Thanks. I know this is a long shot question and this is where NOT being a 
developer blows. 

Thank you,

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com<mailto:jonmcalexan...@wellsfargo.com>
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

Re: listeners

[Greg Kaszycki]

nevermind - the issue was that they have 2 web.xml files in the source tree
(don't know why) and I changed the wrong one.
BTW thanks for the earlier answers - that cleared up a lot

On Thu, Mar 29, 2018 at 12:31 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Greg,
>
> On 3/29/18 12:25 PM, Greg Kaszycki wrote:
> > On Thu, Mar 29, 2018 at 11:59 AM, Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >>
> >> Greg,
> >>
> > On 3/29/18 11:16 AM, Greg Kaszycki wrote:
> >>>> Is there a way to query tomcat for registered listeners?
> >>
> >> There are tons of "listeners". What did you have in mind?
> >>
> >> You can get lots of stuff via JMX.
>
> > I am trying to register a listener and it doesn't seem to be
> > getting hit. I am trying to see if it is registered
>
> What kind of listener? How are you registering the listener? How are
> you checking to see if it is "getting hit"?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlq9FOQACgkQHPApP6U8
> pFh5sA/+P1TEVtufwh3gluxSj1d5bSq0BPluIWgeQY7ms6lsoYP8tucXvRrHeSgi
> OxY5UVmDhQXxvJog/Sjg5+HrcVhzLPh3KdsJh08Bg1V1xmswvNnCF9DeqCf0GXmm
> 2h8jLIihK5Vw7cf6boXHcR2qNTH8vaXtG0kmacbs8hjxkIvBJ5qe33l2tWZsSvAq
> NC2BSOVBGh+kJwIlTFVSffbdSELHbzd8hUU2zx4c/CRdGrmMIF3Kqgw8xJpfwdey
> 03xSIWmTSV9DwfznyQcGq6KfGq6fEJhf7J18Jl0N1P2SJjovpVrS+5NhmhpekxGK
> 1IhcFR0u3sNCxntQEtcoOzD3uZPA/Xey3n1cGqbcViqveJncGLcCSbsTJGQIltDg
> VcV1zpJUnnMdRktjLoiPNC7E2DWa9vJLmZZ5crN1VxQaV1zIbpo+ZJukcydnYi8V
> dLWAgI4VR7zUqTlQh32s/VN99rgabdHVS7mhThVFczHvCeYIlrnH5Uo6QLhunwnD
> vQkeX8ff3w1G2FgoOWhe6jxg2qfX2+j92DmQYxnlJhYiPvQ45R75zn1ew5/1DdP9
> UBchE9I6GV35Bx++M/dQSzr5qYU90hE8aVeK5f65R+g9l9h5ommJjKZJxSfh5Md6
> 0kkBVQv+CYXisnN/pugQxUe7N34xRpV6D76L/oabHMf3t4saXeI=
> =xwk9
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
Greg Kaszycki
919-244-3789

Re: listeners

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Greg,

On 3/29/18 12:25 PM, Greg Kaszycki wrote:
> On Thu, Mar 29, 2018 at 11:59 AM, Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
>> 
>> Greg,
>> 
> On 3/29/18 11:16 AM, Greg Kaszycki wrote:
>>>> Is there a way to query tomcat for registered listeners?
>> 
>> There are tons of "listeners". What did you have in mind?
>> 
>> You can get lots of stuff via JMX.

> I am trying to register a listener and it doesn't seem to be
> getting hit. I am trying to see if it is registered

What kind of listener? How are you registering the listener? How are
you checking to see if it is "getting hit"?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlq9FOQACgkQHPApP6U8
pFh5sA/+P1TEVtufwh3gluxSj1d5bSq0BPluIWgeQY7ms6lsoYP8tucXvRrHeSgi
OxY5UVmDhQXxvJog/Sjg5+HrcVhzLPh3KdsJh08Bg1V1xmswvNnCF9DeqCf0GXmm
2h8jLIihK5Vw7cf6boXHcR2qNTH8vaXtG0kmacbs8hjxkIvBJ5qe33l2tWZsSvAq
NC2BSOVBGh+kJwIlTFVSffbdSELHbzd8hUU2zx4c/CRdGrmMIF3Kqgw8xJpfwdey
03xSIWmTSV9DwfznyQcGq6KfGq6fEJhf7J18Jl0N1P2SJjovpVrS+5NhmhpekxGK
1IhcFR0u3sNCxntQEtcoOzD3uZPA/Xey3n1cGqbcViqveJncGLcCSbsTJGQIltDg
VcV1zpJUnnMdRktjLoiPNC7E2DWa9vJLmZZ5crN1VxQaV1zIbpo+ZJukcydnYi8V
dLWAgI4VR7zUqTlQh32s/VN99rgabdHVS7mhThVFczHvCeYIlrnH5Uo6QLhunwnD
vQkeX8ff3w1G2FgoOWhe6jxg2qfX2+j92DmQYxnlJhYiPvQ45R75zn1ew5/1DdP9
UBchE9I6GV35Bx++M/dQSzr5qYU90hE8aVeK5f65R+g9l9h5ommJjKZJxSfh5Md6
0kkBVQv+CYXisnN/pugQxUe7N34xRpV6D76L/oabHMf3t4saXeI=
=xwk9
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: listeners

[Greg Kaszycki]

I am trying to register a listener and it doesn't seem to be getting hit.
I am trying to see if it is registered

On Thu, Mar 29, 2018 at 11:59 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Greg,
>
> On 3/29/18 11:16 AM, Greg Kaszycki wrote:
> > Is there a way to query tomcat for registered listeners?
>
> There are tons of "listeners". What did you have in mind?
>
> You can get lots of stuff via JMX.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlq9DXwACgkQHPApP6U8
> pFgw5A/+LgnYaXbo/3Rp1RngjqxEwvhDVn5tw12J3/o2QunjiXSW9X716Jxo/dBE
> +jevPLxvL01vKOzVVFOXlY0GHPJnN18jdEbZx1yLhMZWvjCSFW3JvNSvS66sbOJD
> IMiIc0peeKui9Ly1G4IknMPvbtzQHDbKu1brCUwswvldWWrMW6cPqMya49PFQoHP
> bFDDDvIeuSijDdiZPkGiKt27H6kqARbnuBcoup3ZbnNRVZpgiI7CMHsB19/jxp7E
> SkPfIjWFommxkHUms8UkMug1b/AjLM1PaI9fCMltRuOp4jki6PpDufCexB9uHaTF
> WJsyVHNwln4phjwTYGDW5r4NV11ThfdAx9fRnimCxlJL6w0cMnFYY5cJDn4mmXNQ
> lsDa4Rcbg0NQbmNzM/agPXqtLXY1NQHPGLl7VqXsGonLr2BoetH4Fah696fQOd+r
> c4wmIAu7JB5YOptcA6DbfDoPjISSWMeBQ5xnOu02Hew7nTb8/Zz1D9lMD3D2aqyK
> dfHpaQ204J2ZIeLMJu7N/k4Ol+gx52uzu+uI0Dy2n2LVc7/l2pCluUMRPabwF5Uc
> PlNP+8HYDtb1gdq6GcysbDlCFYXZzRRei/kHy5dgh93q1Tbmc+ImS7DlLTTDsjaM
> E2b+e6fZiFdPVC5lDUh2TPp3B5Fs6jTsJTpH3xP4BQWOAfXPdP4=
> =l/DJ
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
Greg Kaszycki
919-244-3789

Re: listeners

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Greg,

On 3/29/18 11:16 AM, Greg Kaszycki wrote:
> Is there a way to query tomcat for registered listeners?

There are tons of "listeners". What did you have in mind?

You can get lots of stuff via JMX.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlq9DXwACgkQHPApP6U8
pFgw5A/+LgnYaXbo/3Rp1RngjqxEwvhDVn5tw12J3/o2QunjiXSW9X716Jxo/dBE
+jevPLxvL01vKOzVVFOXlY0GHPJnN18jdEbZx1yLhMZWvjCSFW3JvNSvS66sbOJD
IMiIc0peeKui9Ly1G4IknMPvbtzQHDbKu1brCUwswvldWWrMW6cPqMya49PFQoHP
bFDDDvIeuSijDdiZPkGiKt27H6kqARbnuBcoup3ZbnNRVZpgiI7CMHsB19/jxp7E
SkPfIjWFommxkHUms8UkMug1b/AjLM1PaI9fCMltRuOp4jki6PpDufCexB9uHaTF
WJsyVHNwln4phjwTYGDW5r4NV11ThfdAx9fRnimCxlJL6w0cMnFYY5cJDn4mmXNQ
lsDa4Rcbg0NQbmNzM/agPXqtLXY1NQHPGLl7VqXsGonLr2BoetH4Fah696fQOd+r
c4wmIAu7JB5YOptcA6DbfDoPjISSWMeBQ5xnOu02Hew7nTb8/Zz1D9lMD3D2aqyK
dfHpaQ204J2ZIeLMJu7N/k4Ol+gx52uzu+uI0Dy2n2LVc7/l2pCluUMRPabwF5Uc
PlNP+8HYDtb1gdq6GcysbDlCFYXZzRRei/kHy5dgh93q1Tbmc+ImS7DlLTTDsjaM
E2b+e6fZiFdPVC5lDUh2TPp3B5Fs6jTsJTpH3xP4BQWOAfXPdP4=
=l/DJ
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

listeners

[Greg Kaszycki]

Is there a way to query tomcat for registered listeners?

-- 
Greg Kaszycki
919-244-3789

Re: Apache Tomcat context update listeners

[Chiranga Alwis]

Thanks Mark, I will go through and try to understand this. If any
clarifications are required I will post here.

By the way the goal I am pursuing (if it is not clear) is to enable the
loading of a set of custom configurations for every Context. These
configurations cannot be included within the typical web.xml (as we intend
to separate out these custom configurations from the typical web.xml
configurations) Other that that, this file plays a similar role to that
played by the web.xml.

On Sun, Feb 28, 2016 at 3:04 AM, Mark Thomas  wrote:

> On 27/02/2016 17:38, Chiranga Alwis wrote:
> > Well, what I am trying to achieve is as follows:
> >
> > I am trying to load certain custom configurations from a file which is
> > similar to web.xml in Tomcat, for each Context. We can define it globally
> > and also override the configurations at context level. For this I have
> > already created a custom Listener and have added it to lib folder.
> >
> > I have already constructed it in a manner in which for each configuration
> > the configurations are loaded at webapp deployment.
> >
> > But now I intend to perform this task not only at the initial deployment,
> > but also if someone makes a change to the webapp. I believe Tomcat also
> > dynamically reloads a context if modified, for example a modification to
> > the web.xml or a Java class. We don't have to switch off the Tomcat
> server
> > and restart it to load the new changes.
>
> You still haven't defined change.
>
> > In my understanding, in such a situation the Context instance that was
> > initially created at server startup is destroyed and a new Context
> instance
> > is created. I got this idea as I did not come across a new event type
> under
> > Tomcat component lifecycle which defines an event of updating a Tomcat
> > component such as a Context. The ones that exist are for starting and
> > destroying of Tomcat components.
> >
> > Is my understanding correct?
>
> No.
>
> > Or is it different?
>
> Yes.
>
> > Plus what is/are the most
> > appropriate LifeCycle events which I am to use in such a situation?
>
> It appears you are using Tomcat 6 since that is the version of the
> documentation you quoted in your first post in this thread.
>
> You really need to upgrade to at least 7.0.x where the behaviour is much
> better defined. 6.0.x is likely to have some undocumented edge cases
> that might surprise you.
>
> Then you need to read this:
> http://tomcat.apache.org/tomcat-7.0-doc/config/automatic-deployment.html
>
> Pay particular attention to the differences between reload and redeploy.
>
> Then look at the Lifecyle.CONFIGURE_START_EVENT event.
>
> Mark
>
> >
> > On Sat, Feb 27, 2016 at 6:17 PM, Mark Thomas  wrote:
> >
> >> On 26 February 2016 19:09:59 GMT+00:00, Chiranga Alwis <
> >> chirangaal...@gmail.com> wrote:
> >>> Well, sorry if the question is not clear.
> >>>
> >>> What I want to know is for what type of event we need to listen in
> >>> order to
> >>> carry out a task when a Context is modified. It would be great if there
> >>> is
> >>> a clear explanation on how this is to be checked.
> >>
> >> Again, define modified.
> >>
> >> Again, why do you want to run a task? What are you actually trying to
> >> achieve?
> >>
> >> Mark
> >>
> >>>
> >>> On Fri, Feb 26, 2016 at 5:21 PM, Mark Thomas  wrote:
> >>>
>  On 26/02/2016 11:44, Chiranga Alwis wrote:
> > Hi,
> >
> > I have currently created a LifecycleListener which listens to
> >>> Tomcat's
> > context deployment event and loads data in a custom configuration
> >>> file at
> > that point.
> >
> > I have been trying to find out whether LifecycleListeners support
> >>> context
> > update and modification events but yet in my understanding I could
> >>> not
> > discover an appropriate resource to use.
> 
>  Define update.
> 
>  Define modification.
> 
>  Better still, explain what it is you actually want to achieve rather
>  than ask for help implementing your, potentially flawed, solution.
> 
>  Mark
> 
>  -
>  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>  For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> >>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Apache Tomcat context update listeners

[Mark Thomas]

On 27/02/2016 17:38, Chiranga Alwis wrote:
> Well, what I am trying to achieve is as follows:
> 
> I am trying to load certain custom configurations from a file which is
> similar to web.xml in Tomcat, for each Context. We can define it globally
> and also override the configurations at context level. For this I have
> already created a custom Listener and have added it to lib folder.
> 
> I have already constructed it in a manner in which for each configuration
> the configurations are loaded at webapp deployment.
> 
> But now I intend to perform this task not only at the initial deployment,
> but also if someone makes a change to the webapp. I believe Tomcat also
> dynamically reloads a context if modified, for example a modification to
> the web.xml or a Java class. We don't have to switch off the Tomcat server
> and restart it to load the new changes.

You still haven't defined change.

> In my understanding, in such a situation the Context instance that was
> initially created at server startup is destroyed and a new Context instance
> is created. I got this idea as I did not come across a new event type under
> Tomcat component lifecycle which defines an event of updating a Tomcat
> component such as a Context. The ones that exist are for starting and
> destroying of Tomcat components.
> 
> Is my understanding correct?

No.

> Or is it different?

Yes.

> Plus what is/are the most
> appropriate LifeCycle events which I am to use in such a situation?

It appears you are using Tomcat 6 since that is the version of the
documentation you quoted in your first post in this thread.

You really need to upgrade to at least 7.0.x where the behaviour is much
better defined. 6.0.x is likely to have some undocumented edge cases
that might surprise you.

Then you need to read this:
http://tomcat.apache.org/tomcat-7.0-doc/config/automatic-deployment.html

Pay particular attention to the differences between reload and redeploy.

Then look at the Lifecyle.CONFIGURE_START_EVENT event.

Mark

> 
> On Sat, Feb 27, 2016 at 6:17 PM, Mark Thomas  wrote:
> 
>> On 26 February 2016 19:09:59 GMT+00:00, Chiranga Alwis <
>> chirangaal...@gmail.com> wrote:
>>> Well, sorry if the question is not clear.
>>>
>>> What I want to know is for what type of event we need to listen in
>>> order to
>>> carry out a task when a Context is modified. It would be great if there
>>> is
>>> a clear explanation on how this is to be checked.
>>
>> Again, define modified.
>>
>> Again, why do you want to run a task? What are you actually trying to
>> achieve?
>>
>> Mark
>>
>>>
>>> On Fri, Feb 26, 2016 at 5:21 PM, Mark Thomas  wrote:
>>>
 On 26/02/2016 11:44, Chiranga Alwis wrote:
> Hi,
>
> I have currently created a LifecycleListener which listens to
>>> Tomcat's
> context deployment event and loads data in a custom configuration
>>> file at
> that point.
>
> I have been trying to find out whether LifecycleListeners support
>>> context
> update and modification events but yet in my understanding I could
>>> not
> discover an appropriate resource to use.

 Define update.

 Define modification.

 Better still, explain what it is you actually want to achieve rather
 than ask for help implementing your, potentially flawed, solution.

 Mark

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org


>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
> 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Apache Tomcat context update listeners

[Mark Eggers]

Chiranga,

On 2/27/2016 9:38 AM, Chiranga Alwis wrote:
> Well, what I am trying to achieve is as follows:
> 
> I am trying to load certain custom configurations from a file which
> is similar to web.xml in Tomcat, for each Context. We can define it
> globally and also override the configurations at context level. For
> this I have already created a custom Listener and have added it to
> lib folder.
> 
> I have already constructed it in a manner in which for each
> configuration the configurations are loaded at webapp deployment.
> 
> But now I intend to perform this task not only at the initial
> deployment, but also if someone makes a change to the webapp. I
> believe Tomcat also dynamically reloads a context if modified, for
> example a modification to the web.xml or a Java class. We don't have
> to switch off the Tomcat server and restart it to load the new
> changes.
> 
> In my understanding, in such a situation the Context instance that
> was initially created at server startup is destroyed and a new
> Context instance is created. I got this idea as I did not come across
> a new event type under Tomcat component lifecycle which defines an
> event of updating a Tomcat component such as a Context. The ones that
> exist are for starting and destroying of Tomcat components.
> 
> Is my understanding correct? Or is it different? Plus what is/are the
> most appropriate LifeCycle events which I am to use in such a
> situation?
> 
> On Sat, Feb 27, 2016 at 6:17 PM, Mark Thomas 
> wrote:
> 
>> On 26 February 2016 19:09:59 GMT+00:00, Chiranga Alwis < 
>> chirangaal...@gmail.com> wrote:
>>> Well, sorry if the question is not clear.
>>> 
>>> What I want to know is for what type of event we need to listen
>>> in order to carry out a task when a Context is modified. It would
>>> be great if there is a clear explanation on how this is to be
>>> checked.
>> 
>> Again, define modified.
>> 
>> Again, why do you want to run a task? What are you actually trying
>> to achieve?
>> 
>> Mark
>> 
>>> 
>>> On Fri, Feb 26, 2016 at 5:21 PM, Mark Thomas 
>>> wrote:
>>> 
 On 26/02/2016 11:44, Chiranga Alwis wrote:
> Hi,
> 
> I have currently created a LifecycleListener which listens
> to
>>> Tomcat's
> context deployment event and loads data in a custom
> configuration
>>> file at
> that point.
> 
> I have been trying to find out whether LifecycleListeners
> support
>>> context
> update and modification events but yet in my understanding I
> could
>>> not
> discover an appropriate resource to use.
 
 Define update.
 
 Define modification.
 
 Better still, explain what it is you actually want to achieve
 rather than ask for help implementing your, potentially flawed,
 solution.
 
 Mark

My thoughts on this from an operations / sanity viewpoint.

I am always leery of changing web application configurations on the fly.
It's easy to get source code repositories not agreeing with production
code, not agreeing with Maven repositories (if you use Maven), etc.,
etc. Then when you go to debug a production problem, figuring out what
you're working with becomes challenging.

I much prefer using parallel deployment, and changing the web
application every time a configuration changes. Tomcat handles this
gracefully. We've found that Jenkins / Nexus / Maven / parallel
deployment makes it easy to manage test, UAT, and production releases.

The Jenkins job sends all interested parties email, which contains the
version of the product, who did the release, and where the release can
be found. There's also a record in the Jenkins logs, so we can look at a
product release history fairly easily.

That being said, if you absolutely want to change configurations on the
fly, I'd look at something like the following (please note that I am a
systems architect and NOT a Java developer):

1. Store your configuration in a Singleton
   Maybe use a ConcurrentHashMap

2. Populate the Singelton via a ServletContextListener on start up

3. Create a protected administrative interface
   Look at using the Remote Address Filter to provide protection

4. Reload the configuration using the protected administrative interface

I think this is ugly, and you should strongly consider releasing point
updates when the configuration changes.

. . . just my two cents
/mde/



signature.asc
Description: OpenPGP digital signature

Re: Apache Tomcat context update listeners

[Chiranga Alwis]

Well, what I am trying to achieve is as follows:

I am trying to load certain custom configurations from a file which is
similar to web.xml in Tomcat, for each Context. We can define it globally
and also override the configurations at context level. For this I have
already created a custom Listener and have added it to lib folder.

I have already constructed it in a manner in which for each configuration
the configurations are loaded at webapp deployment.

But now I intend to perform this task not only at the initial deployment,
but also if someone makes a change to the webapp. I believe Tomcat also
dynamically reloads a context if modified, for example a modification to
the web.xml or a Java class. We don't have to switch off the Tomcat server
and restart it to load the new changes.

In my understanding, in such a situation the Context instance that was
initially created at server startup is destroyed and a new Context instance
is created. I got this idea as I did not come across a new event type under
Tomcat component lifecycle which defines an event of updating a Tomcat
component such as a Context. The ones that exist are for starting and
destroying of Tomcat components.

Is my understanding correct? Or is it different? Plus what is/are the most
appropriate LifeCycle events which I am to use in such a situation?

On Sat, Feb 27, 2016 at 6:17 PM, Mark Thomas  wrote:

> On 26 February 2016 19:09:59 GMT+00:00, Chiranga Alwis <
> chirangaal...@gmail.com> wrote:
> >Well, sorry if the question is not clear.
> >
> >What I want to know is for what type of event we need to listen in
> >order to
> >carry out a task when a Context is modified. It would be great if there
> >is
> >a clear explanation on how this is to be checked.
>
> Again, define modified.
>
> Again, why do you want to run a task? What are you actually trying to
> achieve?
>
> Mark
>
> >
> >On Fri, Feb 26, 2016 at 5:21 PM, Mark Thomas  wrote:
> >
> >> On 26/02/2016 11:44, Chiranga Alwis wrote:
> >> > Hi,
> >> >
> >> > I have currently created a LifecycleListener which listens to
> >Tomcat's
> >> > context deployment event and loads data in a custom configuration
> >file at
> >> > that point.
> >> >
> >> > I have been trying to find out whether LifecycleListeners support
> >context
> >> > update and modification events but yet in my understanding I could
> >not
> >> > discover an appropriate resource to use.
> >>
> >> Define update.
> >>
> >> Define modification.
> >>
> >> Better still, explain what it is you actually want to achieve rather
> >> than ask for help implementing your, potentially flawed, solution.
> >>
> >> Mark
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Apache Tomcat context update listeners

[Mark Thomas]

On 26 February 2016 19:09:59 GMT+00:00, Chiranga Alwis 
 wrote:
>Well, sorry if the question is not clear.
>
>What I want to know is for what type of event we need to listen in
>order to
>carry out a task when a Context is modified. It would be great if there
>is
>a clear explanation on how this is to be checked.

Again, define modified.

Again, why do you want to run a task? What are you actually trying to achieve?

Mark

>
>On Fri, Feb 26, 2016 at 5:21 PM, Mark Thomas  wrote:
>
>> On 26/02/2016 11:44, Chiranga Alwis wrote:
>> > Hi,
>> >
>> > I have currently created a LifecycleListener which listens to
>Tomcat's
>> > context deployment event and loads data in a custom configuration
>file at
>> > that point.
>> >
>> > I have been trying to find out whether LifecycleListeners support
>context
>> > update and modification events but yet in my understanding I could
>not
>> > discover an appropriate resource to use.
>>
>> Define update.
>>
>> Define modification.
>>
>> Better still, explain what it is you actually want to achieve rather
>> than ask for help implementing your, potentially flawed, solution.
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Apache Tomcat context update listeners

[Chiranga Alwis]

Well, sorry if the question is not clear.

What I want to know is for what type of event we need to listen in order to
carry out a task when a Context is modified. It would be great if there is
a clear explanation on how this is to be checked.

On Fri, Feb 26, 2016 at 5:21 PM, Mark Thomas  wrote:

> On 26/02/2016 11:44, Chiranga Alwis wrote:
> > Hi,
> >
> > I have currently created a LifecycleListener which listens to Tomcat's
> > context deployment event and loads data in a custom configuration file at
> > that point.
> >
> > I have been trying to find out whether LifecycleListeners support context
> > update and modification events but yet in my understanding I could not
> > discover an appropriate resource to use.
>
> Define update.
>
> Define modification.
>
> Better still, explain what it is you actually want to achieve rather
> than ask for help implementing your, potentially flawed, solution.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Apache Tomcat context update listeners

[Mark Thomas]

On 26/02/2016 11:44, Chiranga Alwis wrote:
> Hi,
> 
> I have currently created a LifecycleListener which listens to Tomcat's
> context deployment event and loads data in a custom configuration file at
> that point.
> 
> I have been trying to find out whether LifecycleListeners support context
> update and modification events but yet in my understanding I could not
> discover an appropriate resource to use.

Define update.

Define modification.

Better still, explain what it is you actually want to achieve rather
than ask for help implementing your, potentially flawed, solution.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Apache Tomcat context update listeners

[Chiranga Alwis]

Hi,

I have currently created a LifecycleListener which listens to Tomcat's
context deployment event and loads data in a custom configuration file at
that point.

I have been trying to find out whether LifecycleListeners support context
update and modification events but yet in my understanding I could not
discover an appropriate resource to use.

Most specifically, no event type which is triggered at the point of Context
modification has been provided. Or does Tomcat first destroy the modified
context instance and create a new Context instance which means it calls a
destroy event on the Context and then create a new Context instance?

The ones that have come closest to the expectations are as follows:

 - A Context WatchedResource
 which simply
observes defined resources
   within a context. But yet in my understanding this does not allow me
   to monitor any modification within the context.

 - Java WatchService


It also has to be noted that currently I am collecting all the deployed
Contexts at deployment to a map along with their corresponding custom
configuration objects. Hence, there has to be a mechanism through which I
am to identify the Context which is modified.

Any help with this will be highly appreciated.

Listeners' requestDestoyed() method not called in exception cases

[Pilkington, Simon]

We recently ran into an issue where the requestDestroyed() method of listeners 
were not being called when exceptions were propagated out of our application.

Looking into the code, it seems related to this[1]. Is this the expected 
behavior for listeners and we can’t rely on the requestDestroyed() method 
always being called for a request? 

One option we have considered is migrating to exclusively using filters and 
handling the exceptional use case explicitly there. Is there a recommended 
approach for this use case?

-Simon



[1] 
http://grepcode.com/file/repo1.maven.org/maven2/org.apache.tomcat.embed/tomcat-embed-core/7.0.59/org/apache/catalina/core/ApplicationDispatcher.java#486

Re: Listeners' requestDestoyed() method not called in exception cases

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Simon,

On 5/15/15 2:26 PM, Pilkington, Simon wrote:
 We recently ran into an issue where the requestDestroyed() method
 of listeners were not being called when exceptions were propagated
 out of our application.
 
 Looking into the code, it seems related to this[1]. Is this the 
 expected behavior for listeners and we can’t rely on the 
 requestDestroyed() method always being called for a request?

Hmm. Looking at the spec, I don't see any requirement that the
container *must* invoke those event listeners, so I think Tomcat is
in-spec, here.

That being said, I think a reasonable person would expect that the
listener would fire even in the case of an exception condition.

This is something I might want to file with the Servlet EG. At the
very least, they might be able to make a statement about the intent of
the EG, and provide a clarification with the next release of the
Specification. Would you be willing to do that? The Servlet EG's JIRA
instance is dog-slow, but usable.

 One option we have considered is migrating to exclusively using 
 filters and handling the exceptional use case explicitly there. Is 
 there a recommended approach for this use case?

That all depends upon your use case. The Filter interface certainly
allows you to use your own try/catch blocks to make sure you intercept
exceptions that propagate up the stack.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVVjxiAAoJEBzwKT+lPKRYVpIQAJUg37n/jybTxhhKYK/j53dL
nKDK4C/PJDlwewvmeljtSHD9ghqGXR1WMgnfkXDcECVARJqgoEhOhTT+aY8W7b0M
/BDvB48LiCYkaE6/z6gEqDkrz+JWo2y1p2m/3XgwOaYdhvqzlC0Le88tB+scmDdo
LgaJFTrgVyTDdH1cZs3d0TAFCy+5kQR7Zt8UxxRL7xaxohwj5NB8KMVD4TZZysY8
Q3PBAsjI43bJYgLlVFX9lp3aDWKd4Ug549z2BMrFDeRivP6tkwNaCRICuluHClrx
opEpQj7kvpQOUivQfmYxRTHqavoj0rgaOtocvtN/+4TRboTff6fpxSTZJtSVc/gc
OIRGe7t6wr7jqLXvTw7eAV49zMsA23GwSUb1fa62kaLdmW2ohxLGpQud45yUgYSr
gM01UP6gIWuckO1mMAT8kEsujUGC3eCxAUJCV9F8ZNnw4zT5SS2DIPbzvj6I5qIR
q7GGmskfeijKDOHyt111McQbQFYl9liMiKBOORd1wDk9lGP/QzPqpGSvZhwDA0wa
NlBABocrAgsWPjk81jjvaDdpVMVsv3269FTiQhh4D06372tai6E0/cV+uKHrPGOU
BV4R6gS9FuQTc7VRiSmenusvuw5ILD1/YhnU3eU/0V+ovq5Nn0PLTq0Xr1lPnrnZ
3oLXMtc/GwZ0PNOXDDVB
=fFyO
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: ThreadLocals, context listeners and classloader leaks

[Rainer Jung]

On 26.01.2012 18:00, Jess Holle wrote:

On 1/26/2012 10:38 AM, Mark Thomas wrote:

OK. ThreadLocals have no place in a web application. Period. If a
programmer insists on using them, then it is their responsibility to
clean up the mess they leave behind.

Tomcat's memory leak detection and prevention code goes some way to
clearing up things like this but it is never going to cover every case.

Mark

Or put another way, you have a choice:

1. Use ThreadLocals the way you'd have assumed you could, but don't
expect to ever restart your web app without leaking tons of memory.
2. Use ThreadLocals, but be sure you religiously clean up after
yourself by the time your web app is fully shut down.
3. Don't use ThreadLocals.

If you use someone else's library that uses ThreadLocals then you'll
probably end up in forced into A.

That said, there could and arguably should be another choice:

4. Select a special mode in a servlet engine that shuts down all
threads that have ever serviced requests for a given web app when it
is shutdown (and code your web app to shutdown any threads it
creates, obviously!), e.g. after they complete servicing any request
in progress. [It could just replace all request threads with new
ones after the requests currently in progress complete.]

That's assuming the servlet engine is nice enough to provide such a
mode. If it did, however, I believe that would resolve any ThreadLocal
issues without one having to avoid using a perfect natural and useful
Java language feature. I'd argue all servlet engines should really
provide this feature for just this reason. That said, I can live with A.


Renewing threads is what was implemented some time ago in Tomcat's 
ThreadLocal leak prevention:


http://tomcat.apache.org/tomcat-7.0-doc/config/listeners.html#ThreadLocal_Leak_Prevention_Listener_-_org.apache.catalina.core.ThreadLocalLeakPreventionListener

Regards,

Rainer

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

ThreadLocals, context listeners and classloader leaks

[Patric Rufflar]

Hi,

I've got some questions regards the use of ThreadLocals in context 
listeners:

(This is a general question, but I tested this with tomcat 6.0.32 only)

1. It's unspecified in the servlet spec 2.5 if a servlet context 
listener is allowed to take the use of ThreadLocals during 
contextInitialized().

   Is this (also) allowed in tomcat?


   If the answer of this question is yes:

2. Tomcat invokes the contextInitialized() method with the main thread.
   At some later time, the main thread (most probably) spawns some more 
threads (e.g. the http connector/acceptor threads).
   Because ThreadLocals are inherited from its parent threads, the 
thread local value references of each ThreadLocal object

   are copied to the child threads.

   With the result that even if the reference to the original 
ThreadLocal instance is removed (for example during contextDestroyed(),
   the inherited ThreadLocals are still there and reference to the 
original values - and will most probably remain in the spawned threads 
forever.
   (I am aware that tomcat's leak-prevention system / 
WebClassLoader.clearThreadLocalMap() may remove them,
   but I can neither rely on that at customer installations nor 
consider this as a good style)


   a) Is the main thread usage for context initializers intended? Is 
this configurable?
   b) What's the best way to deal with this situation (especially if 
the avoidance of ThreadLocals in context initializers is not an option)?
   c) Wouldn't it be better to create an individual thread for (each) 
context initializer to avoid these kind of problems?



Thanks you very much in advance.

- Patric
















-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: ThreadLocals, context listeners and classloader leaks

[Caldarale, Charles R]

 From: Patric Rufflar [mailto:pat...@rufflar.com] 
 Subject: ThreadLocals, context listeners and classloader leaks

 It's unspecified in the servlet spec 2.5 if a servlet context 
 listener is allowed to take the use of ThreadLocals during 
 contextInitialized().

I have no idea what the phrase take the use of means; what are you trying to 
say?  Any thread can make use of ThreadLocal, but in a thread pool environment, 
it's usually silly to do so, unless you're very, very careful.

 Is this (also) allowed in tomcat?

Tomcat makes little effort to prevent stupid programmer tricks.

 Because ThreadLocals are inherited from its parent threads

??? A ThreadLocal is _not_ inherited from the parent thread, although the 
_value_ of each InheritableThreadLocal is copied to a spawned thread.

 the inherited ThreadLocals are still there and reference to the 
 original values - and will most probably remain in the spawned 
 threads forever

Which is an example of why you must be very, very careful in your use of 
ThreadLocal in a pooled environment.

 Is the main thread usage for context initializers intended?

Yes.  In Tomcat 7, you can have parallel initialization, but not in Tomcat 6.  
Read the docs for Engine and Host.

 What's the best way to deal with this situation (especially
 if the avoidance of ThreadLocals in context initializers is
 not an option)?

Why is it not an option?  Even if your code calls some 3rd-party package to do 
its work, you can clean up the mess created before returning from the 
initializer.

 Wouldn't it be better to create an individual thread for (each) 
 context initializer to avoid these kind of problems?

Tomcat can't work around every possible programming silliness.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

RE: ThreadLocals, context listeners and classloader leaks

[Patric Rufflar]

I have no idea what the phrase take the use of means; what are you
trying to say?


I'd like to know if there's some statement from the tomcat team if the 
usage of ThreadLocals within contextInitialized() is discouraged or even 
not supported.



??? A ThreadLocal is _not_ inherited from the parent thread, although
the _value_ of each InheritableThreadLocal is copied to a spawned
thread.


I meant exactly that.
Consider the situation:
1. contextInitializer() sets value A to the ThreadLocal X in thread 
main
2. childs threads get spawned from main thread, now we have more than 
one ThreadLocal which references to value A
3. Reference to ThreadLocal X gets dropped, but references to value A 
still exist - without being able to remove them.




Why is it not an option?  Even if your code calls some 3rd-party
package to do its work, you can clean up the mess created before
returning from the initializer.
This means that everyone which uses tomcat has to deeply analyze which 
ThreadLocals are created under which circumstances,
and everytime a 3rd party library is added/upgraded/replaced he has to 
do this again.

Beside the risk, that something will be missed...


Tomcat can't work around every possible programming silliness.


Agreed.
But wouldn't it be much easier for everyone if tomcat would always use 
a separate thread for each context initializer (even if parallel 
initialization is disabled)
than to rely on that every possible programming silliness in 
3rd-party code will be fixed?


(BTW, Log4j is one of those buggy libraries - see 
https://issues.apache.org/bugzilla/show_bug.cgi?id=50486 for details)


- Patric



Am 26.01.2012 15:50, schrieb Caldarale, Charles R:

From: Patric Rufflar [mailto:pat...@rufflar.com]
Subject: ThreadLocals, context listeners and classloader leaks



It's unspecified in the servlet spec 2.5 if a servlet context
listener is allowed to take the use of ThreadLocals during
contextInitialized().


I have no idea what the phrase take the use of means; what are you
trying to say?  Any thread can make use of ThreadLocal, but in a
thread pool environment, it's usually silly to do so, unless you're
very, very careful.


Is this (also) allowed in tomcat?


Tomcat makes little effort to prevent stupid programmer tricks.


Because ThreadLocals are inherited from its parent threads


??? A ThreadLocal is _not_ inherited from the parent thread, although
the _value_ of each InheritableThreadLocal is copied to a spawned
thread.


the inherited ThreadLocals are still there and reference to the
original values - and will most probably remain in the spawned
threads forever


Which is an example of why you must be very, very careful in your use
of ThreadLocal in a pooled environment.


Is the main thread usage for context initializers intended?


Yes.  In Tomcat 7, you can have parallel initialization, but not in
Tomcat 6.  Read the docs for Engine and Host.


What's the best way to deal with this situation (especially
if the avoidance of ThreadLocals in context initializers is
not an option)?


Why is it not an option?  Even if your code calls some 3rd-party
package to do its work, you can clean up the mess created before
returning from the initializer.


Wouldn't it be better to create an individual thread for (each)
context initializer to avoid these kind of problems?


Tomcat can't work around every possible programming silliness.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE
PROPRIETARY MATERIAL and is thus for use only by the intended
recipient. If you received this in error, please contact the sender
and delete the e-mail and its attachments from all computers.



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: ThreadLocals, context listeners and classloader leaks

[Caldarale, Charles R]

 From: Patric Rufflar [mailto:pat...@rufflar.com] 
 Subject: RE: ThreadLocals, context listeners and classloader leaks

 1. contextInitializer() sets value A to the ThreadLocal X 
 in thread main
 2. childs threads get spawned from main thread, now we have 
 more than one ThreadLocal which references to value A

No; again, a ThreadLocal is _not_ inherited, but an InheritableThreadLocal is.  
These are different animals.

 3. Reference to ThreadLocal X gets dropped, but references 
 to value A still exist - without being able to remove them.

Why can't they be removed?  (The code to do so is ugly, but readily findable 
with Google.)

 But wouldn't it be much easier for everyone if tomcat would 
 always use a separate thread for each context initializer 

Again, that would fix _one_ stupid programmer trick, out of the uncountable 
number of potential errors.

Note that Tomcat 7 includes a ThreadLocalLeakPreventionListener, but it is only 
invoked during undeployment of a Context to clean up Executor thread pools. 
 It would certainly be possible to use this logic upon return from an 
initializer; filing a bugzilla enhancement request would at least allow some 
discussion by the committers.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

RE: ThreadLocals, context listeners and classloader leaks

[Patric Rufflar]

Am 26.01.2012 16:59, schrieb Caldarale, Charles R:

No; again, a ThreadLocal is _not_ inherited, but an
InheritableThreadLocal is.  These are different animals.


1. A InheritableThreadLocal is (extends) a ThreadLocal.
2. Surprise: A InheritableThreadLocal is _not_ used for the 
Thread.inheritableThreadLocals field/mechanism when creating a new 
thread
(at least not in oracle jdk 6, see Thread.class source for details) - 
for this, a ThreadLocal.class instance is used, too.


So the statement we have more than one ThreadLocal which references to 
value A seems correct to me.



Why can't they be removed?  (The code to do so is ugly, but readily
findable with Google.)


I think you mean by traversing all threads and do some reflection 
actions on them?
Please note that I already included feasible workarounds into my 
projects - so for me, this issue is not a show stopper anymore.


But:
The intention of my original mail was to highlight the problem with 
ThreadLocals/Context initializers and to suggest an improvement to 
tomcat to prevent

others from falling into this pit.
Secondly, from an economic perspective such an improvement in tomcat 
would be much cheaper than to include such hacks inside all the projects

all over the world.


Again, that would fix _one_ stupid programmer trick, out of the
uncountable number of potential errors.


I am interested in these disadvantages.
What kind of potential errors do you see if an individual thread would 
be used for each context initialization?


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: ThreadLocals, context listeners and classloader leaks

[Mark Thomas]

On 26/01/2012 15:16, Patric Rufflar wrote:
 I have no idea what the phrase take the use of means; what are you
 trying to say?
 
 I'd like to know if there's some statement from the tomcat team if the
 usage of ThreadLocals within contextInitialized() is discouraged or even
 not supported.

OK. ThreadLocals have no place in a web application. Period. If a
programmer insists on using them, then it is their responsibility to
clean up the mess they leave behind.

Tomcat's memory leak detection and prevention code goes some way to
clearing up things like this but it is never going to cover every case.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: ThreadLocals, context listeners and classloader leaks

[Jess Holle]

On 1/26/2012 10:38 AM, Mark Thomas wrote:

OK. ThreadLocals have no place in a web application. Period. If a
programmer insists on using them, then it is their responsibility to
clean up the mess they leave behind.

Tomcat's memory leak detection and prevention code goes some way to
clearing up things like this but it is never going to cover every case.

Mark

Or put another way, you have a choice:

1. Use ThreadLocals the way you'd have assumed you could, but don't
   expect to ever restart your web app without leaking tons of memory.
2. Use ThreadLocals, but be sure you religiously clean up after
   yourself by the time your web app is fully shut down.
3. Don't use ThreadLocals.

If you use someone else's library that uses ThreadLocals then you'll 
probably end up in forced into A.


That said, there could and arguably should be another choice:

4. Select a special mode in a servlet engine that shuts down all
   threads that have ever serviced requests for a given web app when it
   is shutdown (and code your web app to shutdown any threads it
   creates, obviously!), e.g. after they complete servicing any request
   in progress.  [It could just replace all request threads with new
   ones after the requests currently in progress complete.]

That's assuming the servlet engine is nice enough to provide such a 
mode.  If it did, however, I believe that would resolve any ThreadLocal 
issues without one having to avoid using a perfect natural and useful 
Java language feature.  I'd argue all servlet engines should really 
provide this feature for just this reason.  That said, I can live with A.


--
Jess Holle

RE: ThreadLocals, context listeners and classloader leaks

[Caldarale, Charles R]

 From: Jess Holle [mailto:je...@ptc.com] 
 Subject: Re: ThreadLocals, context listeners and classloader leaks

 That said, there could and arguably should be another choice:

I'll suggest something more radical: define a class such as ScopeLocal where 
values are added to and removed from threads as they enter and leave a scope 
boundary.  For servlet engine purposes, typical scopes would be webapp, 
session, request, servlet, etc.  Doing it properly (and efficiently) might well 
require JVM intervention, but it would certainly help in providing a useful 
mechanism for app writers.  Obviously, there's lots of definition work needed 
here...

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

Re: ThreadLocals, context listeners and classloader leaks

[Pid]

On 26/01/2012 17:30, Caldarale, Charles R wrote:
 From: Jess Holle [mailto:je...@ptc.com] 
 Subject: Re: ThreadLocals, context listeners and classloader leaks
 
 That said, there could and arguably should be another choice:
 
 I'll suggest something more radical: define a class such as ScopeLocal where 
 values are added to and removed from threads as they enter and leave a scope 
 boundary.  For servlet engine purposes, typical scopes would be webapp, 
 session, request, servlet, etc.  Doing it properly (and efficiently) might 
 well require JVM intervention, but it would certainly help in providing a 
 useful mechanism for app writers.  Obviously, there's lots of definition work 
 needed here...

Imagine the fiendishly clever and machiavellian applications we'd have
to debug if you did that...


p


 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
 MATERIAL and is thus for use only by the intended recipient. If you received 
 this in error, please contact the sender and delete the e-mail and its 
 attachments from all computers.
 


-- 

[key:62590808]



signature.asc
Description: OpenPGP digital signature

RE: ThreadLocals, context listeners and classloader leaks

[Caldarale, Charles R]

 From: Pid [mailto:p...@pidster.com] 
 Subject: Re: ThreadLocals, context listeners and classloader leaks

 Imagine the fiendishly clever and machiavellian applications 
 we'd have to debug if you did that...

Job security.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

Re: ThreadLocals, context listeners and classloader leaks

[Pid]

On 26/01/2012 17:48, Caldarale, Charles R wrote:
 From: Pid [mailto:p...@pidster.com] 
 Subject: Re: ThreadLocals, context listeners and classloader leaks
 
 Imagine the fiendishly clever and machiavellian applications 
 we'd have to debug if you did that...
 
 Job security.

ROFL.


p



-- 

[key:62590808]



signature.asc
Description: OpenPGP digital signature

Tomcat 6 - Multiple JMX Remote Lifecycle Listeners

[Brett Delle Grazie]

Hi,

I'm running Tomcat 6.0.23 and Sun Java 1.6.0.22 on RHEL 5.6 x86_64.

I've currently got one JMX Remote Lifecycle listener configured in server.xml:
Listener 
className=org.apache.catalina.mbeans.JmxRemoteLifecycleListener
rmiRegistryPortPlatform=X
rmiServerPortPlatform=X+1
useLocalPorts=true / !-- For SSH Tunnelling --

We use this to connect JConsole to the system via an SSH tunnel.

However I have a local system on the same lan that I would now like to use.

Can I add another listener with different ports (and no useLocalPorts=true) or
should I use rmiRegistryPort as the same or should I avoid having two of these
listeners at all.

Thanks,

-- 
Best Regards,

Brett Delle Grazie

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 6 - Multiple JMX Remote Lifecycle Listeners

[Brett Delle Grazie]

Hi,

On 16 February 2011 11:18, Brett Delle Grazie
brett.dellegra...@gmail.com wrote:
 Hi,

 I'm running Tomcat 6.0.23 and Sun Java 1.6.0.22 on RHEL 5.6 x86_64.

 I've currently got one JMX Remote Lifecycle listener configured in server.xml:
        Listener 
 className=org.apache.catalina.mbeans.JmxRemoteLifecycleListener
                rmiRegistryPortPlatform=X
                rmiServerPortPlatform=X+1
                useLocalPorts=true / !-- For SSH Tunnelling --

 We use this to connect JConsole to the system via an SSH tunnel.

 However I have a local system on the same lan that I would now like to use.

 Can I add another listener with different ports (and no useLocalPorts=true) 
 or
 should I use rmiRegistryPort as the same or should I avoid having two of these
 listeners at all.

Experimentation says 'yes' it does work with different ports. I
haven't tried it using the same
RMI registry port.


 Thanks,

 --
 Best Regards,

 Brett Delle Grazie




-- 
Best Regards,

Brett Delle Grazie

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Destroying Context Listeners

[Pid]

On 16/08/2010 18:32, CRANFORD, CHRIS wrote:
 
 I recently upgraded my Tomcat installation from 6.0.x to Tomcat 7
 (Win64) and I am actively testing our current web applications for
 backward compatibility, and so forth.  One of these web applications
 creates a set of context listeners to manage various things during the
 lifecycle of the web application.
 
 During the startup of the web app, I do see that the
 contextInitialized() method is called; however when either Tomcat is
 stopped or restarted whether from the command line or via MyEclipse 8.6;
 I do not see that contextDestroyed() is being invoked.  This is causing
 some heartburn on our end with this particular web app and I cannot find
 any solution.
 
 Has anyone seen this and/or is this confirmed as a problem with Tomcat
 7?
 Or is there another expectation under Servlet 3.0 that I may have
 overlooked.

Which exact version of Tomcat 7.0?

Are you able to consistently reproduce this?

What means are you using to determine that contextDestroyed() is not
called?  Log messages or... ?


p

 Chris
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 



0x62590808.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

RE: Destroying Context Listeners

[CRANFORD, CHRIS]

When I check the version of Tomcat 7, it says it is 7.0.0.0.
It's the compiled version from 6/13/2010.

And yes, the log calls in the destroy method are never done, hence my
concern that it isn't being invoked.  Under Tomcat 6, these log messages
were captured and written indicating a successful execution of the
method.  Even when I use a simple context listener that does a log
message at startup and destroy times, only the startup one is captured.

Chris 

 -Original Message-
 From: Pid [mailto:p...@pidster.com]
 Sent: Tuesday, August 17, 2010 7:47 AM
 To: Tomcat Users List
 Subject: Re: Destroying Context Listeners
 
 On 16/08/2010 18:32, CRANFORD, CHRIS wrote:
 
  I recently upgraded my Tomcat installation from 6.0.x to Tomcat 7
  (Win64) and I am actively testing our current web applications for
  backward compatibility, and so forth.  One of these web applications
  creates a set of context listeners to manage various things during
 the
  lifecycle of the web application.
 
  During the startup of the web app, I do see that the
  contextInitialized() method is called; however when either Tomcat is
  stopped or restarted whether from the command line or via MyEclipse
 8.6;
  I do not see that contextDestroyed() is being invoked.  This is
 causing
  some heartburn on our end with this particular web app and I cannot
 find
  any solution.
 
  Has anyone seen this and/or is this confirmed as a problem with
 Tomcat
  7?
  Or is there another expectation under Servlet 3.0 that I may have
  overlooked.
 
 Which exact version of Tomcat 7.0?
 
 Are you able to consistently reproduce this?
 
 What means are you using to determine that contextDestroyed() is not
 called?  Log messages or... ?
 
 
 p
 
  Chris
 
 
 
-
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
 



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Destroying Context Listeners

[Pid]

On 17/08/2010 14:11, CRANFORD, CHRIS wrote:
 When I check the version of Tomcat 7, it says it is 7.0.0.0.
 It's the compiled version from 6/13/2010.

Try downloading the latest beta, (or compile from trunk).

 http://people.apache.org/~markt/dev/tomcat-7/v7.0.2/bin/

 And yes, the log calls in the destroy method are never done, hence my

It might seem like a silly question, but it's not always guaranteed that
someone is using log messages to determine a fault.

Is the log call the very first statement in the method?

What kind of logging is it?  If it's a proper logging system and not a
System.out.println call, can you try with the latter instead?


p


 concern that it isn't being invoked.  Under Tomcat 6, these log messages
 were captured and written indicating a successful execution of the
 method.  Even when I use a simple context listener that does a log
 message at startup and destroy times, only the startup one is captured.
 
 Chris 
 
 -Original Message-
 From: Pid [mailto:p...@pidster.com]
 Sent: Tuesday, August 17, 2010 7:47 AM
 To: Tomcat Users List
 Subject: Re: Destroying Context Listeners

 On 16/08/2010 18:32, CRANFORD, CHRIS wrote:

 I recently upgraded my Tomcat installation from 6.0.x to Tomcat 7
 (Win64) and I am actively testing our current web applications for
 backward compatibility, and so forth.  One of these web applications
 creates a set of context listeners to manage various things during
 the
 lifecycle of the web application.

 During the startup of the web app, I do see that the
 contextInitialized() method is called; however when either Tomcat is
 stopped or restarted whether from the command line or via MyEclipse
 8.6;
 I do not see that contextDestroyed() is being invoked.  This is
 causing
 some heartburn on our end with this particular web app and I cannot
 find
 any solution.

 Has anyone seen this and/or is this confirmed as a problem with
 Tomcat
 7?
 Or is there another expectation under Servlet 3.0 that I may have
 overlooked.

 Which exact version of Tomcat 7.0?

 Are you able to consistently reproduce this?

 What means are you using to determine that contextDestroyed() is not
 called?  Log messages or... ?


 p

 Chris



 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 



0x62590808.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

RE: Destroying Context Listeners

[CRANFORD, CHRIS]

Pid -

I will download the latest beta and give it a try.  When I realized what
was going on, I simply commented out all the logic I had in the two
methods and replaced them with the following:

public void contextDestroyed(ServletContextEvent arg) { 
  System.out.println(webapp listener context was destroyed.);
  log.debug(contextDestroyed invoked successfully.);
}

public void contextInitialized(ServletContextEvent arg) {
  System.out.println(webapp listener context was initialized.);
  log.debug(contextInitialized invoked successfully.);
}   

In my case, I saw the log entries for the initialization, but never for
destroy.

After I update to 7.0.2, I'll retest and let you know.

Chris

 -Original Message-
 From: Pid [mailto:p...@pidster.com]
 Sent: Tuesday, August 17, 2010 10:07 AM
 To: Tomcat Users List
 Subject: Re: Destroying Context Listeners
 
 On 17/08/2010 14:11, CRANFORD, CHRIS wrote:
  When I check the version of Tomcat 7, it says it is 7.0.0.0.
  It's the compiled version from 6/13/2010.
 
 Try downloading the latest beta, (or compile from trunk).
 
  http://people.apache.org/~markt/dev/tomcat-7/v7.0.2/bin/
 
  And yes, the log calls in the destroy method are never done, hence
my
 
 It might seem like a silly question, but it's not always guaranteed
 that
 someone is using log messages to determine a fault.
 
 Is the log call the very first statement in the method?
 
 What kind of logging is it?  If it's a proper logging system and not a
 System.out.println call, can you try with the latter instead?
 
 
 p
 
 
  concern that it isn't being invoked.  Under Tomcat 6, these log
 messages
  were captured and written indicating a successful execution of the
  method.  Even when I use a simple context listener that does a log
  message at startup and destroy times, only the startup one is
 captured.
 
  Chris
 
  -Original Message-
  From: Pid [mailto:p...@pidster.com]
  Sent: Tuesday, August 17, 2010 7:47 AM
  To: Tomcat Users List
  Subject: Re: Destroying Context Listeners
 
  On 16/08/2010 18:32, CRANFORD, CHRIS wrote:
 
  I recently upgraded my Tomcat installation from 6.0.x to Tomcat 7
  (Win64) and I am actively testing our current web applications for
  backward compatibility, and so forth.  One of these web
 applications
  creates a set of context listeners to manage various things during
  the
  lifecycle of the web application.
 
  During the startup of the web app, I do see that the
  contextInitialized() method is called; however when either Tomcat
 is
  stopped or restarted whether from the command line or via
MyEclipse
  8.6;
  I do not see that contextDestroyed() is being invoked.  This is
  causing
  some heartburn on our end with this particular web app and I
cannot
  find
  any solution.
 
  Has anyone seen this and/or is this confirmed as a problem with
  Tomcat
  7?
  Or is there another expectation under Servlet 3.0 that I may have
  overlooked.
 
  Which exact version of Tomcat 7.0?
 
  Are you able to consistently reproduce this?
 
  What means are you using to determine that contextDestroyed() is
not
  called?  Log messages or... ?
 
 
  p
 
  Chris
 
 
 
 
-
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 
 
 
-
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
 



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Destroying Context Listeners

[CRANFORD, CHRIS]

Upgrading to 7.0.2 resolved the issue, thanks!

 -Original Message-
 From: CRANFORD, CHRIS [mailto:chris.cranf...@setech.com]
 Sent: Tuesday, August 17, 2010 10:23 AM
 To: Tomcat Users List
 Subject: RE: Destroying Context Listeners
 
 Pid -
 
 I will download the latest beta and give it a try.  When I realized
 what
 was going on, I simply commented out all the logic I had in the two
 methods and replaced them with the following:
 
 public void contextDestroyed(ServletContextEvent arg) {
   System.out.println(webapp listener context was destroyed.);
   log.debug(contextDestroyed invoked successfully.);
 }
 
 public void contextInitialized(ServletContextEvent arg) {
   System.out.println(webapp listener context was initialized.);
   log.debug(contextInitialized invoked successfully.);
 }
 
 In my case, I saw the log entries for the initialization, but never
for
 destroy.
 
 After I update to 7.0.2, I'll retest and let you know.
 
 Chris
 
  -Original Message-
  From: Pid [mailto:p...@pidster.com]
  Sent: Tuesday, August 17, 2010 10:07 AM
  To: Tomcat Users List
  Subject: Re: Destroying Context Listeners
 
  On 17/08/2010 14:11, CRANFORD, CHRIS wrote:
   When I check the version of Tomcat 7, it says it is 7.0.0.0.
   It's the compiled version from 6/13/2010.
 
  Try downloading the latest beta, (or compile from trunk).
 
   http://people.apache.org/~markt/dev/tomcat-7/v7.0.2/bin/
 
   And yes, the log calls in the destroy method are never done, hence
 my
 
  It might seem like a silly question, but it's not always guaranteed
  that
  someone is using log messages to determine a fault.
 
  Is the log call the very first statement in the method?
 
  What kind of logging is it?  If it's a proper logging system and not
 a
  System.out.println call, can you try with the latter instead?
 
 
  p
 
 
   concern that it isn't being invoked.  Under Tomcat 6, these log
  messages
   were captured and written indicating a successful execution of the
   method.  Even when I use a simple context listener that does a log
   message at startup and destroy times, only the startup one is
  captured.
  
   Chris
  
   -Original Message-
   From: Pid [mailto:p...@pidster.com]
   Sent: Tuesday, August 17, 2010 7:47 AM
   To: Tomcat Users List
   Subject: Re: Destroying Context Listeners
  
   On 16/08/2010 18:32, CRANFORD, CHRIS wrote:
  
   I recently upgraded my Tomcat installation from 6.0.x to Tomcat
7
   (Win64) and I am actively testing our current web applications
 for
   backward compatibility, and so forth.  One of these web
  applications
   creates a set of context listeners to manage various things
 during
   the
   lifecycle of the web application.
  
   During the startup of the web app, I do see that the
   contextInitialized() method is called; however when either
Tomcat
  is
   stopped or restarted whether from the command line or via
 MyEclipse
   8.6;
   I do not see that contextDestroyed() is being invoked.  This is
   causing
   some heartburn on our end with this particular web app and I
 cannot
   find
   any solution.
  
   Has anyone seen this and/or is this confirmed as a problem with
   Tomcat
   7?
   Or is there another expectation under Servlet 3.0 that I may
have
   overlooked.
  
   Which exact version of Tomcat 7.0?
  
   Are you able to consistently reproduce this?
  
   What means are you using to determine that contextDestroyed() is
 not
   called?  Log messages or... ?
  
  
   p
  
   Chris
  
  
  
  
 -
   To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
   For additional commands, e-mail: users-h...@tomcat.apache.org
  
  
  
  
  
 -
   To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
   For additional commands, e-mail: users-h...@tomcat.apache.org
  
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Destroying Context Listeners

[CRANFORD, CHRIS]

I recently upgraded my Tomcat installation from 6.0.x to Tomcat 7
(Win64) and I am actively testing our current web applications for
backward compatibility, and so forth.  One of these web applications
creates a set of context listeners to manage various things during the
lifecycle of the web application.

During the startup of the web app, I do see that the
contextInitialized() method is called; however when either Tomcat is
stopped or restarted whether from the command line or via MyEclipse 8.6;
I do not see that contextDestroyed() is being invoked.  This is causing
some heartburn on our end with this particular web app and I cannot find
any solution.

Has anyone seen this and/or is this confirmed as a problem with Tomcat
7?
Or is there another expectation under Servlet 3.0 that I may have
overlooked.

Chris


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Which listeners required in server.xml?

[Mark Thomas]

Bill Barker wrote:
  !-- JMX Support for the Tomcat server. Documentation at
 /docs/non-existent.html --
  Listener className=org.apache.catalina.mbeans.ServerLifecycleListener
 /
 
 This looks like it is left over from the admin webapp (RIP).  It doesn't 
 look like it does anything particularly useful anymore, but again the 
 warning about weird errors.

There is almost certainly some code in there that is now redundant.
However, this listener is currently where we make sure all of the mbeans
are destroyed when a server stops. Only an issue when embedding and
starting/stopping the server.

So, scope for clean-up but at least some code needs to remain here or
elsewhere.

Mark



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Which listeners required in server.xml?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bill,

On 5/30/2009 12:43 AM, Bill Barker wrote:
 Christopher Schultz ch...@christopherschultz.net wrote in message 

 Adding the APR library will give you a significant performance
 improvement even with the plain-old HTTP connector. It might be worth
 installing APR and leaving that listener in there.
 
 Urm, and u are basing this on what?

I am basing this on my recent benchmarking, with some results available
on this list under the thread Apache httpd vs Tomcat static content
performance.

I'm not just talking out of my ass, here.

 A low-traffic dynamic site should see
 next to nothing using APR, and could even lose (given the interlocks to 
 JNI).  It all depends on who is smarter, the JVM developer, or the APR 
 develper for CentOS.

CentOS is just another GNU/Linux flavor. I doubt any optimizations are
made especially for it (or other Linux flavors), so I wouldn't worry too
much about the APR developer for CentOS having to do too much work to
get decent performance out of it. It's not like httpd is a dog on CentOS
or anything.

 Again, to the OP, profile both configurations for your OS, and make the 
 decision then.

+1

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkokEQ0ACgkQ9CaO5/Lv0PCxewCfeijsi0vMkH6nwuIRi6IUpdyp
GgwAniEROVb9ScKvEzjHICuiLv0CEQFR
=NttG
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Which listeners required in server.xml?

[johnrock]

Running tomcat 6.0.18 server.xml has the following listener's enabled by
default:


  !--APR library loader. Documentation at /docs/apr.html --
  Listener className=org.apache.catalina.core.AprLifecycleListener
SSLEngine=on /

  !--Initialize Jasper prior to webapps are loaded. Documentation at
/docs/jasper-howto.html --
  Listener className=org.apache.catalina.core.JasperListener /

  !-- JMX Support for the Tomcat server. Documentation at
/docs/non-existent.html --
  Listener className=org.apache.catalina.mbeans.ServerLifecycleListener
/
  Listener
className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener /

I am using standalone tomcat (no apache) without SSL, without APR, I am not
using any manager or host-manager applications ..

Do I need these listeners or can I remove some/all of them?

-- 
View this message in context: 
http://www.nabble.com/Which-listeners-required-in-server.xml--tp23787784p23787784.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Which listeners required in server.xml?

[Martin Gainty]

DONT_NEEDdont need with Comment

 Running tomcat 6.0.18 server.xml has the following listener's enabled by
 default:
 
 
   !--APR library loader. Documentation at /docs/apr.html --
   Listener className=org.apache.catalina.core.AprLifecycleListener
 SSLEngine=on /
DONT_NEEDNO Implementation of LifecycleListener that will init and
 and destroy APR? then comment this out
 
   !--Initialize Jasper prior to webapps are loaded. Documentation at
 /docs/jasper-howto.html --
   Listener className=org.apache.catalina.core.JasperListener /
DONT_NEEDNO implementation of listener is designed to initialize Jasper before 
web applications are
 started then DONT_NEEDcomment out
 
   !-- JMX Support for the Tomcat server. Documentation at
 /docs/non-existent.html --
   Listener className=org.apache.catalina.mbeans.ServerLifecycleListener
 /
DONT_NEEDNo implementation of LifecycleListener that
 instantiates the set of MBeans associated with the DONT_NEEDcomponents of a
 running instance of Catalina. 
(MX Agents) then comment this out

   Listener
 className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener /
DONT_NEEDNo Implementation of LifecycleListener that instantiates the
 set of MBeans associated with global DONT_NEEDJNDI resources that are subject 
to
 management. 
then comment this out!

 
 I am using standalone tomcat (no apache) without SSL, without APR, I am not
 using any manager or host-manager applications ..
 
 Do I need these listeners or can I remove some/all of them?
DONT_NEEDIf No Apr then remove AprLifecycleListener
DONT_NEEDIf No Jsp then remove JasperListener
DONT_NEEDIf No MBean then remove ServerLifecycleListener
DONT_NEEDIf No JNDI then remove GlobalResourcesLifecycleListener

 -- 
 View this message in context: 
 http://www.nabble.com/Which-listeners-required-in-server.xml--tp23787784p23787784.html
 Sent from the Tomcat - User mailing list archive at Nabble.com.
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 

_
Hotmail® has ever-growing storage! Don’t worry about storage limits.
http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage1_052009

RE: Which listeners required in server.xml?

[johnrock]

mgainty wrote:
 
 Do I need these listeners or can I remove some/all of them?
 DONT_NEEDIf No Apr then remove AprLifecycleListener
 DONT_NEEDIf No Jsp then remove JasperListener
 DONT_NEEDIf No MBean then remove ServerLifecycleListener
 DONT_NEEDIf No JNDI then remove GlobalResourcesLifecycleListener
 
Thank you very much. I am not explicitly using JNDI or MBean in my app, but
I am not sure if Tomcat relies on this functionality either internally or
with Spring?



-- 
View this message in context: 
http://www.nabble.com/Which-listeners-required-in-server.xml--tp23787784p23788146.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Which listeners required in server.xml?

[Martin Gainty]

Spring and/or DI frameworks do not use either JNDI or MXbean unless 
specifically configured to do so
free to disable those listeners as they are serve no useful purpose

Martin Gainty 
__ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
 
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.




 Date: Fri, 29 May 2009 15:50:00 -0700
 From: johnpi...@yahoo.com
 To: users@tomcat.apache.org
 Subject: RE: Which listeners required in server.xml?
 
 
 
 mgainty wrote:
  
  Do I need these listeners or can I remove some/all of them?
  DONT_NEEDIf No Apr then remove AprLifecycleListener
  DONT_NEEDIf No Jsp then remove JasperListener
  DONT_NEEDIf No MBean then remove ServerLifecycleListener
  DONT_NEEDIf No JNDI then remove GlobalResourcesLifecycleListener
  
 Thank you very much. I am not explicitly using JNDI or MBean in my app, but
 I am not sure if Tomcat relies on this functionality either internally or
 with Spring?
 
 
 
 -- 
 View this message in context: 
 http://www.nabble.com/Which-listeners-required-in-server.xml--tp23787784p23788146.html
 Sent from the Tomcat - User mailing list archive at Nabble.com.
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 

_
Hotmail® has ever-growing storage! Don’t worry about storage limits.
http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage1_052009

Re: Which listeners required in server.xml?

[Bill Barker]

johnrock johnpi...@yahoo.com wrote in message 
news:23787784.p...@talk.nabble.com...

 Running tomcat 6.0.18 server.xml has the following listener's enabled by
 default:


  !--APR library loader. Documentation at /docs/apr.html --
  Listener className=org.apache.catalina.core.AprLifecycleListener
 SSLEngine=on /


If you are not using APR, than you don't need this (and removing it gets rid 
of a message at startup).

  !--Initialize Jasper prior to webapps are loaded. Documentation at
 /docs/jasper-howto.html --
  Listener className=org.apache.catalina.core.JasperListener /


If you are never going to use JSP pages, can probably remove it.  However, 
it's pretty light-weight so would leave it in just so that I don't have to 
spend time with any weird errors.

  !-- JMX Support for the Tomcat server. Documentation at
 /docs/non-existent.html --
  Listener className=org.apache.catalina.mbeans.ServerLifecycleListener
 /

This looks like it is left over from the admin webapp (RIP).  It doesn't 
look like it does anything particularly useful anymore, but again the 
warning about weird errors.

  Listener
 className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener /


Also left over from the admin webapp (RIP).  This one really doesn't do 
anything particularly useful anymore, so it is safe to remove.  It should 
probably be removed from the distribution as well (at least for TC 7), since 
it was a bad idea in the first place.

 I am using standalone tomcat (no apache) without SSL, without APR, I am 
 not
 using any manager or host-manager applications ..

 Do I need these listeners or can I remove some/all of them?

 -- 
 View this message in context: 
 http://www.nabble.com/Which-listeners-required-in-server.xml--tp23787784p23787784.html
 Sent from the Tomcat - User mailing list archive at Nabble.com. 




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Which listeners required in server.xml?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

John,

On 5/29/2009 6:08 PM, johnrock wrote:
 I am using standalone tomcat (no apache) without SSL, without APR, I am not
 using any manager or host-manager applications ..

Adding the APR library will give you a significant performance
improvement even with the plain-old HTTP connector. It might be worth
installing APR and leaving that listener in there.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkogqhcACgkQ9CaO5/Lv0PDCKwCfRq5BCxjaog1MQYTqbMzY7zpc
r4AAn0cu/kmZmWNq+stofg9zLEXeDP0p
=/Oi6
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Which listeners required in server.xml?

[Bill Barker]

Christopher Schultz ch...@christopherschultz.net wrote in message 
news:4a20aa17.2050...@christopherschultz.net...
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 John,

 On 5/29/2009 6:08 PM, johnrock wrote:
 I am using standalone tomcat (no apache) without SSL, without APR, I am 
 not
 using any manager or host-manager applications ..

 Adding the APR library will give you a significant performance
 improvement even with the plain-old HTTP connector. It might be worth
 installing APR and leaving that listener in there.


Urm, and u are basing this on what?  A low-traffic dynamic site should see 
next to nothing using APR, and could even lose (given the interlocks to 
JNI).  It all depends on who is smarter, the JVM developer, or the APR 
develper for CentOS.

Again, to the OP, profile both configurations for your OS, and make the 
decision then.

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (MingW32)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAkogqhcACgkQ9CaO5/Lv0PDCKwCfRq5BCxjaog1MQYTqbMzY7zpc
 r4AAn0cu/kmZmWNq+stofg9zLEXeDP0p
 =/Oi6
 -END PGP SIGNATURE- 




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Session listeners and clustering problem

[David Rees]

Hi,

I'm trying to implement a session listener so that I can check the
status of a session.  Essentially, I need to maintain a Map of all the
sessions.  I would add sessions to this map based on business logic.

The problem I have is that the behavior of the listeners is different
when clustering is enabled compared to when it's not enabled.

Without clustering on, an instance of HttpSessionActivationListener in
each session has it's didActivate or willPassivate functions called
when Tomcat is shutting down or starting up.

With clustering on, I get no such notifications. Or any other
notifications when a node starts up and loads it's sessions from the
cluster.  But I do notice through a HttpSessionListener, every single
session gets destroyed when shutting down a node.

So when clustering is enabled, there is no way for me to rebuild a
list of sessions that are being managed.

This is on Tomcat 5.5.27.

Anyone else hit this problem?  Anyone else have any ideas on how to
work around it?

Thanks

Dave

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: tomcat-5.5.20 tld listeners from jars only from .../tomcat/common/lib?

[Zsolt Koppany]

David,

it is very simple. If the jar file (ditchnet-tabs-taglib.jar
http://ditchnet.org/tabs/) is under
/install_dir/tomcat/webapps/APPLICATION/WEB-INF/lib the
ServletContextListener is not called I need the following lines in my
web.xml:

listener
 
listener-classorg.ditchnet.jsp.taglib.tabs.listener.TabServletContextListe
ner/listener-class
/listener

If the jar file is under /install_dir/tomcat/common/lib/ the
TabServletContextListener is called and I don't need the lines above in
web.xml.

I use jdk1.5.0_08, Windows-XP.

Zsolt 

 -Original Message-
 From: David Smith [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, November 01, 2006 4:24 PM
 To: Tomcat Users List
 Subject: Re: tomcat-5.5.20 tld listeners from jars only from
 .../tomcat/common/lib?
 
 While this relevant to a more generic question of classloaders, it
 doesn't address the OP's issue.
 
 Zsolt -- can we get a bit more context for this?  My experience with
 taglibs is they work just find under tc 5.5.x.
 
 --David
 
 Martin Gainty wrote:
 
 Hi Zsolt-
 
 Straight from the doc
 http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html
 If you're using webappX classloader the search order is
   a.. Bootstrap classes of your JVM
   b.. System class loader classses (described above)
 a.. $CATALINA_HOME/bin/bootstrap.jar - Contains the main() method
 that is used to initialize the Tomcat 5 server, and the class loader
 implementation classes it depends on.
 b.. $JAVA_HOME/lib/tools.jar - Contains the javac compiler used to
 convert JSP pages into servlet classes.
 c.. $CATALINA_HOME/bin/commons-logging-api.jar - Jakarta commons
 logging API.
 d.. $CATALINA_HOME/bin/commons-daemon.jar - Jakarta commons daemon
 API.
 e.. jmx.jar - The JMX 1.2 implementation.
   c.. /WEB-INF/classes of your web application
   d.. /WEB-INF/lib/*.jar of your web application
   e.. $CATALINA_HOME/common/classes
   f.. $CATALINA_HOME/common/endorsed/*.jar
   g.. $CATALINA_HOME/common/i18n/*.jar
   h.. $CATALINA_HOME/common/lib/*.jar
   i.. $CATALINA_BASE/shared/classes
   j.. $CATALINA_BASE/shared/lib/*.jar
 
   Martin--
 This e-mail communication and any attachments may contain confidential
 and privileged information for the use of the
 designated recipients named above. If you are not the intended recipient,
 you are hereby notified that you have received
 this communication in error and that any review, disclosure,
 dissemination, distribution or copying of it or its
 contents
 - Original Message -
 From: Zsolt [EMAIL PROTECTED]
 To: Tomcat Users List tomcat-user@jakarta.apache.org
 Sent: Tuesday, October 24, 2006 10:13 AM
 Subject: tomcat-5.5.20 tld listeners from jars only from
 .../tomcat/common/lib?
 
 
 
 
 Hi,
 
 After some debuging I have the impressions that tomcat-5.5.20 searches
 for
 tld listeners only in jars files under /tomcat/common/lib.
 
 Am I right? Is that a bug or a (new) feature?
 
 Zsolt
 
 
 
 
 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
 
 
 
 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: tomcat-5.5.20 tld listeners from jars only from .../tomcat/common/lib?

[Mark Thomas]

Zsolt Koppany wrote:
 David,
 
 it is very simple. If the jar file (ditchnet-tabs-taglib.jar
 http://ditchnet.org/tabs/) is under
 /install_dir/tomcat/webapps/APPLICATION/WEB-INF/lib the
 ServletContextListener is not called I need the following lines in my
 web.xml:
 
 listener
  
 listener-classorg.ditchnet.jsp.taglib.tabs.listener.TabServletContextListe
 ner/listener-class
 /listener
 
 If the jar file is under /install_dir/tomcat/common/lib/ the
 TabServletContextListener is called and I don't need the lines above in
 web.xml.

You are not alone. This appears to be a bug.
http://issues.apache.org/bugzilla/show_bug.cgi?id=40809

Mark


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: tomcat-5.5.20 tld listeners from jars only from .../tomcat/common/lib?

[Martin Gainty]

Hi Zsolt-

Straight from the doc
http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html
If you're using webappX classloader the search order is
  a.. Bootstrap classes of your JVM 
  b.. System class loader classses (described above) 
a.. $CATALINA_HOME/bin/bootstrap.jar - Contains the main() method that is 
used to initialize the Tomcat 5 server, and the class loader implementation 
classes it depends on. 
b.. $JAVA_HOME/lib/tools.jar - Contains the javac compiler used to 
convert JSP pages into servlet classes. 
c.. $CATALINA_HOME/bin/commons-logging-api.jar - Jakarta commons logging 
API. 
d.. $CATALINA_HOME/bin/commons-daemon.jar - Jakarta commons daemon API. 
e.. jmx.jar - The JMX 1.2 implementation. 
  c.. /WEB-INF/classes of your web application 
  d.. /WEB-INF/lib/*.jar of your web application 
  e.. $CATALINA_HOME/common/classes 
  f.. $CATALINA_HOME/common/endorsed/*.jar 
  g.. $CATALINA_HOME/common/i18n/*.jar 
  h.. $CATALINA_HOME/common/lib/*.jar 
  i.. $CATALINA_BASE/shared/classes 
  j.. $CATALINA_BASE/shared/lib/*.jar 

  Martin--
This e-mail communication and any attachments may contain confidential and 
privileged information for the use of the 
designated recipients named above. If you are not the intended recipient, you 
are hereby notified that you have received
this communication in error and that any review, disclosure, dissemination, 
distribution or copying of it or its 
contents
- Original Message - 
From: Zsolt [EMAIL PROTECTED]
To: Tomcat Users List tomcat-user@jakarta.apache.org
Sent: Tuesday, October 24, 2006 10:13 AM
Subject: tomcat-5.5.20 tld listeners from jars only from .../tomcat/common/lib?


 Hi,
 
 After some debuging I have the impressions that tomcat-5.5.20 searches for
 tld listeners only in jars files under /tomcat/common/lib.
 
 Am I right? Is that a bug or a (new) feature?
 
 Zsolt
 
 
 
 
 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: tomcat-5.5.20 tld listeners from jars only from .../tomcat/common/lib?

[David Smith]

While this relevant to a more generic question of classloaders, it 
doesn't address the OP's issue.


Zsolt -- can we get a bit more context for this?  My experience with 
taglibs is they work just find under tc 5.5.x.


--David

Martin Gainty wrote:


Hi Zsolt-

Straight from the doc
http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html
If you're using webappX classloader the search order is
 a.. Bootstrap classes of your JVM 
 b.. System class loader classses (described above) 
   a.. $CATALINA_HOME/bin/bootstrap.jar - Contains the main() method that is used to initialize the Tomcat 5 server, and the class loader implementation classes it depends on. 
   b.. $JAVA_HOME/lib/tools.jar - Contains the javac compiler used to convert JSP pages into servlet classes. 
   c.. $CATALINA_HOME/bin/commons-logging-api.jar - Jakarta commons logging API. 
   d.. $CATALINA_HOME/bin/commons-daemon.jar - Jakarta commons daemon API. 
   e.. jmx.jar - The JMX 1.2 implementation. 
 c.. /WEB-INF/classes of your web application 
 d.. /WEB-INF/lib/*.jar of your web application 
 e.. $CATALINA_HOME/common/classes 
 f.. $CATALINA_HOME/common/endorsed/*.jar 
 g.. $CATALINA_HOME/common/i18n/*.jar 
 h.. $CATALINA_HOME/common/lib/*.jar 
 i.. $CATALINA_BASE/shared/classes 
 j.. $CATALINA_BASE/shared/lib/*.jar 


 Martin--
This e-mail communication and any attachments may contain confidential and privileged information for the use of the 
designated recipients named above. If you are not the intended recipient, you are hereby notified that you have received
this communication in error and that any review, disclosure, dissemination, distribution or copying of it or its 
contents
- Original Message - 
From: Zsolt [EMAIL PROTECTED]

To: Tomcat Users List tomcat-user@jakarta.apache.org
Sent: Tuesday, October 24, 2006 10:13 AM
Subject: tomcat-5.5.20 tld listeners from jars only from .../tomcat/common/lib?


 


Hi,

After some debuging I have the impressions that tomcat-5.5.20 searches for
tld listeners only in jars files under /tomcat/common/lib.

Am I right? Is that a bug or a (new) feature?

Zsolt




-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

   








-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

tomcat-5.5.20 tld listeners from jars only from .../tomcat/common/lib?

[Zsolt]

Hi,

After some debuging I have the impressions that tomcat-5.5.20 searches for
tld listeners only in jars files under /tomcat/common/lib.

Am I right? Is that a bug or a (new) feature?

Zsolt




-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Tomcat 5.0.28: ROOT.Context Error - application listeners issue.

[Todd Patrick]

Tomcat 5.0.28
Eclipse Version: 3.2.0

When I start Tomcat from within Eclipse, I receive the following in my
Console. My application still works fine, but I have no clue on what
could be causing this error to be displayed?

2006-09-19 08:46:20,079 INFO
[org.apache.catalina.core.StandardHostDeployer] - Installing web
application at context path  from URL
file:C:\javaworkspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\webapps\ROOT

2006-09-19 08:46:20,157 ERROR [tomcat.localhost.ROOT.Context] -
Skipped installing application listeners due to previous error(s)

2006-09-19 08:46:20,157 ERROR [tomcat.localhost.ROOT.Context] - Error
listenerStart

2006-09-19 08:46:20,157 ERROR [tomcat.localhost.ROOT.Context] -
Context startup failed due to previous errors

In the 
C:\javaworkspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\webapps\ROOT
directory there is a WEB-INF directory that contains a web.xml file.
The web.xml file contains:

?xml version=1.0 encoding=UTF-8?
web-app id=WebApp_ID version=2.4
xmlns=http://java.sun.com/xml/ns/j2ee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;
/web-app


I'd greatly appreciate any help.

Thanks,
--
--Todd

[EMAIL PROTECTED]

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat 5.0.28: ROOT.Context Error - application listeners issue.

[Martin Gainty]

Todd

Here is the web.xml from my root webapp
?xml version=1.0 encoding=ISO-8859-1?
!--
  Copyright 2004 The Apache Software Foundation
  Licensed under the Apache License, Version 2.0 (the License);
  you may not use this file except in compliance with the License.
  You may obtain a copy of the License at
  http://www.apache.org/licenses/LICENSE-2.0
  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an AS IS BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.
--
web-app xmlns=http://java.sun.com/xml/ns/j2ee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee 
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;
version=2.4
  display-nameWelcome to Tomcat/display-name
  description
 Welcome to Tomcat
  /description

!-- JSPC servlet mappings start --
servlet
servlet-nameorg.apache.jsp.index_jsp/servlet-name
servlet-classorg.apache.jsp.index_jsp/servlet-class
/servlet
servlet-mapping
servlet-nameorg.apache.jsp.index_jsp/servlet-name
url-pattern/index.jsp/url-pattern
/servlet-mapping
!-- JSPC servlet mappings end --
/web-app

So my question is What happens when you deploy the root.war (normally)?

M-
*
This email message and any files transmitted with it contain confidential
information intended only for the person(s) to whom this email message is
addressed.  If you have received this email message in error, please notify
the sender immediately by telephone or email and destroy the original
message without making a copy.  Thank you.



- Original Message - 
From: Todd Patrick [EMAIL PROTECTED]
To: users@tomcat.apache.org
Sent: Tuesday, September 19, 2006 9:50 AM
Subject: Tomcat 5.0.28: ROOT.Context Error - application listeners issue.


 Tomcat 5.0.28
 Eclipse Version: 3.2.0
 
 When I start Tomcat from within Eclipse, I receive the following in my
 Console. My application still works fine, but I have no clue on what
 could be causing this error to be displayed?
 
 2006-09-19 08:46:20,079 INFO
 [org.apache.catalina.core.StandardHostDeployer] - Installing web
 application at context path  from URL
 file:C:\javaworkspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\webapps\ROOT
 
 2006-09-19 08:46:20,157 ERROR [tomcat.localhost.ROOT.Context] -
 Skipped installing application listeners due to previous error(s)
 
 2006-09-19 08:46:20,157 ERROR [tomcat.localhost.ROOT.Context] - Error
 listenerStart
 
 2006-09-19 08:46:20,157 ERROR [tomcat.localhost.ROOT.Context] -
 Context startup failed due to previous errors
 
 In the 
 C:\javaworkspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\webapps\ROOT
 directory there is a WEB-INF directory that contains a web.xml file.
 The web.xml file contains:
 
 ?xml version=1.0 encoding=UTF-8?
 web-app id=WebApp_ID version=2.4
 xmlns=http://java.sun.com/xml/ns/j2ee;
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee
 http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;
 /web-app
 
 
 I'd greatly appreciate any help.
 
 Thanks,
 -- 
 --Todd
 
 [EMAIL PROTECTED]
 
 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: Tomcat 5.0.28: ROOT.Context Error - application listeners issue.

[Todd Patrick]

Martin: Thanks for the response. Your example helped me realized that
my install was really messed up.

Thanks,

--Todd

On 9/19/06, Martin Gainty [EMAIL PROTECTED] wrote:

Todd

Here is the web.xml from my root webapp
?xml version=1.0 encoding=ISO-8859-1?
!--
  Copyright 2004 The Apache Software Foundation
  Licensed under the Apache License, Version 2.0 (the License);
  you may not use this file except in compliance with the License.
  You may obtain a copy of the License at
  http://www.apache.org/licenses/LICENSE-2.0
  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an AS IS BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.
--
web-app xmlns=http://java.sun.com/xml/ns/j2ee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee 
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;
version=2.4
  display-nameWelcome to Tomcat/display-name
  description
 Welcome to Tomcat
  /description

!-- JSPC servlet mappings start --
servlet
servlet-nameorg.apache.jsp.index_jsp/servlet-name
servlet-classorg.apache.jsp.index_jsp/servlet-class
/servlet
servlet-mapping
servlet-nameorg.apache.jsp.index_jsp/servlet-name
url-pattern/index.jsp/url-pattern
/servlet-mapping
!-- JSPC servlet mappings end --
/web-app

So my question is What happens when you deploy the root.war (normally)?

M-
*
This email message and any files transmitted with it contain confidential
information intended only for the person(s) to whom this email message is
addressed.  If you have received this email message in error, please notify
the sender immediately by telephone or email and destroy the original
message without making a copy.  Thank you.



- Original Message -
From: Todd Patrick [EMAIL PROTECTED]
To: users@tomcat.apache.org
Sent: Tuesday, September 19, 2006 9:50 AM
Subject: Tomcat 5.0.28: ROOT.Context Error - application listeners issue.


 Tomcat 5.0.28
 Eclipse Version: 3.2.0

 When I start Tomcat from within Eclipse, I receive the following in my
 Console. My application still works fine, but I have no clue on what
 could be causing this error to be displayed?

 2006-09-19 08:46:20,079 INFO
 [org.apache.catalina.core.StandardHostDeployer] - Installing web
 application at context path  from URL
 
file:C:\javaworkspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\webapps\ROOT

 2006-09-19 08:46:20,157 ERROR [tomcat.localhost.ROOT.Context] -
 Skipped installing application listeners due to previous error(s)

 2006-09-19 08:46:20,157 ERROR [tomcat.localhost.ROOT.Context] - Error
 listenerStart

 2006-09-19 08:46:20,157 ERROR [tomcat.localhost.ROOT.Context] -
 Context startup failed due to previous errors

 In the 
C:\javaworkspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\webapps\ROOT
 directory there is a WEB-INF directory that contains a web.xml file.
 The web.xml file contains:

 ?xml version=1.0 encoding=UTF-8?
 web-app id=WebApp_ID version=2.4
 xmlns=http://java.sun.com/xml/ns/j2ee;
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee
 http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;
 /web-app


 I'd greatly appreciate any help.

 Thanks,
 --
 --Todd

 [EMAIL PROTECTED]

 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]





--
--Todd

[EMAIL PROTECTED]

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: SEVERE: Error reading tld listeners javax.servlet.ServletException. HELP

[Marc Farrow]

Have you checked the version of the struts jar files to make sure they are
the same level from your old install of tomcat to your new install?

It may just be that tomcat 5.5.X expects a certain level of struts.  /shrug


On 6/7/06, Richard DeGrande [EMAIL PROTECTED] wrote:


I've recently upgraded to tomcat 5.5.15.  I'm migrating current apps the
the new tomcat.  I get this error when starting/deploying a specific
app.  I have one other app deployed, it too uses struts,  I have no
problems with it.

thanks



Jun 7, 2006 4:28:51 PM org.apache.catalina.core.StandardContext
processTlds
SEVERE: Error reading tld listeners javax.servlet.ServletException:
Exception processing TLD at resource path /WEB-INF/struts-logic.tld in
context /paimport
javax.servlet.ServletException: Exception processing TLD at resource
path /WEB-INF/struts-logic.tld in context /paimport
   at
org.apache.catalina.startup.TldConfig.tldScanTld(TldConfig.java:547)
   at
org.apache.catalina.startup.TldConfig.execute(TldConfig.java:300)
   at
org.apache.catalina.core.StandardContext.processTlds(StandardContext.jav

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Marc Farrow

Re: SEVERE: Error reading tld listeners javax.servlet.ServletException.

[RickD]

Sorry, I should have included this in my original email.  I'm also converting
from struts 1.1 - struts 1.2.9.  I wanted to take advantage of some of the
features offered by 2.4/2.0 servlet/jsp.  So, the jars are different.

thx
--
View this message in context: 
http://www.nabble.com/SEVERE%3A-Error-reading-tld-listeners-javax.servlet.ServletException.---HELP-t1751842.html#a4773129
Sent from the Tomcat - User forum at Nabble.com.


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

SEVERE: Error reading tld listeners javax.servlet.ServletException. HELP

[Richard DeGrande]

I've recently upgraded to tomcat 5.5.15.  I'm migrating current apps the
the new tomcat.  I get this error when starting/deploying a specific
app.  I have one other app deployed, it too uses struts,  I have no
problems with it.

thanks



Jun 7, 2006 4:28:51 PM org.apache.catalina.core.StandardContext
processTlds
SEVERE: Error reading tld listeners javax.servlet.ServletException:
Exception processing TLD at resource path /WEB-INF/struts-logic.tld in
context /paimport
javax.servlet.ServletException: Exception processing TLD at resource
path /WEB-INF/struts-logic.tld in context /paimport
at
org.apache.catalina.startup.TldConfig.tldScanTld(TldConfig.java:547)
at
org.apache.catalina.startup.TldConfig.execute(TldConfig.java:300)
at
org.apache.catalina.core.StandardContext.processTlds(StandardContext.jav

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Error processing TLD listeners

[Farrow, Marc]

Try removing the leading slash in your TLD path..

Change 
/WEB-INF/tlds/fmt.tld
TO
WEB-INF/tlds/fmt.tld


Not sure if this will help, but worth a shot.

-Original Message-
From: A. Alonso Dominguez [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 12, 2006 4:19 AM
To: users@tomcat.apache.org
Subject: Error processing TLD listeners

Hi there,

I'm having problems starting tomcat. My current version is 5.5.9 and when it
starts it always logs the following error message:

SEVERE: Error reading tld listeners javax.servlet.ServletException:
Exception processing TLD at resource path /WEB-INF/tlds/fmt.tld in context
/portal-webapp

javax.servlet.ServletException: Exception processing TLD at resource path
/WEB-INF/tlds/fmt.tld in context /portal-webapp
at org.apache.catalina.startup.TldConfig.tldScanTld(TldConfig.java
:547)
at org.apache.catalina.startup.TldConfig.execute(TldConfig.java:300)
at org.apache.catalina.core.StandardContext.processTlds(
StandardContext.java:4193)
at org.apache.catalina.core.StandardContext.start(
StandardContext.java:4049)
at org.apache.catalina.core.ContainerBase.addChildInternal(
ContainerBase.java:759)
at org.apache.catalina.core.ContainerBase.access$000(
ContainerBase.java:121)
at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(
ContainerBase.java:143)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.catalina.core.ContainerBase.addChild(
ContainerBase.java:737)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java
:524)
at org.apache.catalina.startup.HostConfig.deployDirectory(
HostConfig.java:894)
at org.apache.catalina.startup.HostConfig.deployDirectories(
HostConfig.java:857)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java
:475)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java
:1102)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(
HostConfig.java:311)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(
LifecycleSupport.java:119)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java
:1020)
at org.apache.catalina.core.StandardHost.start(StandardHost.java
:718)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java
:1012)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java
:442)
at org.apache.catalina.core.StandardService.start(
StandardService.java:450)
at org.apache.catalina.core.StandardServer.start(StandardServer.java
:683)
at org.apache.catalina.startup.Catalina.start(Catalina.java:537)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:271)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:409)

The webapp at that context path uses servlet spec 2.4 but JSP taglibs 1.0,
maybe is there the problem?

Regards,
Alonso


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat 5.5.16 - Confirmation of Extra bytes at the end of class file listeners/ContextListener error

[PocJoc]

I've changed some class files and after the substitution, it works fine.
The files has been reemplaced with the 'zip' distribution and copied
directly to the 'exe' installation.
There are:

Tomcat Path\webapps\jsp-examples\plugin\applet\Clock2.class
Tomcat Path\webapps\jsp-examples\WEB-INF\classes\servletToJsp.class
Tomcat Path\webapps\jsp-examples\WEB-INF\classes\cal\Entries.class
Tomcat Path\webapps\jsp-examples\WEB-INF\classes\cal\Entry.class
Tomcat Path\webapps\jsp-examples\WEB-INF\classes\cal\JspCalendar.class
Tomcat Path\webapps\jsp-examples\WEB-INF\classes\cal\TableBean.class
Tomcat Path\webapps\jsp-examples\WEB-INF\classes\checkbox\CheckTest.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\colors\ColorGameBean.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\compressionFilters\CompressionFilter.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\compressionFilters\CompressionFilterTestServlet.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\compressionFilters\CompressionResponseStream.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\compressionFilters\CompressionServletResponseWrapper.class
Tomcat Path\webapps\jsp-examples\WEB-INF\classes\dates\JspCalendar.class
Tomcat Path\webapps\jsp-examples\WEB-INF\classes\error\Smart.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\examples\ExampleTagBase.class
Tomcat Path\webapps\jsp-examples\WEB-INF\classes\examples\FooTag.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\examples\FooTagExtraInfo.class
Tomcat Path\webapps\jsp-examples\WEB-INF\classes\examples\LogTag.class
Tomcat Path\webapps\jsp-examples\WEB-INF\classes\examples\ShowSource.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\filters\ExampleFilter.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\filters\RequestDumperFilter.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\filters\SetCharacterEncodingFilter.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\jsp2\examples\BookBean.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\jsp2\examples\FooBean.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\jsp2\examples\el\Functions.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\jsp2\examples\simpletag\EchoAttributesTag.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\jsp2\examples\simpletag\FindBookSimpleTag.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\jsp2\examples\simpletag\HelloWorldSimpleTag.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\jsp2\examples\simpletag\RepeatSimpleTag.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\jsp2\examples\simpletag\ShuffleSimpleTag.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\jsp2\examples\simpletag\TileSimpleTag.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\listeners\ContextListener.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\listeners\SessionListener.class
Tomcat Path\webapps\jsp-examples\WEB-INF\classes\num\NumberGuessBean.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\org\apache\jsp\source_jsp.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\org\apache\jsp\cal\cal1_jsp.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\org\apache\jsp\cal\cal2_jsp.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\org\apache\jsp\checkbox\checkresult_jsp.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\org\apache\jsp\colors\colrs_jsp.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\org\apache\jsp\dates\date_jsp.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\org\apache\jsp\error\errorpge_jsp.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\org\apache\jsp\error\err_jsp.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\org\apache\jsp\forward\forward_jsp.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\org\apache\jsp\forward\one_jsp.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\org\apache\jsp\include\foo_jsp.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\org\apache\jsp\include\include_jsp.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\org\apache\jsp\jsp2\el\basic_002darithmetic_jsp.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\org\apache\jsp\jsp2\el\basic_002dcomparisons_jsp.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\org\apache\jsp\jsp2\el\functions_jsp.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\org\apache\jsp\jsp2\el\implicit_002dobjects_jsp.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\org\apache\jsp\jsp2\jspattribute\jspattribute_jsp.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\org\apache\jsp\jsp2\jspattribute\shuffle_jsp.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\org\apache\jsp\jsp2\jspx\basic_jspx.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\org\apache\jsp\jsp2\jspx\textRotate_jspx.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\org\apache\jsp\jsp2\misc\config_jsp.class
Tomcat
Path\webapps\jsp-examples\WEB-INF\classes\org\apache\jsp\jsp2\misc\dynamicattrs_jsp.class
Tomcat
Path

Re: Tomcat 5.5.16 - Confirmation of Extra bytes at the end of class file listeners/ContextListener error

[Adam Hill]

Thanks for confirming I wasn't crazy :-)

adam...

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]