Re: Re: JspC ignores uriroot property as of Tomcat 9.0.14 / 8.5.37

[Adam Rauch]

On 1/3/2019 11:53 AM, Mark Thomas wrote:

On 02/01/2019 19:50, Adam Rauch wrote:

Our build pre-compiles JSPs by invoking JspC following a pattern similar
to the JspC JavaDoc example configuration:
https://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/jasper/JspC.html

Starting with 9.0.14 and 8.5.37, our build stopped pre-compiling JSPs;
JspC no longer converts a tree of *.jsp files into a tree of *_jsp.java
files. Reviewing the change list, it looks like "53737: Extend JspC, the
precompilation tool, to include support for resource JARs. (markt)" is
related. Commit 1846928 no longer respects the "uriroot" property (in
the pages.size() == 0 case):

svn diff -r 1846928
http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_9_0_14/java/org/apache/jasper/JspC.java


Please let me know if I should open bugzilla issue or if this is an
intentional change in behavior.

That sounds like a bug. If you open a BZ issue and provide the simplest
possible example (i.e. zipped up build dir with a single JSP and the
appropriate Ant file or command line to call JspC) then I'll take a look.

Mark


Bugzilla opened: https://bz.apache.org/bugzilla/show_bug.cgi?id=63056

Adam


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

Anyway to set more max ram to Tomcat 32bit?

[arkboy]

Something wierd seems to be going on... I have an application on tomcat that 
used to be on a physical windows server 2008 standard 32-bit which I p2v'd with 
vmware converter over as a VM. I'm upgrading the server to windows server 2008 
r2 64bit and instead of doing an inplace, I'm just building another one up and 
doing parallel side by side, and its a fresh VM from the start, no p2v stuff

