Re: Tomcat 9 symlinks ?

[Robert Turner]

This page might be a useful resource to read if you haven't already:
https://tomcat.apache.org/tomcat-9.0-doc/config/context.html

The short version is -- to publish an application in the "root" web url
path (of http(s)://your.server-name.com/), you can name your WAR file
"ROOT.war" and copy it to the /webapps folder. Tomcat will
extract it into a folder called "ROOT", but this is not a subfolder called
"ROOT" when served to clients, it's served as "/".

Nothing else needs doing to map paths -- nothing really on your context, or
any system config file, etc.

On Wed, Jun 19, 2024 at 4:17 PM Stephen Tenberg 
wrote:

> Thank you.  Do we just rename the existing ROOT to something else so the
> admin stuff is available?  The path="" was appealing as we want this
> existing large application to be available as "/". Is renaming ROOT a
> better way of achieving this?
>
> On Wed, Jun 19, 2024 at 3:50 PM Chuck Caldarale  wrote:
>
> >
> > > On Jun 19, 2024, at 14:42, Stephen Tenberg 
> > wrote:
> > >
> > > You asked why  path="" instead of path="foo" in context at server.xml?
> > >
> > > That was our attempt to mount this application at "/" instead of at
> > "/foo"
> > > which is a requirement here.
> >
> >
> > Just deploy the application as ROOT (case matters) rather than foo.
> >
> >   - Chuck
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
>

Re: HttpSession tracking

[Robert Turner]

Thanks for figuring it out -- I will keep that in mind when I go to split
our "mega session object" up as that will impact some of the decisions for
sure.

Yeah, I guess you end up with a "dummy object" on the session as a result
-- I guess we got lucky with ours -- our handlers on the session object
call out to a "singleton" for tracking, so we probably never really thought
too much about it. So if you have an object on the session already, it pays
to just extend it and call out to the "singleton" instead (like we have).

Some of the listener docs do often leave me wondering how exactly some of
them work (like who creates the object instance for this thing - like for
ServletContextListener).  Although the one  you quoted does seem to be
"clear enough" at least to me (not sure if your comments were sarcastic or
not). I'm not sure it's a good design though -- you would think session
listeners would be independent of the objects on the sessions. Hopefully
there was some logic behind the original design that isn't captured in the
code docs (well, I hope there was).

On Fri, Mar 22, 2024 at 2:02 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> All,
>
> On 3/22/24 09:59, Christopher Schultz wrote:
> > All,
> >
> > On 3/22/24 09:33, Robert Turner wrote:
> >> On Fri, Mar 22, 2024 at 9:28 AM Christopher Schultz <
> >> ch...@christopherschultz.net> wrote:
> >>
> >>> Robert,
> >>>
> >>> On 3/21/24 15:31, Robert Turner wrote:
> >>>> We receive the sessionWillPassivate and sessionDidActivate callbacks
> >>>> on startup. Odd that you are not. That's how we achieve the same.
> >>> On 3/21/24 16:21, Robert Turner wrote:
> >>>> Just to add a bit more information, our handler class, for better or
> >>>> for
> >>>> worse, implements the following interfaces all in one class:
> >>>>
> >>>>implements HttpSessionBindingListener,
> >>>> HttpSessionActivationListener,
> >>>> HttpSessionIdListener, HttpSessionListener, ServletContextListener
> >>>
> >>> Hmm.
> >>>
> >>> I'm already using HttpSessionListener and HttpSessionActivationListener
> >>> and logging every event I receive.
> >>>
> >>> HttpSessionIdListener only lets you know when ids are changed, and I
> >>> actually don't care about those events. I added it, and see no change
> in
> >>> behavior.
> >>>
> >>> HttpSessionBindingListener shouldn't do anything, here, as it will only
> >>> be called when objects are added or removed (and it only *that
> object*).
> >>> During activation and passivation, I wouldn't expect anything to be
> >>> added or removed.
> >>>
> >>> ServletContextListener wouldn't do anything in and of itself, except
> >>> possibly get the listener started earlier. I added it and do not see
> any
> >>> change in behavior.
> >>>
> >>>
> >> Yeah, I wasn't really suggesting adding all those listener interfaces --
> >> more just saying that's what we did in case somehow it made a difference
> >> for you. Certainly you shouldn't have to add them to get it to work.
> >>
> >>
> >>
> >>>> We also use that same class as our "session model" object that we
> >>>> bind as
> >>>> an attribute to the session itself (it's a bit of a mixed bag
> >>> historically
> >>>> that I want to clean up).
> >>>>
> >>>> And in terms of registration, we do not have any annotations on the
> >>> class,
> >>>> instead we register it in web.xml (in the application WAR file) using
> a
> >>>> standard listener entry:
> >>>>
> >>>> 
> >>>>   <>
> >>>> 
> >>>>
> >>>> Our web.xml is set at Servlet API version 3.0 (kind-of old), and we
> are
> >>>> running against Tomcat 9.5 (and this worked on 8.5 and before as
> well).
> >>>>
> >>>> Not sure if that adds anything Chris that you haven't already looked
> >>>> at.
> >>>
> >>> I believe mine is set up identically to yours at this point, except for
> >>> the HttpSessionBindingListener.
> >>>
> >>>> I would really prefer a way to query the sessions from the app, but
> >>>> as we
> >>>> know, that's not part of the curr

Re: HttpSession tracking

[Robert Turner]

On Fri, Mar 22, 2024 at 9:28 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Robert,
>
> On 3/21/24 15:31, Robert Turner wrote:
> > We receive the sessionWillPassivate and sessionDidActivate callbacks
> > on startup. Odd that you are not. That's how we achieve the same.
> On 3/21/24 16:21, Robert Turner wrote:
> > Just to add a bit more information, our handler class, for better or for
> > worse, implements the following interfaces all in one class:
> >
> >   implements HttpSessionBindingListener, HttpSessionActivationListener,
> > HttpSessionIdListener, HttpSessionListener, ServletContextListener
>
> Hmm.
>
> I'm already using HttpSessionListener and HttpSessionActivationListener
> and logging every event I receive.
>
> HttpSessionIdListener only lets you know when ids are changed, and I
> actually don't care about those events. I added it, and see no change in
> behavior.
>
> HttpSessionBindingListener shouldn't do anything, here, as it will only
> be called when objects are added or removed (and it only *that object*).
> During activation and passivation, I wouldn't expect anything to be
> added or removed.
>
> ServletContextListener wouldn't do anything in and of itself, except
> possibly get the listener started earlier. I added it and do not see any
> change in behavior.
>
>
Yeah, I wasn't really suggesting adding all those listener interfaces --
more just saying that's what we did in case somehow it made a difference
for you. Certainly you shouldn't have to add them to get it to work.



> > We also use that same class as our "session model" object that we bind as
> > an attribute to the session itself (it's a bit of a mixed bag
> historically
> > that I want to clean up).
> >
> > And in terms of registration, we do not have any annotations on the
> class,
> > instead we register it in web.xml (in the application WAR file) using a
> > standard listener entry:
> >
> > 
> >  <>
> > 
> >
> > Our web.xml is set at Servlet API version 3.0 (kind-of old), and we are
> > running against Tomcat 9.5 (and this worked on 8.5 and before as well).
> >
> > Not sure if that adds anything Chris that you haven't already looked at.
>
> I believe mine is set up identically to yours at this point, except for
> the HttpSessionBindingListener.
>
> > I would really prefer a way to query the sessions from the app, but as we
> > know, that's not part of the current Servlet specification, or any
> > extensions Tomcat currently provides.
>
> It wouldn't really be appropriate for Tomcat to provide any "extensions"
> like this because it would make applications reliant on capabilities
> that aren't standard. When companies do that, it's called "vendor
> lock-in" and it's not a good look for ASF.
>
>
Yeah, vendor lock-in isn't great -- and I wouldn't really suggest Tomcat
doing that either; it would be better in the Servlet specification, but I
doubt, for various reasons, it would get added.

Your case is certainly odd -- I suppose you might have to resort to firing
up a debugger and debug build and seeing what's going on in Tomcat...(at
least you are more used to doing that on Tomcat than most of us).

>
>

Re: HttpSession tracking

[Robert Turner]

Just to add a bit more information, our handler class, for better or for
worse, implements the following interfaces all in one class:

 implements HttpSessionBindingListener, HttpSessionActivationListener,
HttpSessionIdListener, HttpSessionListener, ServletContextListener

We also use that same class as our "session model" object that we bind as
an attribute to the session itself (it's a bit of a mixed bag historically
that I want to clean up).

And in terms of registration, we do not have any annotations on the class,
instead we register it in web.xml (in the application WAR file) using a
standard listener entry:


<>


Our web.xml is set at Servlet API version 3.0 (kind-of old), and we are
running against Tomcat 9.5 (and this worked on 8.5 and before as well).

Not sure if that adds anything Chris that you haven't already looked at.

I would really prefer a way to query the sessions from the app, but as we
know, that's not part of the current Servlet specification, or any
extensions Tomcat currently provides.

Robert



On Thu, Mar 21, 2024 at 3:31 PM Robert Turner  wrote:

> We receive the sessionWillPassivate and sessionDidActivate callbacks on
> startup. Odd that you are not. That's how we achieve the same.
>
> On Thu, Mar 21, 2024 at 3:25 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
>> All,
>>
>> After having written a solution using JMX to do something like this, I'd
>> like to make it cleaner and I'm not sure it's entirely possible using
>> just Servlet APIs.
>>
>> I'd like to be able to track every HttpSession for the application.
>>
>> for admin purposes, I'd like to be able to analyze:
>>
>> 1. The total number of sessions
>>
>> 2. The number of sessions which represent a logged-in user vs a
>> crawler-session or someone who visited the home-page and got a session
>> but never logged-in
>>
>> 3. Checking-out some specific roles of those logged-in users e.g.
>> end-user, staff, admin
>>
>> 4. Be able to kill a session at will. For example "chris is already
>> logged-in, kill his old session and let the new login remain"
>>
>> I started with the obvious HttpSessionListener +
>> HttpSessionActivationListener, but I tried this experiment and it didn't
>> turn out how I expected:
>>
>> 1. Start the application and hit the front page
>>
>> -> I get a call to HttpSessionListener.sessionCreated (expected)
>>
>> 2. Login
>>
>> 3. Logout
>>
>> -> I get a call to HttpSessionListener.sessionDestroyed (expected)
>> -> I get a call to HttpSessionListener.sessionCreated (expected)
>> (this second one happens because our home-page creates a session)
>>
>> 4. Login again
>>
>> 5. Stop Tomcat
>>
>> -> No calls to anything I can see
>>
>> 6. Start Tomcat
>>
>> -> No calls to anything I can see
>>
>> 7. Access a protected page
>>
>> -> Access is allowed; I'm still logged-in.
>>
>> When Tomcat shuts-down, it's saving the sessions using local
>> persistence[1]. When the application comes back up, all those sessions
>> are restored from the disk.
>>
>> When my HttpSeessionListener starts, it's empty and doesn't know about
>> any sessions. Tomcat doesn't notify it that any sessions are coming from
>> that storage.
>>
>> I would have expected calls to
>> HttpSessionActivationListener.sessionWillPassivate and
>> HttpSessionActivationListener.sessionDidActivate.
>>
>> Do I have unrealistic expectations? Is there a way to capture these
>> events so my in-memory session-watcher/manager is able to have an
>> accurate view of what Tomcat can see?
>>
>> Thanks,
>> -chris
>>
>> [1]
>>
>> https://tomcat.apache.org/tomcat-8.5-doc/config/manager.html#Persistence_Across_Restarts
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>

Re: HttpSession tracking

[Robert Turner]

We receive the sessionWillPassivate and sessionDidActivate callbacks on
startup. Odd that you are not. That's how we achieve the same.

