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
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
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
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
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:
>
>
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.
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
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,
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),
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,
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
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
>
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.
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
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
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,
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
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
-
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
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)
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
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
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
23 matches
Mail list logo