The strange part is I was able to set a max memory in the tomcat9w.exe 
configuration tool to about 1600 Megabytes and that was the hitting of the wall 
on that setup (the original physical one that I p2v'd to a VM), I can set less 
ram, but I cannot set it more than 1600 otherwise when I try to start the 
tomcat service in services.msc it will just crap outs.

So my thinking was since I have to stay on 32-bit of tomcat and 32-bit of Java 
JVM anyhow (long story...) that it might be better to put it in a 64-bit OS 
(server 2008r2) rather than the standard 32bit of server 2008. Long story 
short, from a fresh VM, on this box I'm only able to set a max total ram in 
tomcatw as around 1000 m (1GB) and if I set anymore it will not start, as in I 
cannot get tomcat service to start... so the wall is around 1GB...

As a test, I installed the tomcat (zip extract, not using msi or exe installer) 
to my own client workstation laptop running the latest windows 10 1809 etc and 
once again I hit the 1GB wall and cannot even get it to go up to 1.6GB, even 
though I have like 16GB ram on my laptop machine...

I have googled this for a long time and apparently it has to do with the way 
the operating system itself (in this case windows, be it windows server 2008 
std, 2008 r2, or win10 etc) handles per process memory limitations and thread 
memory allocations that by default only allow around 1.5 to 2 g of ram per 
process and that this is what is constraining the tomcat apache jvm and not the 
programs itself

But if this is indeed an OS difference, I checked on my original 32bit 
server2008 std, the one that I did P2V, and it didn't have anything special set 
in the boot.ini or any bcdedit parameters that allow it to see more ram per 
process nor anything like a /3GB flag etc etc

The only other thing I can think of is that maybe there is a difference between 
a VM and a physical raw bare metal box in how it allocates ram, and that I can 
get more contigous memory that tomcat/jvm requires when running on a 32bit OS 
on a physical box as opposed to and compared to a 64bit OS in a VM?

Why is it I can get the exact same version of Tomcat (bit by bit the same) to 
handle up to 1600m in 32bit version of server 2008 but on server 2008r2 64bit 
or even server 2016 64bit I can only get tomcat to do up to around 1GB total 
max? They are both using the same Java version jvm etc etc etc

Anyway to set more max ram to Tomcat 32bit?

[arkboy]

Something wierd seems to be going on... I have an application on tomcat that 
used to be on a physical windows server 2008 standard 32-bit which I p2v'd with 
vmware converter over as a VM. I'm upgrading the server to windows server 2008 
r2 64bit and instead of doing an inplace, I'm just building another one up and 
doing parallel side by side, and its a fresh VM from the start, no p2v 
stuff 

The strange part is I was able to set a max memory in the tomcat9w.exe 
configuration tool to about 1600 Megabytes and that was the hitting of the wall 
on that setup (the original physical one that I p2v'd to a VM), I can set less 
ram, but I cannot set it more than 1600 otherwise when I try to start the 
tomcat service in services.msc it will just crap outs. 

So my thinking was since I have to stay on 32-bit of tomcat and 32-bit of Java 
JVM anyhow (long story...) that it might be better to put it in a 64-bit OS 
(server 2008r2) rather than the standard 32bit of server 2008. Long story 
short, from a fresh VM, on this box I'm only able to set a max total ram in 
tomcatw as around 1000 m (1GB) and if I set anymore it will not start, as in I 
cannot get tomcat service to start... so the wall is around 1GB...

As a test, I installed the tomcat (zip extract, not using msi or exe installer) 
to my own client workstation laptop running the latest windows 10 1809 etc and 
once again I hit the 1GB wall and cannot even get it to go up to 1.6GB, even 
though I have like 16GB ram on my laptop machine...

I have googled this for a long time and apparently it has to do with the way 
the operating system itself (in this case windows, be it windows server 2008 
std, 2008 r2, or win10 etc) handles per process memory limitations and thread 
memory allocations that by default only allow around 1.5 to 2 g of ram per 
process and that this is what is constraining the tomcat apache jvm and not the 
programs itself 

But if this is indeed an OS difference, I checked on my original 32bit 
server2008 std, the one that I did P2V, and it didn't have anything special set 
in the boot.ini or any bcdedit parameters that allow it to see more ram per 
process nor anything like a /3GB flag etc etc

The only other thing I can think of is that maybe there is a difference between 
a VM and a physical raw bare metal box in how it allocates ram, and that I can 
get more contigous memory that tomcat/jvm requires when running on a 32bit OS 
on a physical box as opposed to and compared to a 64bit OS in a VM?

Why is it I can get the exact same version of Tomcat (bit by bit the same) to 
handle up to 1600m in 32bit version of server 2008 but on server 2008r2 64bit 
or even server 2016 64bit I can only get tomcat to do up to around 1GB total 
max? They are both using the same Java version jvm etc etc etc

Re: Problem with JDK10-12 "NOTE: Picked up JDK_JAVA_OPTIONS"

[Mark Thomas]

On 03/01/2019 20:00, John Larsen wrote:
> How can I surpress it if its not an error?

With difficulty. Tomcat always sets that system property and there is no
way (short of editing the scripts which is generally a bad idea) to stop
it. The JVM always generates that log message to stderr (as far as I am
aware).

> Problem I have is the output
> causes the script thinks its an error.

The immediate solution is probably to update the script.

A fix on the Tomcat side is going to be trickier. We might be able to
skip setting those properties on shutdown (or more likely clear it if
stop is called). That would need some testing.

Mark

> 
> Thanks,
> 
> John
> 
> On Thu, Jan 3, 2019 at 12:51 PM Mark Thomas  wrote:
> 
>> On 31/12/2018 15:12, John Larsen wrote:
>>> Hello,
>>>
>>> Ever since we started using jdk10 and up we get this error message
>> whenever
>>> we do ./shutdown.sh.
>>>
>>> NOTE: Picked up JDK_JAVA_OPTIONS:
>>> --add-opens=java.base/java.lang=ALL-UNNAMED
>>> --add-opens=java.base/java.io=ALL-UNNAMED
>>> --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
>>
>> That is not an error message.
>>
>>> We need to fix the issue or surpress the output. Any suggestions?
>>
>> What issue?
>>
>> That output is generated by the JVM. The options the message refers to
>> are set automatically by Tomcat when running on Java 9 or later to
>> prevent various features failing (mostly around memory leak detection
>> and prevention) due to the additional restrictions added in Java 9.
>>
>> Mark
>>
>>
>>>
>>> There is nothing in catalina.out about this either:
>>>
>>> 31-Dec-2018 15:09:52.058 INFO [main]
>>> org.apache.catalina.core.StandardServer.await A valid shutdown command
>> was
>>> received via the shutdown port. Stopping the Server instance.
>>> 31-Dec-2018 15:09:52.059 INFO [main]
>>> org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler
>>> ["http-nio-8080"]
>>> 31-Dec-2018 15:09:52.066 INFO [main]
>>> org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler
>>> ["ajp-nio-8009"]
>>> 31-Dec-2018 15:09:52.071 INFO [main]
>>> org.apache.catalina.core.StandardService.stopInternal Stopping service
>>> [Catalina]
>>> 31-Dec-2018 15:09:52.081 INFO [main]
>>> org.apache.catalina.core.ApplicationContext.log SessionListener:
>>> contextDestroyed()
>>> 31-Dec-2018 15:09:52.081 INFO [main]
>>> org.apache.catalina.core.ApplicationContext.log ContextListener:
>>> contextDestroyed()
>>> 31-Dec-2018 15:09:52.090 INFO [main]
>>> org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler
>>> ["http-nio-8080"]
>>> 31-Dec-2018 15:09:52.092 INFO [main]
>>> org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler
>>> ["ajp-nio-8009"]
>>> 31-Dec-2018 15:09:52.094 INFO [main]
>>> org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler
>>> ["http-nio-8080"]
>>> 31-Dec-2018 15:09:52.094 INFO [main]
>>> org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler
>>> ["ajp-nio-8009"]
>>>
>>> Thanks,
>>>
>>> John
>>>
>>
>>
>> -
>> 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: Problem with JDK10-12 "NOTE: Picked up JDK_JAVA_OPTIONS"

[John Larsen]

How can I surpress it if its not an error? Problem I have is the output
causes the script thinks its an error.

Thanks,

John

On Thu, Jan 3, 2019 at 12:51 PM Mark Thomas  wrote:

> On 31/12/2018 15:12, John Larsen wrote:
> > Hello,
> >
> > Ever since we started using jdk10 and up we get this error message
> whenever
> > we do ./shutdown.sh.
> >
> > NOTE: Picked up JDK_JAVA_OPTIONS:
> > --add-opens=java.base/java.lang=ALL-UNNAMED
> > --add-opens=java.base/java.io=ALL-UNNAMED
> > --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
>
> That is not an error message.
>
> > We need to fix the issue or surpress the output. Any suggestions?
>
> What issue?
>
> That output is generated by the JVM. The options the message refers to
> are set automatically by Tomcat when running on Java 9 or later to
> prevent various features failing (mostly around memory leak detection
> and prevention) due to the additional restrictions added in Java 9.
>
> Mark
>
>
> >
> > There is nothing in catalina.out about this either:
> >
> > 31-Dec-2018 15:09:52.058 INFO [main]
> > org.apache.catalina.core.StandardServer.await A valid shutdown command
> was
> > received via the shutdown port. Stopping the Server instance.
> > 31-Dec-2018 15:09:52.059 INFO [main]
> > org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler
> > ["http-nio-8080"]
> > 31-Dec-2018 15:09:52.066 INFO [main]
> > org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler
> > ["ajp-nio-8009"]
> > 31-Dec-2018 15:09:52.071 INFO [main]
> > org.apache.catalina.core.StandardService.stopInternal Stopping service
> > [Catalina]
> > 31-Dec-2018 15:09:52.081 INFO [main]
> > org.apache.catalina.core.ApplicationContext.log SessionListener:
> > contextDestroyed()
> > 31-Dec-2018 15:09:52.081 INFO [main]
> > org.apache.catalina.core.ApplicationContext.log ContextListener:
> > contextDestroyed()
> > 31-Dec-2018 15:09:52.090 INFO [main]
> > org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler
> > ["http-nio-8080"]
> > 31-Dec-2018 15:09:52.092 INFO [main]
> > org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler
> > ["ajp-nio-8009"]
> > 31-Dec-2018 15:09:52.094 INFO [main]
> > org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler
> > ["http-nio-8080"]
> > 31-Dec-2018 15:09:52.094 INFO [main]
> > org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler
> > ["ajp-nio-8009"]
> >
> > Thanks,
> >
> > John
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: JspC ignores uriroot property as of Tomcat 9.0.14 / 8.5.37

[Mark Thomas]

On 02/01/2019 19:50, Adam Rauch wrote:
> Our build pre-compiles JSPs by invoking JspC following a pattern similar
> to the JspC JavaDoc example configuration:
> https://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/jasper/JspC.html
> 
> Starting with 9.0.14 and 8.5.37, our build stopped pre-compiling JSPs;
> JspC no longer converts a tree of *.jsp files into a tree of *_jsp.java
> files. Reviewing the change list, it looks like "53737: Extend JspC, the
> precompilation tool, to include support for resource JARs. (markt)" is
> related. Commit 1846928 no longer respects the "uriroot" property (in
> the pages.size() == 0 case):
> 
> svn diff -r 1846928
> http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_9_0_14/java/org/apache/jasper/JspC.java
> 
> 
> Please let me know if I should open bugzilla issue or if this is an
> intentional change in behavior.

That sounds like a bug. If you open a BZ issue and provide the simplest
possible example (i.e. zipped up build dir with a single JSP and the
appropriate Ant file or command line to call JspC) then I'll take a look.

Mark

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

Re: Problem with JDK10-12 "NOTE: Picked up JDK_JAVA_OPTIONS"

[Mark Thomas]

On 31/12/2018 15:12, John Larsen wrote:
> Hello,
> 
> Ever since we started using jdk10 and up we get this error message whenever
> we do ./shutdown.sh.
> 
> NOTE: Picked up JDK_JAVA_OPTIONS:
> --add-opens=java.base/java.lang=ALL-UNNAMED
> --add-opens=java.base/java.io=ALL-UNNAMED
> --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED

That is not an error message.

> We need to fix the issue or surpress the output. Any suggestions?

What issue?

That output is generated by the JVM. The options the message refers to
are set automatically by Tomcat when running on Java 9 or later to
prevent various features failing (mostly around memory leak detection
and prevention) due to the additional restrictions added in Java 9.

Mark


> 
> There is nothing in catalina.out about this either:
> 
> 31-Dec-2018 15:09:52.058 INFO [main]
> org.apache.catalina.core.StandardServer.await A valid shutdown command was
> received via the shutdown port. Stopping the Server instance.
> 31-Dec-2018 15:09:52.059 INFO [main]
> org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler
> ["http-nio-8080"]
> 31-Dec-2018 15:09:52.066 INFO [main]
> org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler
> ["ajp-nio-8009"]
> 31-Dec-2018 15:09:52.071 INFO [main]
> org.apache.catalina.core.StandardService.stopInternal Stopping service
> [Catalina]
> 31-Dec-2018 15:09:52.081 INFO [main]
> org.apache.catalina.core.ApplicationContext.log SessionListener:
> contextDestroyed()
> 31-Dec-2018 15:09:52.081 INFO [main]
> org.apache.catalina.core.ApplicationContext.log ContextListener:
> contextDestroyed()
> 31-Dec-2018 15:09:52.090 INFO [main]
> org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler
> ["http-nio-8080"]
> 31-Dec-2018 15:09:52.092 INFO [main]
> org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler
> ["ajp-nio-8009"]
> 31-Dec-2018 15:09:52.094 INFO [main]
> org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler
> ["http-nio-8080"]
> 31-Dec-2018 15:09:52.094 INFO [main]
> org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler
> ["ajp-nio-8009"]
> 
> Thanks,
> 
> John
> 


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

Re: Unable to determine Catalina base to load file

[PJ Pillai]

Hi Christopher,

This is no an issue with locating jaas.config. I've set it in java options
as
-Djava.security.auth.login.config=C:\Program Files\Apache Software
Foundation\Tomcat 9.0\conf\jaas.config
I also tested changing a file that do not exist and I got the FileNotFound
exception so it is not the issue with jaas.config.

>From the code what I read is that JAASMemoryLoginModule pathname still
using the default value (conf/tomcat-users.xml), Tomcat is running on
Windows so not sure why pathname is conf/tomcat-users.xml).

See the line below in the code that log this warning message.
https://github.com/apache/tomcat/blob/trunk/java/org/apache/catalina/realm/JAASMemoryLoginModule.java#L384

see attached log file. All the JVM arguments in the log are correct.

Thanks,
PJ

On Thu, Jan 3, 2019 at 6:55 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> PJ,
>
> On 1/2/19 22:15, PJ Pillai wrote:
> > Here is additional information. 1. Tomcat is running on Windows
> > 2016 server. 2. Tomcat is started as windows service.
> >
> > I tried Tomcat 8.5 as well and still get the same warning message
> > and user is not authenticated.
>
> Did you copy all your system properties from your Tomcat 6 service to
> your Tomcat 9 service? Look in thew "JVM Parameters" (or whatever)
> section of the Tomcat service manager (tomcat9w.exe).
>
> Tomcat needs to know where the JAAS config file is, and that's done
> through a system property. If that property wasn't copied from the old
> service, it probably won't work.
>
> - -chris
>
> > On Wed, Jan 2, 2019 at 5:00 PM PJ Pillai 
> > wrote:
> >
> >> Hi,
> >>
> >>
> >> I'm using JAASMemoryLoginModule to authenticate users stored in
> >> tomcat-users.xml. The authentication fails on Tomcat 9 with
> >> following warning message in catalina.xx.log.
> >>
> >> org.apache.catalina.realm.JAASMemoryLoginModule.load Unable to
> >> determine Catalina base to load file [conf/tomcat-users.xml]
> >>
> >>
> >> Here is a stack trace from the web application:
> >>
> >> javax.security.auth.login.FailedLoginException: User name or
> >> password is incorrect at
> >> org.apache.catalina.realm.JAASMemoryLoginModule.login(JAASMemoryLogin
> Module.java:350)
> >>
> >>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >> at
> >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:62)
> >>
> >>
> at
> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:43)
> >>
> >>
> at java.lang.reflect.Method.invoke(Method.java:483)
> >> at
> >> javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
> >>
> >>
> at javax.security.auth.login.LoginContext.access$000(LoginContext.java:1
> 95)
> >> at
> >> javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
> >>
> >>
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
> >> at java.security.AccessController.doPrivileged(Native Method) at
> >> javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:6
> 80)
> >>
> >>
> at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
> >>
> >>
> >> Now the same jaas config and same JVM args, it works fine on
> >> Tomcat 6.
> >>
> >> -Djava.security.auth.login.config=C:\Program Files\Apache
> >> Software Foundation\Tomcat 9.0\conf\jaas.config
> >>
> >>
> >>
> >>
> >> Please help.
> >>
> >> Thanks, PJ
> >>
> >>
> >>
> >
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlwuInYACgkQHPApP6U8
> pFj1xRAAnkku03ko/9R3nWALAJm+AF1ULywHtH9qGz2TEvLA71mOfUT/pzGokoNq
> z+7YHrbFoD4k5TlGctwkDYlxftzYWd6YLLSLIycUphaaMSSul2r+kXpkWnxZ/DBS
> yS4pGVIaleaqXf4OFxucKVAomb56QfCSUX/UJg2sd+VcKxHZGG/gsaRkj5P6aFFj
> aTDrMzVUDFnzW+1ShBxcbDs2Zl36JixvoyUXKDQJJRr+qRY6KwkuK1fH0tw2pCQO
> b6wygha0r7AbRvlQiomVCxGZRHBbIctB3n9pNlLutbUsqS70kQeS0fR7UOGsLdFu
> 4/8oEynxjk22wPmrb4GaakGXlwY1JmMNCFYPMrWrK2z3uTV2VmKspV/xvei6nz0W
> fXuo4HoOr6pQ4DihlQHaUwvI1SvkKHJdMjTJQcMuv0fl6AdCMXTW81aR3C69p8uE
> IiTpoSs/WChY13JI5BzDYebQom+aEj4bYjtKdwoFq9zLW9tH/8896j/PgXKHnMim
> 4qJaRg4sN13Lxkh9WOXnZDeAc8gD4XEO7u4gtOt30hEVzuqvzksYJeA1dx9+Efiw
> 7o4V+db6KcHPwklNCgXKQC6GIPofjb0cp89LqVNsh3gWAIz5uN7NecBEIMJCqli+
> CcmVgkL/Bf+4acqT1FD2g3ACYg2/4ekV4ty6HZz9aL8bJ+5N7UU=
> =DkDj
> -END PGP SIGNATURE-
>
> -
> 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.0.14 startup fails

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Steve,