On Thu, Mar 21, 2024 at 3:25 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> All,
>
> After having written a solution using JMX to do something like this, I'd
> like to make it cleaner and I'm not sure it's entirely possible using
> just Servlet APIs.
>
> I'd like to be able to track every HttpSession for the application.
>
> for admin purposes, I'd like to be able to analyze:
>
> 1. The total number of sessions
>
> 2. The number of sessions which represent a logged-in user vs a
> crawler-session or someone who visited the home-page and got a session
> but never logged-in
>
> 3. Checking-out some specific roles of those logged-in users e.g.
> end-user, staff, admin
>
> 4. Be able to kill a session at will. For example "chris is already
> logged-in, kill his old session and let the new login remain"
>
> I started with the obvious HttpSessionListener +
> HttpSessionActivationListener, but I tried this experiment and it didn't
> turn out how I expected:
>
> 1. Start the application and hit the front page
>
> -> I get a call to HttpSessionListener.sessionCreated (expected)
>
> 2. Login
>
> 3. Logout
>
> -> I get a call to HttpSessionListener.sessionDestroyed (expected)
> -> I get a call to HttpSessionListener.sessionCreated (expected)
> (this second one happens because our home-page creates a session)
>
> 4. Login again
>
> 5. Stop Tomcat
>
> -> No calls to anything I can see
>
> 6. Start Tomcat
>
> -> No calls to anything I can see
>
> 7. Access a protected page
>
> -> Access is allowed; I'm still logged-in.
>
> When Tomcat shuts-down, it's saving the sessions using local
> persistence[1]. When the application comes back up, all those sessions
> are restored from the disk.
>
> When my HttpSeessionListener starts, it's empty and doesn't know about
> any sessions. Tomcat doesn't notify it that any sessions are coming from
> that storage.
>
> I would have expected calls to
> HttpSessionActivationListener.sessionWillPassivate and
> HttpSessionActivationListener.sessionDidActivate.
>
> Do I have unrealistic expectations? Is there a way to capture these
> events so my in-memory session-watcher/manager is able to have an
> accurate view of what Tomcat can see?
>
> Thanks,
> -chris
>
> [1]
>
> https://tomcat.apache.org/tomcat-8.5-doc/config/manager.html#Persistence_Across_Restarts
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat SMPT TLS1.2

[Robert Turner]

You can define Java properties in one of the Tomcat files
(catalina.properties I believe), albeit it may depend on the OS /
deployment for your specific instance as some use different loaders -- the
default scripts "catalina.sh/bat" will use that file, but
some distributions load Tomcat differently.

On Mon, Mar 11, 2024 at 12:50 PM Brandie Nickey
 wrote:

> That makes sense,  I did see a file in our java mail jar called
> SocketFetcher that has a line to the extent saying 'if properties not set,
> use TLS 1.0 for smtp' .  My hope was to find where the heck to set the mail
> properties, but sounds like that's in another sun file.
>
> -Original Message-
> From: Ivano Luberti 
> Sent: Monday, March 11, 2024 9:46 AM
> To: users@tomcat.apache.org
> Subject: Re: Tomcat SMPT TLS1.2
>
> [You don't often get email from lube...@archicoop.it.invalid. Learn why
> this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> I had issues in the past connectin to mailserver using TLS and solved them
> upgrading the webapplicatio library from mail-1.4.jar to
> javax.mail-1.6.2.jar
>
> Il 11/03/2024 17:41, Robert Turner ha scritto:
> > AFAIK, there is nothing in Tomcat for SMTP. This would be part of the
> > application you are running typically. It's possible (but not
> > guaranteed) that the web application is using the standard Java
> > libraries for SMTP, and as such, you may (but again not guaranteed) be
> > able to configure some of the mail settings via Java system properties
> > (
> > https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-s
> > ummary.html
> > ).
> >
> > Best bet is to work with your application provider and their
> > documentation / support.
> >
> > Also, consider upgrading Java and Tomcat to current / supported
> > versions as those versions are both very old and likely have many
> > security issues that need patching.
> >
> >
> >
> > On Mon, Mar 11, 2024 at 12:39 PM Jost
> > Richstein
> > wrote:
> >
> >> Hi,
> >>
> >> this is definitely not a Tomcat problem - take a look at:
> >>
> >>
> >> https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-
> >> summary
> >> .html
> >> <https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package
> >> -summary.html>
> >>
> >>
> >> -Ursprüngliche Nachricht-
> >> Von: Brandie Nickey
> >> Gesendet: Montag, 11. März 2024 17:35 An:users@tomcat.apache.org
> >> Betreff: Tomcat SMPT TLS1.2
> >>
> >> Hi all,
> >>
> >> I have a COTS webapp using Tomcat 8.0.43 and Java 1.8.0_121.  I have
> >> been trying to find out where to configure outbound smtp messages to
> >> use only TLS1.2.  I've found plenty of info on the https using TLS1.2
> >> and have configured that just fine in server.xml file and in the Java
> >> tab of the tomcatw.exe file, but that doesn't seem to be applying to
> the emails
> >> outgoing from the webapp.   Anyone have any ideas? (Also upgrading is
> not
> >> an
> >> option as this tomcat/java combo is the only one supported by the
> >> vendor for our webapp version).
> >>
> >> Thank you!
> >> Brandie
> >>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail:users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail:users-h...@tomcat.apache.org
> >>
> >>
> --
>
> Archimede Informatica tratta i dati personali in conformità a quanto
> stabilito dal Regolamento UE n. 2016/679 (GDPR) e dal D. Lgs. 30 giugno
> 2003 n. 196
> per come modificato dal D.Lgs. 10 agosto 2018 n. 101.
> Informativa completa
> <
> http://www.archicoop.it/fileadmin/pdf/InformativaTrattamentoDatiPersonali.pdf
> >
>
> Il contenuto di questo messaggio e dei suoi eventuali allegati è
> riservato. Nel caso in cui Lei non sia il destinatario, La preghiamo di
> contattare telefonicamente o via e-mail il mittente ai recapiti sopra
> indicati e di cancellare il messaggio e gli eventuali allegati dal Suo
> sistema senza farne copia o diffonderli. Le opinioni espresse sono quelle
> dell'autore e non rappresentano necessariamente quelle della Società.
> This message and any attachment are confidential.If you are not the
> intended recipient, please telephone or email the sender and delete this
> message and any attachment from your system. If you are not the intended
> recipient you must not copy this message or attachment or disclose the
> contents to any other person. Any opinions presented are solely those of
> the author and do not necessarily represent those of the Company.
>
> dott. Ivano Mario Luberti
>
> Archimede Informatica società cooperativa a r. l.
> Via Gereschi 36, 56127 Pisa
>
> tel.: +39 050/580959 | fax: +39 050/8932061
>
> web: www.archicoop.it
> linkedin: www.linkedin.com/in/ivanoluberti
> facebook: www.facebook.com/archimedeinformaticapisa/
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

Re: Tomcat SMPT TLS1.2

[Robert Turner]

AFAIK, there is nothing in Tomcat for SMTP. This would be part of the
application you are running typically. It's possible (but not guaranteed)
that the web application is using the standard Java libraries for SMTP, and
as such, you may (but again not guaranteed) be able to configure some of
the mail settings via Java system properties (
https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-summary.html
).

Best bet is to work with your application provider and their
documentation / support.

Also, consider upgrading Java and Tomcat to current / supported versions as
those versions are both very old and likely have many security issues that
need patching.



On Mon, Mar 11, 2024 at 12:39 PM Jost Richstein 
wrote:

> Hi,
>
> this is definitely not a Tomcat problem - take a look at:
>
>
> https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-summary
> .html
> 
>
>
> -Ursprüngliche Nachricht-
> Von: Brandie Nickey 
> Gesendet: Montag, 11. März 2024 17:35
> An: users@tomcat.apache.org
> Betreff: Tomcat SMPT TLS1.2
>
> Hi all,
>
> I have a COTS webapp using Tomcat 8.0.43 and Java 1.8.0_121.  I have been
> trying to find out where to configure outbound smtp messages to use only
> TLS1.2.  I've found plenty of info on the https using TLS1.2 and have
> configured that just fine in server.xml file and in the Java tab of the
> tomcatw.exe file, but that doesn't seem to be applying to the emails
> outgoing from the webapp.   Anyone have any ideas? (Also upgrading is not
> an
> option as this tomcat/java combo is the only one supported by the vendor
> for
> our webapp version).
>
> Thank you!
> Brandie
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: [EXTERNAL] Re: Tomcat 9 returning 404 for audio files

[Robert Turner]

It's also possible you may need to support the "Range" HTTP header for
fetching parts of the audio file for playback. IIRC, we had to do that to
support the HTML 5 audio control properly.

On Mon, Mar 11, 2024 at 9:15 AM Joey Cochran  wrote:

> Thanks for replying!!
>
> Yes audio files are generated dynamically from DB.in a Servlet.
>
> I've verified that audio file exists on file system before returning the
> html code that contains audo control.
>
> I do NOT see this as a server side issue.
> This reads like a client/DOM cache of resource issue with the HTML5 audio
> control.
> simple fix could be (on the return/callback handler) to either
> refresh/reload just that tag on the DOM or even throw a whole DOM reload
> (more than one way to accomplish these, hence keeping it a pseudo code
> response)  -Hope this helps!
> -Joey
>
> On Mon, Mar 11, 2024, 5:22 a.m. Mark Thomas  wrote:
>
> > On 11/03/2024 02:21, Sam wrote:
> > > I just upgraded a legacy application from Tomcat 7 to Tomcat 9. It's
> > > deployed as a war file. I'm facing a weird issue with audio files
> > playback.
> > >
> > > When loading a page that contains an audio file. First time Tomcat
> > returns
> > > 404 error but if reloading the page, audio file is loaded properly and
> no
> > > error from Tomcat.
> > >
> > > I'm using html 5 audio control to display the file.
> > >
> > > All other static resources(images, css and js files) are working
> without
> > > any issues. Only audio files are having this issue.
> > >
> > > I enabled the logs for DefaultServlet in Tomcat. Follwong is the log
> > entry
> > > when I try to open the audio file first time. I can see 404 being
> > returned
> > > from server in Chrome dev tools.
> > >
> > >
> > > *09-Mar-2024 20:12:50.747 INFO DefaultServlet.serveResource: Serving
> > > resource '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers
> and
> > > data*
> > > Following is the log for 2nd attempt. This time audio is available and
> > > playable in browser. *09-Mar-2024 20:13:00.371 INFO
> > > DefaultServlet.serveResource: Serving resource
> > > '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and data *
> > > *09-Mar-2024 20:13:01.372 INFO DefaultServlet.serveFile:
> > > contentType='audio/mpeg'*
> >
> > Are the audio files generated dynamically on request?
> >
> > Mark
> >
> >
> > >
> > > Here is the audio control code:
> > >
> > > 
> > >  > >>
> > >
> > >   src="/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3"
> > > type="audio/mpeg" >
> > >
> > > 
> > > 
> > > I've tried relative path and full path but result is the same in both
> > cases.
> > >
> > > I've spent days trying to solve this but no luck :(
> > >
> > > I would really appreciate any guidance to solve this issue.
> > >
> > > Thanks!
> > >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
>

Re: Any way to look-up a session from application?

[Robert Turner]

Chris,

I think maybe Mark answered a similar question a while back indicating the
only supported method within the Servlet API was custom session tracking. I
could be remembering incorrectly. That's what we do however, because
without "snooping" into the Tomcat internals, I don't think there was a way
that we found.

Robert



On Tue, Feb 27, 2024 at 3:10 PM Olaf Kock  wrote:

> Hi Chris
>
> On 27.02.24 15:19, Christopher Schultz wrote:
> > All,
> >
> > I'm looking at building some administrative tools into my application,
> > and I'd like to be able to inspect user sessions for certain attributes.
> >
> > I know that I can use JMX to make calls to the (session) Manager, but
> > it looks like the only things really exposed are:
> >
> > String[] listSessionIds()
> > String getSessionAttribute(String sessionId, String attributeName)
> >
> > There are other operations available but they aren't related to what
> > I'd like to do: get a reference to the Session object itself, so I can
> > get attributes as their *actual* types and not converted to a String.
> >
> > Is that possible using existing Tomcat-provided tools?
> >
> > Another option would be to register an HttpSessionListener /
> > HttpSessionActivationListener and keep track of all the events so I
> > have my own "private" set of references to all of those sessions.
> >
> > Is there a way to do this without writing my own session-tracking
> > code? The old HttpSessionContext interface has been deprecated for
> > ages and implementations are required to be no-ops.
> >
> I can't really provide a recipe, but have a question for clarification:
>
> As you mention JMX, it sounds like you want to access the session from
> out-of-application context? If that is the case, you might have a hard
> time getting any session objects, if their classes are private to the
> web application's classloader. Strings naturally will work, but for
> others you'd need severe class loading or reflection magic to make sense
> of them.
>
> HttpSessionListener sounds more "in context", and more doable.
>
> I'm not aware of a way that does not involve custom session tracking
> code. But that doesn't mean anything: I can easily be proven wrong :)
>
> Olaf
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Issue Migrating servlets to 10.1

