How to create/setup a referer log on Tomcat 5.5 server?
My company is using Tomcat 5.5 server to host several websites. Right now, we want to track the stats of web traffic, and a referer log on the server is required for some traffic analyzers. How do we setup such a log? -- View this message in context: http://www.nabble.com/How-to-create-setup-a-referer-log-on-Tomcat-5.5-server--tf4590694.html#a13104911 Sent from the Tomcat - User mailing list archive 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]
Tomcat takes over 1 minute to stop
Apache Tomcat version: 9.0.90 and above OS: Windows Server 2019 Tomcat Version Used Time Taken to stop Apache Tomcat/8.5.66~ 9 seconds Apache Tomcat/9.0.1 ~ 9 seconds Apache Tomcat/9.0.10~ 9 seconds Apache Tomcat/9.0.13~ 9 seconds Apache Tomcat/9.0.14~ 1 min 3 secs Apache Tomcat/9.0.16~ 1 min 3 secs Apache Tomcat/9.0.20~ 1 min 3 secs Apache Tomcat/9.0.30~ 1 min 3 secs Apache Tomcat/9.0.40~ 1 min 3 secs Apache Tomcat/9.0.44~ 1 min 3 secs Apache Tomcat/9.0.46~ 1 min 3 secs Apache Tomcat/9.0.75~ 1 min 3 secs Apache Tomcat/9.0.89~ 1 min 3 secs Apache Tomcat/9.0.90~ 1 min 3 secs Apache Tomcat/9.0.93~ 1 min 3 secs >From Tomcat changelog >(https://tomcat.apache.org/tomcat-9.0-doc/changelog.html#Tomcat_9.0.14_(markt): > Version 9.0.14 "Add a scheduled executor to the Server, which can be used to >process periodic utility tasks. The utility threads are non daemon by default. >(remm)", which has the default timeout of 60s for procrun. Workaround: to reduce the default timeout of 60s, I can supply it via Tomcat Monitor (Tomcat9w.exe) or while creating the Windows service. This workaround has worked up to version 9.0.89 and has stopped for version 9.0.90 and above. The difference is version 9.0.89 and lower uses Apache Commons Daemon procrun (1.3.x.0 64-bit) whereas version 9.0.90 and above uses Apache Commons Daemon procrun (1.4.0.0 64-bit). Questions: 1) Am I on the right rack with this procrun timeout? 2) If #1 is yes, does the upgrade from Apache Commons Daemon procrun (1.3.x.0 64-bit) to Apache Commons Daemon procrun (1.4.0.0 64-bit) cause the supplied timeout to be ignored so that the default of 60s is always in effect? 2) If #2 is yes, is there a workaround while waiting for a fix or must wait for a fix? Greatly appreciate your help !!! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat takes over 1 minute to stop
Thank you Mr. Stewart for a quick response !!! Yes sir !!! Everything (web app/configurations/settings, etc.) is the same except for the Tomcat versions with identical Tomcat settings for both versions as asked but also for up to version 9.0.93. I was able to move from version 9.0.14 because of the stated workaround. Now, the workaround is gone starting with version 9.0.90. From: Bill Stewart Sent: Tuesday, August 27, 2024 4:34 PM To: Tomcat Users List Subject: Re: Tomcat takes over 1 minute to stop On Tue, Aug 27, 2024 at 12:58 PM Quoc Nguyen wrote: Apache Tomcat/9.0.13~ 9 seconds > Apache Tomcat/9.0.14~ 1 min 3 secs > Are you using the exact same web app (and the exact same version of the web app, including all settings), as well as identical Tomcat settings, between 9.0.13 and 9.0.14? Bill - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat takes over 1 minute to stop
Thank you Mr. Thomas !!! Yes sir !!! I noticed that a clean Tomcat 9.0.93 install (as with other 9.0.9x versions) stops around 1s. I believe that it is so because it has no managed web apps/resources. Just Tomcat itself. I could be wrong. Yes, I noticed that there are warnings of non-daemon threads that weren't stopped in catalina.log. I read somewhere that they're just warnings; thus don't affect this process. There are no requests running at all while stopping Tomcat. Essentially, install/deploy different versions (9.0.89, 9.0.9x) of Tomcat with the same set of non-changing web apps and stop Tomcat via Windows service and record the stop times. Yes, I took the thread dumps while stopping version 9.0.90. There is a thread "DestroyJavaVM" that, after a few seconds after Tomcat receives the shutdown signal (maybe after it's done stopping its main stuff), was running for 60s. That said, there're no explanations for what happened: a) between version 9.0.13 and 9.0.14 with the introduction of "..scheduled executor to the Server..", which has default wait time of 60s and forces a Timeout in Tomcat9w.exe to get Tomcat stop under 60s. b) between version 9.0.89 and 9.0.90 after the upgrade of Apache Commons Daemon procrun to version 1.4.0.0, which has a default pause of 60s. More work/data to confirm: I'm working with Tomcat version 9.0.89 and 9.0.90 (where I noticed the change) in two different boxes. For version 9.0.90 box: started and stopped. Daemon logs below. Note: * Apache Commons Daemon procrun (1.4.0.0 64-bit) * exactly 60s wait until finished regardless of the Timeout set in Tomcat9w.exe [2024-08-29 13:41:58] [info] [13472] Apache Commons Daemon procrun (1.4.0.0 64-bit) started. [2024-08-29 13:41:58] [info] [13472] Running Service 'Tomcat9'... [2024-08-29 13:41:58] [info] [ 9148] Starting service... [2024-08-29 13:41:58] [error] [12380] Could not create instance of java/io/FileOutputStream [2024-08-29 13:41:59] [info] [ 9148] Service started in 1636 milliseconds. [2024-08-29 13:42:40] [info] [13472] Service SERVICE_CONTROL_STOP signalled. [2024-08-29 13:42:40] [info] [11996] Stopping service... [2024-08-29 13:43:06] [info] [11996] Service stop thread completed. [2024-08-29 13:44:06] [info] [13472] Run service finished. [2024-08-29 13:44:06] [info] [13472] Apache Commons Daemon procrun finished. For version 9.0.90 box: switched version 9.0.89 of Tomcat9.exe into this box. Started and stopped. Daemon logs below. Note: * Apache Commons Daemon procrun (1.3.4.0 64-bit) * stop time is definitely less than 60s if the Timeout set in Tomcat9w.exe is less than 60 and ~63s (or 1 min 3 secs as reported) when set to 0 (out of the box) * the last two log lines of "out of the box" don't appear in the log for Timeout being set to 5. Speculation: the process is short-circuited taking into account the set Timeout. The Timeout was set for 5: [2024-08-29 14:08:04] [info] [11012] Apache Commons Daemon procrun (1.3.4.0 64-bit) started. [2024-08-29 14:08:04] [info] [11012] Running Service 'Tomcat9'... [2024-08-29 14:08:04] [info] [14356] Starting service... [2024-08-29 14:08:05] [error] [ 6740] Could not create instance of java/io/FileOutputStream [2024-08-29 14:08:06] [info] [14356] Service started in 1648 milliseconds. [2024-08-29 14:08:47] [info] [11012] Service SERVICE_CONTROL_STOP signalled. [2024-08-29 14:08:47] [info] [14432] Stopping service... [2024-08-29 14:08:58] [info] [14432] Service stop thread completed. The Timeout was set for 0 (out of the box): [2024-08-29 14:43:51] [info] [ 8848] Apache Commons Daemon procrun (1.3.4.0 64-bit) started. [2024-08-29 14:43:51] [info] [ 8848] Running Service 'Tomcat9'... [2024-08-29 14:43:51] [info] [ 8796] Starting service... [2024-08-29 14:43:52] [error] [ 1688] Could not create instance of java/io/FileOutputStream [2024-08-29 14:43:53] [info] [ 8796] Service started in 1641 milliseconds. [2024-08-29 14:44:47] [info] [ 8848] Service SERVICE_CONTROL_STOP signalled. [2024-08-29 14:44:47] [info] [15996] Stopping service... [2024-08-29 14:45:00] [info] [15996] Service stop thread completed. [2024-08-29 14:46:00] [info] [ 8848] Run service finished. [2024-08-29 14:46:00] [info] [ 8848] Apache Commons Daemon procrun finished. All that said, I believe the procrun version is the difference. Greatly appreciate your help !!! From: Mark Thomas Sent: Thursday, August 29, 2024 9:22 AM To: users@tomcat.apache.org Subject: Re: Tomcat takes over 1 minute to stop On 27/08/2024 21:41, Christopher Schultz wrote: > Quoc, > > On 8/27/24 14:58, Quoc Nguyen wrote: >> Apache Tomcat version: 9.0.90 and above >> OS: Windows Server 2019 >> >> Tomcat Version UsedTime Taken to stop >> >> Apache Tomcat/8.5.66~ 9 seconds >> Apache T
Re: Tomcat takes over 1 minute to stop
Thank you Mr. Shultz !!! We've had warnings like the below forever. I can confirm that these have not affected stopping in anyway whatsoever. WARNING [Catalina-utility-11] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [web app name] appears to have started a thread named [thread name] but has failed to stop it. This is very likely to create a memory leak.. We did try to fix this in the form of a context listener servlet to clean up these threads during destroying the context process but, again, this has had no effects whatsoever. === Tomcat9w.exe --> Shutdown tab --> Timeout >From the logs that I sent, I believe that: Apache Commons Daemon procrun (1.3.4.0 64-bit) --> took this Timeout into account Apache Commons Daemon procrun (1.4.0.0 64-bit) --> did NOT take this Timeout into account From: Christopher Schultz Sent: Thursday, August 29, 2024 5:59 PM To: users@tomcat.apache.org Subject: Re: Tomcat takes over 1 minute to stop Quoc, On 8/29/24 15:23, Quoc Nguyen wrote: > Thank you Mr. Thomas !!! > > Yes sir !!! I noticed that a clean Tomcat 9.0.93 install (as with other > 9.0.9x versions) stops around 1s. I believe that it is so because it has no > managed web apps/resources. Just Tomcat itself. I could be wrong. > > Yes, I noticed that there are warnings of non-daemon threads that weren't > stopped in catalina.log. I read somewhere that they're just warnings; thus > don't affect this process. > > There are no requests running at all while stopping Tomcat. Essentially, > install/deploy different versions (9.0.89, 9.0.9x) of Tomcat with the same > set of non-changing web apps and stop Tomcat via Windows service and record > the stop times. > > Yes, I took the thread dumps while stopping version 9.0.90. There is a thread > "DestroyJavaVM" that, after a few seconds after Tomcat receives the shutdown > signal (maybe after it's done stopping its main stuff), was running for 60s. > > That said, there're no explanations for what happened: > > a) between version 9.0.13 and 9.0.14 with the introduction of "..scheduled > executor to the Server..", which has default wait time of 60s and forces a > Timeout in Tomcat9w.exe to get Tomcat stop under 60s. > b) between version 9.0.89 and 9.0.90 after the upgrade of Apache Commons > Daemon procrun to version 1.4.0.0, which has a default pause of 60s. > > More work/data to confirm: I'm working with Tomcat version 9.0.89 and 9.0.90 > (where I noticed the change) in two different boxes. > > For version 9.0.90 box: started and stopped. Daemon logs below. > > Note: > > * Apache Commons Daemon procrun (1.4.0.0 64-bit) > * exactly 60s wait until finished regardless of the Timeout set in > Tomcat9w.exe > > [2024-08-29 13:41:58] [info] [13472] Apache Commons Daemon procrun (1.4.0.0 > 64-bit) started. > [2024-08-29 13:41:58] [info] [13472] Running Service 'Tomcat9'... > [2024-08-29 13:41:58] [info] [ 9148] Starting service... > [2024-08-29 13:41:58] [error] [12380] Could not create instance of > java/io/FileOutputStream > [2024-08-29 13:41:59] [info] [ 9148] Service started in 1636 milliseconds. > [2024-08-29 13:42:40] [info] [13472] Service SERVICE_CONTROL_STOP signalled. > [2024-08-29 13:42:40] [info] [11996] Stopping service... > [2024-08-29 13:43:06] [info] [11996] Service stop thread completed. > [2024-08-29 13:44:06] [info] [13472] Run service finished. > [2024-08-29 13:44:06] [info] [13472] Apache Commons Daemon procrun finished. > > > For version 9.0.90 box: switched version 9.0.89 of Tomcat9.exe into this box. > Started and stopped. Daemon logs below. > > Note: > > * Apache Commons Daemon procrun (1.3.4.0 64-bit) > * stop time is definitely less than 60s if the Timeout set in Tomcat9w.exe is > less than 60 and ~63s (or 1 min 3 secs as reported) when set to 0 (out of > the box) > * the last two log lines of "out of the box" don't appear in the log for > Timeout being set to 5. Speculation: the process is short-circuited taking > into account the set Timeout. > > The Timeout was set for 5: > > [2024-08-29 14:08:04] [info] [11012] Apache Commons Daemon procrun (1.3.4.0 > 64-bit) started. > [2024-08-29 14:08:04] [info] [11012] Running Service 'Tomcat9'... > [2024-08-29 14:08:04] [info] [14356] Starting service... > [2024-08-29 14:08:05] [error] [ 6740] Could not create instance of > java/io/FileOutputStream > [2024-08-29 14:08:06] [info] [14356] Service started in 1648 milliseconds. > [2024-08-29 14:08:47] [info] [11012] Service SERVICE_CONTROL_STOP signalled. > [2024-08-29 14:08:47] [inf
Re: Tomcat takes over 1 minute to stop
Any insights into this issue please, Mr. Shultz? Anyone? Thanks and regards, Quoc Nguyen Sr. Software Engineer | Octo an IBM Company M: 407.404.4912 quoc.ngu...@octo.us From: Quoc Nguyen Sent: Friday, August 30, 2024 1:03 PM To: Tomcat Users List Subject: Re: Tomcat takes over 1 minute to stop Thank you Mr. Shultz !!! We've had warnings like the below forever. I can confirm that these have not affected stopping in anyway whatsoever. WARNING [Catalina-utility-11] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [web app name] appears to have started a thread named [thread name] but has failed to stop it. This is very likely to create a memory leak.. We did try to fix this in the form of a context listener servlet to clean up these threads during destroying the context process but, again, this has had no effects whatsoever. === Tomcat9w.exe --> Shutdown tab --> Timeout From the logs that I sent, I believe that: Apache Commons Daemon procrun (1.3.4.0 64-bit) --> took this Timeout into account Apache Commons Daemon procrun (1.4.0.0 64-bit) --> did NOT take this Timeout into account From: Christopher Schultz Sent: Thursday, August 29, 2024 5:59 PM To: users@tomcat.apache.org Subject: Re: Tomcat takes over 1 minute to stop Quoc, On 8/29/24 15:23, Quoc Nguyen wrote: > Thank you Mr. Thomas !!! > > Yes sir !!! I noticed that a clean Tomcat 9.0.93 install (as with other > 9.0.9x versions) stops around 1s. I believe that it is so because it has no > managed web apps/resources. Just Tomcat itself. I could be wrong. > > Yes, I noticed that there are warnings of non-daemon threads that weren't > stopped in catalina.log. I read somewhere that they're just warnings; thus > don't affect this process. > > There are no requests running at all while stopping Tomcat. Essentially, > install/deploy different versions (9.0.89, 9.0.9x) of Tomcat with the same > set of non-changing web apps and stop Tomcat via Windows service and record > the stop times. > > Yes, I took the thread dumps while stopping version 9.0.90. There is a thread > "DestroyJavaVM" that, after a few seconds after Tomcat receives the shutdown > signal (maybe after it's done stopping its main stuff), was running for 60s. > > That said, there're no explanations for what happened: > > a) between version 9.0.13 and 9.0.14 with the introduction of "..scheduled > executor to the Server..", which has default wait time of 60s and forces a > Timeout in Tomcat9w.exe to get Tomcat stop under 60s. > b) between version 9.0.89 and 9.0.90 after the upgrade of Apache Commons > Daemon procrun to version 1.4.0.0, which has a default pause of 60s. > > More work/data to confirm: I'm working with Tomcat version 9.0.89 and 9.0.90 > (where I noticed the change) in two different boxes. > > For version 9.0.90 box: started and stopped. Daemon logs below. > > Note: > > * Apache Commons Daemon procrun (1.4.0.0 64-bit) > * exactly 60s wait until finished regardless of the Timeout set in > Tomcat9w.exe > > [2024-08-29 13:41:58] [info] [13472] Apache Commons Daemon procrun (1.4.0.0 > 64-bit) started. > [2024-08-29 13:41:58] [info] [13472] Running Service 'Tomcat9'... > [2024-08-29 13:41:58] [info] [ 9148] Starting service... > [2024-08-29 13:41:58] [error] [12380] Could not create instance of > java/io/FileOutputStream > [2024-08-29 13:41:59] [info] [ 9148] Service started in 1636 milliseconds. > [2024-08-29 13:42:40] [info] [13472] Service SERVICE_CONTROL_STOP signalled. > [2024-08-29 13:42:40] [info] [11996] Stopping service... > [2024-08-29 13:43:06] [info] [11996] Service stop thread completed. > [2024-08-29 13:44:06] [info] [13472] Run service finished. > [2024-08-29 13:44:06] [info] [13472] Apache Commons Daemon procrun finished. > > > For version 9.0.90 box: switched version 9.0.89 of Tomcat9.exe into this box. > Started and stopped. Daemon logs below. > > Note: > > * Apache Commons Daemon procrun (1.3.4.0 64-bit) > * stop time is definitely less than 60s if the Timeout set in Tomcat9w.exe is > less than 60 and ~63s (or 1 min 3 secs as reported) when set to 0 (out of > the box) > * the last two log lines of "out of the box" don't appear in the log for > Timeout being set to 5. Speculation: the process is short-circuited taking > into account the set Timeout. > > The Timeout was set for 5: > > [2024-08-29 14:08:04] [info] [11012] Apache Commons Daemon procrun (1.3.4.0 > 64-bit) started. > [2024-08-29 14:08:04] [info] [11012] Running Service 'Tomcat9'... > [2024-08-29 14:08:04
WebappClassLoaderBase error when upgrading Tomcat 8 to 8.5
Hi,
I'm trying to upgrade Tomcat 8 to 8.5 and I'm getting a
nullpointerexception within WebappClassLoaderBase.CombinedEnumeration.inc.
It seems to occur when it's trying to initialize commons-logging LogFactory
for any class specified in Web.xml, and it's calling
getResources("commons-logging.properties") which I never had. Is it
required in 8.5? Even if I put it in conf/, it's not being picked up.
We're running Tomcat using a wrapper and it's erroring out here:
https://github.com/CodeGerm/osgi-server/blob/master/plugins/org.cg.dao.webcontainer/src/org/cg/dao/webcontainer/tomcat/TomcatWrapper.java#L185
I posted my web.xml and error trace here as well:
https://stackoverflow.com/questions/76139108/web-xml-configuration-is-broken-when-upgrading-to-tomcat-8-5-and-spring-5-1
Thanks,
Jeremy
Re: WebappClassLoaderBase error when upgrading Tomcat 8 to 8.5
I noticed this change was introduced:
https://bz.apache.org/bugzilla/show_bug.cgi?id=62868
https://github.com/apache/tomcat/blame/8.5.x/java/org/apache/catalina/loader/WebappClassLoaderBase.java#L1122
I'll try running 8.5.34 and report back.
Jeremy
On Mon, May 1, 2023 at 2:12 PM Rob Sargent wrote:
>
>
> On 5/1/23 14:36, Christopher Schultz wrote:
> > Jeremy,
> >
> > On 5/1/23 14:22, Jeremy Nguyen wrote:
> >> I'm trying to upgrade Tomcat 8 to 8.5 and I'm getting a
> >> nullpointerexception within
> >> WebappClassLoaderBase.CombinedEnumeration.inc.
> >> It seems to occur when it's trying to initialize commons-logging
> >> LogFactory
> >> for any class specified in Web.xml, and it's calling
> >> getResources("commons-logging.properties") which I never had. Is it
> >> required in 8.5? Even if I put it in conf/, it's not being picked up.
> >>
> >> We're running Tomcat using a wrapper and it's erroring out here:
> >>
> https://github.com/CodeGerm/osgi-server/blob/master/plugins/org.cg.dao.webcontainer/src/org/cg/dao/webcontainer/tomcat/TomcatWrapper.java#L185
> >>
> >>
> >> I posted my web.xml and error trace here as well:
> >>
> https://stackoverflow.com/questions/76139108/web-xml-configuration-is-broken-when-upgrading-to-tomcat-8-5-and-spring-5-1
> >>
> >
> > I have no idea how this is throwing an NPE. The only pointer being
> > dereferenced by the inc() method is "sources":
> >
> > 2773private boolean inc() {
> > 2774while (index < sources.length) {
> > 2775if (sources[index].hasMoreElements()) {
> > 2776return true;
> > 2777}
> > 2778index++;
> > 2779}
> > 2780return false;
> > 2781}
> >
> > That member (sources) is instantiated in the one-and-only-one
> > constructor:
> >
> > CombinedEnumeration(Enumeration enum1, Enumeration
> > enum2) {
> > @SuppressWarnings("unchecked")
> > Enumeration[] sources = new Enumeration[] { enum1,
> > enum2 };
> > this.sources = sources;
> > }
> >
> > Also weird is that this throws NPE on line 2775 and not 2774. I can't
> > explain how line 2775 could throw an NPE if line 2774 did not.
> >
> > >:/
>
> Is the null pointer in the index'th position of source, not source itself?
>
> >
> > I use Tomcat 8.5.x and I have never had a commons-logging.properties
> > file, and I use some components which are surely causing
> > commons-logging LogFactory to initialize, and I've never seen this
> > problem before.
> >
> > -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: WebappClassLoaderBase error when upgrading Tomcat 8 to 8.5
Confirmed that running 8.5.34 resolves the issue. I'll have no choice but
to run this version until the issue is resolved, or a workaround is found.
Thanks all!
On Mon, May 1, 2023 at 2:46 PM Jeremy Nguyen wrote:
> I noticed this change was introduced:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=62868
>
> https://github.com/apache/tomcat/blame/8.5.x/java/org/apache/catalina/loader/WebappClassLoaderBase.java#L1122
>
> I'll try running 8.5.34 and report back.
>
> Jeremy
>
>
>
> On Mon, May 1, 2023 at 2:12 PM Rob Sargent wrote:
>
>>
>>
>> On 5/1/23 14:36, Christopher Schultz wrote:
>> > Jeremy,
>> >
>> > On 5/1/23 14:22, Jeremy Nguyen wrote:
>> >> I'm trying to upgrade Tomcat 8 to 8.5 and I'm getting a
>> >> nullpointerexception within
>> >> WebappClassLoaderBase.CombinedEnumeration.inc.
>> >> It seems to occur when it's trying to initialize commons-logging
>> >> LogFactory
>> >> for any class specified in Web.xml, and it's calling
>> >> getResources("commons-logging.properties") which I never had. Is it
>> >> required in 8.5? Even if I put it in conf/, it's not being picked up.
>> >>
>> >> We're running Tomcat using a wrapper and it's erroring out here:
>> >>
>> https://github.com/CodeGerm/osgi-server/blob/master/plugins/org.cg.dao.webcontainer/src/org/cg/dao/webcontainer/tomcat/TomcatWrapper.java#L185
>> >>
>> >>
>> >> I posted my web.xml and error trace here as well:
>> >>
>> https://stackoverflow.com/questions/76139108/web-xml-configuration-is-broken-when-upgrading-to-tomcat-8-5-and-spring-5-1
>> >>
>> >
>> > I have no idea how this is throwing an NPE. The only pointer being
>> > dereferenced by the inc() method is "sources":
>> >
>> > 2773private boolean inc() {
>> > 2774while (index < sources.length) {
>> > 2775if (sources[index].hasMoreElements()) {
>> > 2776return true;
>> > 2777}
>> > 2778index++;
>> > 2779}
>> > 2780return false;
>> > 2781}
>> >
>> > That member (sources) is instantiated in the one-and-only-one
>> > constructor:
>> >
>> > CombinedEnumeration(Enumeration enum1, Enumeration
>> > enum2) {
>> > @SuppressWarnings("unchecked")
>> > Enumeration[] sources = new Enumeration[] { enum1,
>> > enum2 };
>> > this.sources = sources;
>> > }
>> >
>> > Also weird is that this throws NPE on line 2775 and not 2774. I can't
>> > explain how line 2775 could throw an NPE if line 2774 did not.
>> >
>> > >:/
>>
>> Is the null pointer in the index'th position of source, not source itself?
>>
>> >
>> > I use Tomcat 8.5.x and I have never had a commons-logging.properties
>> > file, and I use some components which are surely causing
>> > commons-logging LogFactory to initialize, and I've never seen this
>> > problem before.
>> >
>> > -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: WebappClassLoaderBase error when upgrading Tomcat 8 to 8.5
at > org.pac4j.core.engine.DefaultSecurityLogic.perform(DefaultSecurityLogic.java:136) > ~[pac4j-core-1.9.1.jar:?] > ... 34 more > Caused by: java.lang.NullPointerException > at > org.apache.jasper.compiler.Validator$ValidateVisitor.(Validator.java:516) > ~[jasper.jar:8.5.34] > at > org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1854) > ~[jasper.jar:8.5.34] > at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:220) > ~[jasper.jar:8.5.34] > at org.apache.jasper.compiler.Compiler.compile(Compiler.java:373) > ~[jasper.jar:8.5.34] > at org.apache.jasper.compiler.Compiler.compile(Compiler.java:350) > ~[jasper.jar:8.5.34] > at org.apache.jasper.compiler.Compiler.compile(Compiler.java:334) > ~[jasper.jar:8.5.34] > at > org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:595) > ~[jasper.jar:8.5.34] > at > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:382) > ~[jasper.jar:8.5.34] > at > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:386) > ~[jasper.jar:8.5.34] > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:330) > ~[jasper.jar:8.5.34] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:742) > ~[servlet-api.jar:?] > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) > ~[catalina.jar:8.5.34] > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) > ~[catalina.jar:8.5.34] > at > com.centrify.platform.service.analytics.filter.GlobalAttributeFilter.doFilter(GlobalAttributeFilter.java:41) > ~[com.centrify.platform.service.analytics/:?] > at > org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:358) > ~[spring-web-5.1.20.RELEASE.jar:5.1.20.RELEASE] > at > org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:271) > ~[spring-web-5.1.20.RELEASE.jar:5.1.20.RELEASE] > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) > ~[catalina.jar:8.5.34] > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) > ~[catalina.jar:8.5.34] > at > org.cg.services.core.filter.ExecutionTimeFilter.doFilterInternal(ExecutionTimeFilter.java:29) > ~[org.cg.services.core/:?] > at > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:119) > ~[spring-web-5.1.20.RELEASE.jar:5.1.20.RELEASE] > at > org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:358) > ~[spring-web-5.1.20.RELEASE.jar:5.1.20.RELEASE] > at > org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:271) > ~[spring-web-5.1.20.RELEASE.jar:5.1.20.RELEASE] > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) > ~[catalina.jar:8.5.34] > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) > ~[catalina.jar:8.5.34] > at > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:317) > ~[spring-security-web-4.1.0.RELEASE.jar:4.1.0.RELEASE] > at > org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:127) > ~[spring-security-web-4.1.0.RELEASE.jar:4.1.0.RELEASE] > at > org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:91) > ~[spring-security-web-4.1.0.RELEASE.jar:4.1.0.RELEASE] > at > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331) > ~[spring-security-web-4.1.0.RELEASE.jar:4.1.0.RELEASE] > at > org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:115) > ~[spring-security-web-4.1.0.RELEASE.jar:4.1.0.RELEASE] > at > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331) > ~[spring-security-web-4.1.0.RELEASE.jar:4.1.0.RELEASE] > at > org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:112) > ~[spring-security-web-4.1.0.RELEASE.jar:4.1.0.RELEASE] > at > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331) > ~[spring-security-web-4.1.0.RELEASE.jar:4.1.0.RELEASE] > at > org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:169) > ~[spring-security-web-4.1.0.RELEASE.jar:4.1.0.RELEASE] > at > org.springframework.security.web.FilterChainProxy$Vir
Re: WebappClassLoaderBase error when upgrading Tomcat 8 to 8.5
I was able to retrieve some logs that might shed some insight on the parent classloader when running 8.5.87. I'll be frank that I don't quite understand the mechanics of classloaders in Java. LogFactory from > org.eclipse.osgi.internal.loader.EquinoxClassLoader@1628551735] [LOOKUP] > LogFactory implementation requested for the first time for context > classloader org.apache.catalina.loader.ParallelWebappClassLoader@1204822967 > > [LogFactory from > org.eclipse.osgi.internal.loader.EquinoxClassLoader@1628551735] [LOOKUP] > org.apache.catalina.loader.ParallelWebappClassLoader@1204822967 == > 'ParallelWebappClassLoader > > context: cg > > delegate: false > > --> Parent Classloader: > > org.cg.dao.webcontainer.tomcat.WebAppClassLoader@b887730 > > ' > > [LogFactory from > org.eclipse.osgi.internal.loader.EquinoxClassLoader@1628551735] [LOOKUP] > ClassLoader > tree:org.apache.catalina.loader.ParallelWebappClassLoader@1204822967 --> > org.cg.dao.webcontainer.tomcat.WebAppClassLoader@193492784 --> > jdk.internal.loader.ClassLoaders$AppClassLoader@2085857771 (SYSTEM) --> > jdk.internal.loader.ClassLoaders$PlatformClassLoader@105966264 --> BOOT > > May 02, 2023 7:23:21 PM org.apache.catalina.core.StandardContext > listenerStart > > SEVERE: Exception sending context initialized event to listener instance > of class [org.springframework.web.context.ContextLoaderListener] > > java.lang.NullPointerException > > at > org.apache.catalina.loader.WebappClassLoaderBase$CombinedEnumeration.inc( > WebappClassLoaderBase.java:2775) > > at > org.apache.catalina.loader.WebappClassLoaderBase$CombinedEnumeration.hasMoreElements( > WebappClassLoaderBase.java:2760) > > at org.apache.commons.logging.LogFactory.getConfigurationFile( > LogFactory.java:1366) > > at org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:453) > > at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:655) > > at org.springframework.web.context.ContextLoader.initWebApplicationContext( > ContextLoader.java:269) > > at > org.springframework.web.context.ContextLoaderListener.contextInitialized( > ContextLoaderListener.java:103) > > at org.apache.catalina.core.StandardContext.listenerStart( > StandardContext.java:4492) > > at org.apache.catalina.core.StandardContext.startInternal( > StandardContext.java:4950) > > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > > at org.apache.catalina.core.ContainerBase.addChildInternal( > ContainerBase.java:711) > > at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:688) > > at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:661) > > at org.cg.dao.webcontainer.tomcat.TomcatWrapper.startWebApp( > TomcatWrapper.java:185) > > at org.cg.dao.webcontainer.tomcat.TomcatWrapper.prepareAllWebApps( > TomcatWrapper.java:140) > > at org.cg.dao.webcontainer.tomcat.TomcatWrapper.startServer( > TomcatWrapper.java:206) > > at org.cg.dao.webcontainer.tomcat.Application.start(Application.java:30) > > at org.eclipse.equinox.internal.app.EclipseAppHandle.run( > EclipseAppHandle.java:203) > > at > org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication( > EclipseAppLauncher.java:136) > > at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start( > EclipseAppLauncher.java:104) > > at org.eclipse.core.runtime.adaptor.EclipseStarter.run( > EclipseStarter.java:402) > > at org.eclipse.core.runtime.adaptor.EclipseStarter.run( > EclipseStarter.java:255) > > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke( > NativeMethodAccessorImpl.java:62) > > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke( > DelegatingMethodAccessorImpl.java:43) > > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > > at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:659) > > at org.eclipse.equinox.launcher.Main.basicRun(Main.java:596) > > at org.eclipse.equinox.launcher.Main.run(Main.java:1467) > > at org.eclipse.equinox.launcher.Main.main(Main.java:1440) > On Tue, May 2, 2023 at 6:18 PM Jeremy Nguyen wrote: > I picked 8.5.34 because 8.5.35 has that code change while 34 doesn't. > https://github.com/apache/tomcat/blob/8.5.35/java/org/apache/catalina/loader/WebappClassLoaderBase.java#L1050 > > I'll do some debugging for the classloader soon. I'm still trying to get > my application running. I'm wrestling with the following error at runtime. > > Caused by: org.apache.jasper.Jasp
Re: WebappClassLoaderBase error when upgrading Tomcat 8 to 8.5
If WebAppClassLoader.findResources returns null then it would come from
java.net.URLClassLoader.findResources.
@Override
> public Enumeration findResources(String resources) throws IOException
> {
> logger.debug("finding resources " + resources);
> Enumeration urls = myPluginLoader.getResources(resources);
> if (urls != null && urls.hasMoreElements())
> return urls;
> urls = tomcatPluginLoader.getResources(resources);
> if (urls != null && urls.hasMoreElements())
> return urls;
> return super.findResources(resources);
> }
On Wed, May 3, 2023 at 8:01 AM wrote:
> Sure Ill run it.
>
> - Jeremy
>
> > On May 3, 2023, at 7:05 AM, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
> >
> >
> > Jeremy,
> >
> >> On 5/2/23 22:27, Jeremy Nguyen wrote:
> >> I was able to retrieve some logs that might shed some insight on the
> >> parent classloader when running 8.5.87. I'll be frank that I don't quite
> >> understand the mechanics of classloaders in Java.
> >> LogFactory from
> >>> org.eclipse.osgi.internal.loader.EquinoxClassLoader@1628551735]
> [LOOKUP]
> >>> LogFactory implementation requested for the first time for context
> >>> classloader
> org.apache.catalina.loader.ParallelWebappClassLoader@1204822967
> >>>
> >>> [LogFactory from
> >>> org.eclipse.osgi.internal.loader.EquinoxClassLoader@1628551735]
> [LOOKUP]
> >>> org.apache.catalina.loader.ParallelWebappClassLoader@1204822967 ==
> >>> 'ParallelWebappClassLoader
> >>>
> >>> context: cg
> >>>
> >>> delegate: false
> >>>
> >>> --> Parent Classloader:
> >>>
> >>> org.cg.dao.webcontainer.tomcat.WebAppClassLoader@b887730
> >
> > I wonder if org.cg.dao.webcontainer.tomcat.WebAppClassLoader has a bug
> where getResources() can return null.
> >
> > That violates the contract of ClassLoader.getResources, but since it's
> /possible/ maybe Tomcat can work around it by simply ignoring the empty
> Enumeration. If I give you an unofficial build, can you try it?
> >
> > -chris
> >
> >>> [LogFactory from
> >>> org.eclipse.osgi.internal.loader.EquinoxClassLoader@1628551735]
> [LOOKUP]
> >>> ClassLoader
> >>> tree:org.apache.catalina.loader.ParallelWebappClassLoader@1204822967
> -->
> >>> org.cg.dao.webcontainer.tomcat.WebAppClassLoader@193492784 -->
> >>> jdk.internal.loader.ClassLoaders$AppClassLoader@2085857771 (SYSTEM)
> -->
> >>> jdk.internal.loader.ClassLoaders$PlatformClassLoader@105966264 -->
> BOOT
> >>>
> >>> May 02, 2023 7:23:21 PM org.apache.catalina.core.StandardContext
> >>> listenerStart
> >>>
> >>> SEVERE: Exception sending context initialized event to listener
> instance
> >>> of class [org.springframework.web.context.ContextLoaderListener]
> >>>
> >>> java.lang.NullPointerException
> >>>
> >>> at
> >>>
> org.apache.catalina.loader.WebappClassLoaderBase$CombinedEnumeration.inc(
> >>> WebappClassLoaderBase.java:2775)
> >>>
> >>> at
> >>>
> org.apache.catalina.loader.WebappClassLoaderBase$CombinedEnumeration.hasMoreElements(
> >>> WebappClassLoaderBase.java:2760)
> >>>
> >>> at org.apache.commons.logging.LogFactory.getConfigurationFile(
> >>> LogFactory.java:1366)
> >>>
> >>> at
> org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:453)
> >>>
> >>> at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:655)
> >>>
> >>> at
> org.springframework.web.context.ContextLoader.initWebApplicationContext(
> >>> ContextLoader.java:269)
> >>>
> >>> at
> >>>
> org.springframework.web.context.ContextLoaderListener.contextInitialized(
> >>> ContextLoaderListener.java:103)
> >>>
> >>> at org.apache.catalina.core.StandardContext.listenerStart(
> >>> StandardContext.java:4492)
> >>>
> >>> at org.apache.catalina.core.StandardContext.startInternal(
> >>> StandardContext.java:4950)
> >>>
> >>> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> >>>
> >>> at org.apache.catalina.core.ContainerBase.addChildInternal(
> >>> ContainerBase.java:711)
Re: WebappClassLoaderBase error when upgrading Tomcat 8 to 8.5
ilter.doFilter( > SecurityContextHolderAwareRequestFilter.java:169) > ~[spring-security-web-4.1.0.RELEASE.jar:4.1.0.RELEASE] > > at > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter( > FilterChainProxy.java:331) > ~[spring-security-web-4.1.0.RELEASE.jar:4.1.0.RELEASE] > > at org.pac4j.springframework.security.web.SecurityFilter.lambda$doFilter$1( > SecurityFilter.java:52) ~[spring-security-pac4j-2.0.0.jar:?] > > at org.pac4j.core.engine.DefaultSecurityLogic.perform( > DefaultSecurityLogic.java:136) ~[pac4j-core-1.9.1.jar:?] > > ... 34 more > On Wed, May 3, 2023 at 9:07 AM Christopher Schultz < ch...@christopherschultz.net> wrote: > Jeremy, > > On 5/3/23 11:00, jeremyn...@gmail.com wrote: > > Sure Ill run it. > > https://people.apache.org/~schultz/binaries/apache-tomcat-8.5.89-dev.tar.gz > > Please note that this is not an official Tomcat release (it's current > 8.5.x HEAD plus a tiny patch to ignore any null resources obtained from > the parent ClassLoader). No warranty, you accept all responsibility, etc. > > -chris > > >> On May 3, 2023, at 7:05 AM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> > >> > >> Jeremy, > >> > >>> On 5/2/23 22:27, Jeremy Nguyen wrote: > >>> I was able to retrieve some logs that might shed some insight on the > >>> parent classloader when running 8.5.87. I'll be frank that I don't > quite > >>> understand the mechanics of classloaders in Java. > >>> LogFactory from > >>>> org.eclipse.osgi.internal.loader.EquinoxClassLoader@1628551735] > [LOOKUP] > >>>> LogFactory implementation requested for the first time for context > >>>> classloader > org.apache.catalina.loader.ParallelWebappClassLoader@1204822967 > >>>> > >>>> [LogFactory from > >>>> org.eclipse.osgi.internal.loader.EquinoxClassLoader@1628551735] > [LOOKUP] > >>>> org.apache.catalina.loader.ParallelWebappClassLoader@1204822967 == > >>>> 'ParallelWebappClassLoader > >>>> > >>>> context: cg > >>>> > >>>> delegate: false > >>>> > >>>> --> Parent Classloader: > >>>> > >>>> org.cg.dao.webcontainer.tomcat.WebAppClassLoader@b887730 > >> > >> I wonder if org.cg.dao.webcontainer.tomcat.WebAppClassLoader has a bug > where getResources() can return null. > >> > >> That violates the contract of ClassLoader.getResources, but since it's > /possible/ maybe Tomcat can work around it by simply ignoring the empty > Enumeration. If I give you an unofficial build, can you try it? > >> > >> -chris > >> > >>>> [LogFactory from > >>>> org.eclipse.osgi.internal.loader.EquinoxClassLoader@1628551735] > [LOOKUP] > >>>> ClassLoader > >>>> tree:org.apache.catalina.loader.ParallelWebappClassLoader@1204822967 > --> > >>>> org.cg.dao.webcontainer.tomcat.WebAppClassLoader@193492784 --> > >>>> jdk.internal.loader.ClassLoaders$AppClassLoader@2085857771 (SYSTEM) > --> > >>>> jdk.internal.loader.ClassLoaders$PlatformClassLoader@105966264 --> > BOOT > >>>> > >>>> May 02, 2023 7:23:21 PM org.apache.catalina.core.StandardContext > >>>> listenerStart > >>>> > >>>> SEVERE: Exception sending context initialized event to listener > instance > >>>> of class [org.springframework.web.context.ContextLoaderListener] > >>>> > >>>> java.lang.NullPointerException > >>>> > >>>> at > >>>> > org.apache.catalina.loader.WebappClassLoaderBase$CombinedEnumeration.inc( > >>>> WebappClassLoaderBase.java:2775) > >>>> > >>>> at > >>>> > org.apache.catalina.loader.WebappClassLoaderBase$CombinedEnumeration.hasMoreElements( > >>>> WebappClassLoaderBase.java:2760) > >>>> > >>>> at org.apache.commons.logging.LogFactory.getConfigurationFile( > >>>> LogFactory.java:1366) > >>>> > >>>> at > org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:453) > >>>> > >>>> at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:655) > >>>> > >>>> at > org.springframework.web.context.ContextLoader.initWebApplicationContext( > >>>> ContextLoader.java:269) >
Tomcat 5.5 SSL Configuration problem, can't connect!
Hi there, I am running Tomcat 5.5 on RH Linux as user 'tomcat', I'm trying to get tomcat to run on a secure port 8443 instead of 8080. I uncommented the "SSL HTTP/1.1 Connector" entry in $CATALINA_HOME/conf/server.xml and generated a host certificate as user 'tomcat'. The .keystore file got generated in the tomcat home dir. After I restarted the tomcat container I launch my browser to: https://:8443 I get error "unable to connect to server" In the CATALINA logs, I get the following error: INFO: Pausing Coyote HTTP/1.1 on http-8443 Apr 12, 2006 9:04:15 PM org.apache.catalina.connector.Connector pause SEVERE: Protocol handler pause failed java.lang.NullPointerException at org.apache.jk.server.JkMain.pause(JkMain.java:677) at org.apache.jk.server.JkCoyoteHandler.pause(JkCoyoteHandler.java:162) Any help would be appreciated! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Where to download mod_jk?
Hi there, I want to download the mod_jk for linux or unix platform. Where can I find the tarball for this? I went to the following link and nothings there: http://jakarta.apache.org/site/downloads/downloads_tomcat-connectors.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
help using SSL with Tomcat error no server.pem?
Hi there, I've posted my issues not being able to connect using tomcat with ssl using port 8443 some days ago, but did not get any response. I am running Tomcat 5.5 on RH Linux as user 'tomcat', I'm trying to get tomcat to run on a secure port 8443 instead of 8080. I uncommented the "SSL HTTP/1.1 Connector" entry in $CATALINA_HOME/conf/server.xml and generated a host certificate as user 'tomcat' : %keytool -genkey -alias tomcat -keyalg RSA The .keystore file got generated in the tomcat home dir at /export/home/tomcat. After that I restarted the tomcat container I launch my browser to: https://:8443 I get error "unable to connect to server" In catalina.out file, error: Apr 14, 2006 2:49:36 PM org.apache.tomcat.util.net.puretls.PureTLSSocketFactory init INFO: Error initializing SocketFactory java.io.FileNotFoundException: server.pem (No such file or directory) This is what looks like in my server.xml file at section SSL: Any help would be appreciated! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Get rid of 8080 port in Tomcat 3.3
Hi, We’re still running 3.3.1 – We’d like to get rid of specifying the port 8080 in the http request like HYPERLINK "http://www.something.com:8080/"http://www.something.com:8080 and have it default to 80 (HYPERLINK "http://www.somehting.com/"http://www.somehting.com only) but could not find any way. I tried to define port=80 in server.xml but tomcat threw exceptions. If you know a way, could you help ? Thanks in advance, Frank Nguyen -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.441 / Virus Database: 268.18.1/691 - Release Date: 2/17/2007 5:06 PM -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.441 / Virus Database: 268.18.1/691 - Release Date: 2/17/2007 5:06 PM
RE: Get rid of 8080 port in Tomcat 3.3
Great article! Yes, this is the way to do it! Many thanks. Frank Nguyen -Original Message- From: Stefan [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 21, 2007 10:43 AM To: Tomcat Users List Subject: Re: Get rid of 8080 port in Tomcat 3.3 Frank Nguyen schrieb: > Hi, > > > > We’re still running 3.3.1 – We’d like to get rid of specifying the port 8080 > in the http request like HYPERLINK > "http://www.something.com:8080/"http://www.something.com:8080 and have it > default to 80 (HYPERLINK "http://www.somehting.com/"http://www.somehting.com > only) but could not find any way. I tried to define port=80 in server.xml > but tomcat threw exceptions. If you know a way, could you help ? > > > > Thanks in advance, > > > > > > Frank Nguyen > > > -- > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.441 / Virus Database: 268.18.1/691 - Release Date: 2/17/2007 > 5:06 PM > > > > That's the way You should go: http://www.linux.org.mt/article/tomcat-ports We run several tomcat servers standalone with the combination of rinetd and iptables. Good luck Stefan -- Stefan Riegel TELIG GmbH - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.441 / Virus Database: 268.18.1/691 - Release Date: 2/17/2007 5:06 PM -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.441 / Virus Database: 268.18.1/691 - Release Date: 2/17/2007 5:06 PM - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Deploy web app with context version by tomcat-maven-plugin
Dear tomcat experts,
I am using Tomcat 7. In the manager html interface, there is a column named
version in the list of applications table. I read the document here
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Naming to find
the way to set version for my web application. I deploy my web application
by tomcat-maven-plugin
org.codehaus.mojo
tomcat-maven-plugin
1.1
${project.build.directory}/${project.build.finalName}.war
http://myhostname.com:8080/manager/text
/
##${project.version}
tomcat
xxx
Please help me how can I set the version for my web app.
If I manually deploy I just rename the war to ROOT#version.war.
Thanks & best regards
Phuoc Nguyen
Re: Deploy web app with context version by tomcat-maven-plugin
Hi Dan >Are you using "ROOT#version.war"? Cause it should be >"ROOT##version.war". >Using one "#" means something different. I am using ROOT##version.war. I have a typo mistake in the previous email. My problem is using tomcat-maven-plugin. I don't know how to achieve this with tomcat-maven-plugin. Thanks you for your reply. Phuoc Nguyen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Performance problem with NIO under high concurrency
Hi, We run JFrog Artifactory which is fronted by Tomcat 8.0.32. We recently upgraded from Tomcat 7.0.56. Since the upgrade, Artifactory occasionally slows to a crawl. We could reproduce this problem by downloading a large (1GB) file concurrently from 500 different machines. However, to avoid exceeding the network bandwidth, we throttled the downloads at 100KB per second. While these 500 requests were being processed, we sent a request to download a smaller file (1MB, no throttling). The smaller download successfully went through several times, then got “stuck”. The download speed was reduced to a few KB per second. We couldn’t reproduce this problem on 7.0.56. We kept 8.0.32 but changed the connector to BIO and couldn’t reproduce it either. We suspect that it has something to do with switching from BIO in 7.0.56 to NIO in 8.0.32. Has anyone run into this problem before? Server.xml, a thread dump and Catalina MBean values are attached. Tomcat version: Server version: Apache Tomcat/8.0.32 Server built: Feb 2 2016 19:34:53 UTC Server number: 8.0.32.0 OS Name:Linux OS Version: 2.6.32-504.el6.x86_64 Architecture: amd64 JVM Version:1.8.0_72-b15 JVM Vendor: Oracle Corporation Thank you, Thuc Nguyen tomcat.tar.gz Description: tomcat.tar.gz - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance problem with NIO under high concurrency
Hi Chris, Thanks for the quick response. Yes, the clients were being throttled. These throttled requests were slow to start with and there was no noticeable difference in the download speed when the problem occurred. The smaller download started out OK. But after 10-15 successful serial requests it hit the problem. Then it remained slow until the big downloads completed or got canceled. The connector configuration: We’ll upgrade to 8.0.46 and see if the problem can be reproduced. Thanks again, Thuc On 8/31/17, 8:51 AM, "Christopher Schultz" wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Thuc, On 8/31/17 11:25 AM, Thuc Nguyen wrote: > We run JFrog Artifactory which is fronted by Tomcat 8.0.32. We > recently upgraded from Tomcat 7.0.56. Since the upgrade, > Artifactory occasionally slows to a crawl. Any chance of using the latest Tomcat 8.0.46? > We could reproduce this problem by downloading a large (1GB) file > concurrently from 500 different machines. However, to avoid > exceeding the network bandwidth, we throttled the downloads at > 100KB per second. You throttled the clients? > While these 500 requests were being processed, we sent a request > to download a smaller file (1MB, no throttling). The smaller > download successfully went through several times, then got “stuck”. > The download speed was reduced to a few KB per second. Over all connections, or just the single "small" requests? Was is stuck permanently? Meaning, if it got "stuck" one time (timed out?), would any later requests succeed? > We couldn’t reproduce this problem on 7.0.56. We kept 8.0.32 but > changed the connector to BIO and couldn’t reproduce it either. We > suspect that it has something to do with switching from BIO in > 7.0.56 to NIO in 8.0.32. It's possible, but you are using a fairly old version of Tomcat (~18 months). > Has anyone run into this problem before? > > Server.xml, a thread dump and Catalina MBean values are attached. > Tomcat version: Can you please post your configuration from server.xml? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJZqDCMAAoJEBzwKT+lPKRYOYMP/RJzkQueb1YORwm6hN0I8u6n idyq+byMzM+JmEM+uVprrBqFKwCGZEYMqKcrf/cirLlpr1F1bpiDyjWXxX6p2zZt IfHKH1oMYa4EpCXGn4PDLag9cCqA1sr44MOzkQ9PvQFJGFLo12exwQDd++EL1YxH DQmMsGh+xGmnaaK9EAJ85e9Jl6t+OHGF0655V8gt5MxsWfDGM+U8i2RDJln0HX0J GWJCcs6ce6qzi82GYXf597QrKhF7x7lYrZMH2JbghxUMqB6GUw0uAyhGdYO5OfYz wVUkB9dzDMwMli8UmmSclN/rF2msKL+RD7G72oNNCyxOmZc5oS4BvLVwLa5a7CCP UPXuCLAXRg+JQ9C4MXGOXvhEKpkOKjaDFBsSSnavycPMSCfK9gCRXIU37DfIZFhN 1k/Jjq13VNaq6KgX2UkEbqwwuEmyjhXLuuz6KC714Hm6raeQEiaE88W2defvc6PG 179/bwXiMxhW6BXa2RCrhMHrqfw1gxIvqdwqoM1xEKIJhAhVD2AjJLpKA2AGJ1Tw 15nictwVIpmjYN13r0/j6UrT3KT6qlbSQT9d9FaErAqBaFWtdknqSe4ZDWcd9i59 Cg8PktKQSpr2dDijxGusydBc9QYzIS28ofLjZwSF2UXTW/rNAVVmtU+8O3y8zCTB lXk0eAvyyWpVxkis8+Ft =2s/6 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org server.xml Description: server.xml - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance problem with NIO under high concurrency
As an experimentation, I started Tomcat with “-Dorg.apache.tomcat.util.net.NioSelectorShared=false”, and “selectorPool.maxSelectors” set to 1000, the same as the number of threads. This problem didn’t happen with that setting. Even with “selectorPool.maxSelectors” set to 1, it was noticeably slow, but wasn’t stuck. I’m surprised that there’s only one shared selector by default. I’m reading the code to get a better understanding of the SelectorPool implementation. I’d appreciate any insights you may have around this. Thanks, Thuc On 8/31/17, 9:09 AM, "Thuc Nguyen" wrote: Hi Chris, Thanks for the quick response. Yes, the clients were being throttled. These throttled requests were slow to start with and there was no noticeable difference in the download speed when the problem occurred. The smaller download started out OK. But after 10-15 successful serial requests it hit the problem. Then it remained slow until the big downloads completed or got canceled. The connector configuration: We’ll upgrade to 8.0.46 and see if the problem can be reproduced. Thanks again, Thuc On 8/31/17, 8:51 AM, "Christopher Schultz" wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Thuc, On 8/31/17 11:25 AM, Thuc Nguyen wrote: > We run JFrog Artifactory which is fronted by Tomcat 8.0.32. We > recently upgraded from Tomcat 7.0.56. Since the upgrade, > Artifactory occasionally slows to a crawl. Any chance of using the latest Tomcat 8.0.46? > We could reproduce this problem by downloading a large (1GB) file > concurrently from 500 different machines. However, to avoid > exceeding the network bandwidth, we throttled the downloads at > 100KB per second. You throttled the clients? > While these 500 requests were being processed, we sent a request > to download a smaller file (1MB, no throttling). The smaller > download successfully went through several times, then got “stuck”. > The download speed was reduced to a few KB per second. Over all connections, or just the single "small" requests? Was is stuck permanently? Meaning, if it got "stuck" one time (timed out?), would any later requests succeed? > We couldn’t reproduce this problem on 7.0.56. We kept 8.0.32 but > changed the connector to BIO and couldn’t reproduce it either. We > suspect that it has something to do with switching from BIO in > 7.0.56 to NIO in 8.0.32. It's possible, but you are using a fairly old version of Tomcat (~18 months). > Has anyone run into this problem before? > > Server.xml, a thread dump and Catalina MBean values are attached. > Tomcat version: Can you please post your configuration from server.xml? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJZqDCMAAoJEBzwKT+lPKRYOYMP/RJzkQueb1YORwm6hN0I8u6n idyq+byMzM+JmEM+uVprrBqFKwCGZEYMqKcrf/cirLlpr1F1bpiDyjWXxX6p2zZt IfHKH1oMYa4EpCXGn4PDLag9cCqA1sr44MOzkQ9PvQFJGFLo12exwQDd++EL1YxH DQmMsGh+xGmnaaK9EAJ85e9Jl6t+OHGF0655V8gt5MxsWfDGM+U8i2RDJln0HX0J GWJCcs6ce6qzi82GYXf597QrKhF7x7lYrZMH2JbghxUMqB6GUw0uAyhGdYO5OfYz wVUkB9dzDMwMli8UmmSclN/rF2msKL+RD7G72oNNCyxOmZc5oS4BvLVwLa5a7CCP UPXuCLAXRg+JQ9C4MXGOXvhEKpkOKjaDFBsSSnavycPMSCfK9gCRXIU37DfIZFhN 1k/Jjq13VNaq6KgX2UkEbqwwuEmyjhXLuuz6KC714Hm6raeQEiaE88W2defvc6PG 179/bwXiMxhW6BXa2RCrhMHrqfw1gxIvqdwqoM1xEKIJhAhVD2AjJLpKA2AGJ1Tw 15nictwVIpmjYN13r0/j6UrT3KT6qlbSQT9d9FaErAqBaFWtdknqSe4ZDWcd9i59 Cg8PktKQSpr2dDijxGusydBc9QYzIS28ofLjZwSF2UXTW/rNAVVmtU+8O3y8zCTB lXk0eAvyyWpVxkis8+Ft =2s/6 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
About whether the described env is safe from CVE 2024-50379 and 56337
Hi Tomcat team I am really sorry to bother you regarding this fix for Tomcat 9.0.98 revolving around the following CVEs, http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-50379 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-56337 (★) My question is if we install our Tomcat 9.0.97 (or lower version) on Windows OS (Case Insensitive), and the default value of DefaultServlet Write Enabled is FALSE (Since readonly parameter is not touched) Then I should not be concerned about the CVE since its first and foremost important condition is below right? > If the default servlet is write enabled (readonly initialisation parameter > set to the non-default value of false) for a case insensitive file system Meaning with the env described in (★) the CVEs are not a concern, and I do NOT have to even set sun.io.useCanonCaches to false on Tomcat9w.exe right? I am trying to avoid upgrade or restarting my Tomcat. Best regards, Nguyen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
class loader for native library
Dear friends, My web-based application needs to communicate with a native library. Therefore, I specify the JAVA_OPTS variable with the path to a native library before running startup.sh: export JAVA_OPTS="-Djava.library.path=/opt/pkg/pl/lib/pl-5.6.6/lib/i686-linux" Unfortunately, I got the following message when calling my JSP: org.apache.jasper.JasperException: The absolute uri: http://java.sun.com/jsp/jstl/core cannot be resolved in either web.xml or the jar files deployed with this application I had a look into the localhost log file and found the following erroneous information: Error loading WebappClassLoader delegate: false repositories: /WEB-INF/classes/ --> Parent Classloader: [EMAIL PROTECTED] com.mycompany.mypackage.ControllerServlet java.lang.ClassNotFoundException: com.mycompany.mypackage.ControllerServlet Could you please help me to find out how I should specify the path to the native library correctly? Where does the error above come from? Thanks a lot. Thinh - 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: class loader for native library
I use following taglibs in my JSP: <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"; %> <%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions"; %> <%@ taglib prefix="ora" uri="orataglib" %> Could you help me please, how to configure/ specify the taglibs we want to use? Did I export the JAVA_OPTS in order to access to the native library correctly? JAVA_OPTS="-Djava.library.path=/opt/pkg/pl/lib/pl-5.6.6/lib/i686-linux" Thanks a lot for your advice. Thinh Mark Thomas wrote: Le Nguyen-Thinh wrote: Dear friends, My web-based application needs to communicate with a native library. Therefore, I specify the JAVA_OPTS variable with the path to a native library before running startup.sh: export JAVA_OPTS="-Djava.library.path=/opt/pkg/pl/lib/pl-5.6.6/lib/i686-linux" Unfortunately, I got the following message when calling my JSP: org.apache.jasper.JasperException: The absolute uri: http://java.sun.com/jsp/jstl/core cannot be resolved in either web.xml or the jar files deployed with this application This is nothing to do with your native library. The problem is that the standard taglibs cannot be found. What steps have you taken to configure taglibs for your application? 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] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Taglibs ; error in a JSP using expression langluage
Dear friends,
I have a JSP which uses following taglibs:
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"; %>
<%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions"; %>
My JSP contains a piece of code which calls a tag from the taglib above:
The Tomcat server returns following error:
java.lang.NumberFormatException: For input string: "${0}"
java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
java.lang.Integer.parseInt(Integer.java:447)
java.lang.Integer.valueOf(Integer.java:553)
org.apache.jasper.compiler.JspUtil.coerceToInt(JspUtil.java:752)
It seems to me that Tomcat could not interpret the JSP.
My question is, do I miss some libraries? Do
My application runs on Linux Debian, Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05) (j2sdk1.5-sun).
The taglibs jstl.jar and standard.jar stem from jakarta-taglibs-standard-1.1.2.
Thanks a lot for your help.
Thinh
-
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: Taglibs ; error in a JSP using expression langluage
Thanks all for your advice.
My web.xml has an entry:
!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd";>
which, I think, caused the error.
I have inserted the line:
<%@ page ... isELIgnored="false" %>
as Pid suggested and the error disappeared.
Thanks a lot.
Thinh
David Smith wrote:
One other possibility -- which servlet spec version do you have
specified in your web.xml? If web.xml declares an older version of
the servlet spec, these ${} expressions may not be available.
--David
Pid wrote:
which version of tomcat are you using?
is Expression Language enabled? as it looks like it's passing the ${0}
variable as a string rather than evaluating it.
Try setting the following attribute in your JSP 'page' directive.
<%@ page ... isELIgnored="false" %>
Le Nguyen-Thinh wrote:
Dear friends,
I have a JSP which uses following taglibs:
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"; %>
<%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions"; %>
My JSP contains a piece of code which calls a tag from the taglib
above:
var="ind"> target="${argBean}" property="name"
value="${paramValues.argName[ind]}" />
The Tomcat server returns following error:
java.lang.NumberFormatException: For input string: "${0}"
java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
java.lang.Integer.parseInt(Integer.java:447)
java.lang.Integer.valueOf(Integer.java:553)
org.apache.jasper.compiler.JspUtil.coerceToInt(JspUtil.java:752)
It seems to me that Tomcat could not interpret the JSP. My question is,
do I miss some libraries? Do My application runs on Linux Debian,
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
(j2sdk1.5-sun).
The taglibs jstl.jar and standard.jar stem from
jakarta-taglibs-standard-1.1.2.
Thanks a lot for your help.
Thinh
-
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]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: using Tomcat web server.
Hi Using Tomcat web server.: Do you know why it is called Tomcat (where does that name come from)? (like Apache is for patches) Thanks, -- Thanh Vinh Nguyen -- Thanh Vinh Nguyen -- Thanh Vinh Nguyen
How many programmers were involved in Tomcat 4.0?
How many programmers were involved in Tomcat 4.0? Please dont answer 4.0 is obsolete: I KNOW THAT. I am doing a reasearch on the evelovment of Tomcat in general. Thanks. -- Thanh Vinh Nguyen
java.net.MalformedURLException: no protocol: Files/thirdparty/TOMCAT/common/classes/
Hi,
I have a Tomcat servlet which communicates with a stand-alone java
application using RMI. I got the above exception whenever my servlet
makes an RMI call.
I have the following configuration in my "catalina.policy" file:
common.loader=${catalina.home}/common/classes,${catalina.home}/common/i1
8n/*.jar,${catalina.home}/common/endorsed/*.jar,${catalina.home}/common/
lib/*.jar
where "catalina.home" is resolved to "C:/Program
Files/thirdparty/TOMCAT"
I am running Tomcat version 5.5.17.0 on windows 2003 server. JVM is
1.5.0_07-b03. Tomcat is installed under C:\Program
Files\thirdparty\TOMCAT
I did some Google search and found some postings similar to the ones
listed below. They seem to suggest that I would run into this problem
if Tomcat was installed under a directory with spaces in it.
http://www.jguru.com/forums/view.jsp?EID=1346101
http://forum.java.sun.com/thread.jspa?threadID=5210992&tstart=30
http://mail-archives.apache.org/mod_mbox/tomcat-dev/200207.mbox/%3C20020
[EMAIL PROTECTED]
http://www.jguru.com/forums/view.jsp?EID=1346069
I was wondering if anyone could tell me if this is a known issue or if I
am doing anything wrong.
Thanks in advance,
Regards,
- Jeffrey
-
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: java.net.MalformedURLException: no protocol: Files/thirdparty/TOMCAT/common/classes/
ster.Digester.startElement(Digester.java:1275
)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElemen
t(Unknown Source)
at
com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.startElement
(Unknown Source)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.s
canStartElement(Unknown Source)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$ContentDi
spatcher.scanRootElementHook(Unknown Source)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$F
ragmentContentDispatcher.dispatch(Unknown Source)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.s
canDocument(Unknown Source)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unkn
own Source)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unkn
own Source)
at
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown
Source)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unkno
wn Source)
at
org.apache.tomcat.util.digester.Digester.parse(Digester.java:1561)
at org.apache.catalina.startup.Catalina.load(Catalina.java:489)
at org.apache.catalina.startup.Catalina.load(Catalina.java:523)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:266)
at
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:431)
One more thing: I don't see any of the above exceptions if I don't
deploy my servlet that uses RMI. Other servlets that are not using RMI
seem to work fine. I'm not sure if this issue is triggered when RMI is
used within Tomcat and when Tomcat is installed under a directory with
spaces. The postings I found mentioned the use of RMI.
- Jeffrey Nguyen
-Original Message-
From: Christopher Schultz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 26, 2007 6:53 AM
To: Tomcat Users List
Subject: Re: java.net.MalformedURLException: no protocol:
Files/thirdparty/TOMCAT/common/classes/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeffrey,
Jeffrey Nguyen (jeffrngu) wrote:
> common.loader=${catalina.home}/common/classes,${catalina.home}/common/
> i1
> 8n/*.jar,${catalina.home}/common/endorsed/*.jar,${catalina.home}/commo
> n/
> lib/*.jar
>
> where "catalina.home" is resolved to "C:/Program
> Files/thirdparty/TOMCAT"
>
> I did some Google search and found some postings similar to the ones
> listed below. They seem to suggest that I would run into this problem
> if Tomcat was installed under a directory with spaces in it.
Yes, for some reason spaces in path names are frequently the cause of
lots of head-scratching. I'm not sure if it's strictly a win32 issue or
not, but a lot of win32 folks seem to have this problem.
Something you could try is explicitly setting the value of the
CATALINA_HOME environment variable, and be sure to use the
8.3-equivalent of the path for the value. For instance:
set CATALINA_HOME=C:\PROGRA~1\thirdparty\TOMCAT
%CATALINA_HOME%\bin\startup.bat
I realize you might be using Tomcat as a service, so you'll have to
figure out how to get the same effect with the service launcher thing.
Another option, of course, is to install Tomcat into a directory with no
spaces in the path.
Hope that helps,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG+mRH9CaO5/Lv0PARAmCJAKCnwaMZ0hFXxHubkPLsUk0z8s3/KACdHN5d
/aLUm/nhKsFfDTZ2JxSFFKE=
=N4rL
-END PGP SIGNATURE-
-
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: java.net.MalformedURLException: no protocol: Files/thirdparty/TOMCAT/common/classes/
Hi Chris,
I can "cd" to all 4 paths w/o any problem (see below). I also verified
that TransactionRef class is part of
CATALINA_HOME/common/lib/naming-factory.jar
C:\>echo %CATALINA_HOME%
C:\Program Files\thirdparty\TOMCAT
C:\>cd %CATALINA_HOME%/common/classes
C:\Program Files\thirdparty\TOMCAT\common\classes>cd\
C:\>cd %CATALINA_HOME%/common/i18n
C:\Program Files\thirdparty\TOMCAT\common\i18n>cd
%CATALINA_HOME%/common/endorsed
C:\Program Files\thirdparty\TOMCAT\common\endorsed>cd
%CATALINA_HOME%/common/lib/
C:\Program Files\thirdparty\TOMCAT\common\lib>
At this point, I'm considering reinstalling Tomcat in a different
directory as the last resort because it's involved a lot of work. I am
looking for a workaround.
- Jeffrey Nguyen
-Original Message-
From: Christopher Schultz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 26, 2007 12:27 PM
To: Tomcat Users List
Subject: Re: java.net.MalformedURLException: no protocol:
Files/thirdparty/TOMCAT/common/classes/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeffrey,
Jeffrey Nguyen (jeffrngu) wrote:
> I had actually tried to define the value for catalina.home explicitely
> in catalina.properties file, but I still can't get this working.
Not sure if catalina.home can actually be specified here. You may have
to specify it externally.
> common.loader=${catalina.home}/common/classes,${catalina.home}/common/
> i1
> 8n/*.jar,${catalina.home}/common/endorsed/*.jar,${catalina.home}/commo
> n/
> lib/*.jar
>
> With this definition, I got the following stacktrace:
>
> 2007-09-26 13:53:13,000 ERROR [Thread-6]
> rmidispatcher.TCTTaskDispatcherImpl - java.rmi.ServerException:
> RemoteException occurred in server thread; nested exception is:
> java.rmi.UnmarshalException: error unmarshalling arguments;
nested
> exception is:
> java.net.MalformedURLException: no protocol:
> Files/thirdparty/TOMCAT/common/classes/
Yes. It's obvious that the path still contains the space, and that the
loader is considering it to be a path delimiter instead of part of the
path itself.
> If I replace "${catalina.home}" with "C:/Program~1/thirdparty/TOMCAT"
> for the first path, I'll get MalformedURLException exception again for
> the second path. If I made the same change for the first 2 paths, I'll
> get the same exception complaining about the third path. If I do this
> for the first 3 paths, the same exception points to the last path.
>
> When I made the same change for all 4 paths, Tomcat failed to start. I
> got the following error in catalina.* log:
>
> Sep 25, 2007 9:59:23 AM org.apache.tomcat.util.digester.Digester
> startElement
> SEVERE: Begin event threw error
> java.lang.NoClassDefFoundError: org/apache/naming/TransactionRef
There are two possibilities:
1. Your path is still not correct (likely) 2. Your Tomcat install must
be broken. This class should be in
CATALINA_HOME/common/lib/naming-factory.jar
Did you check to see that your 8.3 representation of the path is
correct? Try copy-and-pasting that path up there into a "cd" command and
see if windows will put you in the proper directory.
> One more thing: I don't see any of the above exceptions if I don't
> deploy my servlet that uses RMI. Other servlets that are not using RMI
> seem to work fine. I'm not sure if this issue is triggered when RMI is
> used within Tomcat and when Tomcat is installed under a directory with
> spaces. The postings I found mentioned the use of RMI.
I assume you need RMI or you wouldn't be asking.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG+rKQ9CaO5/Lv0PARAt2UAJ0SWFILHZC8VBDoet2UExo6ow+2LwCgvBFT
IZXJsdh+euO/tLKIVgaS7UA=
=BONg
-END PGP SIGNATURE-
-
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: java.net.MalformedURLException: no protocol: Files/thirdparty/TOMCAT/common/classes/
Hi Chris, Sorry for the late reply. We implemented the workaround mentioned at the bottom of http://issues.apache.org/bugzilla/show_bug.cgi?id=4543 for now. This fixed our problem. At the same time, we also consider reinstalling tomcat under another directory without space and see if that fixes our problem. At this point, it seems none of the non-invasive work-arounds fixes this issue we're having. Thanks again for all your help. - Jeffrey Nguyen -Original Message- From: Christopher Schultz [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 26, 2007 3:18 PM To: Tomcat Users List Subject: Re: java.net.MalformedURLException: no protocol: Files/thirdparty/TOMCAT/common/classes/ -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeffrey, Jeffrey Nguyen (jeffrngu) wrote: > I can "cd" to all 4 paths w/o any problem (see below). > > C:\>echo %CATALINA_HOME% > C:\Program Files\thirdparty\TOMCAT Your CATALINA_HOME still has a space in it, jst like it has all along. You need to actually change the value of this environment variable so that it does not contain any spaces. > At this point, I'm considering reinstalling Tomcat in a different > directory as the last resort because it's involved a lot of work. I am > looking for a workaround. There is a very good likelihood that this will fix your problem. It would be easier IMO to just change the environment variable's value. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG+tp69CaO5/Lv0PARAj2YAKCfXMNLona4343ctiNfNHBUksWnuQCfcfUl MZ5FvjTvA/7x6XwPP0ngWZE= =LUlT -END PGP SIGNATURE- - 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]
Monitor CPU usage/IOwait for individual web apps
Hi, Has anyone tried to instrument counters to monitor CPU usage and IOWait for each individual web app? Any help or pointers would be much appreciated. Thanks in advance! - Jeffrey
How to surpress The requested resource XYZ is not available - response
Hello, usually you will get a "The requested resource /XYZ is not available" response when you call an unavailable web service on Apache Tomcat. However, for a special use case I don't want Tomcat to answer to requests for a unknown/unavailable web service. I just want Tomcat to ignore it and "keep quiet", resulting that the caller will get a timeout and therefore knows that there is no service behind this URL. How can I achieve such behaviour? Best Regards, Song Thuy Nguyen
RE: How to surpress The requested resource XYZ is not available - response
The thing is, I'm using the failover behaviour in Apache Synapse (Enterprise
Service Bus). I can give Synapse a list of web service endpoints that have the
same interface. One is the primary service endpoint and the others are the
backups in case the primary endpoint become unavailable for some reason.
Actually there are only 2 general reasons: the (application) server that
provides the services is not running, so the port (lets say port 80) is closed.
Or the second case: the application server is still running, but the service is
made inactive. That means the application server still listens at port 80 but
can't serve request to the mentioned service and answers with the "404 The
requested resource XYZ is not available" response.
Now the problem: Synapse gets this http-404 response, eventhough it can't find
the SOAP envelop it expects it doesn't see the endpoint as faulty and forwards
the 404 message to the caller (web service consumer). The fail-over mechanism
doesn't kick in :( But actually it should because the service is not
available anymore, so the request should be send to the backup endpoints.
Ofcourse I tried to make Synapse understand that a 404-response should be
treated the same as a failure. But it can't easily be done. So I thought I
could make Tomcat to receive calls to inactive services, but just drop them
without answering. After some time... synapse will trigger timeout and tries to
call the backup endpoints.
It doesn't matter if the http/tcp connection has been established or not.
> -Original Message-
> From: Len Popp [mailto:len.p...@gmail.com]
> Sent: Tuesday, March 16, 2010 1:50 AM
> To: Tomcat Users List
> Subject: Re: How to surpress The requested resource XYZ is not
> available - response
>
> I don't think you can do that. After Tomcat accepts the HTTP
> connection and decides whether to respond, it's too late to pretend
> there's no server there. The user's web browser displays a different
> error message for no server (something like "can't establish a
> connection") vs. server timeout (something like "the server took too
> long to respond") or dropping the connection ("the connection was
> reset").
>
> So you might as well just customize the 404 error page to say "There's
> no server here" - it'd fool people just as well. :-) Or just return
> an empty error page.
> --
> Len
>
>
>
> On Mon, Mar 15, 2010 at 19:26, Song Thuy Nguyen
> wrote:
> > Hello,
> >
> >
> >
> > usually you will get a "The requested resource /XYZ is not available"
> response when you call an
> > unavailable web service on Apache Tomcat. However, for a special use
> case I don't want Tomcat to
> > answer to requests for a unknown/unavailable web service. I just
> want Tomcat to ignore it and "keep
> > quiet", resulting that the caller will get a timeout and therefore
> knows that there is no service behind
> > this URL. How can I achieve such behaviour?
> >
> >
> >
> > Best Regards,
> >
> >
> >
> >
> >
> > Song Thuy Nguyen
> >
> >
>
> -
> 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: Separate port for each deployed Web Service or WAR file?
Hi Mark, I'm looking for a workaround to a problem: I'm using the failover feature of Apache Synapse (there will be several backup/alternate web service with the same interface to a primary web service, if the primiary service fails one of the replacements will be called without the notice of the caller (service consumer)). But there is a catch: in the recent version of Synapse one endpoint to a web service will only be seen as failed if the connection to this port will be refused (mostly due to a transport error). But if I deploy the web service on Tomcat every web services will listen to the one standard port. Any incoming request to the standard port of Tomcat calling a service that is inactive will be accepted and then answer with a http 404 error (like service not found or something). For synapse this is a conform answer and it will forward it to the caller. But this is not really what a failover should do. For now the failover only works if the whole application server (Tomcat) is offline/down and any call to the port is beeing rejected. If you still have doubts about the sense of this scenario, rest assured, there are several other users requesting Synapse failover to treat a http-404 error as a reason to call the secondary services. This feature will probably be implemented in a future version of Synapse. Until then, I want to try a workaround to evaluate such a system. Is there anyway you could help me? Song Thuy Nguyen > -Original Message- > From: Mark Thomas [mailto:ma...@apache.org] > Sent: Tuesday, March 23, 2010 11:00 PM > To: Tomcat Users List > Subject: Re: Separate port for each deployed Web Service or WAR file? > > On 23/03/2010 21:51, Song Thuy Nguyen wrote: > > Hello, > > > > I would like to configure the listen/connection port for each Web > Service or each WAR file I deploy. > > Why? What are you trying to achieve? > > 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
Issues changing log4j levels for tomcat web apps
Hi Everyone, This question might be a little off topic, but I thought since it involved tomcat web apps, I figured someone might know the answer. I have Liferay EE 5.2.6 running on top of tomcat 6.0.26. Liferay has an admin GUI page to allows me to change log level settings for different packages. The issue I'm facing is changing the log levels seems to only take effect on the ROOT web apps. All the other plugin web apps do not seem to response to the new log levels. I checked on Liferay support forums and found that others are also facing this problem (http://www.liferay.com/community/forums/-/message_boards/message/492284 1) Is this really Liferay's specific problem or is it Tomcat issue in general? In plain vanilla Tomcat, are the web apps loaded in a WebAppClassLoader and ROOT web app is loaded by StandardClassLoader? If so, I assume this is really just an issue with Tomcat right? How do I get around this problem? In a previous project I worked with, we relied on DB change notification to relay the new log level to all tomcat web apps. However, I don't want to consider that solution because it requires design changes and it has its own set of problem. Any pointers would be much appreciated! Thanks in advance! Regards, - Jeffrey Nguyen
Re: tomcat7 & tomcat6 session replication
thanks for your answer >It might work in some circumstances. do you mean it will work with some modification?? do you have any suggestion for those modification? thank you very much 2013/2/25 Mark Thomas > On 25/02/2013 04:24, Son Nguyen Xuan wrote: > > I want to know how can I have the session replication working between > > tomcat6 & tomcat7 under JRE7 > > That is not supported. It might work in some circumstances. > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- ======= SON NGUYEN XUAN ┏━━━┓International Ichiba, Mall Group ┃楽●天┃Ichiba Service Department & Operation Department, RAKUTEN Inc ┗━━━┛Shinagawa Seaside Rakuten Tower ┼┼─ ─ADDR─ 4-12-3 Higashishinagawa, Shinagawa-ku, Tokyo 140-0002 ──MAIL─ son.ngu...@mail.rakuten.com TEL：050-5817-3844 (73844) [image: 樂天市場購物網] [image: Rakuten BELANJA ONLINE] [image: Rakuten.com.my Online Shopping] ===
Archive localhost_access_log
Hello, Tomcat server version: 9.0.98. server.xml configuration for AccessLogValve: Everything works fine. Now, I have a requirement to archive these log files similar to log4j (pattern is already taken care of in the valve) with (archive when the file size reaches certain size) and (cleanup archived files). Is there a way to archive these logs via the configuration in the valve? If not, what the best way to go about it: a custom class that implements ValveBase or extends AccessLogValve or do something else entirely? Thanks and regards, - Quoc
RE: [EXTERNAL] Re: Archive localhost_access_log
Thank you Mr. Funk.
My request is two-folds a) archive the log files elsewhere (not the "logs"
folder) based on some policy b) clean up (delete) the archived files based on
some policy.
If I'm not mistaken, your suggestion may address the latter but nothing on the
former?
Thanks and regards,
-
Quoc
-Original Message-
From: Tim Funk
Sent: Tuesday, March 18, 2025 1:10 PM
To: Tomcat Users List
Subject: [EXTERNAL] Re: Archive localhost_access_log
Personally. I rely on a daily cron with a find by time and the -delete flag.
Where the time to keeps is based on policy.
-Tim
On Tue, Mar 18, 2025 at 9:52 AM Nguyen, Quoc A. (QUANTUM MANAGEMENT, LLC)
wrote:
> Hello,
>
> Tomcat server version: 9.0.98.
>
> server.xml configuration for AccessLogValve:
>
> directory="logs" prefix="localhost_access_log" suffix=".log" maxDays="7"
> pattern="%h %{X-Forwarded-For}i %t %I "%m %U" %{local}p %s %b %D"
> resolveHosts="false" />
>
> Everything works fine. Now, I have a requirement to archive these log
> files similar to log4j (pattern is already taken care of
> in the valve) with (archive when the file size reaches
> certain
> size) and (cleanup archived files).
>
> Is there a way to archive these logs via the configuration in the valve?
> If not, what the best way to go about it: a custom class that
> implements ValveBase or extends AccessLogValve or do something else entirely?
>
>
>
RE: [EXTERNAL] Re: Archive localhost_access_log
Thank you again. Thanks and regards, - Quoc A. Nguyen (Contractor) Sr. Software Engineer, Octo an IBM Company Office of Information and Technology (OIT), Development Security, and Operations (DevSecOps) Division: Solution Delivery (SD) Mobile: (407) 404-4912 -Original Message- From: Tim Funk Sent: Tuesday, March 18, 2025 5:26 PM To: Tomcat Users List Subject: Re: [EXTERNAL] Re: Archive localhost_access_log Nothing built in to move them. But the same advice applies. The find command chained with mv or mv+gzip could be a solution Or if your backup policy is good enough. Doing nothing and relying on backups to retrieve old logs would work too. But all of this depends on use case for need of retrieval. Such as how quickly do the files need retrieved. What’s the effort and how often would this happen. On Tue, Mar 18, 2025 at 10:41 AM Nguyen, Quoc A. (QUANTUM MANAGEMENT, LLC) wrote: > Thank you Mr. Funk. > > My request is two-folds a) archive the log files elsewhere (not the "logs" > folder) based on some policy b) clean up (delete) the archived files > based on some policy. > > If I'm not mistaken, your suggestion may address the latter but > nothing on the former? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