On 1/3/19 02:07, Steve Demy wrote:
> I opened a bug on this 
> (https://bz.apache.org/bugzilla/show_bug.cgi?id=63041).  It was 
> closed by Christopher Schultz suggesting a probable configuration 
> issue. Possibly so, but the configuration is out of the box prior
> to any /conf file modification and with no user web apps involved.
> And as you’ve confirmed Greg, 9.0.13 works as expected where
> 9.0.14 fails, all else unchanged.
> 
> Any further pointers as to where to look would be appreciated.

Can you try to make a single change?

Back-up the 9.0.14 version of catalina.sh and then copy the 9.0.13 in
its place (so you have a 9.0.14 Tomcat with q 9.0.13 catalina.sh).

There was a change to catalina.sh that might make systemd upset. If
9.0.14 works with a 9.0.13 catalina.sh, please re-open BZ 63041 with
that explanation.

Your bug report shows that Tomcat either isn't running or isn't
configured to listed on the port being attempted when shutting down.
Can you post your  element from conf/server.xml?

While the server is running, can you do:

# netstat -plan | grep java

Finally, I would say that, with systemd, using jsvc is probably the
way to go.

- -chris

>> On Dec 29, 2018, at 8:54 AM, Greg Huber 
>> wrote:
>> 
>> I used your startup script as a test, there does seem to be some 
>> differences between v13 and v14.  v13 starts OK but v14 fails, I
>> can see the temp/tomcat.pid being created but then disappears.
>> 
>> 
>> systemctl status -l tomcat ● tomcat.service - Apache Tomcat Web
>> Application Container Loaded: loaded
>> (/etc/systemd/system/tomcat.service; disabled; vendor preset:
>> disabled) Active: inactive (dead)
>> 
>> Dec 29 16:50:52 dev.box shutdown.sh[22941]: at 
>> java.net.Socket.(Socket.java:211) Dec 29 16:50:52 dev.box
>> shutdown.sh[22941]: at 
>> org.apache.catalina.startup.Catalina.stopServer(Catalina.java:513)
>>
>> 
Dec 29 16:50:52 dev.box shutdown.sh[22941]: at
>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) Dec
>> 29 16:50:52 dev.box shutdown.sh[22941]: at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:62)
>>
>> 
Dec 29 16:50:52 dev.box shutdown.sh[22941]: at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:43)
>>
>> 
Dec 29 16:50:52 dev.boxshutdown.sh[22941]: at
>> java.lang.reflect.Method.invoke(Method.java:498) Dec 29 16:50:52
>> dev.box shutdown.sh[22941]: at 
>> org.apache.catalina.startup.Bootstrap.stopServer(Bootstrap.java:403)
>>
>> 
Dec 29 16:50:52 dev.box shutdown.sh[22941]: at
>> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:497) 
>> Dec 29 16:50:52 dev.box shutdown.sh[22941]: The stop command
>> failed. Attempting to signal the process to stop through OS
>> signal. Dec 29 16:50:53 dev.box shutdown.sh[22941]: Tomcat
>> stopped.
>> 
>> 
>> It seems to work OK using jsvc however.  There are no error
>> logs.
>> 
>> Cheers Greg
> 
> 
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlwuJHYACgkQHPApP6U8
pFjhJQ//fBHdPXyMPQKOMnQ59FZZzS4r8NHN1bv6ALneWYGQKBxvIDBJUNpe02OL
6bMo6HCUKolUx8RcYnf8OOBjZha3VC5oL9pG6kOmbBEkjGkQYLJ/GM37sDKR9IRo
z1JPSgo9D5N/7kwemEf73ohRXhcB79SCz80elgotCmD9pXzzQ0bAMJBYCIiOEm8B
7sJPwQoAvf+z7C8ygSj8hvf5gzwtvmQ/AF0RglrkmtRS/skXH7KwBJxrASvR63ng
4qJnIkKg5RYNhoqiHcmS/UEor5ruxc5ywTmVKPQXygpKOc9UquB19aji243bSzvd
Sg9VnTOxZXQjZWFx5XvhgWntlETwY59g1Qn8Y3nDyDftCOCo+Nz/hzfVnJ+jytQ+
u81TqeWuDZeyf8AHhYQlVZvBZD3PY8OwOBIXSfdIz8ZdxXX8zfuQM9z+Qh4eHS8E
xnhpKIiXfdg4M4/2y0EGk17cLvbnxcMDW2bOoV+01ZtrA1H1vIFWhDd+lctk/SYl
52fs2561hHI7G8BFRuS6fJK6pXJxgLCdMTXn01tc/FEIZUveg/KLslN4oDGxk+kc
qaXj0q4VGqTeBiw1rQn1mv+h7FJqJL96Hh4aCA4sgg41W1sywFXGoB5zVMeuiESM
ipgyfvjsJUgBWEPRiFMRoXCJtc9NXj9GB+DBqerGtpLdPP0pQps=
=wjpy
-END PGP SIGNATURE-

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