[Robert Turner]

I don't think there is an upper limit. I know 17 works for us, but your
mileage may vary depending on your app libraries, etc.


On Tue, Nov 21, 2023, 15:49 Campbell, Lance  wrote:

> Thanks so much.
> One last question. If I want to use javax.serlet.* then what is the
> highest version of Java I should use?
>
> Thanks,
>
> Lance
>
> -Original Message-
> From: Robert Turner 
> Sent: Tuesday, November 21, 2023 2:36 PM
> To: Tomcat Users List 
> Subject: Re: Issue Migrating servlets to 10.1
>
> Tomcat 10.x and higher require Jakarta namespaces versions of the Servlet
> specifications.
> Tomcat 9.x is the last Tomcat support javax.servlet namespaces.
>
> Refer to the Which Version page for Tomcat for details:
>
> https://urldefense.com/v3/__https://tomcat.apache.org/whichversion.html__;!!DZ3fjg!4VB2wQDqugXc0S2euhB5gcgb0Cu6xk-8SLRK_GwqXTxu2U6M3PLo_zrv8d_LmTAOeY0pUCw2GMYHX0pcXv1cMQ$
>
> On Tue, Nov 21, 2023 at 3:30 PM Campbell, Lance 
> wrote:
>
> > I am migrating from Java 8 tomcat 9 to Java 11 tomcat 10.1 .
> >
> > I am getting a cast class exception when trying to access my login
> > servlet. In my servlets I am using these packages:
> >
> >
> > import javax.servlet.ServletException;
> >
> > import javax.servlet.http.HttpServlet;
> >
> > import javax.servlet.http.HttpServletRequest;
> >
> > import javax.servlet.http.HttpServletResponse;
> >
> >
> >   1.  Does either Java 11 or Tomcat 10.1 require that I use
> > Jakarta.servlet.* packages instead of javax.servlet.*?
> >   2.  If that is the case, then what is specifically requiring this?
> > Is it Java 11 or Tomcat 10.1 or both?
> >
> > My servlet is getting this error:
> >
> > 21-Nov-2023 14:14:52.768 INFO [main]
> > org.apache.catalina.core.ApplicationContext.log Marking servlet
> > [LoginServlet] as unavailable
> > 21-Nov-2023 14:14:52.769 SEVERE [main]
> > org.apache.catalina.core.StandardContext.loadOnStartup Servlet
> > [LoginServlet] in web application [] threw load() exception
> > java.lang.ClassCastException: class xyz.servlet.LoginServlet
> > cannot be cast to class jakarta.servlet.Servlet
> > (xyz.servlet.LoginServlet is in unnamed module of loader
> > org.apache.catalina.loader.ParallelWebappClassLoader
> > @2ccca26f; jakarta.servlet.Servlet is in unnamed module of loader
> > java.net.URLClassLoader @63e2203c)
> >
> > Thanks,
> >
> > Lance
> >
>

Re: Issue Migrating servlets to 10.1

[Robert Turner]

Tomcat 10.x and higher require Jakarta namespaces versions of the Servlet
specifications.
Tomcat 9.x is the last Tomcat support javax.servlet namespaces.

Refer to the Which Version page for Tomcat for details:
https://tomcat.apache.org/whichversion.html

On Tue, Nov 21, 2023 at 3:30 PM Campbell, Lance  wrote:

> I am migrating from Java 8 tomcat 9 to Java 11 tomcat 10.1 .
>
> I am getting a cast class exception when trying to access my login
> servlet. In my servlets I am using these packages:
>
>
> import javax.servlet.ServletException;
>
> import javax.servlet.http.HttpServlet;
>
> import javax.servlet.http.HttpServletRequest;
>
> import javax.servlet.http.HttpServletResponse;
>
>
>   1.  Does either Java 11 or Tomcat 10.1 require that I use
> Jakarta.servlet.* packages instead of javax.servlet.*?
>   2.  If that is the case, then what is specifically requiring this? Is it
> Java 11 or Tomcat 10.1 or both?
>
> My servlet is getting this error:
>
> 21-Nov-2023 14:14:52.768 INFO [main]
> org.apache.catalina.core.ApplicationContext.log Marking servlet
> [LoginServlet] as unavailable
> 21-Nov-2023 14:14:52.769 SEVERE [main]
> org.apache.catalina.core.StandardContext.loadOnStartup Servlet
> [LoginServlet] in web application [] threw load() exception
> java.lang.ClassCastException: class xyz.servlet.LoginServlet
> cannot be cast to class jakarta.servlet.Servlet
> (xyz.servlet.LoginServlet is in unnamed module of loader
> org.apache.catalina.loader.ParallelWebappClassLoader
> @2ccca26f; jakarta.servlet.Servlet is in unnamed module of loader
> java.net.URLClassLoader @63e2203c)
>
> Thanks,
>
> Lance
>

Re: CIS Tomcat 8 Benchmark (v1.1.0) -- Questions

[Robert Turner]

Thanks Mark -- I appreciate your insights, and I agree with not donating
your time so someone else can make money off it. It definitely seems
somewhat unethical on their part not to make those resources available for
free if they are sourcing them for free. I would imagine it's still easy
enough to build up a commercial service around it, even if the artifacts
are all public.

I have traditionally relied on the advice in the Tomcat documentation in
precedence over anything the auditors "recommend" for the reasons you
articulated. Unfortunately, "audit" has a "special place" in the world ...

We do already override the "Server" header which is the obvious visible
version information (as so many "audits" insist on this being a "good
thing"), but I agree about staying on top of versions as the more correct
solution (rant: if only AWS would keep their Elastic Beanstalk platform up
to date as well...never mind that they skipped version 9, making it quite
awkward to jump from 8.5 to 10). Thanks for the additional details on that
one should it come up as a "finding".

I was only using that one as a "example", more to start a discussion, and
to ensure I wasn't "out to lunch" on my thoughts. There are plenty of
others entries in the evaluation document where the method for determining
is too narrow, and relies on a specific version (often old) or a particular
location for configuration (like explicitly specifying options in
catalina.sh, even though there are more appropriate places, like in
$CATALINA_HOME/conf files, or in the applications), as well as some items
that are somewhat obscure and don't result in improving security in any
material way (i.e. obscuring, rather than securing).

Robert


On Tue, Sep 5, 2023 at 11:27 AM Mark Thomas  wrote:

> I spoke to some CIS representatives at a recent conference given that I
> have concerns about the quality of some of the recommendations.
>
> It appears that these benchmarks are effectively crowdsourced. My
> primary concern is that there is no validation of the resulting
> recommendations so they run the risk of reinforcing current widespread
> bad practice as well as good practice.
>
> The only response CIS had was to join the CIS community and try and
> improve these guides. That is on my TODO list but it pains me to do so
> as they charge for commercial use. I don't like the idea of providing my
> expertise for free so someone else can make money out of it. I think I'd
> rather spend time on the security guides in the Tomcat docs.
>
> Hmm. Looking back at my notes it appears I looked into doing something
> similar back in 2010 and had similar concerns regarding the
> participation terms back then too.
>
> Regarding the suggestion to edit the contents of a JAR, that is a bad
> idea on so many levels.
>
> I'd argue that rather than spending time hiding the current Tomcat
> version - which is nothing more than security by obscurity - system
> admins should be investing time in an update process that allows easy
> updates (and roll-backs) to the Tomcat version. You only need to hide
> the version number if you aren't on top of your security updates. And if
> you aren't on top of your security updates you have bigger problems than
> needing to hide the version number.
>
> If you find you need to hide this version number to appease auditors -
> and using smarter auditors isn't an option - then there are a range of
> options as set out in the Tomcat 8.5 security guide. That guide also
> provides the correct way to override the version number (if you really
> need to) without editing the JAR contents. In short, you can simply
> override the individual file by placing at the right place in the file
> system:
>
> $CATALINA_BASE/lib/org/apache/catalina/util/ServerInfo.properties
>
> HTH,
>
> Mark
>
>
> On 05/09/2023 14:54, Robert Turner wrote:
> > Thanks Peter. Just to be clear that I have no concern about the goal of
> the
> > test -- only the method for obtaining the information, and the "implied"
> > correction.
> >
> > After going through the rest of the document I was provided, it seems to
> > "get more modern" as the questions go on -- suggesting the method of
> > improvement is additive, and possibly not corrective.
>
> Improvements are definitely corrective as well as additive. Early
> versions of the guide had very odd advice regarding MIME type mapping
> that has since been removed.
>
>
> >
> > On Tue, Sep 5, 2023 at 9:36 AM Peter Kreuser  wrote:
> >
> >> Robert,
> >>
> >> While Mark Thomas will have a more detailled answer to this...
> >>
> >> The finding behind this test is valid (information disclo

Re: CIS Tomcat 8 Benchmark (v1.1.0) -- Questions

[Robert Turner]

Thanks Peter. Just to be clear that I have no concern about the goal of the
test -- only the method for obtaining the information, and the "implied"
correction.

After going through the rest of the document I was provided, it seems to
"get more modern" as the questions go on -- suggesting the method of
improvement is additive, and possibly not corrective.

On Tue, Sep 5, 2023 at 9:36 AM Peter Kreuser  wrote:

> Robert,
>
> While Mark Thomas will have a more detailled answer to this...
>
> The finding behind this test is valid (information disclosure with server
> version in responses), though the remediation listed here is from looong
> time ago, when the was no ErrorReportValve to purge the version info.
>
> So the CIS Tomcat 8(!) Guide is pretty outdated! Probably in more than
> this spot...
>
> Peter
>
> > Am 05.09.2023 um 14:03 schrieb Robert Turner :
> >
> > While I think I know the answer to my question, I wanted to double-check
> > with the group to confirm.
> >
> > I have been asked to perform the CIS Apache Tomcat 8 Benchmark (v1.1.0)
> on
> > our production Tomcat installation, and I am looking through the
> questions
> > / information extraction requests, and I suspect they are not really
> > evaluating what they think they are, and furthermore encouraging bad
> > practices.
> >
> > For instance, the first entry I have in the spreadsheet I was provided is
> > listed as follows:
> >
> > CIS Control:
> > 2.1 Alter the Advertised server.info String (Scored)
> >
> > Description:
> > The server.info attribute contains the name of the application service.
> > This value is presented to Tomcat clients when clients connect to the
> > tomcat server.
> >
> > Audit Procedures:
> > Perform the following to determine if the server.info value has been
> > changed:
> > Extract the ServerInfo.properties file and examine the server.info
> > attribute.
> > $ cd $CATALINA_HOME/lib
> > $ jar xf catalina.jar org/apache/catalina/util/ServerInfo.properties
> > $ grep server.info org/apache/catalina/util/ServerInfo.properties
> >
> >
> > So, other than a few issues with the audit procedures, etc. This seems to
> > be doing the following:
> >
> > a) evaluating a default value which I believe can be overridden and thus
> > may not actually reflect the value the server may provide to external
> > clients
> > b) encouraging the modification of the catalina.jar contents to correct
> the
> > default value
> >
> > There are a few similar items (for server.number, server.built) (2.2,
> 2.3).
> >
> >
> > Thoughts / comments from "those in the know"?
> >
> > Thanks,
> >
> > Robert
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

CIS Tomcat 8 Benchmark (v1.1.0) -- Questions

[Robert Turner]

While I think I know the answer to my question, I wanted to double-check
with the group to confirm.

I have been asked to perform the CIS Apache Tomcat 8 Benchmark (v1.1.0) on
our production Tomcat installation, and I am looking through the questions
/ information extraction requests, and I suspect they are not really
evaluating what they think they are, and furthermore encouraging bad
practices.

For instance, the first entry I have in the spreadsheet I was provided is
listed as follows:

CIS Control:
2.1 Alter the Advertised server.info String (Scored)

Description:
The server.info attribute contains the name of the application service.
This value is presented to Tomcat clients when clients connect to the
tomcat server.

Audit Procedures:
Perform the following to determine if the server.info value has been
changed:
Extract the ServerInfo.properties file and examine the server.info
attribute.
$ cd $CATALINA_HOME/lib
$ jar xf catalina.jar org/apache/catalina/util/ServerInfo.properties
$ grep server.info org/apache/catalina/util/ServerInfo.properties


So, other than a few issues with the audit procedures, etc. This seems to
be doing the following:

a) evaluating a default value which I believe can be overridden and thus
may not actually reflect the value the server may provide to external
clients
b) encouraging the modification of the catalina.jar contents to correct the
default value

