Re: Tomcat 9 returns INameEnvironment error

[Joel Griffith]

I found a workaround that I'll post here in case anyone with the same
problem stumbles on this thread.  The fix is to install the older
`libeclipse-jdt-core-java` JDT package from the Ubuntu 20.04 repo.

1. Add the line `deb http://de.archive.ubuntu.com/ubuntu/ focal main
universe` to the end of `/etc/apt/sources.list`.

2. Update Apt ($ sudo apt update)

3. Install the old version of the package, specifying the older version:
$ sudo apt install libeclipse-jdt-core-java=3.18.0+eclipse4.12-1
Apt should identify this as a `DOWNGRADE` operation automatically, so
there's no worry about conflicting package versions.

4. Hold this package back from further updates so that apt-upgrade doesn't
return it to the newer `3.27.0+eclipse4.21-1` version:
$ sudo apt-mark hold libeclipse-jdt-core-java

5. Delete the line `deb http://de.archive.ubuntu.com/ubuntu/ focal main
universe` from `/etc/apt/sources.list` to restore its original state.

6. Upgrade Apt again ($ sudo apt upgrade)

7. Restart Tomcat ($ sudo systemctl restart tomcat9.service)

This worked for me on Ubuntu 22.04/Tomcat 9/Java 8.

Joel

On Fri, Jun 16, 2023 at 4:35 PM Joel Griffith  wrote:

> This is definitely the issue, I found a bug report to Canonical on the
> very thing:
> https://bugs.launchpad.net/ubuntu/+source/tomcat9/+bug/1972829
> Oh, well.
>
> Thanks for your help, everyone!
>
> On Fri, Jun 16, 2023 at 4:17 AM Mark Thomas  wrote:
>
>> On 16/06/2023 09:07, Rémy Maucherat wrote:
>> > On Thu, Jun 15, 2023 at 9:54 PM Mark Thomas  wrote:
>> >>
>> >> On 15/06/2023 19:23, Joel Griffith wrote:
>> >>> It looks like the JDT you mention is the Ubuntu package
>> >>> `libeclipse-jdt-core-java`.
>> >>>
>> >>> When I installed Tomcat 9 (9.0.31) on the functioning Ubuntu 20.04
>> system,
>> >>> version 3.18.0+eclipse4.12-1 of this JDT package was installed as a
>> >>> dependency.  When I installed Tomcat 9 (9.0.58) on the Ubuntu 22.04
>> system,
>> >>> version 3.27.0+eclipse4.21-1 was installed.  Assuming the "4.12" and
>> "4.21"
>> >>> numbers are the JDT versions you're referring to, it seems like you're
>> >>> right about the cause.
>> >>>
>> >>> According to this table (https://tomcat.apache.org/whichversion.html
>> ),
>> >>> Tomcat 9 is supposed to be compatible with Java 8, yet in this case it
>> >>> seems to have broken compatibility on a patch update between 9.0.31
>> and
>> >>> 9.0.58.  In order to regain compatibility, the dependency on JDT
>> should be
>> >>> adjusted to a lower version.  Is this something the Tomcat people
>> have to
>> >>> handle, or is it the package maintainers at Canonical who make that
>> choice?
>> >>
>> >> That would be Canonical.
>> >>
>> >> If you get Tomcat 9 from the ASF it works out of the box on Java 8.
>> (You
>> >> actually get the reverse issue with really new JDKs and very old JDTs
>> >> but that isn't what is happening here).
>> >
>> > JDT seems to be getting more and more aggressive with bumping Java
>> > requirements. For example, Tomcat 10.1 uses Java 11 as the minimum,
>> > but JDT 4.28 is *already* Java 17+. So Tomcat 10.1 will stay on 4.27
>> > forever basically.
>>
>> Thanks for the info. I hadn't realized that. I guess I would have found
>> out when I did the version updates for the July releases. I've added a
>> note to the 10.1.x build.properties file.
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>

Re: Tomcat 9 returns INameEnvironment error

[Joel Griffith]

This is definitely the issue, I found a bug report to Canonical on the very
thing:
https://bugs.launchpad.net/ubuntu/+source/tomcat9/+bug/1972829
Oh, well.

Thanks for your help, everyone!

On Fri, Jun 16, 2023 at 4:17 AM Mark Thomas  wrote:

> On 16/06/2023 09:07, Rémy Maucherat wrote:
> > On Thu, Jun 15, 2023 at 9:54 PM Mark Thomas  wrote:
> >>
> >> On 15/06/2023 19:23, Joel Griffith wrote:
> >>> It looks like the JDT you mention is the Ubuntu package
> >>> `libeclipse-jdt-core-java`.
> >>>
> >>> When I installed Tomcat 9 (9.0.31) on the functioning Ubuntu 20.04
> system,
> >>> version 3.18.0+eclipse4.12-1 of this JDT package was installed as a
> >>> dependency.  When I installed Tomcat 9 (9.0.58) on the Ubuntu 22.04
> system,
> >>> version 3.27.0+eclipse4.21-1 was installed.  Assuming the "4.12" and
> "4.21"
> >>> numbers are the JDT versions you're referring to, it seems like you're
> >>> right about the cause.
> >>>
> >>> According to this table (https://tomcat.apache.org/whichversion.html),
> >>> Tomcat 9 is supposed to be compatible with Java 8, yet in this case it
> >>> seems to have broken compatibility on a patch update between 9.0.31 and
> >>> 9.0.58.  In order to regain compatibility, the dependency on JDT
> should be
> >>> adjusted to a lower version.  Is this something the Tomcat people have
> to
> >>> handle, or is it the package maintainers at Canonical who make that
> choice?
> >>
> >> That would be Canonical.
> >>
> >> If you get Tomcat 9 from the ASF it works out of the box on Java 8. (You
> >> actually get the reverse issue with really new JDKs and very old JDTs
> >> but that isn't what is happening here).
> >
> > JDT seems to be getting more and more aggressive with bumping Java
> > requirements. For example, Tomcat 10.1 uses Java 11 as the minimum,
> > but JDT 4.28 is *already* Java 17+. So Tomcat 10.1 will stay on 4.27
> > forever basically.
>
> Thanks for the info. I hadn't realized that. I guess I would have found
> out when I did the version updates for the July releases. I've added a
> note to the 10.1.x build.properties file.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat 9 returns INameEnvironment error

[Joel Griffith]

It looks like the JDT you mention is the Ubuntu package
`libeclipse-jdt-core-java`.

When I installed Tomcat 9 (9.0.31) on the functioning Ubuntu 20.04 system,
version 3.18.0+eclipse4.12-1 of this JDT package was installed as a
dependency.  When I installed Tomcat 9 (9.0.58) on the Ubuntu 22.04 system,
version 3.27.0+eclipse4.21-1 was installed.  Assuming the "4.12" and "4.21"
numbers are the JDT versions you're referring to, it seems like you're
right about the cause.

According to this table (https://tomcat.apache.org/whichversion.html),
Tomcat 9 is supposed to be compatible with Java 8, yet in this case it
seems to have broken compatibility on a patch update between 9.0.31 and
9.0.58.  In order to regain compatibility, the dependency on JDT should be
adjusted to a lower version.  Is this something the Tomcat people have to
handle, or is it the package maintainers at Canonical who make that choice?

Thanks,
Joel

On Thu, Jun 15, 2023 at 11:26 AM Rémy Maucherat  wrote:

> On Thu, Jun 15, 2023 at 5:17 PM Joel Griffith 
> wrote:
> >
> > I'm setting up a JSP webapp on an Ubuntu 22.04 system.  The webapp uses
> > Tomcat 9 proxied through Apache 2, just as described here
> > <https://tomcat.apache.org/tomcat-9.0-doc/proxy-howto.html> .  I'm
> > recreating a setup that works on an Ubuntu 20.04/Tomcat 9 system, and has
> > worked in the past for earlier versions of both Ubuntu and Tomcat.
> >
> > When I access the page https://localhost/app/foo, I get a 500 Internal
> > Server Error.  The error message is
> >
> > java.lang.UnsupportedClassVersionError:
> > org/eclipse/jdt/internal/compiler/env/INameEnvironment has been compiled
> by
> > a more recent version of the Java Runtime (class file version 55.0), this
> > version of the Java Runtime only recognizes class file versions up to
> 52.0
> >
> > The exception is
> >
> > javax.servlet.ServletException: java.lang.UnsupportedClassVersionError:
> > org/eclipse/jdt/internal/compiler/env/INameEnvironment has been compiled
> by
> > a more recent version of the Java Runtime (class file version 55.0), this
> > version of the Java Runtime only recognizes class file versions up to
> 52.0
> > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:332)
> > javax.servlet.http.HttpServlet.service(HttpServlet.java:764)
> > org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
> >
> > There is no file by any variation of the name `INameEnvironment` in my
> > webapp code, and that string does not appear in any file.  I recognize
> > Eclipse as a popular IDE, but I don't use it.  The full stack trace
> (which
> > I can provide if anyone thinks it would be useful) doesn't refer to any
> > other file I recognize.
> >
> > Searching through the Tomcat source code on GitHub, I found the file `
> > java/org/apache/jasper/compiler/JDTCompiler.java` that appears to be the
> > source of the error.  This link takes you to the code snippet in
> question:
> >
> >
> https://github.com/search?q=repo%3Aapache%2Ftomcat%20INameEnvironment=code
> >
> > Is this a bug?  It seems strange that it affects only one system when
> I've
> > set up Tomcat 9 on many systems.  Is there something on the Ubuntu 22.04
> > system that might cause the bug to be thrown that I can fix?
> >
> > The Java version on the Ubuntu 22.04 system (localhost) is
> > ```
> > $ java -version
> > openjdk version "1.8.0_362"
> > OpenJDK Runtime Environment (build 1.8.0_362-8u362-ga-0ubuntu1~22.04-b09)
> > OpenJDK 64-Bit Server VM (build 25.362-b09, mixed mode)
> > ```
> >
> > and the Tomcat version is
> > ```
> > $ java -cp catalina.jar org.apache.catalina.util.ServerInfo
> > Server version: Apache Tomcat/9.0.58 (Ubuntu)
> > Server built:   Jan 6 1970 15:09:28 UTC
> > Server number:  9.0.58.0
> > OS Name:Linux
> > OS Version: 5.19.0-38-generic
> > Architecture:   amd64
> > JVM Version:1.8.0_362-8u362-ga-0ubuntu1~22.04-b09
> > JVM Vendor: Private Build
> > ```
> >
> > The Java version on the Ubuntu 20.04 server for which the webapp works is
> > effectively identical:
> > ```
> > $ java -version
> > openjdk version "1.8.0_362"
> > OpenJDK Runtime Environment (build
> > 1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09)
> > OpenJDK 64-Bit Server VM (build 25.362-b09, mixed mode)
> > ```
> >
> > and its Tomcat version is
> > ```
> > $ java -cp catalina.jar org.apache.catalina.util.ServerInfo
> > Server version: Apache Tomcat/9.0.31 (Ubuntu)
> > Se

Tomcat 9 returns INameEnvironment error

[Joel Griffith]

I'm setting up a JSP webapp on an Ubuntu 22.04 system.  The webapp uses
Tomcat 9 proxied through Apache 2, just as described here
 .  I'm
recreating a setup that works on an Ubuntu 20.04/Tomcat 9 system, and has
worked in the past for earlier versions of both Ubuntu and Tomcat.

When I access the page https://localhost/app/foo, I get a 500 Internal
Server Error.  The error message is

java.lang.UnsupportedClassVersionError:
org/eclipse/jdt/internal/compiler/env/INameEnvironment has been compiled by
a more recent version of the Java Runtime (class file version 55.0), this
version of the Java Runtime only recognizes class file versions up to 52.0

The exception is

javax.servlet.ServletException: java.lang.UnsupportedClassVersionError:
org/eclipse/jdt/internal/compiler/env/INameEnvironment has been compiled by
a more recent version of the Java Runtime (class file version 55.0), this
version of the Java Runtime only recognizes class file versions up to 52.0
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:332)
javax.servlet.http.HttpServlet.service(HttpServlet.java:764)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)

There is no file by any variation of the name `INameEnvironment` in my
webapp code, and that string does not appear in any file.  I recognize
Eclipse as a popular IDE, but I don't use it.  The full stack trace (which
I can provide if anyone thinks it would be useful) doesn't refer to any
other file I recognize.

Searching through the Tomcat source code on GitHub, I found the file `
java/org/apache/jasper/compiler/JDTCompiler.java` that appears to be the
source of the error.  This link takes you to the code snippet in question:

https://github.com/search?q=repo%3Aapache%2Ftomcat%20INameEnvironment=code

Is this a bug?  It seems strange that it affects only one system when I've
set up Tomcat 9 on many systems.  Is there something on the Ubuntu 22.04
system that might cause the bug to be thrown that I can fix?

The Java version on the Ubuntu 22.04 system (localhost) is
```
$ java -version
openjdk version "1.8.0_362"
OpenJDK Runtime Environment (build 1.8.0_362-8u362-ga-0ubuntu1~22.04-b09)
OpenJDK 64-Bit Server VM (build 25.362-b09, mixed mode)
```

and the Tomcat version is
```
$ java -cp catalina.jar org.apache.catalina.util.ServerInfo
Server version: Apache Tomcat/9.0.58 (Ubuntu)
Server built:   Jan 6 1970 15:09:28 UTC
Server number:  9.0.58.0
OS Name:Linux
OS Version: 5.19.0-38-generic
Architecture:   amd64
JVM Version:1.8.0_362-8u362-ga-0ubuntu1~22.04-b09
JVM Vendor: Private Build
```

The Java version on the Ubuntu 20.04 server for which the webapp works is
effectively identical:
```
$ java -version
openjdk version "1.8.0_362"
OpenJDK Runtime Environment (build
1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09)
OpenJDK 64-Bit Server VM (build 25.362-b09, mixed mode)
```

and its Tomcat version is
```
$ java -cp catalina.jar org.apache.catalina.util.ServerInfo
Server version: Apache Tomcat/9.0.31 (Ubuntu)
Server built:   Nov 18 2022 19:07:15 UTC
Server number:  9.0.31.0
OS Name:Linux
OS Version: 5.4.0-150-generic
Architecture:   amd64
JVM Version:1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09
JVM Vendor: Private Build
```

Thanks for any help you can give me.

Joel

Re: Tomcat ownership changed spontaneously

[Joel Griffith]

> If you use a third-party package for Tomcat (e.g. apt-get), you may be
> seeing something coming from /them/. did you recently get any new
> updates from Ubuntu or any other repositories you use?

I don't have a record of specific updates, but I run `apt upgrade`
regularly and originally installed Tomcat using `apt`.  I'll check with
Canonical, then, I guess.  Thanks for the info!

Joel


On Tue, Apr 5, 2022 at 5:56 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Joel,
>
> On 4/5/22 10:33, Joel Griffith wrote:
> > I'm running a webapp under Tomcat 9 on Ubuntu 20.04.  We run Tomcat as an
> > ad-hoc system user who owns the Tomcat installation files.
> >
> > On Friday, the app stopped working.  Over the weekend, I determined that
> > the problem was that something had reset the ownership of the Tomcat
> > installation files to the 'tomcat' user so that the webapp no longer had
> > permission to access its own files.  I had to spend a couple of days
> poring
> > through my notes to figure out what ownership was required for what files
> > and then manually change everything that needed it back to our ad-hoc
> user.
> >
> > Since this change affected only Tomcat files, I can only guess that an
> > update from Tomcat altered the ownership of these files.  Did any recent
> > Tomcat update change file and folder ownership of the Tomcat installation
> > to force them to the 'tomcat' user?
>
> The Tomcat distribution is just a tarball. When you untar it, you get
> the current-user as the owner of the files.
>
> Tomcat has no installer for *NIX systems.
>
> If you use a third-party package for Tomcat (e.g. apt-get), you may be
> seeing something coming from /them/. did you recently get any new
> updates from Ubuntu or any other repositories you use?
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Tomcat ownership changed spontaneously

[Joel Griffith]

Hi,

I'm running a webapp under Tomcat 9 on Ubuntu 20.04.  We run Tomcat as an
ad-hoc system user who owns the Tomcat installation files.

On Friday, the app stopped working.  Over the weekend, I determined that
the problem was that something had reset the ownership of the Tomcat
installation files to the 'tomcat' user so that the webapp no longer had
permission to access its own files.  I had to spend a couple of days poring
through my notes to figure out what ownership was required for what files
and then manually change everything that needed it back to our ad-hoc user.

Since this change affected only Tomcat files, I can only guess that an
update from Tomcat altered the ownership of these files.  Did any recent
Tomcat update change file and folder ownership of the Tomcat installation
to force them to the 'tomcat' user?

Joel

What sets Java version at installation?

[Joel Griffith]

Hi everyone,

I have two Ubuntu 20.04 servers, both with Tomcat 9 and Java 8 installed
from the standard repositories.

On the first, I installed Java 8 before installing Tomcat 9.  When I
installed Tomcat 9, it evidently found the existing Java 8 installation,
and when I run the server it reports that it's using Java 8
(`/usr/lib/jvm/java-8-openjdk-amd64/bin/java`).

On the second, I installed Tomcat 9 before installing Java.  Thus, Tomcat
found no existing Java on the system, and it installed the additional
packages 'openjdk-11-jre-headless', 'default-jre-headless', and
'java-common' as dependencies that it did not install on the first system.
When I run Tomcat on this one, it reports that it's using Java 11
(`/usr/lib/jvm/default-java/bin/java`, which symlinks to
`/usr/lib/jvm/java-1.11.0-openjdk-amd64/bin/java`), even though I've since
installed Java 8 on that server, too.

Both systems use Java 8 as their default at the OS level (outside of
Tomcat):

$ java -version
openjdk version "1.8.0_292"

so I think it's a Tomcat-specific discrepancy.

I assume that there's a file Tomcat uses to record which version of Java it
established at installation and which continues to affect how it runs now.
Is that right, and if so, where is this file?

Thanks,
Joel

Re: What is `tomcat7/common/` for?

[Joel Griffith]

On Wed, Mar 13, 2019 at 9:38 AM Olaf Kock  wrote:

>
> On 13.03.19 14:22, Joel Griffith wrote:
> > > I think it was accomplishing something; tomcat7/common/lib/ contained a
> > > bunch of .jar files that looked like standard Tomcat installation files
> > > (tomcat7-websocket.jar, tomcat-catalina-7.0.68.jar, etc.).  If I switch
> > > directories in the deployment script to tomcat8/lib/, which is
> > empty, javac
> > > complains that it can't find the files to compile.  It looks like
> > I'm going
> > > to need to go through /usr/share/java/ and find tomcat8 versions of
> > all of
> > > the .jar files in tomcat7/common/lib/ and symlink those to
> tomcat8/lib/,
> > > unless someone knows a better way.
>
> If your tomcat/lib folder is empty, I suggest to download the
> distribution again. It has quite a few files in there. If yours doesn't,
> you can either start over, or figure out where they are instead (e.g. if
> you're using your Linux distribution's packaged tomcat)
>
> I installed it using Ubuntu's apt-get install, so installing it again
won't do anything different.  Is there a documentation page that lists what
files are supposed to be there?  That would help.  I can't seem to find one.


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

Re: What is `tomcat7/common/` for?

[Joel Griffith]

On Tue, Mar 12, 2019 at 9:01 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Mark,
>
> On 3/12/19 14:39, Mark Thomas wrote:
> > On 12/03/2019 14:42, Christopher Schultz wrote:
> >> Joel,
> >>
> >> On 3/12/19 09:43, Joel Griffith wrote:
> >>> I'm upgrading a webapp server from Tomcat 7 to Tomcat 8 on
> >>> Ubuntu 16.04. At installation, Tomcat 7 creates a directory
> >>> `/var/lib/tomcat7/common/`. When Tomcat 8 is installed,
> >>> however, the `/var/lib/tomcat8/` directory it creates does not
> >>> include a `common/` directory, and the deployment script
> >>> complains that it isn't there.
> >>
> >>> build.xml:129: /var/lib/tomcat8/common/lib does not exist.
> >>
> >> This must be a deployment script that is managed by neither the
> >> Tomcat project nor the Ubuntu package maintainers. You will need
> >> to update it.
> >>
> >>> I've been searching for a day and have found exactly zero
> >>> documentation on this, including on the official 8.0 migration
> >>> guide ( https://tomcat.apache.org/migration-8.html).
> >>
> >> You are right; it isn't mentioned. That should be added to the
> >> migration guide.
> >
> > Is is practical to try and cover changes in file system layout for
> > distributions we don't control?
>
> No, but there is no mention of the classloader re-organization in the
> migration guide.
>
> Oh, hmm. The reason it's not in there, or in the Tomcat 7 migration
> guide... is because this change was made in Tomcat *6*, and it *is* in
> the migration guide... for Tomcat 6.
>
> So, never mind.
>
> For some reason, I thought this change was made more recently, but I
> guess not.
>
> Joel, it looks like your distribution was (still?) using that
> directory in Tomcat 7 even thought Tomcat hasn't shipped that way for
> ... a long time. I wonder if your deployment script was accomplishing
> anything by touching that directory in the first place.
>
> Okay, things are starting to make a bunch more sense now, thanks.

I think it was accomplishing something; tomcat7/common/lib/ contained a
bunch of .jar files that looked like standard Tomcat installation files
(tomcat7-websocket.jar, tomcat-catalina-7.0.68.jar, etc.).  If I switch
directories in the deployment script to tomcat8/lib/, which is empty, javac
complains that it can't find the files to compile.  It looks like I'm going
to need to go through /usr/share/java/ and find tomcat8 versions of all of
the .jar files in tomcat7/common/lib/ and symlink those to tomcat8/lib/,
unless someone knows a better way.

Thanks again!


> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlyIVmsACgkQHPApP6U8
> pFj5AA/8COXrlLOL+LV8JM/qCvVdCWrSEzoFsBQ3yvAiHgaANPFVWaid0q5DGLiQ
> J7mhzCwcT0h5ObDk1vIlTH8f+VFerlXBd6Ucio//xbQ8Gy2VXsuuNnOz42Rxuk4/
> E/LpSFljo4JUkaYs0XApxNx6yo7ZxZlK3rCvTTx2ZgVQ9SlcRIQ/m6QJkM3m153r
> 1EKSTAKmp4lrsVjes4uwhA6sm/ZJDlR0qNuUAu+0g50F170qOeVJrPRQwnTcI8TE
> q0zbnniw5Wlp2UcsW0gI7iLrtwu7/Bcwnjp0r9V6EA7pjagxTOMPWJxuwzF9SyZU
> r+DtUNFikG7EMXl4Z9POy207B2TlBAt1FJlgkR06LxUJaJjPxdTmNhqREfeiYZGW
> f+uFnrXmHK587UTMYQ4DzhEILj7ZItXyvA6fgQ2xDSoXPTdwBU7obxFZTVZwQc+D
> RodvTUY1nh/xik6oFxd5BEAv5+euXR/Aag+89gPo7Qpdq5qPC05t3iHveQqf0CuE
> rZIvclGKDHwMJG0QfG2UJlwU13JPxtorFc5Fh2ubPrkDypSAtw2zMb/LGeOMFDqx
> h/t/i92W/j10NtMegBTvhp5lolMLTl9guRA8LhjZw15gajutdXVv2VBrlgnqhp8p
> fZjNRgI6nDtXjn/OxsXypQ/6uYoJatjQ9i5JWykl42qFBa6TNHE=
> =AERs
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

What is `tomcat7/common/` for?

[Joel Griffith]

I'm upgrading a webapp server from Tomcat 7 to Tomcat 8 on Ubuntu 16.04.
At installation, Tomcat 7 creates a directory `/var/lib/tomcat7/common/`.
When Tomcat 8 is installed, however, the `/var/lib/tomcat8/` directory it
creates does not include a `common/` directory, and the deployment script
complains that it isn't there.

build.xml:129: /var/lib/tomcat8/common/lib does not exist.

I've been searching for a day and have found exactly zero documentation on
this, including on the official 8.0 migration guide (
https://tomcat.apache.org/migration-8.html).

What is the `/var/lib/tomcat7/common/` directory for, and why does Tomcat 8
not have one?

Re: Tomcat gives 404 for file that exists

[Joel Griffith]

On Tue, Feb 5, 2019 at 9:49 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Joel,
>
> On 2/5/19 08:56, Joel Griffith wrote:
> > On Mon, Feb 4, 2019 at 4:50 PM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Joel,
> >
> > On 2/4/19 16:35, Joel Griffith wrote:
> >>>> I've installed Tomcat 8.0.32 a local Ubuntu 16.04 VM (Oracle
> >>>> VirtualBox) and I'm using it to access a webapp through the
> >>>> laptop the VM is local to. The VM port-forwards 3081 to 8080,
> >>>> so I can access Tomcat as ` http://127.0.0.1:3081/`
> <http://127.0.0.1:3081/>
> >>>> <http://127.0.0.1:3081/> in
> > my laptop browser.
> >
> > Are you sure it's going to the Tomcat you think it's going to?
> >
> > I'm not at all certain.  I didn't even know there was more than
> > one.  How can I tell?
>
> I was thinking that maybe you had either more than one Tomcat running
> or that your port-forwarding wasn't working the way you thought it was.
>
> >> Accessing `http://127.0.0.1:3081/` <http://127.0.0.1:3081/> <
> http://127.0.0.1:3081/> gives
> >> the default page stored in
> >> `/var/lib/tomcat8/webapps/ROOT/index.html`.  So, Tomcat is able
> >> to find and serve from the `webapps/` directory.
> >>
> >> However, if I try to access
> >> `http://127.0.0.1:3081/myWebapp/index.html`
> <http://127.0.0.1:3081/myWebapp/index.html>, which exists as
> >> `/var/lib/tomcat8/webapps/myWebapp/index.html`, Tomcat returns a
> >> 404, reporting that the requested resource in unavailable.
> >>
> >> `/var/lib/tomcat8/webapps/myWebapp/WEB-INF/web.xml` exists and
> >> is identical to that used in a functioning setup on a different
> >> server.
> >>
> >> What am I missing?  Why can Tomcat find
> >> `webapps/ROOT/index.html` but not `webapps/myWebapp/index.html`?
> >
> > Do you have an AccessLogVave enabled for the server? Is it showing
> > your requests and the 404 response when you make a request?
> >
> >
> >> Yes, and yes.
>
> Okay, that's (sort of) good. It means that your request is going to
> the right place.
>
> If you delete your log files and start Tomcat cleanly, what does
> catalina.out say about which applications were started? You should
> have some log entries that look like this:
>
> INFO: Deploying web application directory [/path/to/your/webappp]
> ...
> INFO: Deployment of web application directory [/path/to/your/webapp]
> has finished in [6,417] ms
>
> That's the ticket.  The webapp wasn't deploying because I was missing a
class required by the webapp's web.xml.  I'll get that fixed.  Thanks for
your help!

>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxZon8ACgkQHPApP6U8
> pFho+Q//XYLSHMBzQKSWR4luiMXRaml5ahpWUqcgUa8h/753Aeeiks2Dgr0KcXgB
> dwCWxN/9VE1s+MHzKPWcvoaX2pWHW3ceABw8EzpftMQqrl6pMT9cfqY29d8B0Sbz
> mKyaIrV1qJrnG5bb+G89a8DhCyTroRF5BOXvkKQCiHIJhQ4Q6lihRa/HEYWFLA4l
> cKdfaTjSTfBtkJLfDaQ8+BlDRSY+lfk6joi0P3BOqkNn+kEgM6uTDBadN2NwsBP8
> C7rOK8+Fk2t938it9yPdi3lJ67NUCFbjb8HCYyt36UPuurPZV0ZVf4UdOqYmdPWF
> U+0fqh8XFIH+HLnLS85c+y0BSZ+MukjdkVqRGgiVGhF53icTtv6K1SVOUdI5jw8x
> LdOdn3s7QFCTV2Of3er3Vw/s4NcZRchKZhttd1KnEjAH3Op+IHo88YAGk+3R6bAg
> kCCDHXHs378o7SqVRqW10cujkUN4dAWfkt3/agS+VoRH92VtXFy/zOS++UlD+eBm
> 4tglZSwwhqkEs2tYA+ZDXe1A9e+op4dZ7y48yGo91dDo4E0uRnqrVWDNoROE7a4i
> nyCT4C8NrtP1UUyt43fYcUtbiWlYf1pQcUsVuYOSDkGWNA3Ejj7F8hDaj0XuwB9E
> XLxpjgbZSuf5+ifC+lJat8tBqKBDw+vDBJyKYAs1XqLMIm7WgFw=
> =fay0
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat gives 404 for file that exists

[Joel Griffith]

On Mon, Feb 4, 2019 at 4:50 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Joel,
>
> On 2/4/19 16:35, Joel Griffith wrote:
> > I've installed Tomcat 8.0.32 a local Ubuntu 16.04 VM (Oracle
> > VirtualBox) and I'm using it to access a webapp through the laptop
> > the VM is local to. The VM port-forwards 3081 to 8080, so I can
> > access Tomcat as ` http://127.0.0.1:3081/` <http://127.0.0.1:3081/> in
> my laptop browser.
>
> Are you sure it's going to the Tomcat you think it's going to?
>
> I'm not at all certain.  I didn't even know there was more than one.  How
can I tell?

> Accessing `http://127.0.0.1:3081/` <http://127.0.0.1:3081/> gives the
> default page stored
> > in `/var/lib/tomcat8/webapps/ROOT/index.html`.  So, Tomcat is able
> > to find and serve from the `webapps/` directory.
> >
> > However, if I try to access
> > `http://127.0.0.1:3081/myWebapp/index.html`
> <http://127.0.0.1:3081/myWebapp/index.html>, which exists as
> > `/var/lib/tomcat8/webapps/myWebapp/index.html`, Tomcat returns a
> > 404, reporting that the requested resource in unavailable.
> >
> > `/var/lib/tomcat8/webapps/myWebapp/WEB-INF/web.xml` exists and is
> > identical to that used in a functioning setup on a different
> > server.  It was originally written for a Tomcat 7 deployment, I
> > think, but there's nothing in it that seems to have anything to do
> > with these URLs, so I don't think it's a problem with that file.
> > Similarly, `/var/lib/tomcat8/conf/server.xml` exists and is
> > virtually identical to that used in the other (functioning)
> > deployment.
> >
> > All of the information I've been able to scrape together from web
> > searches over the past two days indicate that the presence of a
> > folder within the `webapps/` directory is sufficient for Tomcat to
> > recognize and register it as a Context.  I'm at a complete loss for
> > what else I need to do to have Tomcat serve the file
> > `webapps/myWebapp/index.html`
> >
> > What am I missing?  Why can Tomcat find `webapps/ROOT/index.html`
> > but not `webapps/myWebapp/index.html`?
>
> Do you have an AccessLogVave enabled for the server? Is it showing
> your requests and the 404 response when you make a request?
>

Yes, and yes.


> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxYs5gACgkQHPApP6U8
> pFgDGQ//VQnrKG77d+ciLUx5hgapoTR73DEHIIXD1vrbkPR9XLydjRcgnbTXFWzf
> xIH2rB2hROWAsA0T/GjaG87EfqFehlGmqa5isFNLqoah6Ss3wCvjvquwtdS+1OPX
> 0wxl2uqxgDmFVpMAOgmYGmp3HLi87nP/8h5Rn/Ef/Iqg3Z4CTKjvcUUhKRf3Lupw
> CYoPe3AFUOXTG40EKBDqzJ8IW2+Mt0rNfkU3T5v4BUtrKKc3ARof5CygVvgVS+5Q
> qpjH/p+hskvXWWuAz9is6+qAgu7WPyoV7KhOq93M9yQQ/bR7fNMfjVYg9q6z+UKO
> m6bNf+eQCtXfaHnDJp5Bytied0nUlCfBbHP6tvvNNl9B2jdaV4nT+9ZQIykOXN4E
> p64PvpHk8V2v/6GIlJ04E1LNiMwNycu3l24DnSn27sVxD6JKIMoTlyf4dvPK+zsw
> Jp8Bguiqog6geBpo+CNU1vzToWpiGHP/8rSwh9pbX7xpyTfWgq3bnvJmzNaVYJQ5
> ggPCRiMRFgPurIr5edvvlyaGp8gfeFtb1FgCTKNTg2J9j8yxVI2p30lT8L+I+Rxp
> Tpapvum6q1/NAtKigCuq7ylXpN3XQnOmJq7fb1a7+lYwzA0NQ3IC8uooSys4GNBb
> ijeTnYsCTJqXNZ9k5BiCkUgMEr5yo4qiAtmppTbelGoNsWno+Jc=
> =VZa6
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Tomcat gives 404 for file that exists

[Joel Griffith]

I've installed Tomcat 8.0.32 a local Ubuntu 16.04 VM (Oracle VirtualBox)
and I'm using it to access a webapp through the laptop the VM is local to.
The VM port-forwards 3081 to 8080, so I can access Tomcat as `
http://127.0.0.1:3081/` in my laptop browser.

Accessing `http://127.0.0.1:3081/` gives the default page stored in
`/var/lib/tomcat8/webapps/ROOT/index.html`.  So, Tomcat is able to find and
serve from the `webapps/` directory.

However, if I try to access `http://127.0.0.1:3081/myWebapp/index.html`,
which exists as `/var/lib/tomcat8/webapps/myWebapp/index.html`, Tomcat
returns a 404, reporting that the requested resource in unavailable.

`/var/lib/tomcat8/webapps/myWebapp/WEB-INF/web.xml` exists and is identical
to that used in a functioning setup on a different server.  It was
originally written for a Tomcat 7 deployment, I think, but there's nothing
in it that seems to have anything to do with these URLs, so I don't think
it's a problem with that file.  Similarly,
`/var/lib/tomcat8/conf/server.xml` exists and is virtually identical to
that used in the other (functioning) deployment.

All of the information I've been able to scrape together from web searches
over the past two days indicate that the presence of a folder within the
`webapps/` directory is sufficient for Tomcat to recognize and register it
as a Context.  I'm at a complete loss for what else I need to do to have
Tomcat serve the file `webapps/myWebapp/index.html`

What am I missing?  Why can Tomcat find `webapps/ROOT/index.html` but not
`webapps/myWebapp/index.html`?

Thanks