RE: Migration tomcat 7 to 9 : export static files

[andre seame]

My  server.xml is the delivered server.xml file + my declaration of testresult
===




  
  
  
  
  
  
  
  
  

  
  


  

  
  





















  
  

  
  


  

  










  

  


===
thanks
PHL.


De : Christopher Schultz 
Envoyé : jeudi 3 janvier 2019 14:52
À : users@tomcat.apache.org
Objet : Re: Migration tomcat 7 to 9 : export static files

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 1/3/19 03:56, andre seame wrote:
> Hello,
>
> In tomcat 7, I have a server.xml config file. In the host section I
> have
>
> 
>
> So, I can access to static file :
> http://server:8080/testresults/myfile.png, where the file is stored
> in d:\TESTRESULTS\myfile.png
>
> When using the HTML gui management interface
> -http://server:8080/manager/html), I see the list of applications
> that are running on my tomcat server. There is my application and a
> "testresult" application.
>
> In tomcat 9, I try the same configuration, but I get an error 404
> when I try to access to http://server:8080/testresults/myfile.png
>
> The
> http://server-tomat-9:8080/manager/html
> gives only y application (no more /testresults).
>
> My bug ? Tomcat 9 bug ? Insuffisant configuration or new security
> mechanism for tomcat 9.

What does your Tomcat 9 conf/server.xml file look like?

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlwuIZwACgkQHPApP6U8
pFhlXg//boCo965yTmAs+HVb925dSHemgVaWqNHsO0P6sfX58F6oxoNwcs6ZI2h7
GAgXEeSXUVwSwisRGjcRuLcxRf/o2nm+oU6p2OlK7WE+t9xulYsN7YUhVq09Mba9
bUNpY7wK2gk853B3ih4GtmVLOq3qJu+w1aanasoSJUAEC9SY6xg18qZgFc64oAgr
Sz4ij0gfQv3uvb+3mbSTe0LSBA0yApHMTQ8ETo9fXf7Z352FwUAeWM2Lx6WVDlvG
vCXLCDFRmkRvWzE6K5dOlQMMdbuFIs92peoFr/MPztdVYiiZIvR5Zl0xLZEPP/va
of+Va/JKgkJy1JZ0dt0VaqTPP8LgoauprvnyyhhzQYUz/LLmDGq6PGGmoihddKQ0
3Kkv3c+ug0Et+28Ef+aRLk8AJH7Joy16xNOutZbZY2+Nskc67X9Lc3OmSy2R0CEs
tSjo+ZflCAfXBUF2N8LdmtqMdI2XCpOijlTqkl00f3z/5keW0nwLfo7QUVyagDM4
ONg2cj4RbQgLqIgLTEQnIdm6TzWDOad+yOXBPM/8WAS+Qvo4p3aIgOzHBOL/JX89
+3bqMzNWTHGQpEELFtAsaGKQoW/ne1zSiK+uT+S7NR33KJnEBihgQC6LChvqrt5X
uk6b9KGHbphGVVNhWOCfctmI5nSsENXqgrHphoYKjtiu1fCOxVw=
=TDXs
-END PGP SIGNATURE-

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

