Re: [OT] Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54
On 09.08.2018 20:05, Louis Zipes wrote: Oh! André, if you aren't using JMX in production, you are missing-out on a wealth of monitoring information about your JVM(s). OK, fine, I accept that. I was just saying "IF you don't need it in production". So, scratch the idea of running Tomcat in a console also. You want to run Tomcat as a Service AND use JMX. That thus leaves the problem that there is only one set of JVM command-line parameters. But rather than using the JMX protocol, I would recommend using Tomcat's JMXProxyServlet -- a part of the Manager application. That allows you to make JMX queries over HTTP, and you don't have to mess-around with Java's JMX-protocol configuration and ugly (and lacking) authentication capabilities. Just this moment we had a mystery 'hang' with my Tomcat service in PRD that required a Service Restart. If I had JMX enabled then I might have been able to get some more information. We just onboarded a bunch of new users but the Tomcat logs themselves don't clearly show memory issues so would have been nice to have that extra layer of logging that JMX would have given me to see if I could have figured it out. Still working on the other suggestions that people have given over the last 24 hours on trying to get it to working. -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, August 09, 2018 1:57 PM To: users@tomcat.apache.org Subject: Re: [OT] Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54 - - - external message, proceed with caution - - - -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 8/9/18 12:39 PM, André Warnier (tomcat) wrote: 7) a helpful feature of tomcat, is that it itself provides code to connect to localhost port 8005 and send that shutdown string, so that one does not have to write its own separate program to do that. The bit that is a bit confusing about this feature however, is that in order to use that code, one of course needs to start up another separate instance of tomcat, just to run that code and actually stop the "real" running tomcat. This should really not be a requirement. Launching a JVM just to parse some XML and send a single TCP packet is kind of wasteful. The problem is that Tomcat can't rely on any particular utility programs being installed on the server in order to do something possibly more efficient . I could whip-up something using grep, curl, and plain-old sh for example that would work on most *NIX systems, but windows users wouldn't benefit from that kind of thing. Understood also. The problem remains though : Under Windows, a Service has a single executable, which Windows starts when starting the Service, and then waits for that executable to send back a message indicating that the Service has properly started. Similarly, to stop the Service, Windows sends a message "please stop" to that running executable, and waits for the executable to acknowedge that it is stopping. With Tomcat, this executable is "tomcatV.exe" (the renamed Apache Common wrapper). To my knowledge, there is no provision in Windows for starting a service by running one executable, and stopping it using *another* executable. So your suggestion above is indeed not usable for the Windows Service context. And thus, for stopping the Tomcat Service, the user is stuck with tomcatV.exe, which uses the *same* JVM command-line parameters whether it is to start or to stop tomcat. And that's where the problem lies currently, for the OP : if these JVM parameters contain the stanza needed to open the JMX port, then the "stop" command will try again to open the same JMX port, and fail. Under Linux, and under Windows when running tomcat in a console, there is a distinction between JAVA_OPTS (which are always used in the JVM command-line), and CATALINA_OPTS (which are only added when starting tomcat). So you could put the JMX parameters in CATALINA_OPTS, and the JVM would only open the JMX port when starting tomcat. But, currently, when running tomcat as a Windows Service, there is apparently no way to provide JVM command-line parameters which are used only at start. A solution would be to add a separate options box to the "Startup" and "Shutdown" tabs of the tomcat9w.exe dialog for "additional JVM options at start" and "additional JVM options at stop" (and of course all the associated plumbing in the wrapper code). But I guess that this would go in the category of "enhancement request". I've seen Mark's previous answer, which seems to indicate that there is actually another way, but I must confess that I did not understand it. I was very surprised to find out that Tomcat's Windows service-runner doesn't have separate "launch parameters" versus "stop parameters" (i.e. the equivalent of CATALINA_OPTS versus JAVA_OPTS for the script-based service-management). I guess that's just a (another) pill you'll have to
[UPDATE][SECURITY] CVE-2018-8037 Apache Tomcat - Information Disclosure
CVE-2018-8037 Apache Tomcat - Information Disclosure Severity: Important Vendor: The Apache Software Foundation Versions Affected: Apache Tomcat 9.0.0.M9 to 9.0.9 Apache Tomcat 8.5.5 to 8.5.31 Description: If an async request was completed by the application at the same time as the container triggered the async timeout, a race condition existed that could result in a user seeing a response intended for a different user. An additional issue was present in the NIO and NIO2 connectors that did not correctly track the closure of the connection when an async request was completed by the application and timed out by the container at the same time. This could also result in a user seeing a response intended for another user. Mitigation: Users of the affected versions should apply one of the following mitigations: - Upgrade to Apache Tomcat 9.0.10 or later. - Upgrade to Apache Tomcat 8.5.32 or later. History: 2018-07-22 Original advisory 2018-08-09 Update description References: [1] http://tomcat.apache.org/security-9.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: three layers model
Thanks Chris for your response On Thu, Aug 9, 2018 at 8:37 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Loai, > > On 8/8/18 3:51 PM, Loai Abdallatif wrote: > > Dear All > > > > I have java apps running over three tiers model ( Apache - modJK) , > > Tomcat 8.5.29, and postgress 9.4 cluster with repmgr and pgpool -- > > all the layers use same OS Debian 8.10 > > > > we are planing to upgrade the OS to 9.5 and also upgrade the tomcat > > to version 9 and JDK to version 9> Is there any comparability list > > for using these components ? > > If the JRE runs, Tomcat should run. Barring any dependency issues > (like things being removed from JREs that need to be added-back-in to > support your application), any future JRE should work with any older > Tomcat. > > There should really be no compatibility problems with Tomcat and the > JRE. Your application, however, may have some compatibility issues > with those upgrades. > > I you find any problems with Java 9 and Tomcat 9, please report them > here. That configuration should certainly be supported. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltse8wACgkQHPApP6U8 > pFjeKA//UU0DhfLUoHp2NqWFMu/nXl9D/Ijr2fU8Kk9a2+ZikvUj9DkzUuBUHaEi > Kb9hRqEurnwaB9OhvSAfhpxNJ+1FNrlCmH7Q0hTPP730h9VdJCJMaKiILZ196TKK > HG2vdwq3xO8mS5xc17q3o/IfcIQFNN6gnz7OvovtkRnralkSRmPMyrmq5UXb9aeA > M3a5iW7JNUO2TqYxmHzGgQ06CQH66xqY+JCnBe/ro9Jgahg/ulpHJT1ofpun95dq > MYOMVoXz0+yq+AET4KhX5YDApIw7r6bopsUwjA/EySu+NhI3CGCDMfCJXi5GIVt/ > D4V0Y0tNCCDnaMlmaeJBuPImLdYc76jWckg2iHXqXSE6PNcwADYRWlbP6/Ijb0np > Tng+6393kgwcnzPHaZmHEZHppsN/+CiDjV74nvL1hrVCDOyJvJILkpvyq/BVI7Yt > 4nnTNLRrlmXUJcTjiS8g4dksfw6ilwxI3LdTHAplIj4TEC27JCwJGlX9yJSs3wc6 > ZOu3FEtwQsM6TfnTlQQ8sFzQXGzyua/ZM4iHsAjY68z8WbOktzA8ccS7pGOZ86KB > 9tTfCMOat4BXdfASEJsbYMeLyRICMcDrLKgy4zDmzdlELKCFel+iLwyWgMb7rgP3 > bJGqrm1MA8s2J8U1nWV96LFp9Zmr0oO7qrYnRAgl40FlvYkYe/I= > =iL1M > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
RE: [OT] Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54
Oh! André, if you aren't using JMX in production, you are missing-out on a wealth of monitoring information about your JVM(s). But rather than using the JMX protocol, I would recommend using Tomcat's JMXProxyServlet -- a part of the Manager application. That allows you to make JMX queries over HTTP, and you don't have to mess-around with Java's JMX-protocol configuration and ugly (and lacking) authentication capabilities. >> Just this moment we had a mystery 'hang' with my Tomcat service in PRD that >> required a Service Restart. If I had JMX enabled then I might have been >> able to get some more information. We just onboarded a bunch of new users >> but the Tomcat logs themselves don't clearly show memory issues so would >> have been nice to have that extra layer of logging that JMX would have given >> me to see if I could have figured it out. Still working on the other suggestions that people have given over the last 24 hours on trying to get it to working. -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, August 09, 2018 1:57 PM To: users@tomcat.apache.org Subject: Re: [OT] Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54 - - - external message, proceed with caution - - - -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 8/9/18 12:39 PM, André Warnier (tomcat) wrote: > 7) a helpful feature of tomcat, is that it itself provides code to > connect to localhost port 8005 and send that shutdown string, so > that one does not have to write its own separate program to do > that. The bit that is a bit confusing about this feature however, > is that in order to use that code, one of course needs to start up > another separate instance of tomcat, just to run that code and > actually stop the "real" running tomcat. This should really not be a requirement. Launching a JVM just to parse some XML and send a single TCP packet is kind of wasteful. The problem is that Tomcat can't rely on any particular utility programs being installed on the server in order to do something possibly more efficient . I could whip-up something using grep, curl, and plain-old sh for example that would work on most *NIX systems, but windows users wouldn't benefit from that kind of thing. I was very surprised to find out that Tomcat's Windows service-runner doesn't have separate "launch parameters" versus "stop parameters" (i.e. the equivalent of CATALINA_OPTS versus JAVA_OPTS for the script-based service-management). I guess that's just a (another) pill you'll have to swallow if you want to run on Windows. > Of course, one could also wonder if you really need JMX when you > run tomcat in production mode. If this is only for testing, you > could run tomcat in a console, where you would not have the same > issue (because you would not have the wrapper with its > single-minded preset JVM options). Oh! André, if you aren't using JMX in production, you are missing-out on a wealth of monitoring information about your JVM(s). But rather than using the JMX protocol, I would recommend using Tomcat's JMXProxyServlet -- a part of the Manager application. That allows you to make JMX queries over HTTP, and you don't have to mess-around with Java's JMX-protocol configuration and ugly (and lacking) authentication capabilities. > (Or you could switch to Linux ;-)) A wise choice IMHO, if you have the expertise to manage it. I wouldn't recommend that a Windows shop just switch to Linux any time soon. But if you have people very familiar with *NIX deployments, I would recommend keeping Windows on desktops and leave the servers running some kind of *NIX. - -chris > On 09.08.2018 02:06, Daniel Savard wrote: >> Le mer. 8 août 2018 à 12:08, Louis Zipes a >> écrit : >> >>> >>> Hi Calder, I can successfully start up as a Windows service and >>> get JMX working BUT my problem is that Service doesn't stop >>> cleanly (just repeating that problem in case it wasn't made >>> clear). It says the PORT is already in use which led me to try >>> to use Catalina_Opts as per the suggestions on the internet. >>> >>> Port already in use: 8008; nested exception is: >>> java.net.BindException: Address already in use: JVM_Bind >>> >>> If you were able to get JMX working and you can start AND stop >>> the Tomcat service cleanly, do you mind sharing me your >>> 'scrubbed' Java tab contents as I can seem to get the right >>> combination to get it to Start and Stop the service. >>> >>> Thanks, Louis >>> >>> >>> >> Louis, >> >> I believe you need to understand a bit more how things are >> working with Java and the JVM. The -D options are pretty straight >> forward for anyone knowing how you define properties to the JVM >> on the command line. I already told you everything you need to >> know to setup properly your Tomcat. Since you were the one >> talking about CATALINA_OPTS I assumed you did know where and how >> to setup the variable for y
Re: [OT] Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
André,
On 8/9/18 12:39 PM, André Warnier (tomcat) wrote:
> 7) a helpful feature of tomcat, is that it itself provides code to
> connect to localhost port 8005 and send that shutdown string, so
> that one does not have to write its own separate program to do
> that. The bit that is a bit confusing about this feature however,
> is that in order to use that code, one of course needs to start up
> another separate instance of tomcat, just to run that code and
> actually stop the "real" running tomcat.
This should really not be a requirement. Launching a JVM just to parse
some XML and send a single TCP packet is kind of wasteful. The problem
is that Tomcat can't rely on any particular utility programs being
installed on the server in order to do something possibly more efficient
.
I could whip-up something using grep, curl, and plain-old sh for
example that would work on most *NIX systems, but windows users
wouldn't benefit from that kind of thing.
I was very surprised to find out that Tomcat's Windows service-runner
doesn't have separate "launch parameters" versus "stop parameters"
(i.e. the equivalent of CATALINA_OPTS versus JAVA_OPTS for the
script-based service-management). I guess that's just a (another) pill
you'll have to swallow if you want to run on Windows.
> Of course, one could also wonder if you really need JMX when you
> run tomcat in production mode. If this is only for testing, you
> could run tomcat in a console, where you would not have the same
> issue (because you would not have the wrapper with its
> single-minded preset JVM options).
Oh! André, if you aren't using JMX in production, you are missing-out
on a wealth of monitoring information about your JVM(s).
But rather than using the JMX protocol, I would recommend using
Tomcat's JMXProxyServlet -- a part of the Manager application. That
allows you to make JMX queries over HTTP, and you don't have to
mess-around with Java's JMX-protocol configuration and ugly (and
lacking) authentication capabilities.
> (Or you could switch to Linux ;-))
A wise choice IMHO, if you have the expertise to manage it. I wouldn't
recommend that a Windows shop just switch to Linux any time soon. But
if you have people very familiar with *NIX deployments, I would
recommend keeping Windows on desktops and leave the servers running
some kind of *NIX.
- -chris
> On 09.08.2018 02:06, Daniel Savard wrote:
>> Le mer. 8 août 2018 à 12:08, Louis Zipes a
>> écrit :
>>
>>>
>>> Hi Calder, I can successfully start up as a Windows service and
>>> get JMX working BUT my problem is that Service doesn't stop
>>> cleanly (just repeating that problem in case it wasn't made
>>> clear). It says the PORT is already in use which led me to try
>>> to use Catalina_Opts as per the suggestions on the internet.
>>>
>>> Port already in use: 8008; nested exception is:
>>> java.net.BindException: Address already in use: JVM_Bind
>>>
>>> If you were able to get JMX working and you can start AND stop
>>> the Tomcat service cleanly, do you mind sharing me your
>>> 'scrubbed' Java tab contents as I can seem to get the right
>>> combination to get it to Start and Stop the service.
>>>
>>> Thanks, Louis
>>>
>>>
>>>
>> Louis,
>>
>> I believe you need to understand a bit more how things are
>> working with Java and the JVM. The -D options are pretty straight
>> forward for anyone knowing how you define properties to the JVM
>> on the command line. I already told you everything you need to
>> know to setup properly your Tomcat. Since you were the one
>> talking about CATALINA_OPTS I assumed you did know where and how
>> to setup the variable for your installation. Otherwise, just go
>> in the setup utility for Tomcat on Windows and put the
>> -Dcom.sun.management.conf.file=${catalina.base}/conf/abc.def
>> entry there without the CATALINA_OPTS= stanza since this one's
>> intent is to set an environment variable for the process to pick
>> while the former is passing directly the property to the JVM from
>> the Tomcat Windows Setup dialog. There is many ways to do things.
>> Bottom line, you need to tell the JVM where is the configuration
>> file for JMX and put your properties in there as any other
>> properties file. This is standard stuff.
>>
>> The effect is the JVM now knows your port is a JMX port and it
>> will stop to try to use it when it is already in use and free it
>> cleanly.
>>
>> Regards,
>>
>> - Daniel Savard
>>
>>
>>>
>>>
>>
>
>
> -
>
>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltsgHgACgkQHPApP6U8
pFg61BAAo+n7gJkweUGuLJK7Vld1n40tj2Pl4M8qS6dWs5RD250kZwNQfDCuB0
Re: Domain name change in Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Laurie, On 8/9/18 8:31 AM, Laurie Miller-Cook wrote: > Hi there > > Sorry for the confusion. > > We have two servers with multiple hosts on. East host has it's own > Host entry in Server.xml due to using a wildcard SSL certificate > > At the bottom of the email I used the details of the prod server > ondemand.com and below I applied the Alias to different server, > which I can test and reboot without the need of an outage window. > > I entered the Alias line in the test.lbpondemand.com host, then > Stopped and Started Tomcat. I then tested access to ever one of > the hosts (using the host name in IE) and everyone came back with > "This page can't be displayed" > > I remove the alias line, stopped and started tomcat and I still > received the "this page can't be displayed". I had to reboot the > server for the hosts to be accessible again. > > To resolve the issue, I entered the Alias line and rebooted the > server and the changes took effect and all the hosts worked. > > Do you have any idea why the stop\Start of Tomcat would cause an > issue whereas the Reboot of the Server worked ok? > > The error logs did not show anything different between when the > hosts failed on a restart of Tomcat and when I rebooted the whole > server. There is no reason I can think of that rebooting would be necessary. Tomcat does not persist anything across restarts except possibly user-sessions. - -chris > -Original Message- From: André Warnier (tomcat) > Sent: Wednesday, August 08, 2018 7:34 PM To: > users@tomcat.apache.org Subject: Re: Domain name change in Tomcat > > Hi. It is getting a bit confused and confusing here : - the latest > configuration that you indicate below, does not match the previous > one which you indicated previously (see even further below). - you > are talking about "broke every site" (implying several "sites"). > What do you mean exactly by "site" ? the "" tags which you > list below (without the Alias) seem to point to a single "site" (if > by "site" you mean one hostname). - you also do not really "broke > every site". What URL were you trying to use, when *your browser* > responded with "this page cannot be displayed" ? - did you look at > the tomcat logfiles, when you got the error ? Maybe it provides > some useful clue. - about >> companytest.lbpondemand.com > : is that hostname registered in the DNS ? (in other words : can > you do "ping companytest.lbpondemand.com", and what does that > respond ?) > > All in all, that makes it a bit hard to guess what you mean and > how we could help. > > > On 08.08.2018 17:39, Laurie Miller-Cook wrote: >> Hi there >> >> I tried entering an Alias, like so >> >> > unpackWARs="true" autoDeploy="true"> >> companytest.lbpondemand.com > className="org.apache.catalina.valves.AccessLogValve" >> directory="logs" prefix="Test_access_log" suffix=".txt" >> pattern="%h %l %u %t "%r" %s %b" /> >> >> >> But this broke every site I had on the server, I got "This page >> can't be displayed" >> >> I had to remove the Alias line and the reboot the server to get >> things working again. >> >> Any ideas? >> >> Laurie -Original Message- From: Igor Cicimov >> Sent: Tuesday, August 07, 2018 11:49 PM To: >> Tomcat Users List Subject: Re: Domain >> name change in Tomcat >> >> On Wed, 8 Aug 2018 1:52 am Laurie Miller-Cook < >> laurie.miller-c...@larmerbrown.com> wrote: >> >>> Hi there, >>> >>> I have an issue where I need to either change the URL of a >>> Website in Tomcat. >>> >>> The current URL is https://training.ondemand.com and this >>> needs to be changed to https://wbt.ondemand.com (we have a >>> wildcard SSL certificate) >>> >>> In my server.xml I have the following >>> >>> >> unpackWARs="true" autoDeploy="true"> >> className="org.apache.catalina.valves.AccessLogValve" >>> directory="logs" prefix="Training_access_log" suffix=".txt" >>> pattern="%h %l %u %t "%r" %s %b" /> >>> >>> >>> Can I change the host name to wbt.ondemand.com and everything >>> will still work or as I expect am I going to have to build a >>> new site from scratch? >>> >>> All the best >>> >>> Laurie >>> >> >> Just use Alias inside the Host >> https://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Host_Name_A l >> >> >> iases >> >>> >> >> - >> >> >> 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 > -BEGIN PGP SIG
Re: Domain name change in Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Laurie, On 8/7/18 11:51 AM, Laurie Miller-Cook wrote: > Hi there, > > I have an issue where I need to either change the URL of a Website > in Tomcat. > > The current URL is https://training.ondemand.com and this needs to > be changed to https://wbt.ondemand.com (we have a wildcard SSL > certificate) > > In my server.xml I have the following > > unpackWARs="true" autoDeploy="true"> className="org.apache.catalina.valves.AccessLogValve" > directory="logs" prefix="Training_access_log" suffix=".txt" > pattern="%h %l %u %t "%r" %s %b" /> > > > Can I change the host name to wbt.ondemand.com and everything will > still work or as I expect am I going to have to build a new site > from scratch? How many elements do you have in your conf/server.xml? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltsfAUACgkQHPApP6U8 pFgzgBAAwhXmVuBR3tv/m2w5hZTsUmCqp3TN0R6NdtT+uoHay9arDKgYeMlgLbIH tRzWAuWwwfaWaJMl+f6HhzKEuAYMrwenQZl4ZEi/wAckQQ9QZLuu3aDP//tJehsz ck+QReyUNvZgHJBCZrQas/GHi5D745AzHZfKzwJMX+hDD1MQyzd1jFA5HkRIwHkf +kZ1VluZ732S8cqFFxmiTQhwYGj0cK6hndKXSiXBl6LBSop46LSNtOztNW/ZvH2i QW2CiT7C7HvbUnX9Egfbb37PxeERHDw6UMn05oB/mfHirmfNaZe/X2RA0uZv8fW+ WYTlys3fOYSnIaEK30Qnmh5wOHyffJkh4Ckqibwe0l7UVEX/JnZJWF9wq6/W7eyZ KoYeh3/+/ldilPaK90xPgTry/hVqapD2ygg38+Ca+0q1OVgUWmshZiisni7BcWay XMf8egcZF8lyTvth3KZ1lIaiIjz7PDpVO4HB2va+0eeHrtyEvvQnPm9suRyHRT77 zseQ7uApBV7ULuhghYWsc7hVOn4zWBmlfEbfnsOG2oNjvGCSRUTrbW4Rgqjux6Oi X7iLJC2fP52kNWGKdrsvmpUYJWR6HCMV1KTu8VOejhAO5QwFc48o9znQ1lzWvX0R VpdjzDhAYOgxph0Qri3dNTUctJ0o77ytQ1XiN7gI4oXSR88V/Xs= =UvHV -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: three layers model
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Loai, On 8/8/18 3:51 PM, Loai Abdallatif wrote: > Dear All > > I have java apps running over three tiers model ( Apache - modJK) , > Tomcat 8.5.29, and postgress 9.4 cluster with repmgr and pgpool -- > all the layers use same OS Debian 8.10 > > we are planing to upgrade the OS to 9.5 and also upgrade the tomcat > to version 9 and JDK to version 9> Is there any comparability list > for using these components ? If the JRE runs, Tomcat should run. Barring any dependency issues (like things being removed from JREs that need to be added-back-in to support your application), any future JRE should work with any older Tomcat. There should really be no compatibility problems with Tomcat and the JRE. Your application, however, may have some compatibility issues with those upgrades. I you find any problems with Java 9 and Tomcat 9, please report them here. That configuration should certainly be supported. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltse8wACgkQHPApP6U8 pFjeKA//UU0DhfLUoHp2NqWFMu/nXl9D/Ijr2fU8Kk9a2+ZikvUj9DkzUuBUHaEi Kb9hRqEurnwaB9OhvSAfhpxNJ+1FNrlCmH7Q0hTPP730h9VdJCJMaKiILZ196TKK HG2vdwq3xO8mS5xc17q3o/IfcIQFNN6gnz7OvovtkRnralkSRmPMyrmq5UXb9aeA M3a5iW7JNUO2TqYxmHzGgQ06CQH66xqY+JCnBe/ro9Jgahg/ulpHJT1ofpun95dq MYOMVoXz0+yq+AET4KhX5YDApIw7r6bopsUwjA/EySu+NhI3CGCDMfCJXi5GIVt/ D4V0Y0tNCCDnaMlmaeJBuPImLdYc76jWckg2iHXqXSE6PNcwADYRWlbP6/Ijb0np Tng+6393kgwcnzPHaZmHEZHppsN/+CiDjV74nvL1hrVCDOyJvJILkpvyq/BVI7Yt 4nnTNLRrlmXUJcTjiS8g4dksfw6ilwxI3LdTHAplIj4TEC27JCwJGlX9yJSs3wc6 ZOu3FEtwQsM6TfnTlQQ8sFzQXGzyua/ZM4iHsAjY68z8WbOktzA8ccS7pGOZ86KB 9tTfCMOat4BXdfASEJsbYMeLyRICMcDrLKgy4zDmzdlELKCFel+iLwyWgMb7rgP3 bJGqrm1MA8s2J8U1nWV96LFp9Zmr0oO7qrYnRAgl40FlvYkYe/I= =iL1M -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JAXB not available on Tomcat 9 and Java 10
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nicolaj, On 8/8/18 1:17 AM, Nicolai Parlog wrote: > Hi, > > with the help of an answer on StackOverflow we have solved this. > In case anybody was watching this, here's what happened... > > First some random facts: > > * if not given a class loader > (https://javaee.github.io/jaxb-v2/doc/user-guide/ch06.html#d0e6919), > > `JAXBContext::newInstance` will use [the thread's context class > loader > (https://docs.oracle.com/javase/10/docs/api/java/lang/Thread.html#getC ontextClassLoader()) > > when looking for the JAXB implementation - this is the case even if > you call `newInstance(Class...)` (one might mistakenly think it > uses the provided class instances' loader) * Tomcat builds a small > class loader hierarchy > (https://tomcat.apache.org/tomcat-9.0-doc/class-loader-howto.html) > to separate web applications from one another * by not relying on > the module _java.xml.bind_, in Java 9, JAXB classes are not loaded > by the bootstrap or system class loader > > So here's what happened on Java 8: > > * we don't pass a class loader to JAXB (oops), so it uses the > thread's context class loader * our conjecture is that Tomcat does > not explicitly set the context class loader and so it will end up > being the same one that loaded Tomcat: the system class loader This is almost certainly an incorrect assumption. While an application is processing a request, the TCCL should be that of the webapp's ClassLoader. Any other situation would be a security problem. > * that's dandy because the system class loader sees the entire JDK > and hence the JAXB implementation included therein > > Java 9 enters - the piano stops playing and everybody puts down > their scotch: > > * we added JAXB as a regular dependency > (https://stackoverflow.com/a/48204154/2525313) and so it is loaded > by the web app's class loader * just as on Java 8, JAXB searches > the system class loader, though, and that one can't see the app's > loader (only the other way around) If your above assumption were true, then this would be true. But I believe both of these assumptions are false. It's easy to test your hypothesis: just print the value of the TCCL at the point where you think JAXB is using the wrong one. If it's a WebappClassLoader, then your analysis above is incorrect. If it's printing the (somewhat confusingly called the) "application" ClassLoader or "system" classloader, or "null", then something running in your environment has broken the TCCL, and it's probably no Tomcat's fault. > * JAXB fails to find the implementation and goes belly up > > The solution is to make sure JAXB uses the right class loader. We > know of three ways: > > * call > > `Thread.getCurrentThread().setContextClassLoader(this.getClass().getCl assLoader());` > > but that's not really a good idea > * create a context resolver > > (https://docs.oracle.com/javaee/7/api/javax/ws/rs/ext/ContextResolver. html), > > but that requires JAX-WS and that feels like replacing one evil with > another * use the package-accepting variant of > `JAXBContext::newInstance` that also takes a class loader and pass > the correct loader, although that requires some refactoring JAXB using the TCCL is entirely appropriate. You need to find out why the TCCL is wrong. Try running your application under a SecurityManager and you'll find out where the TCCL is being set pretty quickly :) - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltsezMACgkQHPApP6U8 pFh76BAAlFiN/qNZm5LSXRAriskFn3HMl6+dNdxzQt8xhVJAIvZt9yE+ntA6RMYd vcXGCR/Ttb/f1wKGxKK6sfgifGWJXuL6+XRL6n0DaKicAN9euGY8qZh2wxarp0Aa wa38zY1PemREkPpJZWphwT1jl/XCXzg/d7k+DCmcOMnKoAtGeH/J/AU18ay5dk97 FfDtVSSbMcp1R0QYNkC9rVta7A1cSgzVVnGHzu6sia7KViiG1/3f5yJEM3NlI9pe EYKzo0N2h901TMDpv81NhGs0qeTkQQZHojtQsg7GWs29DQMXNeBP/Wv/ciuriuHA B0E+NtS3MJRY2LZ3XTBPx3BvSY5giUGolt7tU6LDtKEMuiDMFkCrtdi5Useo1BTt OJZxaphzuqPG94DhsO5b4/t9hNuZ1YurKZDcQ7j2UkI9/TwPiW33ch7T6qzIn6ZO vKi/AAZQsYuOyGEOb7UZj8N2PFMXLXkbv+WX+QtvbnEM/0+s4AHejvxlcLE6I3k3 gUoHwqV+MXccZeEfgKgZm5xURES4AynBXR4BGMbUk6VZOryAVP80G3GKnkebNaK/ RrR0f4WbHDRKOp0azRFDWqmjkKwb4dYJTUWX8hhw1M4oTxRoiJx0pvcjK49sgkaH Fx8MXxhCp00mWY4sOysXtNrHc+Tw8qvonFpO0juLc65/ttSafpI= =GGUk -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54
Maybe it is time here to quote Arthur Clarke's 3rd law :
"Any sufficiently advanced technology is indistinguishable from magic"
(See : https://en.wikipedia.org/wiki/Clarke%27s_three_laws)
The process by which Tomcat is started and/or stopped - particularly under Windows and as
a Service - is not very clear in the on-line documentation.
Neither is it it very easy to write a comprehensive and accurate documentation, because
the thing has gotten to a point where, for mere mortals, it is really quite complicated.
(Have a look at bin/catalina.bat to get an idea).
So let me give you some overall pointers (some of them quite basic, I apologise), and
maybe in there somewhere, you'll find wat you are missing to complete the picture and do
what you want to do.
1) Tomcat is a compiled java application, in java bytecode. To run this bytecode, you
need a JVM. The JVM is machine-executable code, so to run tomcat, you run a JVM and tell
it to run the tomcat bytecode.
2) the java JVM for Windows is not very good at running as a Windows Service (it does not
handle the appropriate Windows "signals" etc.). To solve this, when you want to run tomcat
as a Windows Service (or rather - see above - run the JVM as a Windows Service), you
actually run a specialised "wrapper program" which does work well as a Windows Service,
and you ask this wrapper to start the JVM which runs tomcat.
To make matters a bit more confusing (or maybe, for some, clearer), this generic "Windows
Service JVM wrapper" is renamed to "tomcatV.exe" (where V is the tomcat version, so for
tomcat 9, the program is called tomcat9.exe).
3) the wrapper program, when it starts the JVM, has to know which command-line switches it
should pass to it. For the Windows Service flavor of tomcat, these parameters are stored
in a number of special keys in the Windows Registry, and that is where the wrapper picks
them up, before starting the JVM.
4) To make it easier to set and edit these JVM command-line parameters, tomcat provides
another Windows executable program - a specialised GUI Registry Editor - which is also
renamed according to the tomcat version, as tomcatVw.exe (where V is the tomcat version,
so for tomcat 9 it would be tomcat9w.exe).
5) as a separate bit of knowledge, I would suppose that everyone knows that on any given
host, a given TCP listening port can only be opened by one process at a time. If a second
process tries to open a port which is already opened by a first process, it will get an
error of the kind "port already in use", and most probably the second process will then
exit (non-gracefully).
6) in the tomcat conf/server.xml file, there is a tag :
This provides a clue as to how one actually *stops* tomcat : one opens a TCP connection to
locahost port 8005 (on which tomcat listens), then sends the string "SHUTDOWN" on that
connection. This causes tomcat to shutdown gracefully, at the end of which it does a
"system.exit()" which shuts down the JVM that runs it.
And this in turn causes the JVM wrapper program to tell Windows that the tomcat Service is
shutting down, before itself exiting. And thus is all well and tidy in the Windows Service
world.
7) a helpful feature of tomcat, is that it itself provides code to connect to localhost
port 8005 and send that shutdown string, so that one does not have to write its own
separate program to do that.
The bit that is a bit confusing about this feature however, is that in order to use that
code, one of course needs to start up another separate instance of tomcat, just to run
that code and actually stop the "real" running tomcat.
And of course running a separate instance of tomcat actually means running a separate
instance of the JVM which runs tomcat.
Now armed with all the above knowledge, and with the dialog window offered by the
tomcat9w.exe program, it is relatively easy to figure out what happens (or at least what
may happen in your case, in my modest non-java-expert opinion).
Looking only at the last 3 tabs of that window (Java / Startup / Shutdown), one can figure
out that :
- the "java" tab contains the path of the JVM to be started, and the command-line
parameters that will be passed to that JVM
- the "Startup" tab contains the java class that the JVM should invoke at the start of
tomcat, and the argument ("start") to pass into that initial call.
- the "Shutdown" tab contains the java class that the JVM should invoke to stop an
already-running tomcat, and the argument ("stop") to pass into that initial call.
(Thus triggering the code in (7) above).
And I believe that, in the particular case of Tomcat being run as a Windows Service, here
may be the origin of the problem which you are encountering : the "Java" tab lists
command-line options that are *common* to both the JVM which starts tomcat, and to the
(separate) JVM which stops tomcat. There is only one set of JVM options, for both cases.
Which means that if, in these JVM command-line opti
RE: Documentation for Catalina Base
On Thursday, August 09, 2018 4:23 PM, Marek Czernek wrote: >Hi, > >any thoughts about the PR anyone? [1] Feel free to suggest any >improvements, or help me better the docs with your comments of course. > >[1] https://github.com/apache/tomcat/pull/117 Hi Marek, thanks for writing this. Wish you'd done it earlier as I had the very same problem about two months ago (search for "Tomcat Installation on Windows" in this mailing list). My suggestion would be to have CATALINA_HOME reference something like C:\Program Files\apache-tomcat-9.0.10 on Windows. That would make it very clear that this is code you are not supposed to touch. But I have the feeling that tomcat isn't too strict about such a concept and might require you to do so anyway. Michael > >Cheers, > >On 07/30/2018 09:22 AM, Marek Czernek wrote: >> Hi there, >> >> recently, we noticed the lack of documentation for Catalina Base, and >> I wanted to find out more about it. Other than a strangely obscure txt >> file [1], I did not find the concept and usage of Catalina Base >> documented in the Tomcat docs. >> >> My questions are: >> >> 1) Did I overlook it being documented somewhere? >> >> 2) If not, is there any reason for it not being documented? While I >> don't want to duplicate text, I do not consider a txt file somewhere a >> sufficient docs. >> >> If the answer to both of my questions is no, we'll create a patch >> against the Tomcat docs. >> >> >> [1] https://tomcat.apache.org/tomcat-9.0-doc/RUNNING.txt >> >> >> Cheers, >> > >-- > >Marek Czernek > >JWS/JBCS Associate Quality Engineer, RHCA > >Find me at www.halfastack.com >
Re: Working JKS file for SSL from Tomcat8 doesn't work with Tomcat9
Ugh, right after I sent this, the next search turned up what I needed, the XML had changed. On Aug 08, 2018, at 02:22 PM, Arnold Morein wrote: I have a company-issued, signed SSL cert installed in my Tomcat 8 system and all is well. I downloaded and set up Tomcat 9.0.10 and simply copied the same JKS file over to match my TC8 config. [code] [code] [code] SEVERE: Failed to initialize component [Connector[HTTP/1.1-8443]] org.apache.catalina.LifecycleException: Protocol handler initialization failed at org.apache.catalina.connector.Connector.initInternal(Connector.java:935) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) at org.apache.catalina.core.StandardService.initInternal(StandardService.java:530) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) at org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:852) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) at org.apache.catalina.startup.Catalina.load(Catalina.java:633) at org.apache.catalina.startup.Catalina.load(Catalina.java:656) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.__invoke(DelegatingMethodAccessorImpl.java:43) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:45009) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:45012) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:306) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:491) Caused by: java.lang.IllegalArgumentException: the trustAnchors parameter must be non-empty at org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:114) at org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:85) at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:216) at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1043) at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:540) at org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:74) at org.apache.catalina.connector.Connector.initInternal(Connector.java:932) ... 15 more Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty at java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200) at java.security.cert.PKIXParameters.(PKIXParameters.java:157) at java.security.cert.PKIXBuilderParameters.(PKIXBuilderParameters.java:130) at org.apache.tomcat.util.net.jsse.JSSEUtil.getParameters(JSSEUtil.java:389) at org.apache.tomcat.util.net.jsse.JSSEUtil.getTrustManagers(JSSEUtil.java:313) at org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:112) [code] There is nothing wrong with the JKS files since SSL works fine with TC8. So why is this error appearing in TC9? They are both using JDK 1.8.0_172.
Re: App fails to completely startup on a Tomcat restart
What is your full context.xml file? Also, is there any reason why you have named your application as ROOT.war? Regards, On 9 August 2018 at 15:48, Donald J wrote: > We are running a Tomcat application where the login always fails after a > tomcat restart > with an error about unable to load the configuration context. > The app has a context file defined in > /usr/share/tomcat/webapps/ROOT/META-INF/context.xml > > which contains : > > > > After a Tomcat manager "reload", the application login will always succeed. > A Tomcat manager app stop/start will also let the login succeed. > A Tomcat manager undeploy/deploy will also let the login succeed. > Tomcat version is 7.0.69. > > This appears to be an application programming issue to me, but vendor > seems to be trying > hard to blame it on our customer configuration. As example, they are > saying they did > not test with a ROOT deployment, so we should not use a ROOT deployment. > > catalina log just shows: > > Aug 09, 2018 9:26:23 AM org.apache.catalina.startup.HostConfig deployWAR > INFO: Deployment of web application archive /var/lib/tomcat/webapps/ROOT.war > has finished in 4,825 ms > ... > Aug 09, 2018 9:26:24 AM org.apache.coyote.AbstractProtocol start > INFO: Starting ProtocolHandler ["http-apr-8443"] > Aug 09, 2018 9:26:24 AM org.apache.catalina.startup.Catalina start > INFO: Server startup in 6031 ms > > I realize the above is not sufficient info for anyone to identify the > problem, but > I am asking if there might be any parameter tweeks in Tomcat that might > get the > application to totally start up on a Tomcat restart? > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
App fails to completely startup on a Tomcat restart
We are running a Tomcat application where the login always fails after a tomcat restart with an error about unable to load the configuration context. The app has a context file defined in /usr/share/tomcat/webapps/ROOT/META-INF/context.xml which contains : After a Tomcat manager "reload", the application login will always succeed. A Tomcat manager app stop/start will also let the login succeed. A Tomcat manager undeploy/deploy will also let the login succeed. Tomcat version is 7.0.69. This appears to be an application programming issue to me, but vendor seems to be trying hard to blame it on our customer configuration. As example, they are saying they did not test with a ROOT deployment, so we should not use a ROOT deployment. catalina log just shows: Aug 09, 2018 9:26:23 AM org.apache.catalina.startup.HostConfig deployWAR INFO: Deployment of web application archive /var/lib/tomcat/webapps/ROOT.war has finished in 4,825 ms ... Aug 09, 2018 9:26:24 AM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler ["http-apr-8443"] Aug 09, 2018 9:26:24 AM org.apache.catalina.startup.Catalina start INFO: Server startup in 6031 ms I realize the above is not sufficient info for anyone to identify the problem, but I am asking if there might be any parameter tweeks in Tomcat that might get the application to totally start up on a Tomcat restart? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Documentation for Catalina Base
Hi, any thoughts about the PR anyone? [1] Feel free to suggest any improvements, or help me better the docs with your comments of course. [1] https://github.com/apache/tomcat/pull/117 Cheers, On 07/30/2018 09:22 AM, Marek Czernek wrote: Hi there, recently, we noticed the lack of documentation for Catalina Base, and I wanted to find out more about it. Other than a strangely obscure txt file [1], I did not find the concept and usage of Catalina Base documented in the Tomcat docs. My questions are: 1) Did I overlook it being documented somewhere? 2) If not, is there any reason for it not being documented? While I don't want to duplicate text, I do not consider a txt file somewhere a sufficient docs. If the answer to both of my questions is no, we'll create a patch against the Tomcat docs. [1] https://tomcat.apache.org/tomcat-9.0-doc/RUNNING.txt Cheers, -- Marek Czernek JWS/JBCS Associate Quality Engineer, RHCA Find me at www.halfastack.com
RE: Domain name change in Tomcat
Hi there Sorry for the confusion. We have two servers with multiple hosts on. East host has it's own Host entry in Server.xml due to using a wildcard SSL certificate At the bottom of the email I used the details of the prod server ondemand.com and below I applied the Alias to different server, which I can test and reboot without the need of an outage window. I entered the Alias line in the test.lbpondemand.com host, then Stopped and Started Tomcat. I then tested access to ever one of the hosts (using the host name in IE) and everyone came back with "This page can't be displayed" I remove the alias line, stopped and started tomcat and I still received the "this page can't be displayed". I had to reboot the server for the hosts to be accessible again. To resolve the issue, I entered the Alias line and rebooted the server and the changes took effect and all the hosts worked. Do you have any idea why the stop\Start of Tomcat would cause an issue whereas the Reboot of the Server worked ok? The error logs did not show anything different between when the hosts failed on a restart of Tomcat and when I rebooted the whole server. Best regards Laurie Miller-Cook e: laurie.miller-c...@larmerbrown.com -Original Message- From: André Warnier (tomcat) Sent: Wednesday, August 08, 2018 7:34 PM To: users@tomcat.apache.org Subject: Re: Domain name change in Tomcat Hi. It is getting a bit confused and confusing here : - the latest configuration that you indicate below, does not match the previous one which you indicated previously (see even further below). - you are talking about "broke every site" (implying several "sites"). What do you mean exactly by "site" ? the "" tags which you list below (without the Alias) seem to point to a single "site" (if by "site" you mean one hostname). - you also do not really "broke every site". What URL were you trying to use, when *your browser* responded with "this page cannot be displayed" ? - did you look at the tomcat logfiles, when you got the error ? Maybe it provides some useful clue. - about > companytest.lbpondemand.com : is that hostname registered in the DNS ? (in other words : can you do "ping companytest.lbpondemand.com", and what does that respond ?) All in all, that makes it a bit hard to guess what you mean and how we could help. On 08.08.2018 17:39, Laurie Miller-Cook wrote: > Hi there > > I tried entering an Alias, like so > > unpackWARs="true" autoDeploy="true"> > companytest.lbpondemand.com >className="org.apache.catalina.valves.AccessLogValve" directory="logs" > prefix="Test_access_log" suffix=".txt" > pattern="%h %l %u %t "%r" %s %b" /> > > > But this broke every site I had on the server, I got "This page can't be > displayed" > > I had to remove the Alias line and the reboot the server to get things > working again. > > Any ideas? > > Laurie > -Original Message- > From: Igor Cicimov > Sent: Tuesday, August 07, 2018 11:49 PM > To: Tomcat Users List > Subject: Re: Domain name change in Tomcat > > On Wed, 8 Aug 2018 1:52 am Laurie Miller-Cook < > laurie.miller-c...@larmerbrown.com> wrote: > >> Hi there, >> >> I have an issue where I need to either change the URL of a Website in >> Tomcat. >> >> The current URL is https://training.ondemand.com and this needs to be >> changed to https://wbt.ondemand.com (we have a wildcard SSL >> certificate) >> >> In my server.xml I have the following >> >> > unpackWARs="true" autoDeploy="true"> >> > className="org.apache.catalina.valves.AccessLogValve" directory="logs" >> prefix="Training_access_log" suffix=".txt" >> pattern="%h %l %u %t "%r" %s %b" /> >> >> >> >> Can I change the host name to wbt.ondemand.com and everything will >> still work or as I expect am I going to have to build a new site from >> scratch? >> >> All the best >> >> Laurie >> > > Just use Alias inside the Host > https://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Host_Name_Al > iases > >> > > - > 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: Tomcat 9 does not work with war file named along with revision number
Thanks Mark for the reply. Tried out with a simple app and it works perfectly. Looks like some tweaking may be needed at the application side. Appreciate your help. Thanks Prem -Original Message- From: Mark Thomas Sent: Wednesday, August 08, 2018 10:44 AM To: users@tomcat.apache.org Subject: Re: Tomcat 9 does not work with war file named along with revision number On 08/08/18 15:20, premsudhan jaikumar wrote: > Hello everyone, > > Did some more digging into this issue am facing with various other tomcat > versions and it appears other than Tomcat version 7 all higher versions are > having this behavior, I tried with Tomcat8.0 , 8.5. & 9.0 and all has the > same issue. > > It throws the below error > > SEVERE [http-nio-8080-exec-7] > org.apache.catalina.core.StandardHostValve.custom Exception Processing > ErrorPage[exceptionType=java.lang.Exception, > location=/uncaughtException] > javax.servlet.ServletException: Could not resolve view with name > 'uncaughtException' in servlet with name 'dispatcher' > > Any ideas, pointers to further investigate this? Appreciate any help on this. > Thanks. This works fine for me. You need to create the simplest possible web application - ideally a single JSP or servlet - that demonstrates the problem. Chances are, in reducing the issue to the simplest cause, you'll find the root cause. If not, the community will be able to recreate the issue and investigate. Mark > > -Prem > > > From: premsudhan jaikumar > Sent: Tuesday, August 07, 2018 11:53 AM > To: 'users@tomcat.apache.org' > Subject: Tomcat 9 does not work with war file named along with > revision number > > Hi > Am trying to deploy an application in Tomcat version 9.10,it has application > war file name like For Eg: app-name##r123.war file. And I can see its not > recognizing the context path from the exploded war. If I rename the war file > name without revision number it works fine. > > from Tomcat documentation I can see that this naming convention is supported > - https://tomcat.apache.org/tomcat-9.0-doc/config/http.html however it > doesn't seem to work. > > The same war file works with Tomcat7 without any issues.Did anyone face this > issue ? > > > -Prem > > - 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: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54
On 09/08/18 12:11, Suvendu Sekhar Mondal wrote: > On Thu, Aug 9, 2018 at 2:39 PM Mark Thomas wrote: >> >> On 09/08/18 01:06, Daniel Savard wrote: >> >>> Louis, >>> >>> I believe you need to understand a bit more how things are working with >>> Java and the JVM. >> >> Actually Daniel, it is you who needs to understand things better. >> >> >> Louis, >> >> Clearly, when Tomcat is started a new JVM instance is created and it >> listens on the configured JMX ports. >> >> The problem is that when Tomcat is stopped another JVM instance is >> created (to send the stop message to the first) and that uses the same >> configuration. Hence it tries to open the same JMX port and fails >> because it is already bound. >> >> If you were running from the command line, the fix would be easy. Put >> the JMX options in CATALINA_OPTS and they'd only be used on start but >> not stop. (JAVA_OPTS are used on both start and stop). >> >> There is also a simple fix if running as a Windows Service. The Windows >> Service wrapper is simply a renamed version Apache Common Daemon. When >> running a Java program as a Windows service there are three ways it can >> be integrated. >> >> 1. jvm. The Windows service wrapper starts and embedded JVM using the >> provided parameters and then calls the start method on the appropriate >> class. To stop, it calls the stop method on the appropriate class in the >> embedded jvm. >> >> 2. Java. The Windows service wrapper starts a separate Java process with >> the provided parameters. On stop, a second Java process is started using >> the same parameters which is expected to communicate with the first >> process and stop it. >> >> 3. exe. Same as 2 but any executable can be used rather than java.exe. >> >> You see the error you are see because you are using Java mode. Switch to >> jvm mode and all should be well. >> >> Finally 7.0.54 is very old. I strongly recommend an upgrade at least to >> the latest 7.0.x release is not 8.5.x/9.0.x >> >> Mark >> > One question Mark, if I use > org.apache.catalina.mbeans.JmxRemoteLifecycleListener, would that work > as JVM mode or Java mode? That would work in either mode of the Windows Service wrapper. If a second Java process is created to perform "stop", server.xml is parsed but only to read the shutdown port and command. Everything else is ignored. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54
On 09/08/18 12:45, Louis Zipes wrote: > Hi Mark, > > You wrote: > > 1. You see the error you are see because you are using Java mode. Switch to > jvm mode and all should be well. > >>> I'm already using 'C:\Program >>> Files\Java\jdk1.7.0_80\jre\bin\server\jvm.dll' in my Java Virtual Machine >>> tab. I assume that means I'm already in JVM Mode. I think I recall when >>> setting up Tomcat last year it wouldn't start any other way. It doesn't. The service wrapper can use that dll either to start Java in process (jvm mode) or to start a separate process (Java mode). You want to look at the bottom option on both the Startup and Shutdown tabs of tomcat7w.exe. My expectation is that they will be set to "Java" whereas you need "jvm". Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54
Hi Mark, You wrote: 1. You see the error you are see because you are using Java mode. Switch to jvm mode and all should be well. >> I'm already using 'C:\Program Files\Java\jdk1.7.0_80\jre\bin\server\jvm.dll' >> in my Java Virtual Machine tab. I assume that means I'm already in JVM >> Mode. I think I recall when setting up Tomcat last year it wouldn't start >> any other way. 2. Finally 7.0.54 is very old. I strongly recommend an upgrade at least to the latest 7.0.x release is not 8.5.x/9.0.x >> I'm going to try that today (or tomorrow depending on how busy it is at >> work). The issue that I might run into is the application that is running >> on Tomcat is not my application and I might run into a restriction on how >> high of a version I can go to but I will deal with that later if it does >> work. Thank you to all for the continued assistance. I have a thick skin. : ) - Louis -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Thursday, August 09, 2018 5:10 AM To: users@tomcat.apache.org Subject: Re: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54 - - - external message, proceed with caution - - - On 09/08/18 01:06, Daniel Savard wrote: > Louis, > > I believe you need to understand a bit more how things are working with > Java and the JVM. Actually Daniel, it is you who needs to understand things better. Louis, Clearly, when Tomcat is started a new JVM instance is created and it listens on the configured JMX ports. The problem is that when Tomcat is stopped another JVM instance is created (to send the stop message to the first) and that uses the same configuration. Hence it tries to open the same JMX port and fails because it is already bound. If you were running from the command line, the fix would be easy. Put the JMX options in CATALINA_OPTS and they'd only be used on start but not stop. (JAVA_OPTS are used on both start and stop). There is also a simple fix if running as a Windows Service. The Windows Service wrapper is simply a renamed version Apache Common Daemon. When running a Java program as a Windows service there are three ways it can be integrated. 1. jvm. The Windows service wrapper starts and embedded JVM using the provided parameters and then calls the start method on the appropriate class. To stop, it calls the stop method on the appropriate class in the embedded jvm. 2. Java. The Windows service wrapper starts a separate Java process with the provided parameters. On stop, a second Java process is started using the same parameters which is expected to communicate with the first process and stop it. 3. exe. Same as 2 but any executable can be used rather than java.exe. You see the error you are see because you are using Java mode. Switch to jvm mode and all should be well. Finally 7.0.54 is very old. I strongly recommend an upgrade at least to the latest 7.0.x release is not 8.5.x/9.0.x Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --- CONFIDENTIALITY NOTICE: This message is for intended addressee(s) only and may contain information that is confidential, proprietary or exempt from disclosure. If you are not the intended recipient, please contact the sender immediately. Unauthorized use or distribution is prohibited and may be unlawful. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54
On Thu, Aug 9, 2018 at 2:39 PM Mark Thomas wrote: > > On 09/08/18 01:06, Daniel Savard wrote: > > > Louis, > > > > I believe you need to understand a bit more how things are working with > > Java and the JVM. > > Actually Daniel, it is you who needs to understand things better. > > > Louis, > > Clearly, when Tomcat is started a new JVM instance is created and it > listens on the configured JMX ports. > > The problem is that when Tomcat is stopped another JVM instance is > created (to send the stop message to the first) and that uses the same > configuration. Hence it tries to open the same JMX port and fails > because it is already bound. > > If you were running from the command line, the fix would be easy. Put > the JMX options in CATALINA_OPTS and they'd only be used on start but > not stop. (JAVA_OPTS are used on both start and stop). > > There is also a simple fix if running as a Windows Service. The Windows > Service wrapper is simply a renamed version Apache Common Daemon. When > running a Java program as a Windows service there are three ways it can > be integrated. > > 1. jvm. The Windows service wrapper starts and embedded JVM using the > provided parameters and then calls the start method on the appropriate > class. To stop, it calls the stop method on the appropriate class in the > embedded jvm. > > 2. Java. The Windows service wrapper starts a separate Java process with > the provided parameters. On stop, a second Java process is started using > the same parameters which is expected to communicate with the first > process and stop it. > > 3. exe. Same as 2 but any executable can be used rather than java.exe. > > You see the error you are see because you are using Java mode. Switch to > jvm mode and all should be well. > > Finally 7.0.54 is very old. I strongly recommend an upgrade at least to > the latest 7.0.x release is not 8.5.x/9.0.x > > Mark > One question Mark, if I use org.apache.catalina.mbeans.JmxRemoteLifecycleListener, would that work as JVM mode or Java mode? Thanks! Suvendu - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54
On 09/08/18 01:06, Daniel Savard wrote: > Louis, > > I believe you need to understand a bit more how things are working with > Java and the JVM. Actually Daniel, it is you who needs to understand things better. Louis, Clearly, when Tomcat is started a new JVM instance is created and it listens on the configured JMX ports. The problem is that when Tomcat is stopped another JVM instance is created (to send the stop message to the first) and that uses the same configuration. Hence it tries to open the same JMX port and fails because it is already bound. If you were running from the command line, the fix would be easy. Put the JMX options in CATALINA_OPTS and they'd only be used on start but not stop. (JAVA_OPTS are used on both start and stop). There is also a simple fix if running as a Windows Service. The Windows Service wrapper is simply a renamed version Apache Common Daemon. When running a Java program as a Windows service there are three ways it can be integrated. 1. jvm. The Windows service wrapper starts and embedded JVM using the provided parameters and then calls the start method on the appropriate class. To stop, it calls the stop method on the appropriate class in the embedded jvm. 2. Java. The Windows service wrapper starts a separate Java process with the provided parameters. On stop, a second Java process is started using the same parameters which is expected to communicate with the first process and stop it. 3. exe. Same as 2 but any executable can be used rather than java.exe. You see the error you are see because you are using Java mode. Switch to jvm mode and all should be well. Finally 7.0.54 is very old. I strongly recommend an upgrade at least to the latest 7.0.x release is not 8.5.x/9.0.x Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