There are a few similar items (for server.number, server.built) (2.2, 2.3).


Thoughts / comments from "those in the know"?

Thanks,

Robert

Re: Tomcat 9.0.x on Windows crashing

[Robert Turner]

You can try adding:

-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=C:\HeapDump\java_pid.hprof

to the Java options (in "Configure Tomcat") to capture heap dumps on out of
memory errors (adjust path to suit your configuration)

Robert


On Wed, Aug 23, 2023 at 1:03 PM Daniel Savard 
wrote:

> Hi everyone,
>
> I didn't specify the actual Tomcat version because the problem occurs under
> all versions. We are running a commercial web application and all of sudden
> after a while Tomcat is crashing without issuing any message. It is very
> likely due to the application. But the vendor was of no help to solve this
> problem which has existed for a long time. I suspect something like
> insufficient memory allocated to the VM or something like that. Is there
> anything I can do to gather more information on the root cause of this
> issue?
>
> Tomcat is running as a service and is restarted automatically if it
> crashes. Again, the problem is very unlikely to be with Tomcat itself, but
> the tuning of the VM.
>
> -
> Daniel Savard
>

Re: Tomcat links application at the root of the server?

[Robert Turner]

What about the standard / provided Tomcat Manager application?
https://tomcat.apache.org/tomcat-9.0-doc/manager-howto.html




On Fri, Jul 7, 2023 at 9:26 AM Graham Leggett 
wrote:

> Hi all,
>
> Is there is application out there that will provide, at / (or a path of
> your choosing), a list of links of applications currently deployed and
> running under tomcat?
>
> Ideally I want tomcat to tell me what applications have been deployed and
> if they have been deployed successfully, preferably by pointing curl and
> the root of the server and going “what’s here and how do I get there”.
>
> (This is a wildly different question to “what do I think is here and how
> do I think I get there”)
>
> Regards,
> Graham
> —
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: GoDaddy SSL certificate not working with Tomcat9

[Robert Turner]

Pressed send too quickly -- I see different aliases there. Ignore my
previous comments

Using PEM files is much simpler to manage, I would go that route instead...
will make it easier. However, I can't offer any real advice on the specific
issue at this time...

Others will certainly be more helpful than I...sorry.

On Mon, Mar 20, 2023 at 9:14 PM Robert Turner  wrote:

> I believe the default certificate alias used by Tomcat is "tomcat". I
> think you are creating your keystore with the alias "root".
>
> (see https://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html for docs on
> Tomcat SSL configuration -- adjust for the version you are running)
>
> On Mon, Mar 20, 2023 at 9:09 PM Ralph Grove 
> wrote:
>
>> I'm having a problem installing a new SSL certificate on a GoDaddy-hosted
>> server running Tomcat. Any suggestions for resolving it would be
>> appreciated.
>>
>> I set up the server last year and installed the SSL certificate with no
>> problem. This year, after the original certificate expired, I downloaded
>> the new certificate provided by GoDaddy, removed the old certificate files
>> from the keystore, and installed the new ones. Now Tomcat is throwing a
>> "java.io.IOException: jsse.alias_no_key_entry" exception when it tries to
>> open the HTTPS connector. I also tried rebuilding the keystore from scratch
>> and requesting a new certificate, but am getting the same exception with
>> that certificate.
>>
>> These are the commands I used to obtain and install the certificate:
>>
>> sudo keytool -genkey -alias tomcat -keyalg RSA -keystore keystore.jks
>>
>> sudo keytool -certreq -keyalg RSA -alias tomcat -file certreq.csr
>> -keystore keystore.jks
>>
>> (--request and obtain certificate files from GoDaddy--)
>>
>> sudo keytool -import -alias root -keystore keystore.jks -trustcacerts
>> -file gdcerts/gdroot-g2.crt
>>
>> sudo keytool -import -alias inter -keystore keystore.jks -trustcacerts
>> -file gdcerts/gd_bundle-g2-g1.crt
>>
>> sudo keytool -import -alias tomcat -keystore keystore.jks -file
>> gdcerts/.crt
>>
>>
>>
>> And this is the Tomcat configuration for the connector:
>>
>>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>>
>>   maxThreads="150" SSLEnabled="true">
>>
>>
>>
>>>
>>  type="RSA" certificateKeystorePassword="xx" />
>>
>>
>>
>>
>>
>>
>
>

Re: GoDaddy SSL certificate not working with Tomcat9

[Robert Turner]

I believe the default certificate alias used by Tomcat is "tomcat". I think
you are creating your keystore with the alias "root".

(see https://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html for docs on
Tomcat SSL configuration -- adjust for the version you are running)

On Mon, Mar 20, 2023 at 9:09 PM Ralph Grove 
wrote:

> I'm having a problem installing a new SSL certificate on a GoDaddy-hosted
> server running Tomcat. Any suggestions for resolving it would be
> appreciated.
>
> I set up the server last year and installed the SSL certificate with no
> problem. This year, after the original certificate expired, I downloaded
> the new certificate provided by GoDaddy, removed the old certificate files
> from the keystore, and installed the new ones. Now Tomcat is throwing a
> "java.io.IOException: jsse.alias_no_key_entry" exception when it tries to
> open the HTTPS connector. I also tried rebuilding the keystore from scratch
> and requesting a new certificate, but am getting the same exception with
> that certificate.
>
> These are the commands I used to obtain and install the certificate:
>
> sudo keytool -genkey -alias tomcat -keyalg RSA -keystore keystore.jks
>
> sudo keytool -certreq -keyalg RSA -alias tomcat -file certreq.csr
> -keystore keystore.jks
>
> (--request and obtain certificate files from GoDaddy--)
>
> sudo keytool -import -alias root -keystore keystore.jks -trustcacerts
> -file gdcerts/gdroot-g2.crt
>
> sudo keytool -import -alias inter -keystore keystore.jks -trustcacerts
> -file gdcerts/gd_bundle-g2-g1.crt
>
> sudo keytool -import -alias tomcat -keystore keystore.jks -file
> gdcerts/.crt
>
>
>
> And this is the Tomcat configuration for the connector:
>
> protocol="org.apache.coyote.http11.Http11NioProtocol"
>
>   maxThreads="150" SSLEnabled="true">
>
>
>
>
>  type="RSA" certificateKeystorePassword="xx" />
>
>
>
>
>
>

Re: Tomcat for Apple silicon coming soon?

[Robert Turner]

You can run an aarm64 version of the Java runtime (various distributions
exist) and run Tomcat on that -- it works well. No specific version of
Tomcat is required as it a Java package.



On Mon, Jan 16, 2023 at 3:38 PM m...@cvkimball.com 
wrote:

>
> I'd like to run Tomcat on one of the new Apple products based on the
> Apple Mac silicon ARM64 architecture.
>
> Is a Tomcat release, preferably Tomcat 10.1, for Mac silicon likely in
> the near future?
>
> Thanks,
>
> Chris Kimball
>
> Redding, CT
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: [Tomcat9][Linux]listening all local addresses by default is not security best practice

[Robert Turner]

My 2 cents:

I think that it would be a very strange change to make to a generic product
and a "sample" configuration file. If Tomcat was packaged in a
distribution, that might be a more reasonable suggestion. I don't think
Tomcat is insecure because of this; binding to addresses/ports is a key
part of configuration of any deployed system and the responsibility of the
person(s) deploying it to ensure correct basic configuration (which this is
part of).

Also, if an attacker manages to add additional IP addresses to your
machine, and your already running processes start taking requests from
them, I think you have much bigger worries than Tomcat happening to take
requests from multiple addresses at that point as the attacker already
pretty much has full control over your machine and can likely edit your
configuration file anyway

This CWE is really about a deployed system -- not a library or tool...

Just a thought or two...

(Disclaimer: I have no current involvement in the project's
development/maintenance)


On Wed, Nov 23, 2022 at 2:35 PM  wrote:

> Hi there,
>
> The default behaviour of http connector is listenning all interfaces. It
> is found in the description of "address" in attributes section. (
> https://tomcat.apache.org/tomcat-9.0-doc/config/http.html#SSL_Support)
>
> In terms of security default, it could be not best practice. In case of
> unexpected mistakes made by people, default behaviour of exposing the
> server to every possible network may pose a potential threat on security.
>
> CWE-1327: Binding to an Unrestricted IP Address:
> https://cwe.mitre.org/data/definitions/1327.html
>
> The issue should be a security enhancement. I recommend changing default
> behaviour to a single interface/network, e.g loopback interface 127.0.0.1
> and adding configuration option with default value OFF for 0.0.0.0 or : :.
>
> If there have been any previous discusstion about this, could you please
> tell me?
>
> Hope that I make it clear.
>
>

Re: Tomcat Native on M1 Macs

[Robert Turner]

I think you need to use an ARM-based JVM -- IIRC, you will need Corretto
JDK 18 I think, otherwise it will be running in emulation.

On Tue, Apr 5, 2022 at 1:56 PM Paquin, Brian  wrote:

> After compiling Tomcat Native (that comes with Tomcat 9.0.62, version
> 1.2.32) on a (ARM) M1 Mac (with Amazon Coretto 11 JDK, APR, and OpenSSL
> 1.1.1n), I get the following error in Catalina.out:
>
> 05-Apr-2022 11:10:32.307 WARNING [main]
> org.apache.catalina.core.AprLifecycleListener.init The Apache Tomcat Native
> library failed to load. The error reported was
> [/Library/Java/Extensions/libtcnative-1.0.dylib:
> dlopen(/Library/Java/Extensions/libtcnative-1.0.dylib, 0x0001): tried:
> '/Library/Java/Extensions/libtcnative-1.0.dylib' (mach-o file, but is an
> incompatible architecture (have 'arm64', need 'x86_64')),
> '/usr/lib/libtcnative-1.0.dylib' (no such file)]
> java.lang.UnsatisfiedLinkError:
> /Library/Java/Extensions/libtcnative-1.0.dylib:
> dlopen(/Library/Java/Extensions/libtcnative-1.0.dylib, 0x0001): tried:
> '/Library/Java/Extensions/libtcnative-1.0.dylib' (mach-o file, but is an
> incompatible architecture (have 'arm64', need 'x86_64')),
> '/usr/lib/libtcnative-1.0.dylib' (no such file)
>
> Note: After I compiled Native, I did the following (we did this in the
> past but I don’t know if it is still required):
>
>   1.  cp
> /usr/local/tomcat/bin/tomcat-native-1.2.32-src/native/.libs/libtcnative-1.0.dylib
> /Library/Java/Extensions
>   2.  cd /Library/Java/Extensions
>   3.  ln -sfhv libtcnative-1.0.dylib libtcnative-1.dylib
>   4.  ln -sfhv libtcnative-1.dylib libtcnative-1.jnilib
> (Not sure if this is needed anymore…)
>
> Does anyone have instructions for compiling Native on an ARM-based Mac? Or
> suggestions around this issue?
>
> Thank you,
>
> Brian
>

Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)

[Robert Turner]

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)

[Robert Turner]

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);
> > %>
> > 
> > 
&

Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)

[Robert Turner]

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)

[Robert Turner]

websocket.server.WsFilter.doFilter(WsFilter.java:53)
Note The full stack trace of the root cause is available in
the server logs.Apache
Tomcat/9.0.58


And a "working" scenario, replace step 8 with the following:

docker run -d -p 8075:8080 tomcat:9.0.58-jre11-openjdk
docker cp target/test-e-resolver.war
:/usr/local/tomcat/webapps/

Accessing the page with the curl command above will result in the expect
page being displayed (and no exception).


Robert



On Tue, Feb 8, 2022 at 9:39 AM Robert Turner  wrote:

> 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
>> >>&

Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)

[Robert Turner]

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.
> >>>> Com

Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)

[Robert Turner]

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.setAttr

Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)

[Robert Turner]

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

Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)

[Robert Turner]

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.
&

Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)

[Robert Turner]

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-ube

Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)

[Robert Turner]

mcat-coyote.jar
URL=file:/lib/tomcat-dbcp.jar
URL=file:/lib/tomcat-i18n-cs.jar
URL=file:/lib/tomcat-i18n-de.jar
URL=file:/lib/tomcat-i18n-es.jar
URL=file:/lib/tomcat-i18n-fr.jar
URL=file:/lib/tomcat-i18n-ja.jar
URL=file:/lib/tomcat-i18n-ko.jar
URL=file:/lib/tomcat-i18n-pt-BR.jar
URL=file:/lib/tomcat-i18n-ru.jar
URL=file:/lib/tomcat-i18n-zh-CN.jar
URL=file:/lib/tomcat-jdbc.jar
URL=file:/lib/tomcat-jni.jar
URL=file:/lib/tomcat-util-scan.jar
URL=file:/lib/tomcat-util.jar
URL=file:/lib/tomcat-websocket.jar
URL=file:/lib/websocket-api.jar
  Class loader name=jdk.internal.loader.ClassLoaders$AppClassLoader
  Class loader name=jdk.internal.loader.ClassLoaders$PlatformClassLoader