Re: Unable to determine Catalina base to load file

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

PJ,

On 1/2/19 22:15, PJ Pillai wrote:
> Here is additional information. 1. Tomcat is running on Windows
> 2016 server. 2. Tomcat is started as windows service.
> 
> I tried Tomcat 8.5 as well and still get the same warning message
> and user is not authenticated.

Did you copy all your system properties from your Tomcat 6 service to
your Tomcat 9 service? Look in thew "JVM Parameters" (or whatever)
section of the Tomcat service manager (tomcat9w.exe).

Tomcat needs to know where the JAAS config file is, and that's done
through a system property. If that property wasn't copied from the old
service, it probably won't work.

- -chris

> On Wed, Jan 2, 2019 at 5:00 PM PJ Pillai 
> wrote:
> 
>> Hi,
>> 
>> 
>> I'm using JAASMemoryLoginModule to authenticate users stored in 
>> tomcat-users.xml. The authentication fails on Tomcat 9 with
>> following warning message in catalina.xx.log.
>> 
>> org.apache.catalina.realm.JAASMemoryLoginModule.load Unable to
>> determine Catalina base to load file [conf/tomcat-users.xml]
>> 
>> 
>> Here is a stack trace from the web application:
>> 
>> javax.security.auth.login.FailedLoginException: User name or
>> password is incorrect at 
>> org.apache.catalina.realm.JAASMemoryLoginModule.login(JAASMemoryLogin
Module.java:350)
>>
>> 
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:62)
>>
>> 
at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:43)
>>
>> 
at java.lang.reflect.Method.invoke(Method.java:483)
>> at
>> javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
>>
>> 
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:1
95)
>> at
>> javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
>>
>> 
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
>> at java.security.AccessController.doPrivileged(Native Method) at
>> javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:6
80)
>>
>> 
at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
>> 
>> 
>> Now the same jaas config and same JVM args, it works fine on
>> Tomcat 6.
>> 
>> -Djava.security.auth.login.config=C:\Program Files\Apache
>> Software Foundation\Tomcat 9.0\conf\jaas.config
>> 
>> 
>> 
>> 
>> Please help.
>> 
>> Thanks, PJ
>> 
>> 
>> 
> 
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlwuInYACgkQHPApP6U8
pFj1xRAAnkku03ko/9R3nWALAJm+AF1ULywHtH9qGz2TEvLA71mOfUT/pzGokoNq
z+7YHrbFoD4k5TlGctwkDYlxftzYWd6YLLSLIycUphaaMSSul2r+kXpkWnxZ/DBS
yS4pGVIaleaqXf4OFxucKVAomb56QfCSUX/UJg2sd+VcKxHZGG/gsaRkj5P6aFFj
aTDrMzVUDFnzW+1ShBxcbDs2Zl36JixvoyUXKDQJJRr+qRY6KwkuK1fH0tw2pCQO
b6wygha0r7AbRvlQiomVCxGZRHBbIctB3n9pNlLutbUsqS70kQeS0fR7UOGsLdFu
4/8oEynxjk22wPmrb4GaakGXlwY1JmMNCFYPMrWrK2z3uTV2VmKspV/xvei6nz0W
fXuo4HoOr6pQ4DihlQHaUwvI1SvkKHJdMjTJQcMuv0fl6AdCMXTW81aR3C69p8uE
IiTpoSs/WChY13JI5BzDYebQom+aEj4bYjtKdwoFq9zLW9tH/8896j/PgXKHnMim
4qJaRg4sN13Lxkh9WOXnZDeAc8gD4XEO7u4gtOt30hEVzuqvzksYJeA1dx9+Efiw
7o4V+db6KcHPwklNCgXKQC6GIPofjb0cp89LqVNsh3gWAIz5uN7NecBEIMJCqli+
CcmVgkL/Bf+4acqT1FD2g3ACYg2/4ekV4ty6HZz9aL8bJ+5N7UU=
=DkDj
-END PGP SIGNATURE-

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

