Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)
On Thu, Mar 3, 2022 at 1:10 PM Berneburg, Cris J. - US wrote: > > Running Tomcat in a container via Docker Desktop on a Windows host > > with the web application served from a location on the host mounted > > /bound to the container is insecure. > > So the app resides on the "host" OS file system and is mounted into the > Docker "guest" container, rather than residing on a Docker volume or in the > guest container's file system? > Correct (as far as my experience was concerned). The problem only occured for us when we had the Tomcat webapps folder "bound" (or mounted) to a folder on the host file system. If the webapps folder was just on a volume in the Docker container, it worked without issue. Technically I haven't tried it in the container's file system, only a volume attached to the container, but I expect that would also be without issue.
RE: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)
Mark, et al > Running Tomcat in a container via Docker Desktop on a Windows host > with the web application served from a location on the host mounted > /bound to the container is insecure. So the app resides on the "host" OS file system and is mounted into the Docker "guest" container, rather than residing on a Docker volume or in the guest container's file system? -- Cris Berneburg CACI Senior Software Engineer This electronic message contains information from CACI International Inc or subsidiary companies, which may be company sensitive, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify the sender immediately.
Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)
Mark,
Thanks for continuing to look into it, and producing a detailed record of
the issues and the cause (along with intermediate details). Hopefully it
will come in useful for others in the future.
Robert
On Thu, Mar 3, 2022 at 3:11 AM Mark Thomas wrote:
> Robert,
>
> Apologies for the delayed reply. Having found the root cause of the
> issue I wanted to confirm whether or not the Docker desktop team viewed
> it as a security vulnerability or not. I received confirmation yesterday
> that they do not.
>
> TL;DR
> Running Tomcat in a container via Docker Desktop on a Windows host with
> the web application served from a location on the host mounted/bound to
> the container is insecure.
>
> Longer version:
> To ensure that things like security constraints are correctly applied,
> Tomcat has to process URLs in a case sensitive manner. "/Test.jsp" is
> not he same as "/test.jsp".
>
> URLs are often mapped to resources on the file system. This mapping also
> needs to be applied in a case sensitive manner. If the file system is
> case sensitive, this is relatively straight forward. If the file system
> is case insensitive, Tomcat performs some additional checks. These look
> something like this:
> - Request for "/Test.jsp"
> - Find file "$appbase/Test.jsp"
> - Get the canonical path
> - Confirm the case matches the original request
>
> On a case insensitive file system, looking up "$appbase/Test.jsp" will
> match "$appbase/test.jsp" but the canonical path will return
> "$appbase/test.jsp" which doesn't match so a 404 will be returned.
>
> The issue with Docker Desktop is that paths on the Windows host
> mounted/bound to the container behave like this:
> - The path - as far as Windows is concerned - is "$appbase/Test.jsp"
> - Code running in the container looks up "$appbase/Test.jsp"
> - The file is found
> - The canonical path is "$appbase/Test.jsp"
> - So far, so good
> - Code running in the container looks up "$appbase/test.jsp"
> - The file is found
> - The canonical path is "$appbase/test.jsp"
>
> The issue is that the canonical path returned the second time matches
> the path used to obtain the resource, not the canonical path on the
> Windows file system. This means Tomcat cannot perform the case
> sensitivity tests.
> This creates the following security issues:
> - security constraints can be bypasses
> - JSP source code disclosure
> It also creates class loading issues as Java class and package names are
> also case sensitive.
>
> The view of the Docket Desktop team is that this is, at best, a bug not
> a security vulnerability because Docker Desktop is a developer tool, not
> a tool for running production instances. Further, the expectation is
> that the web application would be included in the container in production.
>
> If you do continue to use this approach in development, keep in mind that:
> - you may see issues like the original EL issue you reported
> - security testing may report false positives
>
> HTH,
>
> Mark
>
>
>
>
> On 08/02/2022 15:11, Robert Turner wrote:
> > Okay. Yep, my most recent suspicion was correct -- it's related to the
> > Docker bind to a local folder containing the webapps. As such, I believe
> > it's a Docker issue of some sort and not Tomcat specific. However, you
> may
> > want to understand it more completely in any case.
> >
> > Thanks for your help Mark, Rob S and Neil.
> >
> >
> > Here are the full details of the reproduction scenario:
> >
> > Host system: MacOS 12.2; Docker Desktop v4.4.2 (73305), Engine 20.10.12
> >
> > 1. Using Maven Archetypes, do the following:
> >
> > mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes
> > -DarchetypeArtifactId=maven-archetype-webapp -DarchetypeVersion=1.4
> >
> > When prompted for configuration values, use the following:
> >
> > groupId: com.example.rt
> > artifactId: test-el-resolver
> > version: 1.0-SNAPSHOT
> > package: com.example.rt
> >
> > 2. Switch to the new folder created for the web app
> >
> > cd test-el-resolver
> >
> > 3. Modify the index.jsp file (src/main/webapp/index.jsp) to have the
> > following contents:
> >
> > <%@page contentType="text/html" pageEncoding="UTF-8" isELIgnored="false"
> %>
> > <%@page import="com.example.rt.Failing"%>
> > <%
> > final Failing failing = null;
> > pageContext.setAttribute("failing", failing);
> > %>
> >
> >
> > Hello World!
> >
> > field1=${failing.field1}
> >
> >
> >
> > 4. Add the following contents to
> > file src/main/java/com/example/rt/Failing.java:
> >
> > package com.example.rt;
> >
> > public class Failing {
> >
> > private final String field1 = "field1_value";
> >
> > public String getField1() {
> > return field1;
> > }
> >
> > }
> >
> >
> > 5. Build the web app
> >
> > mvn package
> >
> >
> > 6. Create a local folder to mount/bind into the Docker container
> >
> > mkdir webapps
> >
> >
> > 7. Copy the WAR file to the new folder
> >
> > cp target/test-el-resolver.war webapps/
> >
> >
> > 8. Start a
Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)
Robert,
Apologies for the delayed reply. Having found the root cause of the
issue I wanted to confirm whether or not the Docker desktop team viewed
it as a security vulnerability or not. I received confirmation yesterday
that they do not.
TL;DR
Running Tomcat in a container via Docker Desktop on a Windows host with
the web application served from a location on the host mounted/bound to
the container is insecure.
Longer version:
To ensure that things like security constraints are correctly applied,
Tomcat has to process URLs in a case sensitive manner. "/Test.jsp" is
not he same as "/test.jsp".
URLs are often mapped to resources on the file system. This mapping also
needs to be applied in a case sensitive manner. If the file system is
case sensitive, this is relatively straight forward. If the file system
is case insensitive, Tomcat performs some additional checks. These look
something like this:
- Request for "/Test.jsp"
- Find file "$appbase/Test.jsp"
- Get the canonical path
- Confirm the case matches the original request
On a case insensitive file system, looking up "$appbase/Test.jsp" will
match "$appbase/test.jsp" but the canonical path will return
"$appbase/test.jsp" which doesn't match so a 404 will be returned.
The issue with Docker Desktop is that paths on the Windows host
mounted/bound to the container behave like this:
- The path - as far as Windows is concerned - is "$appbase/Test.jsp"
- Code running in the container looks up "$appbase/Test.jsp"
- The file is found
- The canonical path is "$appbase/Test.jsp"
- So far, so good
- Code running in the container looks up "$appbase/test.jsp"
- The file is found
- The canonical path is "$appbase/test.jsp"
The issue is that the canonical path returned the second time matches
the path used to obtain the resource, not the canonical path on the
Windows file system. This means Tomcat cannot perform the case
sensitivity tests.
This creates the following security issues:
- security constraints can be bypasses
- JSP source code disclosure
It also creates class loading issues as Java class and package names are
also case sensitive.
The view of the Docket Desktop team is that this is, at best, a bug not
a security vulnerability because Docker Desktop is a developer tool, not
a tool for running production instances. Further, the expectation is
that the web application would be included in the container in production.
If you do continue to use this approach in development, keep in mind that:
- you may see issues like the original EL issue you reported
- security testing may report false positives
HTH,
Mark
On 08/02/2022 15:11, Robert Turner wrote:
Okay. Yep, my most recent suspicion was correct -- it's related to the
Docker bind to a local folder containing the webapps. As such, I believe
it's a Docker issue of some sort and not Tomcat specific. However, you may
want to understand it more completely in any case.
Thanks for your help Mark, Rob S and Neil.
Here are the full details of the reproduction scenario:
Host system: MacOS 12.2; Docker Desktop v4.4.2 (73305), Engine 20.10.12
1. Using Maven Archetypes, do the following:
mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes
-DarchetypeArtifactId=maven-archetype-webapp -DarchetypeVersion=1.4
When prompted for configuration values, use the following:
groupId: com.example.rt
artifactId: test-el-resolver
version: 1.0-SNAPSHOT
package: com.example.rt
2. Switch to the new folder created for the web app
cd test-el-resolver
3. Modify the index.jsp file (src/main/webapp/index.jsp) to have the
following contents:
<%@page contentType="text/html" pageEncoding="UTF-8" isELIgnored="false" %>
<%@page import="com.example.rt.Failing"%>
<%
final Failing failing = null;
pageContext.setAttribute("failing", failing);
%>
Hello World!
field1=${failing.field1}
4. Add the following contents to
file src/main/java/com/example/rt/Failing.java:
package com.example.rt;
public class Failing {
private final String field1 = "field1_value";
public String getField1() {
return field1;
}
}
5. Build the web app
mvn package
6. Create a local folder to mount/bind into the Docker container
mkdir webapps
7. Copy the WAR file to the new folder
cp target/test-el-resolver.war webapps/
8. Start a docker container binding the local web apps folder
docker run -d -p 8075:8080 --mount
type=volume,src=`pwd`/webapps,dst=/usr/local/tomcat/webapps
tomcat:9.0.58-jre11-openjdk
9. Using a browser (or equivalent), access the app:
curl http://localhost:8075/test-el-resolver/
10. Observe the following exception in the error page:
Stacktrace:
org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:610)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:489)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:379)
Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)
That's good to know. I suppose the key use case we would have is having the ability to "hot deploy" from an IDE into the webapps folder rather than a full build, package, deploy cycle (which can be time consuming). Robert On Tue, Feb 8, 2022 at 11:41 AM Mark Eggers wrote: > Just a note: > > On 2/8/2022 8:32 AM, Rob Sargent wrote: > > > > > > On 2/8/22 08:11, Robert Turner wrote: > >> Okay. Yep, my most recent suspicion was correct -- it's related to the > >> Docker bind to a local folder containing the webapps. As such, I believe > >> it's a Docker issue of some sort and not Tomcat specific. However, you > >> may > >> want to understand it more completely in any case. > >> > >> Thanks for your help Mark, Rob S and Neil. > >> > >> > > Is docker the new regexp? You know: I had a problem. Used docker to > > solve it. Now I have two problems. > > When you attach a volume to a container from a case-insensitive file > system (Windows, MacOS), then that directory will be case-insensitive. > > At least that's what a quick search indicates. I run all of my local > Docker images from WSL2 (Ubuntu 20.04 LTS) on Windows 10 Pro, so I don't > experience a case issue. > > This may or may not help > > . . . just my two cents > /mde/ >
Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)
Just a note: On 2/8/2022 8:32 AM, Rob Sargent wrote: On 2/8/22 08:11, Robert Turner wrote: Okay. Yep, my most recent suspicion was correct -- it's related to the Docker bind to a local folder containing the webapps. As such, I believe it's a Docker issue of some sort and not Tomcat specific. However, you may want to understand it more completely in any case. Thanks for your help Mark, Rob S and Neil. Is docker the new regexp? You know: I had a problem. Used docker to solve it. Now I have two problems. When you attach a volume to a container from a case-insensitive file system (Windows, MacOS), then that directory will be case-insensitive. At least that's what a quick search indicates. I run all of my local Docker images from WSL2 (Ubuntu 20.04 LTS) on Windows 10 Pro, so I don't experience a case issue. This may or may not help . . . just my two cents /mde/ OpenPGP_signature Description: OpenPGP digital signature
Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)
On 2/8/22 08:11, Robert Turner wrote: Okay. Yep, my most recent suspicion was correct -- it's related to the Docker bind to a local folder containing the webapps. As such, I believe it's a Docker issue of some sort and not Tomcat specific. However, you may want to understand it more completely in any case. Thanks for your help Mark, Rob S and Neil. Is docker the new regexp? You know: I had a problem. Used docker to solve it. Now I have two problems. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)
Okay. Yep, my most recent suspicion was correct -- it's related to the
Docker bind to a local folder containing the webapps. As such, I believe
it's a Docker issue of some sort and not Tomcat specific. However, you may
want to understand it more completely in any case.
Thanks for your help Mark, Rob S and Neil.
Here are the full details of the reproduction scenario:
Host system: MacOS 12.2; Docker Desktop v4.4.2 (73305), Engine 20.10.12
1. Using Maven Archetypes, do the following:
mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes
-DarchetypeArtifactId=maven-archetype-webapp -DarchetypeVersion=1.4
When prompted for configuration values, use the following:
groupId: com.example.rt
artifactId: test-el-resolver
version: 1.0-SNAPSHOT
package: com.example.rt
2. Switch to the new folder created for the web app
cd test-el-resolver
3. Modify the index.jsp file (src/main/webapp/index.jsp) to have the
following contents:
<%@page contentType="text/html" pageEncoding="UTF-8" isELIgnored="false" %>
<%@page import="com.example.rt.Failing"%>
<%
final Failing failing = null;
pageContext.setAttribute("failing", failing);
%>
Hello World!
field1=${failing.field1}
4. Add the following contents to
file src/main/java/com/example/rt/Failing.java:
package com.example.rt;
public class Failing {
private final String field1 = "field1_value";
public String getField1() {
return field1;
}
}
5. Build the web app
mvn package
6. Create a local folder to mount/bind into the Docker container
mkdir webapps
7. Copy the WAR file to the new folder
cp target/test-el-resolver.war webapps/
8. Start a docker container binding the local web apps folder
docker run -d -p 8075:8080 --mount
type=volume,src=`pwd`/webapps,dst=/usr/local/tomcat/webapps
tomcat:9.0.58-jre11-openjdk
9. Using a browser (or equivalent), access the app:
curl http://localhost:8075/test-el-resolver/
10. Observe the following exception in the error page:
Stacktrace:
org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:610)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:489)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:379)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:327)
javax.servlet.http.HttpServlet.service(HttpServlet.java:764)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
Root Causejavax.servlet.ServletException:
java.lang.NoClassDefFoundError: comexamplertFailing (wrong
name: comexamplertfailing)
org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:657)
org.apache.jsp.index_jsp._jspService(index_jsp.java:145)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
javax.servlet.http.HttpServlet.service(HttpServlet.java:764)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:466)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:379)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:327)
javax.servlet.http.HttpServlet.service(HttpServlet.java:764)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
Root Causejava.lang.NoClassDefFoundError:
comexamplertFailing (wrong name:
comexamplertfailing)
java.basejava.lang.ClassLoader.defineClass1(Native Method)
java.basejava.lang.ClassLoader.defineClass(Unknown Source)
java.basejava.security.SecureClassLoader.defineClass(Unknown Source)
org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:2478)
org.apache.catalina.loader.WebappClassLoaderBase.findClass(WebappClassLoaderBase.java:870)
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1371)
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1215)
javax.el.ImportHandler.findClass(ImportHandler.java:477)
javax.el.ImportHandler.resolveClass(ImportHandler.java:421)
javax.servlet.jsp.el.ScopedAttributeELResolver.getValue(ScopedAttributeELResolver.java:85)
org.apache.jasper.el.JasperELResolver.getValue(JasperELResolver.java:124)
org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:93)
org.apache.el.parser.AstValue.getValue(AstValue.java:136)
org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:189)
org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContextImpl.java:692)
org.apache.jsp.index_jsp._jspService(index_jsp.java:130)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
javax.servlet.http.HttpServlet.service(HttpServlet.java:764)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:466)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:379)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:327)
javax.servlet.http.HttpServlet.service(HttpServlet.java:764)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
Note The full stack trace of
Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)
Mark, Thanks for the quick follow up. Based on your comments I have some ideas on what it might be, and I should be able to narrow that down further for you, and provide all the details that you requested. A few notes on the environment I'm using: Docker (the host) is running on my Mac (12.2), not in AWS. AWS Linux is only involved in the Docker image (as per the Dockerfile I shared earlier). Moreover, it happens with Debian in the Docker image as well. What I think is important is that I have "/work" and "/webapps" mounted to file folders on the Mac, so I am suspecting it's something to do with that "mounting" of the volume to the host OS, and how Docker is mapping those and handling filename casing, etc. My MacOS file system is APFS, Encrypted (and I thought I had case sensitivity enabled, but I can no longer see that option -- maybe not an option for APFS). I will try to confirm suspicions and provide details in a few hours (hopefully -- got a few meetings today that will get in the way). Thanks again, Robert On Tue, Feb 8, 2022 at 8:51 AM Mark Thomas wrote: > Robert, > > I agree this is something to do with the Docker environment. > > I think case insensitivity is involved somewhere as I can trigger the > error if I copy my equivalent of Failure.class to failure.class and then > call the JSP. > > I understand why it only occurs for * imports. In that instance, Tomcat > has to check if the class can be loaded from each of the imported > packages. Tomcat checks the file system first as that is faster than > trying (and failing) to load a class. The file system checks are > designed to be case sensitive - even on case insensitive file systems. > Something seems to be going wrong here and I'm still not sure what. > > I have tried to recreate this on AWS without success. If you have time, > I think we'd need the following to dig into this further: > > - Source for the simplest possible test WAR that demonstrates this >issue. I think a single class and a single JSP page should be >sufficient. > > - The WAR you created from the above (to rule out any build issues). > > - A minimal Dockerfile to create a Tomcat instance that demonstrates >this issue. Should just copy the WAR to the container and start it >with JPDA enabled. > > - Which AMI you used to create the AWS instance. I'm using the AWS free >tier so I used a t2.micro instance with >amzn2-ami-kernel-5.10-hvm-2.0.20220121.0-x86_64-gp2 > > Thanks, > > Mark > > > On 08/02/2022 13:24, Robert Turner wrote: > > One thing to add is that my "conclusion" about OS variances I believe to > be > > incorrect. Our tests typically run on Linux, so I think it's still > > something to do with a difference in the Docker-based environment. > > > > Let me know if you need any more details on anything...(but I suspect > with > > a debugger up on the Expression Resolvers, you will at least narrow it > down > > quickly...) > > > > On Tue, Feb 8, 2022 at 7:55 AM Robert Turner > wrote: > > > >> Thanks Mark. Much appreciated. > >> > >> On Tue., Feb. 8, 2022, 04:06 Mark Thomas, wrote: > >> > >>> Robert, > >>> > >>> Thank you for putting the effort in to debugging this. Narrowing down > >>> the issue to a simple test case is extremely helpful. > >>> > >>> The behaviour you describe looks odd to me. I'd expect consistent > >>> behaviour across platforms irrespective of the case sensitivity of the > >>> file system in use. > >>> > >>> I'm going to use your test case to investigate this further. I'll > report > >>> back here with my findings - hopefully later today. > >>> > >>> Mark > >>> > >>> > >>> On 08/02/2022 03:29, Robert Turner wrote: > Okay, so I have finally narrowed it down the trivial failure case, > and I > think I have an explanation as a result: > > [1] works (in docker), and [2] fails (in docker) but works outside. > The > difference between the two is the import directive being a wildcard > >>> (ugly, > but historical in our app in some places we haven't yet cleaned up). > > I am therefore speculating based on the Expression Language > >>> specification > that because the class wasn't explicitly imported, it's not in the > list > >>> of > available classes for static class resolution, and thus it fails. > Combine this with MacOS and Windows not caring about filename cases, > and > Linux caring, then I suspect it's just matching differently in both > >>> cases. > > Workaround/fix would be: > - to ensure we explicitly import the class (instead or in addition to > >>> the > wildcard) > OR > - rename the attribute so it doesn't map directly to the class name. > > > So I think I can bring my overly-detailed thread to an end...unless my > guess at the reasoning is incorrect and someone has a better > >>> explanation. > > Thanks Rob S and Neil for having a look and providing suggestions -- > in > part, it was
Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)
Robert,
I agree this is something to do with the Docker environment.
I think case insensitivity is involved somewhere as I can trigger the
error if I copy my equivalent of Failure.class to failure.class and then
call the JSP.
I understand why it only occurs for * imports. In that instance, Tomcat
has to check if the class can be loaded from each of the imported
packages. Tomcat checks the file system first as that is faster than
trying (and failing) to load a class. The file system checks are
designed to be case sensitive - even on case insensitive file systems.
Something seems to be going wrong here and I'm still not sure what.
I have tried to recreate this on AWS without success. If you have time,
I think we'd need the following to dig into this further:
- Source for the simplest possible test WAR that demonstrates this
issue. I think a single class and a single JSP page should be
sufficient.
- The WAR you created from the above (to rule out any build issues).
- A minimal Dockerfile to create a Tomcat instance that demonstrates
this issue. Should just copy the WAR to the container and start it
with JPDA enabled.
- Which AMI you used to create the AWS instance. I'm using the AWS free
tier so I used a t2.micro instance with
amzn2-ami-kernel-5.10-hvm-2.0.20220121.0-x86_64-gp2
Thanks,
Mark
On 08/02/2022 13:24, Robert Turner wrote:
One thing to add is that my "conclusion" about OS variances I believe to be
incorrect. Our tests typically run on Linux, so I think it's still
something to do with a difference in the Docker-based environment.
Let me know if you need any more details on anything...(but I suspect with
a debugger up on the Expression Resolvers, you will at least narrow it down
quickly...)
On Tue, Feb 8, 2022 at 7:55 AM Robert Turner wrote:
Thanks Mark. Much appreciated.
On Tue., Feb. 8, 2022, 04:06 Mark Thomas, wrote:
Robert,
Thank you for putting the effort in to debugging this. Narrowing down
the issue to a simple test case is extremely helpful.
The behaviour you describe looks odd to me. I'd expect consistent
behaviour across platforms irrespective of the case sensitivity of the
file system in use.
I'm going to use your test case to investigate this further. I'll report
back here with my findings - hopefully later today.
Mark
On 08/02/2022 03:29, Robert Turner wrote:
Okay, so I have finally narrowed it down the trivial failure case, and I
think I have an explanation as a result:
[1] works (in docker), and [2] fails (in docker) but works outside. The
difference between the two is the import directive being a wildcard
(ugly,
but historical in our app in some places we haven't yet cleaned up).
I am therefore speculating based on the Expression Language
specification
that because the class wasn't explicitly imported, it's not in the list
of
available classes for static class resolution, and thus it fails.
Combine this with MacOS and Windows not caring about filename cases, and
Linux caring, then I suspect it's just matching differently in both
cases.
Workaround/fix would be:
- to ensure we explicitly import the class (instead or in addition to
the
wildcard)
OR
- rename the attribute so it doesn't map directly to the class name.
So I think I can bring my overly-detailed thread to an end...unless my
guess at the reasoning is incorrect and someone has a better
explanation.
Thanks Rob S and Neil for having a look and providing suggestions -- in
part, it was something related to what you both said, but I believe in
different contexts than you expected.
Robert
[1]
$ cat src/main/webapp/index.jsp
<%@page contentType="text/html" pageEncoding="UTF-8"
isELIgnored="false" %>
<%@page import="com.example.rt.Failing" %>
<%
final Failing failing = null;
pageContext.setAttribute("failing", failing);
%>
Hello World!
field1=${failing.field1}
[2]
$ cat src/main/webapp/index.jsp
<%@page contentType="text/html" pageEncoding="UTF-8"
isELIgnored="false" %>
<%@page import="com.example.rt.*" %>
<%
final Failing failing = null;
pageContext.setAttribute("failing", failing);
%>
Hello World!
field1=${failing.field1}
On Mon, Feb 7, 2022 at 10:14 PM Robert Turner
wrote:
So back to a divide and conquer approach I think.
I just created a trivial "example" [1] and it works as expected (i.e.
no
exception was generated) (on the same servers I was testing the
complex JAR
file) -- so possibly something else modifying the behaviour -- a JAR
on the
classpath, or something in the JSP file...
[1]
$ cat src/main/webapp/index.jsp
<%@page contentType="text/html" pageEncoding="UTF-8"
isELIgnored="false" %>
<%@page import="com.example.rt.Failing"%>
<%
final Failing failing = null;
pageContext.setAttribute("failing", failing);
%>
Hello World!
field1=${failing.field1}
$ cat src/main/java/com/example/rt/Failing.java
package com.example.rt;
public class Failing {
private final String field1 =
Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)
One thing to add is that my "conclusion" about OS variances I believe to be
incorrect. Our tests typically run on Linux, so I think it's still
something to do with a difference in the Docker-based environment.
Let me know if you need any more details on anything...(but I suspect with
a debugger up on the Expression Resolvers, you will at least narrow it down
quickly...)
On Tue, Feb 8, 2022 at 7:55 AM Robert Turner wrote:
> Thanks Mark. Much appreciated.
>
> On Tue., Feb. 8, 2022, 04:06 Mark Thomas, wrote:
>
>> Robert,
>>
>> Thank you for putting the effort in to debugging this. Narrowing down
>> the issue to a simple test case is extremely helpful.
>>
>> The behaviour you describe looks odd to me. I'd expect consistent
>> behaviour across platforms irrespective of the case sensitivity of the
>> file system in use.
>>
>> I'm going to use your test case to investigate this further. I'll report
>> back here with my findings - hopefully later today.
>>
>> Mark
>>
>>
>> On 08/02/2022 03:29, Robert Turner wrote:
>> > Okay, so I have finally narrowed it down the trivial failure case, and I
>> > think I have an explanation as a result:
>> >
>> > [1] works (in docker), and [2] fails (in docker) but works outside. The
>> > difference between the two is the import directive being a wildcard
>> (ugly,
>> > but historical in our app in some places we haven't yet cleaned up).
>> >
>> > I am therefore speculating based on the Expression Language
>> specification
>> > that because the class wasn't explicitly imported, it's not in the list
>> of
>> > available classes for static class resolution, and thus it fails.
>> > Combine this with MacOS and Windows not caring about filename cases, and
>> > Linux caring, then I suspect it's just matching differently in both
>> cases.
>> >
>> > Workaround/fix would be:
>> > - to ensure we explicitly import the class (instead or in addition to
>> the
>> > wildcard)
>> > OR
>> > - rename the attribute so it doesn't map directly to the class name.
>> >
>> >
>> > So I think I can bring my overly-detailed thread to an end...unless my
>> > guess at the reasoning is incorrect and someone has a better
>> explanation.
>> >
>> > Thanks Rob S and Neil for having a look and providing suggestions -- in
>> > part, it was something related to what you both said, but I believe in
>> > different contexts than you expected.
>> >
>> > Robert
>> >
>> >
>> > [1]
>> > $ cat src/main/webapp/index.jsp
>> > <%@page contentType="text/html" pageEncoding="UTF-8"
>> isELIgnored="false" %>
>> > <%@page import="com.example.rt.Failing" %>
>> > <%
>> > final Failing failing = null;
>> > pageContext.setAttribute("failing", failing);
>> > %>
>> >
>> >
>> > Hello World!
>> >
>> > field1=${failing.field1}
>> >
>> >
>> > [2]
>> > $ cat src/main/webapp/index.jsp
>> > <%@page contentType="text/html" pageEncoding="UTF-8"
>> isELIgnored="false" %>
>> > <%@page import="com.example.rt.*" %>
>> > <%
>> > final Failing failing = null;
>> > pageContext.setAttribute("failing", failing);
>> > %>
>> >
>> >
>> > Hello World!
>> >
>> > field1=${failing.field1}
>> >
>> >
>> >
>> >
>> > On Mon, Feb 7, 2022 at 10:14 PM Robert Turner
>> wrote:
>> >
>> >> So back to a divide and conquer approach I think.
>> >>
>> >> I just created a trivial "example" [1] and it works as expected (i.e.
>> no
>> >> exception was generated) (on the same servers I was testing the
>> complex JAR
>> >> file) -- so possibly something else modifying the behaviour -- a JAR
>> on the
>> >> classpath, or something in the JSP file...
>> >>
>> >> [1]
>> >>
>> >> $ cat src/main/webapp/index.jsp
>> >> <%@page contentType="text/html" pageEncoding="UTF-8"
>> isELIgnored="false" %>
>> >> <%@page import="com.example.rt.Failing"%>
>> >> <%
>> >> final Failing failing = null;
>> >> pageContext.setAttribute("failing", failing);
>> >> %>
>> >>
>> >>
>> >> Hello World!
>> >>
>> >> field1=${failing.field1}
>> >>
>> >>
>> >>
>> >> $ cat src/main/java/com/example/rt/Failing.java
>> >> package com.example.rt;
>> >>
>> >> public class Failing {
>> >>
>> >> private final String field1 = "field1_value";
>> >>
>> >> public String getField1() {
>> >> return field1;
>> >> }
>> >>
>> >> }
>> >>
>> >>
>> >>
>> >> On Mon, Feb 7, 2022 at 9:51 PM Robert Turner
>> wrote:
>> >>
>> >>> I'm just avoiding sharing product details or things I think only
>> serves
>> >>> to confuse the problem. Sorry if you felt I wasn't sharing. It wasn't
>> my
>> >>> intention to be obtuse. I didn't believe they added any value for the
>> >>> diagnostics (of course that assumes I know enough about the problem).
>> >>>
>> >>> However, since you think they might be useful, here they the name
>> mapping
>> >>> from the exception and the Java and JSP code excerpts:
>> >>>
>> >>>"package1" -> "model"
>> >>>"Class1" -> "Organization"
>> >>>"class1" -> "organization"
>> >>>
>> >>> The class is present in the package (see [1]) -- otherwise it
Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)
Thanks Mark. Much appreciated.
On Tue., Feb. 8, 2022, 04:06 Mark Thomas, wrote:
> Robert,
>
> Thank you for putting the effort in to debugging this. Narrowing down
> the issue to a simple test case is extremely helpful.
>
> The behaviour you describe looks odd to me. I'd expect consistent
> behaviour across platforms irrespective of the case sensitivity of the
> file system in use.
>
> I'm going to use your test case to investigate this further. I'll report
> back here with my findings - hopefully later today.
>
> Mark
>
>
> On 08/02/2022 03:29, Robert Turner wrote:
> > Okay, so I have finally narrowed it down the trivial failure case, and I
> > think I have an explanation as a result:
> >
> > [1] works (in docker), and [2] fails (in docker) but works outside. The
> > difference between the two is the import directive being a wildcard
> (ugly,
> > but historical in our app in some places we haven't yet cleaned up).
> >
> > I am therefore speculating based on the Expression Language specification
> > that because the class wasn't explicitly imported, it's not in the list
> of
> > available classes for static class resolution, and thus it fails.
> > Combine this with MacOS and Windows not caring about filename cases, and
> > Linux caring, then I suspect it's just matching differently in both
> cases.
> >
> > Workaround/fix would be:
> > - to ensure we explicitly import the class (instead or in addition to the
> > wildcard)
> > OR
> > - rename the attribute so it doesn't map directly to the class name.
> >
> >
> > So I think I can bring my overly-detailed thread to an end...unless my
> > guess at the reasoning is incorrect and someone has a better explanation.
> >
> > Thanks Rob S and Neil for having a look and providing suggestions -- in
> > part, it was something related to what you both said, but I believe in
> > different contexts than you expected.
> >
> > Robert
> >
> >
> > [1]
> > $ cat src/main/webapp/index.jsp
> > <%@page contentType="text/html" pageEncoding="UTF-8" isELIgnored="false"
> %>
> > <%@page import="com.example.rt.Failing" %>
> > <%
> > final Failing failing = null;
> > pageContext.setAttribute("failing", failing);
> > %>
> >
> >
> > Hello World!
> >
> > field1=${failing.field1}
> >
> >
> > [2]
> > $ cat src/main/webapp/index.jsp
> > <%@page contentType="text/html" pageEncoding="UTF-8" isELIgnored="false"
> %>
> > <%@page import="com.example.rt.*" %>
> > <%
> > final Failing failing = null;
> > pageContext.setAttribute("failing", failing);
> > %>
> >
> >
> > Hello World!
> >
> > field1=${failing.field1}
> >
> >
> >
> >
> > On Mon, Feb 7, 2022 at 10:14 PM Robert Turner
> wrote:
> >
> >> So back to a divide and conquer approach I think.
> >>
> >> I just created a trivial "example" [1] and it works as expected (i.e. no
> >> exception was generated) (on the same servers I was testing the complex
> JAR
> >> file) -- so possibly something else modifying the behaviour -- a JAR on
> the
> >> classpath, or something in the JSP file...
> >>
> >> [1]
> >>
> >> $ cat src/main/webapp/index.jsp
> >> <%@page contentType="text/html" pageEncoding="UTF-8"
> isELIgnored="false" %>
> >> <%@page import="com.example.rt.Failing"%>
> >> <%
> >> final Failing failing = null;
> >> pageContext.setAttribute("failing", failing);
> >> %>
> >>
> >>
> >> Hello World!
> >>
> >> field1=${failing.field1}
> >>
> >>
> >>
> >> $ cat src/main/java/com/example/rt/Failing.java
> >> package com.example.rt;
> >>
> >> public class Failing {
> >>
> >> private final String field1 = "field1_value";
> >>
> >> public String getField1() {
> >> return field1;
> >> }
> >>
> >> }
> >>
> >>
> >>
> >> On Mon, Feb 7, 2022 at 9:51 PM Robert Turner
> wrote:
> >>
> >>> I'm just avoiding sharing product details or things I think only serves
> >>> to confuse the problem. Sorry if you felt I wasn't sharing. It wasn't
> my
> >>> intention to be obtuse. I didn't believe they added any value for the
> >>> diagnostics (of course that assumes I know enough about the problem).
> >>>
> >>> However, since you think they might be useful, here they the name
> mapping
> >>> from the exception and the Java and JSP code excerpts:
> >>>
> >>>"package1" -> "model"
> >>>"Class1" -> "Organization"
> >>>"class1" -> "organization"
> >>>
> >>> The class is present in the package (see [1]) -- otherwise it wouldn't
> >>> work in one environment and not the other -- I believe I have confirmed
> >>> that carefully. Full class paths (with path-names relativised to
> compare
> >>> between environments) listed below [2], and the code that emitted the
> >>> listing is here [3]. I post-processed the log lines as follows [4].
> Docker
> >>> file for the Tomcat container provided [5]. JDK details listed in [6].
> >>> Tomcat version is 9.0.58 in all cases.
> >>>
> >>> What seems to be different is:
> >>> - the way the EL resolver is working
> >>> OR
> >>> - the behaviour of the class loader
Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)
Robert,
Thank you for putting the effort in to debugging this. Narrowing down
the issue to a simple test case is extremely helpful.
The behaviour you describe looks odd to me. I'd expect consistent
behaviour across platforms irrespective of the case sensitivity of the
file system in use.
I'm going to use your test case to investigate this further. I'll report
back here with my findings - hopefully later today.
Mark
On 08/02/2022 03:29, Robert Turner wrote:
Okay, so I have finally narrowed it down the trivial failure case, and I
think I have an explanation as a result:
[1] works (in docker), and [2] fails (in docker) but works outside. The
difference between the two is the import directive being a wildcard (ugly,
but historical in our app in some places we haven't yet cleaned up).
I am therefore speculating based on the Expression Language specification
that because the class wasn't explicitly imported, it's not in the list of
available classes for static class resolution, and thus it fails.
Combine this with MacOS and Windows not caring about filename cases, and
Linux caring, then I suspect it's just matching differently in both cases.
Workaround/fix would be:
- to ensure we explicitly import the class (instead or in addition to the
wildcard)
OR
- rename the attribute so it doesn't map directly to the class name.
So I think I can bring my overly-detailed thread to an end...unless my
guess at the reasoning is incorrect and someone has a better explanation.
Thanks Rob S and Neil for having a look and providing suggestions -- in
part, it was something related to what you both said, but I believe in
different contexts than you expected.
Robert
[1]
$ cat src/main/webapp/index.jsp
<%@page contentType="text/html" pageEncoding="UTF-8" isELIgnored="false" %>
<%@page import="com.example.rt.Failing" %>
<%
final Failing failing = null;
pageContext.setAttribute("failing", failing);
%>
Hello World!
field1=${failing.field1}
[2]
$ cat src/main/webapp/index.jsp
<%@page contentType="text/html" pageEncoding="UTF-8" isELIgnored="false" %>
<%@page import="com.example.rt.*" %>
<%
final Failing failing = null;
pageContext.setAttribute("failing", failing);
%>
Hello World!
field1=${failing.field1}
On Mon, Feb 7, 2022 at 10:14 PM Robert Turner wrote:
So back to a divide and conquer approach I think.
I just created a trivial "example" [1] and it works as expected (i.e. no
exception was generated) (on the same servers I was testing the complex JAR
file) -- so possibly something else modifying the behaviour -- a JAR on the
classpath, or something in the JSP file...
[1]
$ cat src/main/webapp/index.jsp
<%@page contentType="text/html" pageEncoding="UTF-8" isELIgnored="false" %>
<%@page import="com.example.rt.Failing"%>
<%
final Failing failing = null;
pageContext.setAttribute("failing", failing);
%>
Hello World!
field1=${failing.field1}
$ cat src/main/java/com/example/rt/Failing.java
package com.example.rt;
public class Failing {
private final String field1 = "field1_value";
public String getField1() {
return field1;
}
}
On Mon, Feb 7, 2022 at 9:51 PM Robert Turner wrote:
I'm just avoiding sharing product details or things I think only serves
to confuse the problem. Sorry if you felt I wasn't sharing. It wasn't my
intention to be obtuse. I didn't believe they added any value for the
diagnostics (of course that assumes I know enough about the problem).
However, since you think they might be useful, here they the name mapping
from the exception and the Java and JSP code excerpts:
"package1" -> "model"
"Class1" -> "Organization"
"class1" -> "organization"
The class is present in the package (see [1]) -- otherwise it wouldn't
work in one environment and not the other -- I believe I have confirmed
that carefully. Full class paths (with path-names relativised to compare
between environments) listed below [2], and the code that emitted the
listing is here [3]. I post-processed the log lines as follows [4]. Docker
file for the Tomcat container provided [5]. JDK details listed in [6].
Tomcat version is 9.0.58 in all cases.
What seems to be different is:
- the way the EL resolver is working
OR
- the behaviour of the class loader differs in the different
environments.
OR
- something else I do not understand is relevant
The working environments are MacOS and Windows, and the failing
environment is either Debian or AWS Linux 2 running in a docker container.
If the class loaders behaviour differently, then that could explain the
issues, however, that would surprise me if they differed in any material
way on the different platforms.
I hope that helps provide more detail that might be useful...
Robert
[1]
$ unzip -l target/app.war | grep "model\/Organization\.class"
66246 02-07-2022 20:17 WEB-INF/classes/model/Organization.class
[2]
java.class.path=/bin/bootstrap.jar:/bin/tomcat-juli.jar
Class loader URLs:
Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)
Okay, so I have finally narrowed it down the trivial failure case, and I
think I have an explanation as a result:
[1] works (in docker), and [2] fails (in docker) but works outside. The
difference between the two is the import directive being a wildcard (ugly,
but historical in our app in some places we haven't yet cleaned up).
I am therefore speculating based on the Expression Language specification
that because the class wasn't explicitly imported, it's not in the list of
available classes for static class resolution, and thus it fails.
Combine this with MacOS and Windows not caring about filename cases, and
Linux caring, then I suspect it's just matching differently in both cases.
Workaround/fix would be:
- to ensure we explicitly import the class (instead or in addition to the
wildcard)
OR
- rename the attribute so it doesn't map directly to the class name.
So I think I can bring my overly-detailed thread to an end...unless my
guess at the reasoning is incorrect and someone has a better explanation.
Thanks Rob S and Neil for having a look and providing suggestions -- in
part, it was something related to what you both said, but I believe in
different contexts than you expected.
Robert
[1]
$ cat src/main/webapp/index.jsp
<%@page contentType="text/html" pageEncoding="UTF-8" isELIgnored="false" %>
<%@page import="com.example.rt.Failing" %>
<%
final Failing failing = null;
pageContext.setAttribute("failing", failing);
%>
Hello World!
field1=${failing.field1}
[2]
$ cat src/main/webapp/index.jsp
<%@page contentType="text/html" pageEncoding="UTF-8" isELIgnored="false" %>
<%@page import="com.example.rt.*" %>
<%
final Failing failing = null;
pageContext.setAttribute("failing", failing);
%>
Hello World!
field1=${failing.field1}
On Mon, Feb 7, 2022 at 10:14 PM Robert Turner wrote:
> So back to a divide and conquer approach I think.
>
> I just created a trivial "example" [1] and it works as expected (i.e. no
> exception was generated) (on the same servers I was testing the complex JAR
> file) -- so possibly something else modifying the behaviour -- a JAR on the
> classpath, or something in the JSP file...
>
> [1]
>
> $ cat src/main/webapp/index.jsp
> <%@page contentType="text/html" pageEncoding="UTF-8" isELIgnored="false" %>
> <%@page import="com.example.rt.Failing"%>
> <%
> final Failing failing = null;
> pageContext.setAttribute("failing", failing);
> %>
>
>
> Hello World!
>
> field1=${failing.field1}
>
>
>
> $ cat src/main/java/com/example/rt/Failing.java
> package com.example.rt;
>
> public class Failing {
>
> private final String field1 = "field1_value";
>
> public String getField1() {
> return field1;
> }
>
> }
>
>
>
> On Mon, Feb 7, 2022 at 9:51 PM Robert Turner wrote:
>
>> I'm just avoiding sharing product details or things I think only serves
>> to confuse the problem. Sorry if you felt I wasn't sharing. It wasn't my
>> intention to be obtuse. I didn't believe they added any value for the
>> diagnostics (of course that assumes I know enough about the problem).
>>
>> However, since you think they might be useful, here they the name mapping
>> from the exception and the Java and JSP code excerpts:
>>
>> "package1" -> "model"
>> "Class1" -> "Organization"
>> "class1" -> "organization"
>>
>> The class is present in the package (see [1]) -- otherwise it wouldn't
>> work in one environment and not the other -- I believe I have confirmed
>> that carefully. Full class paths (with path-names relativised to compare
>> between environments) listed below [2], and the code that emitted the
>> listing is here [3]. I post-processed the log lines as follows [4]. Docker
>> file for the Tomcat container provided [5]. JDK details listed in [6].
>> Tomcat version is 9.0.58 in all cases.
>>
>> What seems to be different is:
>> - the way the EL resolver is working
>> OR
>> - the behaviour of the class loader differs in the different
>> environments.
>> OR
>> - something else I do not understand is relevant
>>
>> The working environments are MacOS and Windows, and the failing
>> environment is either Debian or AWS Linux 2 running in a docker container.
>> If the class loaders behaviour differently, then that could explain the
>> issues, however, that would surprise me if they differed in any material
>> way on the different platforms.
>>
>> I hope that helps provide more detail that might be useful...
>>
>> Robert
>>
>>
>> [1]
>> $ unzip -l target/app.war | grep "model\/Organization\.class"
>> 66246 02-07-2022 20:17 WEB-INF/classes/model/Organization.class
>>
>>
>> [2]
>> java.class.path=/bin/bootstrap.jar:/bin/tomcat-juli.jar
>> Class loader URLs:
>> Class loader name=org.apache.catalina.loader.ParallelWebappClassLoader,
>> URL count=146
>> URL=file:/WEB-INF/classes/
>> URL=file:/WEB-INF/lib/FastInfoset-1.2.18.jar
>> URL=file:/WEB-INF/lib/SparseBitSet-1.2.jar
>> URL=file:/WEB-INF/lib/VeracodeAnnotations-1.2.1.jar
>>
Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)
So back to a divide and conquer approach I think.
I just created a trivial "example" [1] and it works as expected (i.e. no
exception was generated) (on the same servers I was testing the complex JAR
file) -- so possibly something else modifying the behaviour -- a JAR on the
classpath, or something in the JSP file...
[1]
$ cat src/main/webapp/index.jsp
<%@page contentType="text/html" pageEncoding="UTF-8" isELIgnored="false" %>
<%@page import="com.example.rt.Failing"%>
<%
final Failing failing = null;
pageContext.setAttribute("failing", failing);
%>
Hello World!
field1=${failing.field1}
$ cat src/main/java/com/example/rt/Failing.java
package com.example.rt;
public class Failing {
private final String field1 = "field1_value";
public String getField1() {
return field1;
}
}
On Mon, Feb 7, 2022 at 9:51 PM Robert Turner wrote:
> I'm just avoiding sharing product details or things I think only serves to
> confuse the problem. Sorry if you felt I wasn't sharing. It wasn't my
> intention to be obtuse. I didn't believe they added any value for the
> diagnostics (of course that assumes I know enough about the problem).
>
> However, since you think they might be useful, here they the name mapping
> from the exception and the Java and JSP code excerpts:
>
> "package1" -> "model"
> "Class1" -> "Organization"
> "class1" -> "organization"
>
> The class is present in the package (see [1]) -- otherwise it wouldn't
> work in one environment and not the other -- I believe I have confirmed
> that carefully. Full class paths (with path-names relativised to compare
> between environments) listed below [2], and the code that emitted the
> listing is here [3]. I post-processed the log lines as follows [4]. Docker
> file for the Tomcat container provided [5]. JDK details listed in [6].
> Tomcat version is 9.0.58 in all cases.
>
> What seems to be different is:
> - the way the EL resolver is working
> OR
> - the behaviour of the class loader differs in the different environments.
> OR
> - something else I do not understand is relevant
>
> The working environments are MacOS and Windows, and the failing
> environment is either Debian or AWS Linux 2 running in a docker container.
> If the class loaders behaviour differently, then that could explain the
> issues, however, that would surprise me if they differed in any material
> way on the different platforms.
>
> I hope that helps provide more detail that might be useful...
>
> Robert
>
>
> [1]
> $ unzip -l target/app.war | grep "model\/Organization\.class"
> 66246 02-07-2022 20:17 WEB-INF/classes/model/Organization.class
>
>
> [2]
> java.class.path=/bin/bootstrap.jar:/bin/tomcat-juli.jar
> Class loader URLs:
> Class loader name=org.apache.catalina.loader.ParallelWebappClassLoader,
> URL count=146
> URL=file:/WEB-INF/classes/
> URL=file:/WEB-INF/lib/FastInfoset-1.2.18.jar
> URL=file:/WEB-INF/lib/SparseBitSet-1.2.jar
> URL=file:/WEB-INF/lib/VeracodeAnnotations-1.2.1.jar
> URL=file:/WEB-INF/lib/activation-1.1.jar
> URL=file:/WEB-INF/lib/animal-sniffer-annotations-1.20.jar
> URL=file:/WEB-INF/lib/annotations-4.1.1.4.jar
> URL=file:/WEB-INF/lib/api-common-2.0.1.jar
> URL=file:/WEB-INF/lib/auto-value-annotations-1.8.2.jar
> URL=file:/WEB-INF/lib/avatax-rest-v2-api-java_2.11-21.12.1.jar
> URL=file:/WEB-INF/lib/aws-java-sdk-core-1.12.145.jar
> URL=file:/WEB-INF/lib/aws-java-sdk-kms-1.12.145.jar
> URL=file:/WEB-INF/lib/aws-java-sdk-s3-1.12.145.jar
> URL=file:/WEB-INF/lib/bcmail-jdk15on-1.70.jar
> URL=file:/WEB-INF/lib/bcpkix-jdk15on-1.70.jar
> URL=file:/WEB-INF/lib/bcprov-jdk15on-1.70.jar
> URL=file:/WEB-INF/lib/bcutil-jdk15on-1.70.jar
> URL=file:/WEB-INF/lib/castor-core-1.4.1.jar
> URL=file:/WEB-INF/lib/castor-xml-1.4.1.jar
> URL=file:/WEB-INF/lib/checker-qual-3.5.0.jar
> URL=file:/WEB-INF/lib/commons-beanutils-1.9.4.jar
> URL=file:/WEB-INF/lib/commons-codec-1.15.jar
> URL=file:/WEB-INF/lib/commons-collections-3.2.2.jar
> URL=file:/WEB-INF/lib/commons-collections4-4.4.jar
> URL=file:/WEB-INF/lib/commons-compress-1.21.jar
> URL=file:/WEB-INF/lib/commons-digester-2.1.jar
> URL=file:/WEB-INF/lib/commons-fileupload-1.4.jar
> URL=file:/WEB-INF/lib/commons-io-2.11.0.jar
> URL=file:/WEB-INF/lib/commons-lang3-3.12.0.jar
> URL=file:/WEB-INF/lib/commons-logging-1.2.jar
> URL=file:/WEB-INF/lib/commons-math3-3.6.1.jar
> URL=file:/WEB-INF/lib/commons-text-1.9.jar
> URL=file:/WEB-INF/lib/conscrypt-openjdk-uber-2.5.1.jar
> URL=file:/WEB-INF/lib/curvesapi-1.06.jar
> URL=file:/WEB-INF/lib/ecj-3.21.0.jar
> URL=file:/WEB-INF/lib/encoder-1.2.3.jar
> URL=file:/WEB-INF/lib/encoder-jsp-1.2.3.jar
> URL=file:/WEB-INF/lib/error_prone_annotations-2.9.0.jar
> URL=file:/WEB-INF/lib/failureaccess-1.0.1.jar
> URL=file:/WEB-INF/lib/fontbox-2.0.25.jar
> URL=file:/WEB-INF/lib/gax-2.3.0.jar
>
Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)
I'm just avoiding sharing product details or things I think only serves to confuse the problem. Sorry if you felt I wasn't sharing. It wasn't my intention to be obtuse. I didn't believe they added any value for the diagnostics (of course that assumes I know enough about the problem). However, since you think they might be useful, here they the name mapping from the exception and the Java and JSP code excerpts: "package1" -> "model" "Class1" -> "Organization" "class1" -> "organization" The class is present in the package (see [1]) -- otherwise it wouldn't work in one environment and not the other -- I believe I have confirmed that carefully. Full class paths (with path-names relativised to compare between environments) listed below [2], and the code that emitted the listing is here [3]. I post-processed the log lines as follows [4]. Docker file for the Tomcat container provided [5]. JDK details listed in [6]. Tomcat version is 9.0.58 in all cases. What seems to be different is: - the way the EL resolver is working OR - the behaviour of the class loader differs in the different environments. OR - something else I do not understand is relevant The working environments are MacOS and Windows, and the failing environment is either Debian or AWS Linux 2 running in a docker container. If the class loaders behaviour differently, then that could explain the issues, however, that would surprise me if they differed in any material way on the different platforms. I hope that helps provide more detail that might be useful... Robert [1] $ unzip -l target/app.war | grep "model\/Organization\.class" 66246 02-07-2022 20:17 WEB-INF/classes/model/Organization.class [2] java.class.path=/bin/bootstrap.jar:/bin/tomcat-juli.jar Class loader URLs: Class loader name=org.apache.catalina.loader.ParallelWebappClassLoader, URL count=146 URL=file:/WEB-INF/classes/ URL=file:/WEB-INF/lib/FastInfoset-1.2.18.jar URL=file:/WEB-INF/lib/SparseBitSet-1.2.jar URL=file:/WEB-INF/lib/VeracodeAnnotations-1.2.1.jar URL=file:/WEB-INF/lib/activation-1.1.jar URL=file:/WEB-INF/lib/animal-sniffer-annotations-1.20.jar URL=file:/WEB-INF/lib/annotations-4.1.1.4.jar URL=file:/WEB-INF/lib/api-common-2.0.1.jar URL=file:/WEB-INF/lib/auto-value-annotations-1.8.2.jar URL=file:/WEB-INF/lib/avatax-rest-v2-api-java_2.11-21.12.1.jar URL=file:/WEB-INF/lib/aws-java-sdk-core-1.12.145.jar URL=file:/WEB-INF/lib/aws-java-sdk-kms-1.12.145.jar URL=file:/WEB-INF/lib/aws-java-sdk-s3-1.12.145.jar URL=file:/WEB-INF/lib/bcmail-jdk15on-1.70.jar URL=file:/WEB-INF/lib/bcpkix-jdk15on-1.70.jar URL=file:/WEB-INF/lib/bcprov-jdk15on-1.70.jar URL=file:/WEB-INF/lib/bcutil-jdk15on-1.70.jar URL=file:/WEB-INF/lib/castor-core-1.4.1.jar URL=file:/WEB-INF/lib/castor-xml-1.4.1.jar URL=file:/WEB-INF/lib/checker-qual-3.5.0.jar URL=file:/WEB-INF/lib/commons-beanutils-1.9.4.jar URL=file:/WEB-INF/lib/commons-codec-1.15.jar URL=file:/WEB-INF/lib/commons-collections-3.2.2.jar URL=file:/WEB-INF/lib/commons-collections4-4.4.jar URL=file:/WEB-INF/lib/commons-compress-1.21.jar URL=file:/WEB-INF/lib/commons-digester-2.1.jar URL=file:/WEB-INF/lib/commons-fileupload-1.4.jar URL=file:/WEB-INF/lib/commons-io-2.11.0.jar URL=file:/WEB-INF/lib/commons-lang3-3.12.0.jar URL=file:/WEB-INF/lib/commons-logging-1.2.jar URL=file:/WEB-INF/lib/commons-math3-3.6.1.jar URL=file:/WEB-INF/lib/commons-text-1.9.jar URL=file:/WEB-INF/lib/conscrypt-openjdk-uber-2.5.1.jar URL=file:/WEB-INF/lib/curvesapi-1.06.jar URL=file:/WEB-INF/lib/ecj-3.21.0.jar URL=file:/WEB-INF/lib/encoder-1.2.3.jar URL=file:/WEB-INF/lib/encoder-jsp-1.2.3.jar URL=file:/WEB-INF/lib/error_prone_annotations-2.9.0.jar URL=file:/WEB-INF/lib/failureaccess-1.0.1.jar URL=file:/WEB-INF/lib/fontbox-2.0.25.jar URL=file:/WEB-INF/lib/gax-2.3.0.jar URL=file:/WEB-INF/lib/gax-grpc-2.3.0.jar URL=file:/WEB-INF/lib/gmbal-api-only-4.0.3.jar URL=file:/WEB-INF/lib/google-auth-library-credentials-1.1.0.jar URL=file:/WEB-INF/lib/google-auth-library-oauth2-http-1.1.0.jar URL=file:/WEB-INF/lib/google-cloud-speech-1.30.5.jar URL=file:/WEB-INF/lib/google-http-client-1.39.2.jar URL=file:/WEB-INF/lib/google-http-client-gson-1.39.2.jar URL=file:/WEB-INF/lib/googleauth-1.5.0.jar URL=file:/WEB-INF/lib/grpc-alts-1.40.0.jar URL=file:/WEB-INF/lib/grpc-api-1.40.0.jar URL=file:/WEB-INF/lib/grpc-auth-1.40.0.jar URL=file:/WEB-INF/lib/grpc-context-1.40.0.jar URL=file:/WEB-INF/lib/grpc-core-1.40.0.jar URL=file:/WEB-INF/lib/grpc-grpclb-1.40.0.jar URL=file:/WEB-INF/lib/grpc-netty-shaded-1.40.0.jar URL=file:/WEB-INF/lib/grpc-protobuf-1.40.0.jar URL=file:/WEB-INF/lib/grpc-protobuf-lite-1.40.0.jar URL=file:/WEB-INF/lib/grpc-stub-1.40.0.jar URL=file:/WEB-INF/lib/gson-2.8.9.jar URL=file:/WEB-INF/lib/guava-31.0.1-jre.jar
Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)
On 2/7/22 19:13, Robert Turner wrote: So, I've gone back and double-checked as much as I can (Tomcat version, JDK version), and the classpath, and I have identical classpaths in both environments (except the sort order of the URLs per "level" of ClassLoader), and I've re-verified the behaviour: - fails in the docker environment - works locally (Same WAR file on both). I guess I'm in to one of the following approaches next: - build a debug version of Tomcat, and step through the code that breaks and see if I can figure out why (not that I have time to do this of course...but might be necessary) - construct a trivial application reproduction, along with docker layout, and see if anyone else can reproduce... (assuming anyone else has time to do that of course...) Anyone got any suggestions of what to look into next? On Mon, Feb 7, 2022 at 5:05 PM Rob Sargent wrote: As you appear averse to sharing names of things, seems you will need to do a lot of extra clean-up before you can share a docker image. Make sure you're clear on what NoClassDefFoundError indicates (present at compile time, absent at runtime) and how that translates to docker-ness (of which I know naught). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)
So, I've gone back and double-checked as much as I can (Tomcat version, JDK
version), and the classpath, and I have identical classpaths in both
environments (except the sort order of the URLs per "level" of
ClassLoader), and I've re-verified the behaviour:
- fails in the docker environment
- works locally
(Same WAR file on both).
I guess I'm in to one of the following approaches next:
- build a debug version of Tomcat, and step through the code that breaks
and see if I can figure out why (not that I have time to do this of
course...but might be necessary)
- construct a trivial application reproduction, along with docker layout,
and see if anyone else can reproduce... (assuming anyone else has time to
do that of course...)
Anyone got any suggestions of what to look into next?
On Mon, Feb 7, 2022 at 5:05 PM Rob Sargent wrote:
>
>
> On 2/7/22 14:50, Robert Turner wrote:
> > All
> >
> > I'm hoping that someone can point me in the right direction as this issue
> > has been baffling me all day, and I'm starting to run out of ideas of
> what
> > to look at next.
> >
> > The logic below is working without issue until I move our test
> environment
> > into a Docker container. I'm using the same Tomcat version, and the same
> > JDK in both the container and the non-container environments.
> >
> >
> > I've got some EL in a JSP page, for example (simplified):
> >
> > ${class1.field}
> >
> >
> > And an attribute is set on the page context as follows:
> >
> > final package1.Class1 objectValue = ...; // either value object of Class1
> > or null
> > pageContext.setAttribute("class1", objectValue);
> >
> >
> > Now, when objectValue is pointing to a valid object, everything is okay.
> > But when objectValue is null, this is where things get peculiar (and I
> get
> > both a working and non-working behaviour in the different environments).
> >
> > I can easily work around the issue by changing the EL to:
> >
> >${not empty class1 ? class1.field : ''$}
> >
> > But it is my understanding that EL should handle nulls on it's own, and
> > this shouldn't be necessary.
> >
> >
> > In the failure situation in the docker container, I'm seeing a
> > NoClassDefFoundError exception for "package1/Class1" below [1] during the
> > JSP page "rendering". Things work fine outside the docker container.
> >
> >
> > It might be worth noting that in my case, the attribute name is of the
> same
> > name as the actual class (with the first letter being lowercase for the
> > attribute instead of uppercase in the class).
> >
> > Note that I've also replaced my actual package name and class names with
> > "package1" and "Class1", and the attribute name with "class", but they
> > translate 1-to-1 as in what I've provided here and do not use reserved
> > names.
> >
> >
> > I've done a bit of digging into the EL scope resolution code in Tomcat,
> and
> > I'm suspecting it might be related to how it chooses the scope of the
> > object. Possibly related to maybe looking for static aspects of the
> class,
> > or something like that. After reviewing the Servlet / JSP / EL
> > documentation, I also haven't found anything obvious that would suggest
> > what the problem might be.
> >
> > Hopefully someone has encountered this before and can nudge me in the
> right
> > direction.
> >
> > Thanks in advance,
> >
> > Robert
> >
> >
> >
> > [1]
> > Caused by: java.lang.NoClassDefFoundError: package1/Class1 (wrong name:
> > package1/class1)
> > at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> > at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017)
> > at
> >
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)
> > at
> >
> org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:2478)
> > at
> >
> org.apache.catalina.loader.WebappClassLoaderBase.findClass(WebappClassLoaderBase.java:870)
> > at
> >
> org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1371)
> > at
> >
> org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1215)
> > at javax.el.ImportHandler.findClass(ImportHandler.java:477)
> > at javax.el.ImportHandler.resolveClass(ImportHandler.java:421)
> > at
> >
> javax.servlet.jsp.el.ScopedAttributeELResolver.getValue(ScopedAttributeELResolver.java:85)
> > at
> org.apache.jasper.el.JasperELResolver.getValue(JasperELResolver.java:124)
> > at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:93)
> > at org.apache.el.parser.AstValue.getValue(AstValue.java:136)
> > at org.apache.el.parser.AstFunction.getValue(AstFunction.java:188)
> > at
> org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:189)
> > at
> >
> org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContextImpl.java:692)
> > at
> >
> And you're sure package1 is on the classpath of the docker version?
>
>
> -
> To
Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)
Neil, I'm not actually trying to have the class loaded. I want it to return "null" in the EL evaluation as though the attribute is missing. The "problem" is that I'm seeing a different behaviour in one environment than another, and it's proving difficult to track down why. I'm still working on the class path analysis as suggested by Rob S, even though the class in question should be in the class path in both cases. Thanks for the suggestion though. Robert On Mon, Feb 7, 2022 at 7:16 PM Neil Aggarwal wrote: > Robert: > > > Caused by: java.lang.NoClassDefFoundError: package1/Class1 (wrong name: > > package1/class1) > > This seems to be the source of your problem. > Java does not like that the case is different. > Make sure everything matches, including the capitals. > > Thank you, > Neil > > -- > Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com > We offer 30 year loans on single family houses! > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
RE: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)
Robert: > Caused by: java.lang.NoClassDefFoundError: package1/Class1 (wrong name: > package1/class1) This seems to be the source of your problem. Java does not like that the case is different. Make sure everything matches, including the capitals. Thank you, Neil -- Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com We offer 30 year loans on single family houses! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)
Okay, after further digging, here's where I'm at:
According to the specification (
https://download.oracle.com/javaee-archive/el-spec.java.net/users/att-0034/EL3.0.PFD.RC1.pdf),
section 1.22 suggests that if we have an import (which it seems we do --
legacy scriptlets code), that an expression containing a class name will be
resolved against the static members of the class.
So, as to why it is different between the two environments, maybe it's as
Rob S suggested (a classpath issue of some sort) -- I will continue looking
in this direction
On Mon, Feb 7, 2022 at 5:07 PM Robert Turner wrote:
> Yep -- I can use the same WAR in both cases, and it's a .class file in the
> WAR.
>
> I've also just figured out that if I rename the attribute from "class1" to
> "cl1", it works -- so it's something to do with the attribute name matching
> the class name.
>
> On Mon, Feb 7, 2022 at 5:05 PM Rob Sargent wrote:
>
>>
>>
>> On 2/7/22 14:50, Robert Turner wrote:
>> > All
>> >
>> > I'm hoping that someone can point me in the right direction as this
>> issue
>> > has been baffling me all day, and I'm starting to run out of ideas of
>> what
>> > to look at next.
>> >
>> > The logic below is working without issue until I move our test
>> environment
>> > into a Docker container. I'm using the same Tomcat version, and the same
>> > JDK in both the container and the non-container environments.
>> >
>> >
>> > I've got some EL in a JSP page, for example (simplified):
>> >
>> > ${class1.field}
>> >
>> >
>> > And an attribute is set on the page context as follows:
>> >
>> > final package1.Class1 objectValue = ...; // either value object of
>> Class1
>> > or null
>> > pageContext.setAttribute("class1", objectValue);
>> >
>> >
>> > Now, when objectValue is pointing to a valid object, everything is okay.
>> > But when objectValue is null, this is where things get peculiar (and I
>> get
>> > both a working and non-working behaviour in the different environments).
>> >
>> > I can easily work around the issue by changing the EL to:
>> >
>> >${not empty class1 ? class1.field : ''$}
>> >
>> > But it is my understanding that EL should handle nulls on it's own, and
>> > this shouldn't be necessary.
>> >
>> >
>> > In the failure situation in the docker container, I'm seeing a
>> > NoClassDefFoundError exception for "package1/Class1" below [1] during
>> the
>> > JSP page "rendering". Things work fine outside the docker container.
>> >
>> >
>> > It might be worth noting that in my case, the attribute name is of the
>> same
>> > name as the actual class (with the first letter being lowercase for the
>> > attribute instead of uppercase in the class).
>> >
>> > Note that I've also replaced my actual package name and class names with
>> > "package1" and "Class1", and the attribute name with "class", but they
>> > translate 1-to-1 as in what I've provided here and do not use reserved
>> > names.
>> >
>> >
>> > I've done a bit of digging into the EL scope resolution code in Tomcat,
>> and
>> > I'm suspecting it might be related to how it chooses the scope of the
>> > object. Possibly related to maybe looking for static aspects of the
>> class,
>> > or something like that. After reviewing the Servlet / JSP / EL
>> > documentation, I also haven't found anything obvious that would suggest
>> > what the problem might be.
>> >
>> > Hopefully someone has encountered this before and can nudge me in the
>> right
>> > direction.
>> >
>> > Thanks in advance,
>> >
>> > Robert
>> >
>> >
>> >
>> > [1]
>> > Caused by: java.lang.NoClassDefFoundError: package1/Class1 (wrong name:
>> > package1/class1)
>> > at java.base/java.lang.ClassLoader.defineClass1(Native Method)
>> > at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017)
>> > at
>> >
>> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)
>> > at
>> >
>> org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:2478)
>> > at
>> >
>> org.apache.catalina.loader.WebappClassLoaderBase.findClass(WebappClassLoaderBase.java:870)
>> > at
>> >
>> org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1371)
>> > at
>> >
>> org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1215)
>> > at javax.el.ImportHandler.findClass(ImportHandler.java:477)
>> > at javax.el.ImportHandler.resolveClass(ImportHandler.java:421)
>> > at
>> >
>> javax.servlet.jsp.el.ScopedAttributeELResolver.getValue(ScopedAttributeELResolver.java:85)
>> > at
>> org.apache.jasper.el.JasperELResolver.getValue(JasperELResolver.java:124)
>> > at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:93)
>> > at org.apache.el.parser.AstValue.getValue(AstValue.java:136)
>> > at org.apache.el.parser.AstFunction.getValue(AstFunction.java:188)
>> > at
>> org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:189)
>> > at
>> >
>>
Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)
Yep -- I can use the same WAR in both cases, and it's a .class file in the
WAR.
I've also just figured out that if I rename the attribute from "class1" to
"cl1", it works -- so it's something to do with the attribute name matching
the class name.
On Mon, Feb 7, 2022 at 5:05 PM Rob Sargent wrote:
>
>
> On 2/7/22 14:50, Robert Turner wrote:
> > All
> >
> > I'm hoping that someone can point me in the right direction as this issue
> > has been baffling me all day, and I'm starting to run out of ideas of
> what
> > to look at next.
> >
> > The logic below is working without issue until I move our test
> environment
> > into a Docker container. I'm using the same Tomcat version, and the same
> > JDK in both the container and the non-container environments.
> >
> >
> > I've got some EL in a JSP page, for example (simplified):
> >
> > ${class1.field}
> >
> >
> > And an attribute is set on the page context as follows:
> >
> > final package1.Class1 objectValue = ...; // either value object of Class1
> > or null
> > pageContext.setAttribute("class1", objectValue);
> >
> >
> > Now, when objectValue is pointing to a valid object, everything is okay.
> > But when objectValue is null, this is where things get peculiar (and I
> get
> > both a working and non-working behaviour in the different environments).
> >
> > I can easily work around the issue by changing the EL to:
> >
> >${not empty class1 ? class1.field : ''$}
> >
> > But it is my understanding that EL should handle nulls on it's own, and
> > this shouldn't be necessary.
> >
> >
> > In the failure situation in the docker container, I'm seeing a
> > NoClassDefFoundError exception for "package1/Class1" below [1] during the
> > JSP page "rendering". Things work fine outside the docker container.
> >
> >
> > It might be worth noting that in my case, the attribute name is of the
> same
> > name as the actual class (with the first letter being lowercase for the
> > attribute instead of uppercase in the class).
> >
> > Note that I've also replaced my actual package name and class names with
> > "package1" and "Class1", and the attribute name with "class", but they
> > translate 1-to-1 as in what I've provided here and do not use reserved
> > names.
> >
> >
> > I've done a bit of digging into the EL scope resolution code in Tomcat,
> and
> > I'm suspecting it might be related to how it chooses the scope of the
> > object. Possibly related to maybe looking for static aspects of the
> class,
> > or something like that. After reviewing the Servlet / JSP / EL
> > documentation, I also haven't found anything obvious that would suggest
> > what the problem might be.
> >
> > Hopefully someone has encountered this before and can nudge me in the
> right
> > direction.
> >
> > Thanks in advance,
> >
> > Robert
> >
> >
> >
> > [1]
> > Caused by: java.lang.NoClassDefFoundError: package1/Class1 (wrong name:
> > package1/class1)
> > at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> > at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017)
> > at
> >
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)
> > at
> >
> org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:2478)
> > at
> >
> org.apache.catalina.loader.WebappClassLoaderBase.findClass(WebappClassLoaderBase.java:870)
> > at
> >
> org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1371)
> > at
> >
> org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1215)
> > at javax.el.ImportHandler.findClass(ImportHandler.java:477)
> > at javax.el.ImportHandler.resolveClass(ImportHandler.java:421)
> > at
> >
> javax.servlet.jsp.el.ScopedAttributeELResolver.getValue(ScopedAttributeELResolver.java:85)
> > at
> org.apache.jasper.el.JasperELResolver.getValue(JasperELResolver.java:124)
> > at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:93)
> > at org.apache.el.parser.AstValue.getValue(AstValue.java:136)
> > at org.apache.el.parser.AstFunction.getValue(AstFunction.java:188)
> > at
> org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:189)
> > at
> >
> org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContextImpl.java:692)
> > at
> >
> And you're sure package1 is on the classpath of the docker version?
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)
On 2/7/22 14:50, Robert Turner wrote:
All
I'm hoping that someone can point me in the right direction as this issue
has been baffling me all day, and I'm starting to run out of ideas of what
to look at next.
The logic below is working without issue until I move our test environment
into a Docker container. I'm using the same Tomcat version, and the same
JDK in both the container and the non-container environments.
I've got some EL in a JSP page, for example (simplified):
${class1.field}
And an attribute is set on the page context as follows:
final package1.Class1 objectValue = ...; // either value object of Class1
or null
pageContext.setAttribute("class1", objectValue);
Now, when objectValue is pointing to a valid object, everything is okay.
But when objectValue is null, this is where things get peculiar (and I get
both a working and non-working behaviour in the different environments).
I can easily work around the issue by changing the EL to:
${not empty class1 ? class1.field : ''$}
But it is my understanding that EL should handle nulls on it's own, and
this shouldn't be necessary.
In the failure situation in the docker container, I'm seeing a
NoClassDefFoundError exception for "package1/Class1" below [1] during the
JSP page "rendering". Things work fine outside the docker container.
It might be worth noting that in my case, the attribute name is of the same
name as the actual class (with the first letter being lowercase for the
attribute instead of uppercase in the class).
Note that I've also replaced my actual package name and class names with
"package1" and "Class1", and the attribute name with "class", but they
translate 1-to-1 as in what I've provided here and do not use reserved
names.
I've done a bit of digging into the EL scope resolution code in Tomcat, and
I'm suspecting it might be related to how it chooses the scope of the
object. Possibly related to maybe looking for static aspects of the class,
or something like that. After reviewing the Servlet / JSP / EL
documentation, I also haven't found anything obvious that would suggest
what the problem might be.
Hopefully someone has encountered this before and can nudge me in the right
direction.
Thanks in advance,
Robert
[1]
Caused by: java.lang.NoClassDefFoundError: package1/Class1 (wrong name:
package1/class1)
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017)
at
java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)
at
org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:2478)
at
org.apache.catalina.loader.WebappClassLoaderBase.findClass(WebappClassLoaderBase.java:870)
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1371)
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1215)
at javax.el.ImportHandler.findClass(ImportHandler.java:477)
at javax.el.ImportHandler.resolveClass(ImportHandler.java:421)
at
javax.servlet.jsp.el.ScopedAttributeELResolver.getValue(ScopedAttributeELResolver.java:85)
at org.apache.jasper.el.JasperELResolver.getValue(JasperELResolver.java:124)
at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:93)
at org.apache.el.parser.AstValue.getValue(AstValue.java:136)
at org.apache.el.parser.AstFunction.getValue(AstFunction.java:188)
at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:189)
at
org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContextImpl.java:692)
at
And you're sure package1 is on the classpath of the docker version?
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