[3]
private static void logClassLoaderUrls(org.apache.logging.log4j.Level
logLevel, ClassLoader cl) {
if (null == cl) {
return;
}
boolean loaderNameLogged = false;
if (cl instanceof URLClassLoader) {
final URLClassLoader urlCl = (URLClassLoader) cl;
final URL[] urls = urlCl.getURLs();
if (null != urls) {
LOG.log(logLevel, "  Class loader name={}, URL count={}",
cl.getClass().getName(), urls.length);
loaderNameLogged = true;
for (int idx = 0; idx < urls.length; idx++) {
final URL url = urls[idx];
LOG.log(logLevel, "URL[{}]={}", idx, url);
}
}
}
if (!loaderNameLogged) {
LOG.log(logLevel, "  Class loader name={}",
cl.getClass().getName());
}
logClassLoaderUrls(logLevel, cl.getParent());
}

..snip..

LOG.info("java.class.path={}",
System.getProperty("java.class.path"));
LOG.debug("Class loader URLs:");
logClassLoaderUrls(org.apache.logging.log4j.Level.DEBUG,
ctx.getClassLoader());


[4]
   cat log-extract.txt | cut -c137- | sed -e "s+/usr/local/tomcat++g" -e
"s+/usr/local/tomcat/webapps/exclaim++g" -e "s+\[[0-9]*\]++"
and I manually sorted the "sections" using vim, with the "sort" command.


[5]
# Debian with OpenJDK
#FROM tomcat:9.0.58-jre11-openjdk AS tomcat_package
# AWS Linux 2 with Corretto
FROM tomcat:9.0.58-jdk11-corretto AS tomcat_package

# Set the timezone to Canada/Eastern
# For Debian
#RUN ln -sf /usr/share/zoneinfo/Canada/Eastern /etc/localtime && echo
"Canada/Eastern" > /etc/timezone && dpkg-reconfigure -f noninteractive
tzdata
# For AWS Linux
RUN ln -sf /usr/share/zoneinfo/Canada/Eastern /etc/localtime && sed -i
's/\"UTC\"/\"Canada\/Eastern\"/' /etc/sysconfig/clock # and reboot, but
will skip as container will be created and ran separately

# Install a postgresql client for testing and the required font packages
needed by JasperReports
# For Debian:
#RUN echo "deb http://deb.debian.org/debian bullseye contrib non-free" >>
/etc/apt/sources.list && apt-get update && apt-get install -y
postgresql-client ttf-mscorefonts-installer
# For AWS Linux:
RUN yum -q list installed epel-release.noarch &>/dev/null && echo
'epel-release already installed' || yum install -y
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
RUN yum install -y cabextract xorg-x11-font-utils fontconfig
RUN rpm -q msttcore-fonts-installer-2.6-1 &>/dev/null && echo
'msttcore-fonts-installer-2.6-1 already installed' || rpm -i
https://iweb.dl.sourceforge.net/project/mscorefonts2/rpms/msttcore-fonts-installer-2.6-1.noarch.rpm

# Add a health-check script to wait for exclaim to be running -- allow at
least 10 minutes for it to start
COPY health_check.sh /usr/local/bin/
HEALTHCHECK --interval=10s --timeout=5s --start-period=10m --retries=10 CMD
/usr/local/bin/health_check.sh

# Set up the resource folders needed by application and make it a
# volume so it persists across container restarts
COPY resources/ /resources/
VOLUME /resources

# Map some of the Tomcat folders to volumes so they persist between
restarts of the container
VOLUME /usr/local/tomcat/logs
VOLUME /usr/local/tomcat/webapps
VOLUME /usr/local/tomcat/work
VOLUME /usr/local/tomcat/conf

# Enable connecting from anywhere for JPDA (req'd for Java 9+)
ENV JPDA_ADDRESS=*:8000

CMD ["catalina.sh","jpda","run"]


[6]
JDK on MacOS is:
openjdk version "11.0.13" 2021-10-19 LTS
OpenJDK Runtime Environment Corretto-11.0.13.8.1 (build 11.0.13+8-LTS)
OpenJDK 64-Bit Server VM Corretto-11.0.13.8.1 (build 11.0.13+8-LTS, mixed
mode)

JDK on Windows is:
openjdk 11.0.14 2022-01-18 LTS
OpenJDK Runtime Environment Corretto-11.0.14.9.1 (build 11.0.14+9-LTS)
OpenJDK 64-Bit Server VM Corretto-11.0.14.9.1 (build 11.0.14+9-LTS, mixed
mode)

JDK on Docker with AWS Linux 2 is:
openjdk 11.0.14 2022-01

Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)

[Robert Turner]

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.

Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)

[Robert Turner]

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 Turner]

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.Weba

Re: Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)

[Robert Turner]

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
>
>

Odd EL resolution issue - java.lang.NoClassDefFoundError: package/Class1 (wrong name: package/class1)

[Robert Turner]

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

Re: [OT] Working with SAML

[Robert Turner]

Yes, that's the one. It's not tied to the OneLogin service or any other. We
are successfully using it against Google Workspace SAML authentication, and
against test servers running KeyCloak, and hoping to use it against
Microsoft Azure as well (but I haven't confirmed that it definitely works
yet). As far as I can tell it's free to use as it's an MIT-style License.
And at least, one can get at the code and "fix" things if needed.

On Tue, Mar 16, 2021 at 4:19 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Robert,
>
> On 3/16/21 14:33, Robert Turner wrote:
> > Chris,
> >
> > I'm not sure if it will do what you want, but when sourcing Java-based
> SAML
> > libraries for our use as an SP, I too found that most of the libraries
> were
> > much larger and more complicated that I thought necessary. We went with
> the
> > (limited but simple to use) OneLogin libraries for our use case. It
> doesn't
> > do everything by any means, but was considerably smaller and simpler than
> > most packages out there.
>
> I did see the OneLogin library. You mean this one, right?
> https://github.com/onelogin/java-saml
>
> Is there anything tied to any particular service for that? Or do they
> simply give-away their library for use anywhere?
>
> Thanks,
> -chris
>
> > On Tue, Mar 16, 2021 at 1:55 PM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> >> All,
> >>
> >> I've got a system which is accepting one-legged, signed SAML responses
> >> from trusted third parties and going all the right things. It's working
> >> great.
> >>
> >> It's time to look at doing the opposite: assembling our own SAML
> >> responses, signing them, and sending them to another party.
> >>
> >> I'm sure I could manually create a DOM document with all the right
> >> namespaces, add the various values that I need, and then use XML DSIG
> >> using the bits and pieces that are provided by Java directly, but
> >> there's got to be a nice compact library that doesn't require me to
> >> download the entire internet in order to use in my product.
> >>
> >> Any recommendations?
> >>
> >> Thanks,
> >> -chris
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: [OT] Working with SAML

[Robert Turner]

Chris,

I'm not sure if it will do what you want, but when sourcing Java-based SAML
libraries for our use as an SP, I too found that most of the libraries were
much larger and more complicated that I thought necessary. We went with the
(limited but simple to use) OneLogin libraries for our use case. It doesn't
do everything by any means, but was considerably smaller and simpler than
most packages out there.

Robert



On Tue, Mar 16, 2021 at 1:55 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> All,
>
> I've got a system which is accepting one-legged, signed SAML responses
> from trusted third parties and going all the right things. It's working
> great.
>
> It's time to look at doing the opposite: assembling our own SAML
> responses, signing them, and sending them to another party.
>
> I'm sure I could manually create a DOM document with all the right
> namespaces, add the various values that I need, and then use XML DSIG
> using the bits and pieces that are provided by Java directly, but
> there's got to be a nice compact library that doesn't require me to
> download the entire internet in order to use in my product.
>
> Any recommendations?
>
> Thanks,
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Unable to start Tomcat 10.0.4

[Robert Turner]

I suggest you have a read here:
https://tomcat.apache.org/tomcat-10.0-doc/config/http.html#SSL_Support
The documentation covers the details you need to correctly configure Tomcat
and SSL and links to a related page about SSL configuration.

Notice the line:
Each secure connector must define at least one *SSLHostConfig*. The names
of the *SSLHostConfig* elements must be unique and one of them must match
the defaultSSLHostConfigName attribute of the *Connector*.




On Tue, Mar 16, 2021 at 12:42 PM  wrote:

> > If you look at the stack trace, it tells you what the problem is:
>
> >  Caused by: java.lang.IllegalArgumentException: No SSLHostConfig
> > element was found with the hostName [_default_] to match the
> > defaultSSLHostConfigName for the connector [https-openssl-nio-8443]
>
> > So it no longer looks like you are hitting a port in use issue.
> Please suggest what configuration need to do. To remove this error. It
> will be very helpful for us.
>
>
> On Tue, Mar 16, 2021 at 12:01 PM  wrote:
>
> > > Please provide full stacktrace
> > Please find full catlina log and I have already shared server.xml in
> trail
> > mail
> >
> > 16-Mar-2021 21:26:54.263 WARNING [main]
> > org.apache.tomcat.util.digester.SetPropertiesRule.begin Match
> > [Server/Service/Connector] failed to set property [compressableMimeType]
> > to
> >
> >
>
> [text/html,text/xml,text/javascript,application/x-javascript,application/javascript]
> > 16-Mar-2021 21:26:54.269 WARNING [main]
> > org.apache.tomcat.util.digester.SetPropertiesRule.begin Match
> > [Server/Service/Connector] failed to set property [clientAuth] to
> [false]
> > 16-Mar-2021 21:26:54.270 WARNING [main]
> > org.apache.tomcat.util.digester.SetPropertiesRule.begin Match
> > [Server/Service/Connector] failed to set property [sslProtocol] to [TLS]
> > 16-Mar-2021 21:26:54.270 WARNING [main]
> > org.apache.tomcat.util.digester.SetPropertiesRule.begin Match
> > [Server/Service/Connector] failed to set property [sslEnabledProtocols]
> to
> > [TLSv1.2,TLSv1.1]
> > 16-Mar-2021 21:26:54.270 WARNING [main]
> > org.apache.tomcat.util.digester.SetPropertiesRule.begin Match
> > [Server/Service/Connector] failed to set property
> > [allowUnsafeLegacyRenegotiation] to [false]
> > 16-Mar-2021 21:26:54.270 WARNING [main]
> > org.apache.tomcat.util.digester.SetPropertiesRule.begin Match
> > [Server/Service/Connector] failed to set property [ciphers] to
> > [TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA]
> > 16-Mar-2021 21:26:54.271 WARNING [main]
> > org.apache.tomcat.util.digester.SetPropertiesRule.begin Match
> > [Server/Service/Connector] failed to set property [keystoreFile] to
> > [/conf/eNotice.key]
> > 16-Mar-2021 21:26:54.272 WARNING [main]
> > org.apache.tomcat.util.digester.SetPropertiesRule.begin Match
> > [Server/Service/Connector] failed to set property [keystorePass] to
> > [eNotice@1]
> > 16-Mar-2021 21:26:54.306 INFO [main]
> > org.apache.catalina.startup.VersionLoggerListener.log Server version
> name:
> >   Apache Tomcat/10.0.4
> > 16-Mar-2021 21:26:54.307 INFO [main]
> > org.apache.catalina.startup.VersionLoggerListener.log Server built: Mar
> > 5 2021 11:07:15 UTC
> > 16-Mar-2021 21:26:54.307 INFO [main]
> > org.apache.catalina.startup.VersionLoggerListener.log Server version
> > number: 10.0.4.0
> > 16-Mar-2021 21:26:54.307 INFO [main]
> > org.apache.catalina.startup.VersionLoggerListener.log OS Name:   Windows
> > 10
> > 16-Mar-2021 21:26:54.307 INFO [main]
> > org.apache.catalina.startup.VersionLoggerListener.log OS Version:   10.0
> > 16-Mar-2021 21:26:54.308 INFO [main]
> > org.apache.catalina.startup.VersionLoggerListener.log Architecture: x86
> > 16-Mar-2021 21:26:54.308 INFO [main]
> > org.apache.catalina.startup.VersionLoggerListener.log Java Home:
> > C:\Program Files (x86)\Java\jdk1.8.0_271\jre
> > 16-Mar-2021 21:26:54.308 INFO [main]
> > org.apache.catalina.startup.VersionLoggerListener.log JVM Version:
> > 1.8.0_271-b09
> > 16-Mar-2021 21:26:54.308 INFO [main]
> > org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor: Oracle
> > Corporation
> > 16-Mar-2021 21:26:54.309 INFO [main]
> > org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE:
> > D:\apache-tomcat-10.0.4_bk\apache-tomcat-10.0.4
> > 16-Mar-2021 21:26:54.309 INFO [main]
> > org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME:
> > D:\apache-tomcat-10.0.4_bk\apache-tomcat-10.0.4
> > 16-Mar-2021 21:26:54.310 INFO [main]
> > org.apache.catalina.startup.VersionLoggerListener.log Command line
> > argument:
> >
> >
>
> -Djava.util.logging.config.file=D:\apache-tomcat-10.0.4_bk\apache-tomcat-10.0.4\conf\logging.properties
> > 16-Mar-2021 21:26:54.310 INFO [main]
> > org.apache.catalina.startup.VersionLoggerListener.log Command line
> > argument:
> > -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> > 16-Mar-2021 21:26:54.311 INFO [main]
> > org.apache.catalina.startup.VersionLoggerListener.log Command line
> > argument: 