Re: Migration tomcat 7 to 9 : export static files

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 1/3/19 03:56, andre seame wrote:
> Hello,
> 
> In tomcat 7, I have a server.xml config file. In the host section I
> have
> 
> 
> 
> So, I can access to static file :
> http://server:8080/testresults/myfile.png, where the file is stored
> in d:\TESTRESULTS\myfile.png
> 
> When using the HTML gui management interface
> -http://server:8080/manager/html), I see the list of applications
> that are running on my tomcat server. There is my application and a
> "testresult" application.
> 
> In tomcat 9, I try the same configuration, but I get an error 404
> when I try to access to http://server:8080/testresults/myfile.png
> 
> The
> http://server-tomat-9:8080/manager/html
> gives only y application (no more /testresults).
> 
> My bug ? Tomcat 9 bug ? Insuffisant configuration or new security
> mechanism for tomcat 9.

What does your Tomcat 9 conf/server.xml file look like?

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlwuIZwACgkQHPApP6U8
pFhlXg//boCo965yTmAs+HVb925dSHemgVaWqNHsO0P6sfX58F6oxoNwcs6ZI2h7
GAgXEeSXUVwSwisRGjcRuLcxRf/o2nm+oU6p2OlK7WE+t9xulYsN7YUhVq09Mba9
bUNpY7wK2gk853B3ih4GtmVLOq3qJu+w1aanasoSJUAEC9SY6xg18qZgFc64oAgr
Sz4ij0gfQv3uvb+3mbSTe0LSBA0yApHMTQ8ETo9fXf7Z352FwUAeWM2Lx6WVDlvG
vCXLCDFRmkRvWzE6K5dOlQMMdbuFIs92peoFr/MPztdVYiiZIvR5Zl0xLZEPP/va
of+Va/JKgkJy1JZ0dt0VaqTPP8LgoauprvnyyhhzQYUz/LLmDGq6PGGmoihddKQ0
3Kkv3c+ug0Et+28Ef+aRLk8AJH7Joy16xNOutZbZY2+Nskc67X9Lc3OmSy2R0CEs
tSjo+ZflCAfXBUF2N8LdmtqMdI2XCpOijlTqkl00f3z/5keW0nwLfo7QUVyagDM4
ONg2cj4RbQgLqIgLTEQnIdm6TzWDOad+yOXBPM/8WAS+Qvo4p3aIgOzHBOL/JX89
+3bqMzNWTHGQpEELFtAsaGKQoW/ne1zSiK+uT+S7NR33KJnEBihgQC6LChvqrt5X
uk6b9KGHbphGVVNhWOCfctmI5nSsENXqgrHphoYKjtiu1fCOxVw=
=TDXs
-END PGP SIGNATURE-

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

Migration tomcat 7 to 9 : export static files

[andre seame]

Hello,

In tomcat 7, I have a server.xml config file. In the host section I have



So, I can access to static file : http://server:8080/testresults/myfile.png, 
where the file is stored in d:\TESTRESULTS\myfile.png

When using the HTML gui management interface -http://server:8080/manager/html), 
I see the list of applications that are running on my tomcat server. There is 
my application and a "testresult" application.

In tomcat 9, I try the same configuration, but I get an error 404 when I try to 
access to http://server:8080/testresults/myfile.png

The http://server-tomat-9:8080/manager/html 
gives only y application (no more /testresults).

My bug ? Tomcat 9 bug ? Insuffisant configuration or new security mechanism for 
tomcat 9.

Have you pointers ? or ideas ?
Thanks.

Re: Java Supported Versions for Apache Tomcat/7.0.77

[Olaf Kock]

On 02.01.19 23:11, Janakiram Maganti wrote:
> Hi Support,
>
> Can you suggest what is the latest Java 8 version supported for “Apache 
> Tomcat/7.0.77”.
>
According to https://tomcat.apache.org/whichversion.html, there's no
maximum version, it's "Java 6 and later".

E.g. if you're running into specific problems with a particular Java
version, feel free to report an issue.

Olaf


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