Re: Unable to start Tomcat 10.0.4

[Robert Turner]

If you look at the stack trace, it tells you what the problem is:

 Caused by: java.lang.IllegalArgumentException: No SSLHostConfig
element was found with the hostName [_default_] to match the
defaultSSLHostConfigName for the connector [https-openssl-nio-8443]

So it no longer looks like you are hitting a port in use issue.



On Tue, Mar 16, 2021 at 12:01 PM  wrote:

> > Please provide full stacktrace
> Please find full catlina log and I have already shared server.xml in trail
> mail
>
> 16-Mar-2021 21:26:54.263 WARNING [main]
> org.apache.tomcat.util.digester.SetPropertiesRule.begin Match
> [Server/Service/Connector] failed to set property [compressableMimeType]
> to
>
> [text/html,text/xml,text/javascript,application/x-javascript,application/javascript]
> 16-Mar-2021 21:26:54.269 WARNING [main]
> org.apache.tomcat.util.digester.SetPropertiesRule.begin Match
> [Server/Service/Connector] failed to set property [clientAuth] to [false]
> 16-Mar-2021 21:26:54.270 WARNING [main]
> org.apache.tomcat.util.digester.SetPropertiesRule.begin Match
> [Server/Service/Connector] failed to set property [sslProtocol] to [TLS]
> 16-Mar-2021 21:26:54.270 WARNING [main]
> org.apache.tomcat.util.digester.SetPropertiesRule.begin Match
> [Server/Service/Connector] failed to set property [sslEnabledProtocols] to
> [TLSv1.2,TLSv1.1]
> 16-Mar-2021 21:26:54.270 WARNING [main]
> org.apache.tomcat.util.digester.SetPropertiesRule.begin Match
> [Server/Service/Connector] failed to set property
> [allowUnsafeLegacyRenegotiation] to [false]
> 16-Mar-2021 21:26:54.270 WARNING [main]
> org.apache.tomcat.util.digester.SetPropertiesRule.begin Match
> [Server/Service/Connector] failed to set property [ciphers] to
> [TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA]
> 16-Mar-2021 21:26:54.271 WARNING [main]
> org.apache.tomcat.util.digester.SetPropertiesRule.begin Match
> [Server/Service/Connector] failed to set property [keystoreFile] to
> [/conf/eNotice.key]
> 16-Mar-2021 21:26:54.272 WARNING [main]
> org.apache.tomcat.util.digester.SetPropertiesRule.begin Match
> [Server/Service/Connector] failed to set property [keystorePass] to
> [eNotice@1]
> 16-Mar-2021 21:26:54.306 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Server version name:
>   Apache Tomcat/10.0.4
> 16-Mar-2021 21:26:54.307 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Server built:   Mar
> 5 2021 11:07:15 UTC
> 16-Mar-2021 21:26:54.307 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Server version
> number: 10.0.4.0
> 16-Mar-2021 21:26:54.307 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log OS Name:   Windows
> 10
> 16-Mar-2021 21:26:54.307 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log OS Version:   10.0
> 16-Mar-2021 21:26:54.308 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Architecture:   x86
> 16-Mar-2021 21:26:54.308 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Java Home:
> C:\Program Files (x86)\Java\jdk1.8.0_271\jre
> 16-Mar-2021 21:26:54.308 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log JVM Version:
> 1.8.0_271-b09
> 16-Mar-2021 21:26:54.308 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor:   Oracle
> Corporation
> 16-Mar-2021 21:26:54.309 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE:
> D:\apache-tomcat-10.0.4_bk\apache-tomcat-10.0.4
> 16-Mar-2021 21:26:54.309 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME:
> D:\apache-tomcat-10.0.4_bk\apache-tomcat-10.0.4
> 16-Mar-2021 21:26:54.310 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument:
>
> -Djava.util.logging.config.file=D:\apache-tomcat-10.0.4_bk\apache-tomcat-10.0.4\conf\logging.properties
> 16-Mar-2021 21:26:54.310 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument:
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> 16-Mar-2021 21:26:54.311 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument: -Djdk.tls.ephemeralDHKeySize=2048
> 16-Mar-2021 21:26:54.311 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument: -Djava.protocol.handler.pkgs=org.apache.catalina.webresources
> 16-Mar-2021 21:26:54.311 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument: -Dignore.endorsed.dirs=
> 16-Mar-2021 21:26:54.312 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument: -Dcatalina.base=D:\apache-tomcat-10.0.4_bk\apache-tomcat-10.0.4
> 16-Mar-2021 21:26:54.312 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument: -Dcatalina.home=D:\apache-tomcat-10.0.4_bk\apache-tomcat-10.0.4
> 16-Mar-2021 21:26:54.312 INFO [main]
> 

Re: Unable to start Tomcat 10.0.4

[Robert Turner]

Your more recent exception log didn't include the "caused by" exception --
which is the actual failure details. Double-check that and make sure it's
the same issue.

Also, use netstat to confirm you aren't using the ports already. Changing
it may just find another conflict (although less likely). The first error
was quite clear about the port being unavailable.

How are you starting Tomcat? Are you somehow starting it twice?



On Tue, Mar 16, 2021 at 9:38 AM  wrote:

> > Deepak,
> > You already have some service listening on port 80 (IIS maybe?)
> >
> >
> > from mobile (sorry for typos ;)
> >
> > We have changed the port still getting same error
>
> > Maybe you have the same port configured twice in your conf/server.xml?
>
> > Please post *all*  elements from your conf/server.xml file,
> > being careful to remove any secrets from your configuration.
>
> -chris
> please find conf/server.xml file
>
> 
> 
>/>
>SSLEngine="on" />
>className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
>className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
>className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
>   
>type="org.apache.catalina.UserDatabase"
>   description="User database that can be updated and saved"
>  factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
>   pathname="conf/tomcat-users.xml" />
>   
>   
> maxThreads="150" minSpareThreads="25"
> enableLookups="false" redirectPort="445" acceptCount="100"
>connectionTimeout="302000" disableUploadTimeout="true"
> compression="on" compressionMinSize="2048"
> noCompressionUserAgents="gozilla, traviata"
> compressableMimeType="text/html,text/xml,text/javascript,application/x-javascript,application/javascript"
>
>  server=" " />
>  port="445" maxHttpHeaderSize="8192" maxThreads="150"
> minSpareThreads="25" enableLookups="false"
> disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true"
> clientAuth="false" sslProtocol="TLS"
> sslEnabledProtocols="TLSv1.2,TLSv1.1" SSLEnabled="true"
> allowUnsafeLegacyRenegotiation="false"
>  ciphers="TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA"
> keystoreFile="/conf/abc.key"
> keystorePass="changeit" server=" " />
> 
>   
> resourceName="UserDatabase"/>
>   
>unpackWARs="true" autoDeploy="true">
>  directory="logs"
>prefix="localhost_access_log" suffix=".txt"
>pattern="%h %l %u %t %r %s %b" />
>   
> 
>   
> 
>
> > 16-Mar-2021 18:09:38.299 INFO [main]
> > org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
> > ["http-nio-81"]
> > 16-Mar-2021 18:09:38.363 INFO [main]
> > org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
> > ["https-openssl-nio-445"]
> > 16-Mar-2021 18:09:38.364 SEVERE [main]
> > org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to
> > initialize component
> > [Connector[org.apache.coyote.http11.Http11NioProtocol-445]]
> >  org.apache.catalina.LifecycleException: Protocol handler
> > initialization failed
> >  at
> >
> org.apache.catalina.connector.Connector.initInternal(Connector.java:1055)
> >
> > On Tue, Mar 16, 2021, 18:36  wrote:
> >
> >> Dear All,
> >>
> >> Unable to start tomcat 10.0.4 and getting error Failed to initialize
> >> component.
> >> /conf/server.xml configuration as below.
> >>
> >>   >> minSpareThreads="25" enableLookups="false" redirectPort="443"
> >> acceptCount="100"
> >> connectionTimeout="302000"
> > disableUploadTimeout="true"
> >> compression="on" compressionMinSize="2048"
> >> noCompressionUserAgents="gozilla, traviata"
> >>
> >>
> >
>
> compressableMimeType="text/html,text/xml,text/javascript,application/x-javascript,application/javascript"
> >>
> >>   server=" " />
> >>
> >>   > ="org.apache.coyote.http11.Http11NioProtocol"
> >> port="443" maxHttpHeaderSize="8192" maxThreads="150"
> >>  minSpareThreads="25"
> > enableLookups="false"
> >> disableUploadTimeout="true" acceptCount="100" scheme="https"
> > secure="true"
> >>  clientAuth="false" sslProtocol="TLS"
> >> sslEnabledProtocols="TLSv1.2,TLSv1.1" SSLEnabled="true"
> >> allowUnsafeLegacyRenegotiation="false"
> >> ciphers="TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA"
> >>  keystoreFile="/conf/abc.key"
> >> keystorePass="changeit" server=" " />
> >>
> >>
> >> Getting below error in catalina log
> >>
> >> Server version name:   Apache Tomcat/10.0.4
> >> Server built:  Mar 5 2021 11:07:15 UTC
> >> Server version number: 10.0.4.0
> >> OS Name:   Windows 10
> >> OS Version:

Re: Unable to start Tomcat 10.0.4

[Robert Turner]

It's saying port 80 is already in use. Make sure another process (like IIS)
isn't using the port already, or change your configuration to a different
port.

You can use 'netstat' (with options) to determine which process is using
the port already.

On Tue., Mar. 16, 2021, 07:36 ,  wrote:

> Dear All,
>
> Unable to start tomcat 10.0.4 and getting error Failed to initialize
> component.
> /conf/server.xml configuration as below.
>
>  minSpareThreads="25" enableLookups="false" redirectPort="443"
> acceptCount="100"
>connectionTimeout="302000" disableUploadTimeout="true"
> compression="on" compressionMinSize="2048"
> noCompressionUserAgents="gozilla, traviata"
>
> compressableMimeType="text/html,text/xml,text/javascript,application/x-javascript,application/javascript"
>
>  server=" " />
>
>  port="443" maxHttpHeaderSize="8192" maxThreads="150"
> minSpareThreads="25" enableLookups="false"
> disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true"
> clientAuth="false" sslProtocol="TLS"
> sslEnabledProtocols="TLSv1.2,TLSv1.1" SSLEnabled="true"
> allowUnsafeLegacyRenegotiation="false"
>  ciphers="TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA"
> keystoreFile="/conf/eNotice.key"
> keystorePass="eNotice@1" server=" " />
>
>
> Getting below error in catalina log
>
> Server version name:   Apache Tomcat/10.0.4
> Server built:  Mar 5 2021 11:07:15 UTC
> Server version number: 10.0.4.0
> OS Name:   Windows 10
> OS Version:10.0
> Architecture:  x86
> Java Home: C:\Program Files (x86)\Java\jdk1.8.0_271\jre
> JVM Version:   1.8.0_271-b09
> JVM Vendor:Oracle Corporation
> CATALINA_BASE: D:\apache-tomcat-10.0.4
> CATALINA_HOME: D:\apache-tomcat-10.0.4
> Command line argument:
>
> -Djava.util.logging.config.file=D:\apache-tomcat-10.0.4\conf\logging.properties
> Command line argument:
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> Command line argument: -Djdk.tls.ephemeralDHKeySize=2048
> Command line argument:
> -Djava.protocol.handler.pkgs=org.apache.catalina.webresources
> Command line argument: -Dignore.endorsed.dirs=
> Command line argument: -Dcatalina.base=D:\apache-tomcat-10.0.4
> Command line argument: -Dcatalina.home=D:\apache-tomcat-10.0.4
> Command line argument: -Djava.io.tmpdir=D:\apache-tomcat-10.0.4\temp
> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded Apache
> Tomcat Native library [1.2.26] using APR version [1.7.0].
> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR
> capabilities: IPv6 [true], sendfile [true], accept filters [false], random
> [true], UDS [true].
> org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL
> successfully initialized [OpenSSL 1.1.1i  8 Dec 2020]
> org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
> ["http-nio-80"]
> org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to
> initialize component [Connector[null-80]]
> org.apache.catalina.LifecycleException: Protocol handler
> initialization failed
> at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:1055)
> at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
> at
>
> org.apache.catalina.core.StandardService.initInternal(StandardService.java:558)
> at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
> at
>
> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:1045)
> at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
> at
> org.apache.catalina.startup.Catalina.load(Catalina.java:747)
> at
> org.apache.catalina.startup.Catalina.load(Catalina.java:769)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:302)
> at
> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:472)
> Caused by: java.net.BindException: Address already in use: bind
> at sun.nio.ch.Net.bind0(Native Method)
> at sun.nio.ch.Net.bind(Net.java:444)
> at sun.nio.ch.Net.bind(Net.java:436)
> at
> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:225)
> at
> org.apache.tomcat.util.net
> .NioEndpoint.initServerSocket(NioEndpoint.java:243)
> at
> 

Re: Out of memory exception

[Robert Turner]

Have you tried enabling heap dumps on OOM exceptions (
https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/clopts001.html
; HeapDumpOnOutOfMemoryError) and then looking at the heap dump? It should
help you identify where the allocated heap is going to, and give you some
ideas of where to look next.


On Thu, Feb 18, 2021 at 2:12 PM Niranjan Rao  wrote:

> Hi Shawn
>
> Thank you the response. This is not a web application, but a standalone
> java program. Hence I said it's not a tomcat question, but a generic JVM
> question. I have been researching about this a lot and based on many
> mails on this list, lot of people here know about internal behavior of
> JVM and specs lot better than I do.
>
> Both the boxes are spawned from same AWS image, we build the image.
> There is no other difference. Both receive tasks over MQ.  Tasks could
> be slightly different - like for different users, number of entities
> user holds etc, but they should not be too different or kind of should
> average out in the long run. We have examined the data for the tasks and
> nothing unusual has come out so far.
>
> Regards,
>
> Niranjan
> On 2/18/21 10:59 AM, Shawn Heisey wrote:
>
> Regards,
>
> Niranjan
>
> > On 2/18/2021 11:36 AM, Niranjan Rao wrote:
> >> First apologies for non tomcat question. I have seen that there is
> >> enough expertise here to provide hints and hints are what I am
> >> looking for to solve the problem and question is generic enough. I
> >> have tried researching problem to best of my abilities.
> >
> > I believe you're right to think this isn't a tomcat question. There
> > are a lot of things it could be.  Tomcat is a *possible* source,
> > though I think the chance of that is low.  Without a LOT of info that
> > I would probably be useless at interpreting or asking for, it's
> > impossible to say for sure.
> >
> > With problems like this, it is normally the application running inside
> > Tomcat that has a problem, not Tomcat itself.  You're likely to get a
> > lot more useful information if you go to the people responsible for
> > those applications.
> >
> >> We have a java program that regularly throws
> >> "java.lang.OutOfMemoryError: Java heap space" exception. Puzzling
> >> point is it happens only on one VM. We have a set of two VMs/boxes
> >> spawned from same AWS image. Machine class/region is exactly same and
> >> since they are from same image, they should be mostly identical
> >> except stuff like host name, ip address etc.
> >>
> >> Number of tasks performed by VMs are comparable and not a significant
> >> difference. Yet, one VM never runs of out of memory and other one
> >> does. Sometimes it's as soon as half an hour after restarting the
> >> process while on the other box process is running for days and no
> >> issues.
> >
> > "Comparable" isn't "identical".
> >
> > Are they running the same apps?  Which apps are involved?  Is the one
> > that's throwing OOME handling substantially similar requests when
> > compared to one that doesn't?  Is the request rate nearly the same, or
> > is the problematic one handling a lot more?  Another applicable
> > question, also off topic for this mailing list:  Are the apps in both
> > cases configured identically?
> >
> >> I took memory dumps from both VMs and they look similar. Program is
> >> started with -Xmx1g flag and we have taken regular memory dumps. In
> >> many cases eclipse MAT reports total memory usage was less than 100MB
> >> when program crashed with out of memory exception.
> >
> > That's extremely odd, unless the application requested a REALLY big
> > chunk of memory such that the 100MB existing plus the new allocation
> > would be larger than the max heap size of 1GB.
> >
> > Do you have enough free memory that you could increase the max heap to
> > 2GB or beyond and see what happens?
> >
> >> Has anyone seen anything similar to this? Identical bits of code
> >> behaving differently? What else should I be looking for?
> >
> > Earlier you said "comparable" and now you're saying "identical". So I
> > have to ask ... which is it?  Remember that differences in
> > configurations, types of requests, and request load can lead to very
> > different requirements, even if the apps running inside Tomcat are the
> > same.
> >
> > Most of my experience in the Java world comes from Solr.  Apache Solr
> > is a servlet application, and ships with Jetty.  Tomcat is not usually
> > involved.  I joined this mailing list because I was responsible for
> > Tomcat servers running apps developed in-house, and every once in a
> > while, I needed to ask something tomcat-specific.
> >
> > Thanks,
> > Shawn
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: 

Re: Security Vulnerability -Default files

[Robert Turner]

ectations a bit high, and you may come away frustrated or
disappointed as a result.

To best benefit from this group, a person needs to put in a reasonable
amount of effort to try to learn how Tomcat works, and how their
installation is set up and working (or not working as the case may be).
Once that is achieved, it is easier for that person to then describe their
Tomcat installation, and pose specific questions about their problems, and
then, the group would likely be more able (and willing) to provide help to
solve them.

If, for whatever reason, you don't have enough time to learn how it works
and/or how your instance is set up, I strongly suggest looking for an
experienced _paid_ consultant to do the work for you. (I do not have any
suggestions on where to look for one though.)


Robert



On Thu, Jan 21, 2021 at 10:43 PM Nitin Kadam 
wrote:

> Thank you Robert for your reply.
>
> If we upgrade the tomcat version from the current 8.5.38 to 8.5.61 will
> this remediate the findings or still we need to delete these files as
> suggested.
>
> Also, is this upgrade is straightforward, or do we need to perform the same
> with any specific steps, Please suggest.
>
> I am from a Windows Administrator background and hence facing these
> challenges, So expecting help from you and this group.
>
> On Thu, Jan 21, 2021 at 8:06 PM Robert Turner 
> wrote:
>
> > Have a look at
> > https://tomcat.apache.org/tomcat-8.5-doc/security-howto.html
> > . The documentation includes the recommendations made by your internal
> > security team, along with others.
> >
> > You may also want to upgrade to 8.5.61 or 9.0.41 to pick up the latest
> > security updates for Tomcat. (latest versions at time of writing)
> >
> >
> > If you are unsure how to delete the files as mentioned in your security
> > teams recommendations and the documentation, you have two approaches
> that I
> > can think of quickly:
> >
> > 1. Remove the files from the installation folder (by navigating to the
> > installed folder under program files, in "webapps" and removing the
> > files/folders).
> >
> > 2. Create a new CATALINA_BASE folder with only what you need, and
> > reconfigure the Windows service to use the new folder. (Use the Configure
> > Tomcat application shortcut, and change the "catalina.base" property
> passed
> > to Java when starting the service to point to your new folder with only
> the
> > things you need (start with a copy of the Tomcat installation folder,
> > remove "bin" and "lib" and the webapps/files you do not need.). This
> > approach avoids modifying the original installation files/folders.
> >
> > You may also be able to modify the installation settings of the
> application
> > using Add or Remove Programs in Windows Control Panel to remove the
> example
> > applications if you'd prefer that approach instead of #1 above, but that
> > might require reinstalling Tomcat again.
> >
> > Best of luck,
> >
> > Robert
> >
> >
> > On Thu, Jan 21, 2021 at 9:24 AM Nitin Kadam 
> > wrote:
> >
> > > Hi Team,
> > >
> > > The internal security team reported below as Security findings. We do
> not
> > > have anyone from a Tomcat background and for same we need to know the
> > best
> > > steps to resolve this issue.
> > >
> > > "Delete the default index page and remove the example JSP and servlets.
> > > Follow the Tomcat or OWASP instructions to replace or modify the
> default
> > > error page."
> > >
> > > this is fiding from the Nessus tool, It would be great if someone helps
> > > with steps to resolve.
> > >
> > > APache tomcat version: 8.5.38
> > > Operating system: Windows Server 2012 R2
> > >
> > >
> > > --
> > > Regards
> > > Nitin Kadam
> > > (9967688959)
> > >
> >
>
>
> --
> Regards
> Nitin Kadam
> (9967688959)
>

Re: Security Vulnerability -Default files

[Robert Turner]

Have a look at https://tomcat.apache.org/tomcat-8.5-doc/security-howto.html
. The documentation includes the recommendations made by your internal
security team, along with others.

You may also want to upgrade to 8.5.61 or 9.0.41 to pick up the latest
security updates for Tomcat. (latest versions at time of writing)


If you are unsure how to delete the files as mentioned in your security
teams recommendations and the documentation, you have two approaches that I
can think of quickly:

1. Remove the files from the installation folder (by navigating to the
installed folder under program files, in "webapps" and removing the
files/folders).

2. Create a new CATALINA_BASE folder with only what you need, and
reconfigure the Windows service to use the new folder. (Use the Configure
Tomcat application shortcut, and change the "catalina.base" property passed
to Java when starting the service to point to your new folder with only the
things you need (start with a copy of the Tomcat installation folder,
remove "bin" and "lib" and the webapps/files you do not need.). This
approach avoids modifying the original installation files/folders.

You may also be able to modify the installation settings of the application
using Add or Remove Programs in Windows Control Panel to remove the example
applications if you'd prefer that approach instead of #1 above, but that
might require reinstalling Tomcat again.

Best of luck,

Robert


On Thu, Jan 21, 2021 at 9:24 AM Nitin Kadam 
wrote:

> Hi Team,
>
> The internal security team reported below as Security findings. We do not
> have anyone from a Tomcat background and for same we need to know the best
> steps to resolve this issue.
>
> "Delete the default index page and remove the example JSP and servlets.
> Follow the Tomcat or OWASP instructions to replace or modify the default
> error page."
>
> this is fiding from the Nessus tool, It would be great if someone helps
> with steps to resolve.
>
> APache tomcat version: 8.5.38
> Operating system: Windows Server 2012 R2
>
>
> --
> Regards
> Nitin Kadam
> (9967688959)
>

Re: TomCat 9 service failed to start on Windows after TomCat 9 update

[Robert Turner]

I would check permissions on the folders/files. The account running the
windows service may not have permissions to execute the programs or maybe
access the directories. That's the first thing I would check. (Also check
Event Viewer for any related messages).

On Fri, Jan 15, 2021 at 8:24 AM Igor Sluge  wrote:

>
>
> Hello,
> I updated TomCat for my app to the latest TomCat 9.0.41 and after update
> TomCat service failed to start successfully as Windows service. I just see
> 404 error when trying to open the TomCat app. Also there are no logs at all
> in the log directory! If I start TomCat locally by the command
> tomcat9.exe" //TS//MyApp   it started successfully.
> OS: Windows 7 and Server 2012
> Does anybody have any ideas of how to troubleshoot this issue?
>
>

Re: Browser complains of "weak signature algorithm" in cert on a new Tomcat installation. Does anybody here know anything about that sort of thing

[Robert Turner]

You'll want to set the protocols, ciphers, and honorCipherOrder attributes
on either the Connector or the SSLHostConfig objects in your server.xml
file to restrict the available TLS/SSL protocols and ciphers available to
avoid using weak ones.

See the documentation here for details:
https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#SSL_Support

For example (please pick TLS levels and ciphers for your application --
this may not suit your requirements):














On Wed, Jan 6, 2021 at 6:34 PM James H. H. Lampert 
wrote:

> We just had our first Tomcat 8.5 installation on a customer's AS/400.
>
> The customer apparently has his own CA (they're a big company), and when
> I installed SSL in their Tomcat, and tested it with a browser, it
> complained, something to the general effect of "weak signature algorithm."
>
> While it's not really my problem (and is only connected to Tomcat by
> virtue of it happening with a Tomcat server), I'm curious about what's
> up with it, if anybody here is able and willing to explain it.
>
> Of course, a customer that's big enough to run a private CA in
> production is already doing things beyond my pay grade.
>
> --
> JHHL
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: TLS on Tomcat: Using ECC and RSA certificates together -- invalid intermediate certificate in chain

[Robert Turner]

Not a problem -- that was my issue as well, I'm just not familiar with the
code, and it can take a while to figure it out.
In the meantime, we're testing with only ECC the certificate for now, but
of course it would be nice to have both.

Thanks for looking into it.



On Fri, Dec 11, 2020 at 12:56 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Robert,
>
> On 12/9/20 21:31, Robert Turner wrote:
> > Actually, one incorrect statement in my previous response. testssl.sh
> > didn't report the details of the certificate chain, only that it was
> > broken. I used https://ssllabs.com/ssltest/analyze.html as well, and it
> > reported the specific details of the certificate chain (and that the
> chain
> > was also broken).
> >
> > Sorry about that.
>
> No problem.
>
> Sad to see that the single-file didn't work, though Tomcat should have
> known enough to link server cert + chain cert in the  in a
> way that httpd actually can't be configured to do. (In httpd, it appears
> that single-file cert+chain ought to work, though I haven't tried it).
>
> I will have to look more deeply at how Tomcat constructs those chains.
> Tomcat creates a Keystore in memory containing all those PEM
> certificates and hands it off to to the Java ServerSocketFactory which
> makes all the decisions about which certificates and chains it will
> provide.
>
> But each certificate specifies its signer's identity and the signer's
> certificate is available, so ... I don't see why there would be any
> confusion in there.
>
> When you use OpenSSL (which you ARE using, though the APR connector is
> disabled based upon the useAprConnector="false" you can see on startup),
> the process is the same except that the certificate and key material are
> extracted from the KeyStore as if it were specified in PEM files. So it
> should (theoretically) all be the same.
>
> Something isn't quite right.
>
> This will probably take me a long while to figure out (because of my
> lack of familiarity with the code and even what's expected to happen),
> but others (ahem, Markt) can probably answer from memory and maybe even
> get it patched quickly.
>
> So... apologies if this takes a while to investigate.
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: TLS on Tomcat: Using ECC and RSA certificates together -- invalid intermediate certificate in chain

[Robert Turner]

Actually, one incorrect statement in my previous response. testssl.sh
didn't report the details of the certificate chain, only that it was
broken. I used https://ssllabs.com/ssltest/analyze.html as well, and it
reported the specific details of the certificate chain (and that the chain
was also broken).

Sorry about that.

Robert



On Wed, Dec 9, 2020 at 9:22 PM Robert Turner  wrote:

> Thanks Chris for replying.
>
> I'm pretty sure I'm using the APR connector. Without double-checking how
> things are configured... the startup logs show:
>
> 09-Dec-2020 21:05:25.689 INFO [main]
> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded Apache
> Tomcat Native library [1.2.24] using APR version [1.7.0].
> 09-Dec-2020 21:05:25.689 INFO [main]
> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR
> capabilities: IPv6 [true], sendfile [true], accept filters [false], random
> [true].
> 09-Dec-2020 21:05:25.689 INFO [main]
> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR/OpenSSL
> configuration: useAprConnector [false], useOpenSSL [true]
> 09-Dec-2020 21:05:25.704 INFO [main]
> org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL
> successfully initialized [OpenSSL 1.1.1g  21 Apr 2020]
>
> On your ECC/RSA separately question: yes, each one works fine by itself.
>
> I'm not sure what testssl.sh does specifically to verify the chains for
> each certificate. I haven't dug into its source yet, but it reports that
> the chain for my RSA certificate has the wrong intermediate (and shows the
> intermediate for the ECC certificate). So, with minimal examination, to me
> it suggests that Tomcat/OpenSSL is not exposing the correct intermediate
> certificate when presenting the RSA certificate chain for validation by the
> client.
>
>
> I may be able to request the re-issue, but I'm running with fairly
> inexpensive certificates, so it might be a bit more of a challenge to get
> done, but I could try -- that was going to be my "last resort" approach.
>
> I'm not clear on it either -- I'm not sure it's a requirement per say from
> what I can tell, but maybe just a limitation of the implementation. But I
> haven't done enough research (yet) into how TLS negotiation works, or the
> implementation of OpenSSL to offer a non-speculative conclusion. I was
> sort-of hoping to avoid a 2 or 3 day diversion to learn enough about it all.
>
> I had been planning on trying the combined certificates in single files to
> see if it worked (As it was the only idea that I had based on looking at
> the code and how it "saved" the certificates for use), and just kicked it
> off the changes while typing this up. (time to check the results)
>
> With the combined certificates (in order) in the main certificate file,
> both certificates now get reported by testssl.sh as:
>Chain of trust   NOT ok (chain incomplete)
>
> And when I connect using "openssl s_client -connect :", I see
> only the initial certificate in the server response, where normally I would
> see the chain listed out up to the root CA.
>
> So unfortunately, it looks like that doesn't quite work properly either.
>
> Robert
>
> On Wed, Dec 9, 2020 at 8:38 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
>> Robert,
>>
>> On 12/9/20 17:54, Robert Turner wrote:
>> > I am trying to configure Tomcat 9.0.37 (or later if I need to) to use
>> both
>> > an RSA and an ECC certificate for the same host.
>> >
>> > Platform is Windows 2008 R2, with the Tomcat Native 1.2.24 library
>> > installed.
>>
>> Do you know if you are using the APR connector or the NIO(2) connector?
>>
>> > My configuration is roughly as follows:
>> >
>> >
>> >  > >honorCipherOrder="true"
>> >ciphers=""
>> >hostName="*.blahblah.com">
>> >  > certificateKeyFile="conf/blahblah_com_priv.key"
>> >   certificateFile="conf/blahblah_com.crt"
>> >
>> >   certificateChainFile="conf/blahblah_com.intermediate.crt"
>> >   type="RSA"
>> > />
>> >  > > certificateKeyFile="conf/blahblah_com_com-ECC.private.key"
>> >   certificateFile="conf/blahblah_com-ECC.pem"
>> >
>> >   certificateChainFile="conf/blahblah_com-ECC.intermediate.pem"
>> >   type="EC"
>> > />
>> >  
>> >
>> 

Re: TLS on Tomcat: Using ECC and RSA certificates together -- invalid intermediate certificate in chain

[Robert Turner]

Thanks Chris for replying.

I'm pretty sure I'm using the APR connector. Without double-checking how
things are configured... the startup logs show:

09-Dec-2020 21:05:25.689 INFO [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded Apache
Tomcat Native library [1.2.24] using APR version [1.7.0].
09-Dec-2020 21:05:25.689 INFO [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR
capabilities: IPv6 [true], sendfile [true], accept filters [false], random
[true].
09-Dec-2020 21:05:25.689 INFO [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR/OpenSSL
configuration: useAprConnector [false], useOpenSSL [true]
09-Dec-2020 21:05:25.704 INFO [main]
org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL
successfully initialized [OpenSSL 1.1.1g  21 Apr 2020]

On your ECC/RSA separately question: yes, each one works fine by itself.

I'm not sure what testssl.sh does specifically to verify the chains for
each certificate. I haven't dug into its source yet, but it reports that
the chain for my RSA certificate has the wrong intermediate (and shows the
intermediate for the ECC certificate). So, with minimal examination, to me
it suggests that Tomcat/OpenSSL is not exposing the correct intermediate
certificate when presenting the RSA certificate chain for validation by the
client.


I may be able to request the re-issue, but I'm running with fairly
inexpensive certificates, so it might be a bit more of a challenge to get
done, but I could try -- that was going to be my "last resort" approach.

I'm not clear on it either -- I'm not sure it's a requirement per say from
what I can tell, but maybe just a limitation of the implementation. But I
haven't done enough research (yet) into how TLS negotiation works, or the
implementation of OpenSSL to offer a non-speculative conclusion. I was
sort-of hoping to avoid a 2 or 3 day diversion to learn enough about it all.

I had been planning on trying the combined certificates in single files to
see if it worked (As it was the only idea that I had based on looking at
the code and how it "saved" the certificates for use), and just kicked it
off the changes while typing this up. (time to check the results)

With the combined certificates (in order) in the main certificate file,
both certificates now get reported by testssl.sh as:
   Chain of trust   NOT ok (chain incomplete)

And when I connect using "openssl s_client -connect :", I see
only the initial certificate in the server response, where normally I would
see the chain listed out up to the root CA.

So unfortunately, it looks like that doesn't quite work properly either.

Robert

On Wed, Dec 9, 2020 at 8:38 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Robert,
>
> On 12/9/20 17:54, Robert Turner wrote:
> > I am trying to configure Tomcat 9.0.37 (or later if I need to) to use
> both
> > an RSA and an ECC certificate for the same host.
> >
> > Platform is Windows 2008 R2, with the Tomcat Native 1.2.24 library
> > installed.
>
> Do you know if you are using the APR connector or the NIO(2) connector?
>
> > My configuration is roughly as follows:
> >
> >
> >   >honorCipherOrder="true"
> >ciphers=""
> >hostName="*.blahblah.com">
> >   >   certificateFile="conf/blahblah_com.crt"
> >
> >   certificateChainFile="conf/blahblah_com.intermediate.crt"
> >   type="RSA"
> > />
> >   > certificateKeyFile="conf/blahblah_com_com-ECC.private.key"
> >   certificateFile="conf/blahblah_com-ECC.pem"
> >
> >   certificateChainFile="conf/blahblah_com-ECC.intermediate.pem"
> >   type="EC"
> > />
> >  
> >
> >
> > The only change I've made was to add the additional Certificate element
> for
> > the ECC certificate (so I believe everything else about our configuration
> > is all good.
> >
> > When I run "testssh.sh" against the host, I end up with a failed
> > certificate chain for the RSA certificate. The ECC certificate is all
> fine
> > though, and before adding the ECC certificate, the RSA certificate was
> fine.
>
> Hmm. So if you specify either RSA or EC alone, with the certificate
> chain, all is well (aside from the fact that you can only use one of the
> two certs)?
>
> What does testssh.sh do?
>
> > I've dug into the documentation and found this statement with reference
> to
> > the certificateChainFile parameter:
> >
> > "Note that when using more t

TLS on Tomcat: Using ECC and RSA certificates together -- invalid intermediate certificate in chain

[Robert Turner]

I am trying to configure Tomcat 9.0.37 (or later if I need to) to use both
an RSA and an ECC certificate for the same host.

Platform is Windows 2008 R2, with the Tomcat Native 1.2.24 library
installed.

My configuration is roughly as follows:








The only change I've made was to add the additional Certificate element for
the ECC certificate (so I believe everything else about our configuration
is all good.

When I run "testssh.sh" against the host, I end up with a failed
certificate chain for the RSA certificate. The ECC certificate is all fine
though, and before adding the ECC certificate, the RSA certificate was fine.

I've dug into the documentation and found this statement with reference to
the certificateChainFile parameter:

"Note that when using more than one certificate for different types, they
all must use the same certificate chain"

So I checked the Git repo, and that was added with a commit comment that
references the Apache HTTP configuration which states something slightly
differently:

"But be careful: Providing the certificate chain works only if you are
using a single RSA or DSA based server certificate. If you are using a
coupled RSA+DSA certificate pair, this will work only if actually both
certificates use the same certificate chain. Else the browsers will be
confused in this situation."

The two statements suggest slightly different things. However the second
doesn't suggest that ECC and RSA cannot be combined with different chains.

Is there any way to have two different certificate chains for the ECC and
RSA certificates and get it working with Tomcat/OpenSSL? (as we don't have
certificates with the same chains as our provider seems to use different
intermediate CAs for ECC versus RSA).


Thanks for any suggestions anyone can provide,

Robert