Tomcat 9.0.87 - status 400 in css / images
Hi guys. Tomcat 9.0.87 (and Tomcat 9.0.76) Ubuntu 22.04 (and Red hat 8) java 8 : openjdk version "1.8.0_382" protocol: HTTP I have migrated an application from tomcat 7 (7.0.76) to tomcat 9.0.76 (and also to tomcat 9.0.87) After upgrading to Tomcat 9.0.76, the web page is not displaying correctly as some CSS/images are returning HTTP status 400. If we reload the browser, it works fine. When this happens, the "type" of the resources is text/html . My error is similar to this: https://stackoverflow.com/questions/77989064/intermittently-getting-status-400-for-js-css-images-after-upgrading-to-tomcat-9 Any configuration I may be missing? Any advice to solve this error is welcome. thank you Angel
RE: [EXT]Re: Tomcat session replication issue - java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute :
Thank you very much Chris
The classes my app uses should be serialize anyway so I just go that route.
But thanks for that code snippet too
Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com
-Original Message-
From: Christopher Schultz
Sent: Friday, March 22, 2024 2:36 PM
To: Tomcat Users List ; Rick Noel
Subject: Re: [EXT]Re: Tomcat session replication issue -
java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute :
Rick,
On 3/22/24 13:33, Rick Noel wrote:
> I do not want to replicate customer because that class does not
> implement serializable
>
> I was looking for someway that the Manager would NOT try to replicate
> it
This is an allow-list which is much more secure than a deny-list.
It's a regular expression, so you can feel free to get super-creative with the
expression if you want to effectively create a deny-list with one item.
Honestly, this is probably some technical dept worth paying off at this point.
Another option would be to store the object in a wrapper in the session that
*is* serializable but it doesn't actually try to serialize the object it wraps.
I did one of these ages ago for similar reasons: I didn't want to go change all
those classes to be Serializable. Here it is:
public class TransientObjectWrapper
implements Serializable
{
private static final long serialVersionUID = -4694896879363833304L;
private transient final T _o;
public TransientObjectWrapper(T o) { _o = o; }
public T getWrappedObject() { return _o; } }
Using this plus a craftily-written Filter, HttpServletRequestWrapper, and
HttpSession implementation would allow you to do this kind of thing without any
failures.
Or you could just configure Tomcat's already flexible allow-list for session
attribute names.
-chris
> -Original Message-
> From: Mark Thomas
> Sent: Friday, March 22, 2024 1:27 PM
> To: users@tomcat.apache.org
> Subject: Re: [EXT]Re: Tomcat session replication issue -
> java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute :
>
> On 22/03/2024 15:43, Rick Noel wrote:
>> Mark,
>>
>> So if my customer object is failing to get set in the session
>> replication, I could add this to the config snippet?
>>
>> sessionAttributeNameFilter="customer"
>
> You set that to the attributes you DO want to replicate, not the ones you
> don't.
>
> Mark
>
>>
>> so like this?...
>>
>>
>> >channelSendOptions="6">
>>
>> > className="org.apache.catalina.ha.session.DeltaManager"
>> expireSessionsOnShutdown="false"
>>
>> notifyListenersOnReplication="true"
>> maxActiveSessions="8192"
>>
>> sessionAttributeNameFilter="customer"
>> />
>>
>> > className="org.apache.catalina.tribes.group.GroupChannel">
>> > className="org.apache.catalina.tribes.membership.McastService"
>> address="228.0.0.4"
>> port="45564"
>> frequency="500"
>> dropTime="3000"/>
>> > className="org.apache.catalina.tribes.transport.nio.NioReceiver"
>> address="auto"
>> port="5000"
>> selectorTimeout="100"
>> maxThreads="6"/>
>>
>> > className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
>> > className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
>>
>> > className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
>> > className="org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor"/>
>> > className="org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor"/>
>>
>>
>> > className="org.apache.catalina.ha.tcp.ReplicationValve"
>>
>> filter=".*\.gif|.*\.js|.*\.jpeg|.*\.jpg|.*\.png|.*\.htm|.*\.html|.*\.
>> c
>> ss|.*\.txt"/>
>>
>>
>> > className="org.apache.catalina.ha.session.ClusterSessionListener"/>
>>
>>
>>
>>
>>
>>
>> Rick
Re: HttpSession tracking
Robert. On 3/22/24 14:11, Robert Turner wrote: 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). Or, more likely, whoever implemented it discovered that you *must* have a singleton for this kind of thing, and didn't just get lucky. :) 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). The container does. It's in the spec :) If you haven't read it, it's 100% worth reading and it's quite readable. It was written by real humans trying to get a job done and not lawyers. or whatever. Although the one you quoted does seem to be "clear enough" at least to me (not sure if your comments were sarcastic or not). Nope. I meant "I either didn't read this, or ignored what it said" because there really is no confusion, there. 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). I can't know why the original design was the way that it was. Would be interesting to be able to have an "observer" listener that doesn't have to be put into each and every session? Possibly. But this isn't particularly "expensive" to implement using the existing interfaces and their existing semantics. My guess is that sessionWillPassivate and sessionDidActivate are there so that caches, connections to other systems, etc. can be re-created after a session comes back into memory for things that aren't appropriate to be Serializable. Maybe that's not appropriate for *every* session and also if you put 10 caches into a session you just implement each of your 10 re-creation algorithms separately. If you had one uber-listener, it would have to understand how to re-create all 10 of those caches and so the fine-grained notification system is actually more flexible. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [EXT]Re: Tomcat session replication issue - java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute :
Rick,
On 3/22/24 13:33, Rick Noel wrote:
I do not want to replicate customer because that class does not
implement serializable
I was looking for someway that the Manager would NOT try to replicate
it
This is an allow-list which is much more secure than a deny-list.
It's a regular expression, so you can feel free to get super-creative
with the expression if you want to effectively create a deny-list with
one item.
Honestly, this is probably some technical dept worth paying off at this
point.
Another option would be to store the object in a wrapper in the session
that *is* serializable but it doesn't actually try to serialize the
object it wraps.
I did one of these ages ago for similar reasons: I didn't want to go
change all those classes to be Serializable. Here it is:
public class TransientObjectWrapper
implements Serializable
{
private static final long serialVersionUID = -4694896879363833304L;
private transient final T _o;
public TransientObjectWrapper(T o) { _o = o; }
public T getWrappedObject() { return _o; }
}
Using this plus a craftily-written Filter, HttpServletRequestWrapper,
and HttpSession implementation would allow you to do this kind of thing
without any failures.
Or you could just configure Tomcat's already flexible allow-list for
session attribute names.
-chris
-Original Message-
From: Mark Thomas
Sent: Friday, March 22, 2024 1:27 PM
To: users@tomcat.apache.org
Subject: Re: [EXT]Re: Tomcat session replication issue -
java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute :
On 22/03/2024 15:43, Rick Noel wrote:
Mark,
So if my customer object is failing to get set in the session
replication, I could add this to the config snippet?
sessionAttributeNameFilter="customer"
You set that to the attributes you DO want to replicate, not the ones you don't.
Mark
so like this?...
filter=".*\.gif|.*\.js|.*\.jpeg|.*\.jpg|.*\.png|.*\.htm|.*\.html|.*\.c
ss|.*\.txt"/>
Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com
-Original Message-
From: Mark Thomas
Sent: Friday, March 22, 2024 11:32 AM
To: users@tomcat.apache.org
Subject: [EXT]Re: Tomcat session replication issue -
java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute :
On 22/03/2024 15:15, Rick Noel wrote:
Is there a way to configure DeltaManager or the Cluster element so it does not
cause my application to throw this error.
22-Mar-2024 10:56:34.382 SEVERE [http-nio-8586-exec-5]
org.apache.catalina.core.StandardWrapperValve.invoke
Servlet.service() for servlet [jsp] in context with path [##0001]
threw exception [An exception occurred processing
[/services/include/properties.jsp] at line [196]
193:
194:session.setAttribute( "format", stationFormat );
195:session.setAttribute( "employee_id", employeeId );
196:session.setAttribute( "customer", customer );
197:session.setAttribute( "customer_id", customerId );
198:session.setAttribute( "nonidentifier_call_letters",
nonIdentifierCallLetters );
199:session.setAttribute( "call_letters", callLetters );
Stacktrace:] with root cause
java.lang.IllegalArgumentException: setAttribute:
Non-serializable attribute [customer]
I know why the error, it is because the customer object was never written to
be serialiazable.
The old application I am working on has a lot of such non serialized
objects and I do not want to search out change them all to implement
serialiazable
I am hoping there is a way to configure Tomcat to just not try and
replication sessions all object which are not serialiazable
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftomc
at.apache.org%2Ftomcat-10.1-doc%2Fconfig%2Fmanager.html=05%7C02%7
CRNoel%40westwoodone.com%7C1b723f1052ef4e59bf0808dc4a959af2%7Ce5d6709f
becf4b058cee37f5a62617c4%7C0%7C0%7C638467253633727340%7CUnknown%7CTWFp
bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
0%3D%7C0%7C%7C%7C=o5SvJv%2FM4QtRYM%2BEk18%2For7R81deb1g%2BW7N7XS
rMwuM%3D=0
Search for sessionAttributeNameFilter
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
CAUTION: This email originated from outside of the organization. Do
Re: HttpSession tracking
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 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). > > > > So... by went ahead and loaded-up this class with *everything* - > > including putting the listener class instance into every session and I > > do indeed get "session will passivate" and
Re: HttpSession tracking
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 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).
So... by went ahead and loaded-up this class with *everything* -
including putting the listener class instance into every session and I
do indeed get "session will passivate" and "session has activated" log
messgaes.
So I started removing things and it kept working until ... it didn't.
I'm trying to track-down exactly what difference makes it work, but it
doesn't many any sense to me.
The StandardManager code looks like this:
if (log.isTraceEnabled()) {
log.trace("Loading " + n + " persisted sessions");
}
for (int i = 0; i < n; i++) {
StandardSession session = getNewSession();
session.readObjectData(ois);
session.setManager(this);
sessions.put(session.getIdInternal(), session);
session.activate();
if (!session.isValidInternal()) {
// If session is already invalid,
// expire session to prevent memory leak.
session.setValid(true);
session.expire();
}
sessionCounter++;
}
and StandardSession.activate looks like this:
public void activate() {
// Initialize access count
if (ACTIVITY_CHECK) {
accessCount = new AtomicInteger();
}
// Notify interested session event listeners
fireSessionEvent(SESSION_ACTIVATED_EVENT, null);
// Notify ActivationListeners
HttpSessionEvent event = null;
String keys[] = keys();
for (String key : keys) {
Object attribute = attributes.get(key);
if (attribute instanceof HttpSessionActivationListener) {
if (event == null) {
event = new HttpSessionEvent(getSession());
}
try {
((HttpSessionActivationListener)
attribute).sessionDidActivate(event);
} catch (Throwable
RE: [EXT]Re: Tomcat session replication issue - java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute :
I do not want to replicate customer because that class does not implement serializable I was looking for someway that the Manager would NOT try to replicate it Rick Noel Systems Programmer | Westwood One rn...@westwoodone.com -Original Message- From: Mark Thomas Sent: Friday, March 22, 2024 1:27 PM To: users@tomcat.apache.org Subject: Re: [EXT]Re: Tomcat session replication issue - java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute : On 22/03/2024 15:43, Rick Noel wrote: > Mark, > > So if my customer object is failing to get set in the session > replication, I could add this to the config snippet? > > sessionAttributeNameFilter="customer" You set that to the attributes you DO want to replicate, not the ones you don't. Mark > > so like this?... > > >channelSendOptions="6"> > > className="org.apache.catalina.ha.session.DeltaManager" > expireSessionsOnShutdown="false" > > notifyListenersOnReplication="true" > maxActiveSessions="8192" > > sessionAttributeNameFilter="customer" > /> > > className="org.apache.catalina.tribes.group.GroupChannel"> > className="org.apache.catalina.tribes.membership.McastService" > address="228.0.0.4" > port="45564" > frequency="500" > dropTime="3000"/> > className="org.apache.catalina.tribes.transport.nio.NioReceiver" >address="auto" >port="5000" >selectorTimeout="100" >maxThreads="6"/> > > className="org.apache.catalina.tribes.transport.ReplicationTransmitter"> > className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/> > > className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/> > className="org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor"/> > className="org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor"/> > > > className="org.apache.catalina.ha.tcp.ReplicationValve" > > filter=".*\.gif|.*\.js|.*\.jpeg|.*\.jpg|.*\.png|.*\.htm|.*\.html|.*\.c > ss|.*\.txt"/> > > > className="org.apache.catalina.ha.session.ClusterSessionListener"/> > > > > > > > Rick Noel > Systems Programmer | Westwood One > rn...@westwoodone.com > > -Original Message- > From: Mark Thomas > Sent: Friday, March 22, 2024 11:32 AM > To: users@tomcat.apache.org > Subject: [EXT]Re: Tomcat session replication issue - > java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute : > > On 22/03/2024 15:15, Rick Noel wrote: >> Is there a way to configure DeltaManager or the Cluster element so it does >> not cause my application to throw this error. >> >> 22-Mar-2024 10:56:34.382 SEVERE [http-nio-8586-exec-5] >> org.apache.catalina.core.StandardWrapperValve.invoke >> Servlet.service() for servlet [jsp] in context with path [##0001] >> threw exception [An exception occurred processing >> [/services/include/properties.jsp] at line [196] >> >> 193: >> 194:session.setAttribute( "format", stationFormat ); >> 195:session.setAttribute( "employee_id", employeeId ); >> 196:session.setAttribute( "customer", customer ); >> 197:session.setAttribute( "customer_id", customerId ); >> 198:session.setAttribute( "nonidentifier_call_letters", >> nonIdentifierCallLetters ); >> 199:session.setAttribute( "call_letters", callLetters ); >> >> >> Stacktrace:] with root cause >> java.lang.IllegalArgumentException: setAttribute: >> Non-serializable attribute [customer] >> >> >> I know why the error, it is because the customer object was never written >> to be serialiazable. >> The old application I am working on has a lot of such non serialized >> objects and I do not want to search out change them all to implement >> serialiazable >> >> I am hoping there is a way to configure Tomcat to
Re: [EXT]Re: Tomcat session replication issue - java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute :
On 22/03/2024 15:43, Rick Noel wrote: Mark, So if my customer object is failing to get set in the session replication, I could add this to the config snippet? sessionAttributeNameFilter="customer" You set that to the attributes you DO want to replicate, not the ones you don't. Mark so like this?... Rick Noel Systems Programmer | Westwood One rn...@westwoodone.com -Original Message- From: Mark Thomas Sent: Friday, March 22, 2024 11:32 AM To: users@tomcat.apache.org Subject: [EXT]Re: Tomcat session replication issue - java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute : On 22/03/2024 15:15, Rick Noel wrote: Is there a way to configure DeltaManager or the Cluster element so it does not cause my application to throw this error. 22-Mar-2024 10:56:34.382 SEVERE [http-nio-8586-exec-5] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [jsp] in context with path [##0001] threw exception [An exception occurred processing [/services/include/properties.jsp] at line [196] 193: 194:session.setAttribute( "format", stationFormat ); 195:session.setAttribute( "employee_id", employeeId ); 196:session.setAttribute( "customer", customer ); 197:session.setAttribute( "customer_id", customerId ); 198:session.setAttribute( "nonidentifier_call_letters", nonIdentifierCallLetters ); 199:session.setAttribute( "call_letters", callLetters ); Stacktrace:] with root cause java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute [customer] I know why the error, it is because the customer object was never written to be serialiazable. The old application I am working on has a lot of such non serialized objects and I do not want to search out change them all to implement serialiazable I am hoping there is a way to configure Tomcat to just not try and replication sessions all object which are not serialiazable https://tomcat.apache.org/tomcat-10.1-doc/config/manager.html Search for sessionAttributeNameFilter Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you know the sender and you are sure the content is safe. Please report the message using the Report Message feature in your email client if you believe the email is suspicious. - 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: [EXT]Re: Tomcat session replication issue - java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute :
So setting... sessionAttributeNameFilter="customer" does not work, still getting the error java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute : customer Do I need to set this also? sessionAttributeValueClassNameFilter= "java\\.lang\\.(?:Boolean|Integer|Long|Number|String)|com.radiovoodoo.customer.Customer" I am thinking no config setting can stop this error. I am thinking I must alter my Customer code and make that class implement java.io.Serializable. And that is what I was hoping not to do. (alter the application code itself) Rick Noel Systems Programmer | Westwood One rn...@westwoodone.com -Original Message- From: Rick Noel Sent: Friday, March 22, 2024 11:43 AM To: Tomcat Users List Subject: RE: [EXT]Re: Tomcat session replication issue - java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute : Mark, So if my customer object is failing to get set in the session replication, I could add this to the config snippet? sessionAttributeNameFilter="customer" so like this?... Rick Noel Systems Programmer | Westwood One rn...@westwoodone.com -Original Message- From: Mark Thomas Sent: Friday, March 22, 2024 11:32 AM To: users@tomcat.apache.org Subject: [EXT]Re: Tomcat session replication issue - java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute : On 22/03/2024 15:15, Rick Noel wrote: > Is there a way to configure DeltaManager or the Cluster element so it does > not cause my application to throw this error. > > 22-Mar-2024 10:56:34.382 SEVERE [http-nio-8586-exec-5] > org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() > for servlet [jsp] in context with path [##0001] threw exception [An > exception occurred processing [/services/include/properties.jsp] at > line [196] > > 193: > 194:session.setAttribute( "format", stationFormat ); > 195:session.setAttribute( "employee_id", employeeId ); > 196:session.setAttribute( "customer", customer ); > 197:session.setAttribute( "customer_id", customerId ); > 198:session.setAttribute( "nonidentifier_call_letters", > nonIdentifierCallLetters ); > 199:session.setAttribute( "call_letters", callLetters ); > > > Stacktrace:] with root cause > java.lang.IllegalArgumentException: setAttribute: > Non-serializable attribute [customer] > > > I know why the error, it is because the customer object was never written to > be serialiazable. > The old application I am working on has a lot of such non serialized > objects and I do not want to search out change them all to implement > serialiazable > > I am hoping there is a way to configure Tomcat to just not try and > replication sessions all object which are not serialiazable https://tomcat.apache.org/tomcat-10.1-doc/config/manager.html Search for sessionAttributeNameFilter Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you know the sender and you are sure the content is safe. Please report the message using the Report Message feature in your email client if you believe the email is suspicious. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Memory leak in EncodingDetector?
Very cool Chris, thanks for the quick reaction! Simon out On Fri, Mar 22, 2024 at 1:41 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > Simon, > > On 3/21/24 12:39, Simon Niederberger wrote: > > Hi Chris > > > > Personally I'd go with > > > > XML_INPUT_FACTORY = > > XMLInputFactory.newFactory(XMLInputFactory.class.getName(), > > EncodingDetector.class.getClassLoader()); > > > > allowing me to place my own JAR in common/lib if I really want to (the > > only scenario I can think of is an edge-case where there's a bug in > > the JVM XMLInputFactory and no upgrade path is available, so I'd place > > my own JAR in common/lib). > > > >> I wonder if there really are any use-cases for applications wanting > Tomcat to specify the XMLInputFactory *to be used for JSP* > > > > That sounds pretty far-fetched. Our use case is simply that we deploy > > frequently (several times a day) on a Tomcat 10.1 installation, and > > have various reasons for not going down the Docker/container/FAT JAR > > path. So, making sure we don't have memory leaks is relevant. > > Done and done. > > Feel free to put the fix in yourself, or grab 10.1.x from GitHub, or wit > for Tomcat 10.1.21 to be released (10.1.20 has already been rolled and > the voting will end shortly, so you'll have to wait for the next release). > > -chris > > > On Thu, Mar 21, 2024 at 1:44 PM Christopher Schultz > > wrote: > >> > >> Simon, > >> > >> On 3/20/24 15:36, Simon Niederberger wrote: > What if you create an empty jaxp.properties file and make it > available to the common ClassLoader (e.g. in > lib/empty-jaxp.jar:/jaxp.properties) -- does that prevent the problem? > >> > > >>> I think that boils down to what I'm already doing with the system > >>> property, getting to the FactoryFinder before it uses > >>> findServiceProvider(). Haven't tried it, but I'm sure it would work. > >> > >> The difference is that Tomcat can ship it as a part of the distribution, > >> while we shouldn't really be setting system properties like that. It > >> might prevent, for example, applications using their own preferred > >> implementation. > >> > >>> imho, Tomcat's EncodingDetector should init with either > >>> > >>> XML_INPUT_FACTORY = XMLInputFactory.newDefaultFactory(); > >>> > >>> to just always use the JVM XMLInputFactory, or then > >>> > >>> XML_INPUT_FACTORY = > >>> XMLInputFactory.newFactory(XMLInputFactory.class.getName(), > >>> EncodingDetector.class.getClassLoader()); > >>> > >>> to honor it's own classloader (maybe > >>> EncodingDetector.class.getClassLoader() is the wrong approach, > >>> basically something getTomcatCommonClassloader()) > >> > >> Yeah, that's probably better than an empty properties file wrapped in a > >> JAR file wrapped in an enigma. > >> > >> We also have the option of using the JreMemoryLeakPreventionListener for > >> this. There are already some XML-related protections in there, though > >> this one is not specifically there. > >> > >> Do you have a preferred technique for fixing this? All of those > >> suggestions seem equally reasonable. I think I have a slight preference > >> for passing the JSP compiler's ClassLoader in to the factory method: > >> > >> XML_INPUT_FACTORY = > >> XMLInputFactory.newFactory(XMLInputFactory.class.getName(), > >> EncodingDetector.class.getClassLoader()); > >> > >> If you absolutey need to get your JSP compiler to have a custom > >> XMLInputFactory, you can copy the JSP compiler into your application and > >> it will use that ClassLoader instead. > >> > >>> What I just don't get is why there's so little online about others > >>> havingEncodingDetector similar issues. Spring + libs like CXF or > >>> jackson-dataformat-xml are common, both those libs have transitive > >>> dependencies on woodstox-core. Throw in ehcache, also common, and your > >>> webapp won't undeploy if it's the first webapp to load a JSP and thus > >>> clinit EncodingDetector. Maybe the public has just given up on clean > >>> undeploying. > >> > >> My guess is that most people don't really care too much about clean > >> shutdowns of their applications. They either bring their applications up > >> and down along with the whole JVM (either standalone or via Docker, > >> etc.) or they use an embedded Tomcat where their own application hosts > >> Tomcat and they start/stop that. > >> > >> Or they disable/ignore memory-leak detection log messages. *shrug* > >> > >> I wonder if there really are any use-cases for applications wanting > >> Tomcat to specify the XMLInputFactory *to be used for JSP*. I suspect > not. > >> > >> -chris > >> > >>> On Wed, Mar 20, 2024 at 7:01 PM Christopher Schultz > >>> wrote: > > Simon, > > On 3/20/24 09:59, Simon Niederberger wrote: > > The whole thing is caused by Maven dependencies which pull in > > com.fasterxml.woodstox:woodstox-core. The WstxInputFactory has a > > > > @ServiceProvider(XMLInputFactory.class) > > > > annotation, where
RE: [EXT]Re: Tomcat session replication issue - java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute :
Mark, So if my customer object is failing to get set in the session replication, I could add this to the config snippet? sessionAttributeNameFilter="customer" so like this?... Rick Noel Systems Programmer | Westwood One rn...@westwoodone.com -Original Message- From: Mark Thomas Sent: Friday, March 22, 2024 11:32 AM To: users@tomcat.apache.org Subject: [EXT]Re: Tomcat session replication issue - java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute : On 22/03/2024 15:15, Rick Noel wrote: > Is there a way to configure DeltaManager or the Cluster element so it does > not cause my application to throw this error. > > 22-Mar-2024 10:56:34.382 SEVERE [http-nio-8586-exec-5] > org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for > servlet [jsp] in context with path [##0001] threw exception [An exception > occurred processing [/services/include/properties.jsp] at line [196] > > 193: > 194:session.setAttribute( "format", stationFormat ); > 195:session.setAttribute( "employee_id", employeeId ); > 196:session.setAttribute( "customer", customer ); > 197:session.setAttribute( "customer_id", customerId ); > 198:session.setAttribute( "nonidentifier_call_letters", > nonIdentifierCallLetters ); > 199:session.setAttribute( "call_letters", callLetters ); > > > Stacktrace:] with root cause > java.lang.IllegalArgumentException: setAttribute: > Non-serializable attribute [customer] > > > I know why the error, it is because the customer object was never written to > be serialiazable. > The old application I am working on has a lot of such non serialized objects > and I do not want to search out change them all to implement serialiazable > > I am hoping there is a way to configure Tomcat to just not try and > replication sessions all object which are not serialiazable https://tomcat.apache.org/tomcat-10.1-doc/config/manager.html Search for sessionAttributeNameFilter Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you know the sender and you are sure the content is safe. Please report the message using the Report Message feature in your email client if you believe the email is suspicious. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat session replication issue - java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute :
On 22/03/2024 15:15, Rick Noel wrote: Is there a way to configure DeltaManager or the Cluster element so it does not cause my application to throw this error. 22-Mar-2024 10:56:34.382 SEVERE [http-nio-8586-exec-5] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [jsp] in context with path [##0001] threw exception [An exception occurred processing [/services/include/properties.jsp] at line [196] 193: 194:session.setAttribute( "format", stationFormat ); 195:session.setAttribute( "employee_id", employeeId ); 196:session.setAttribute( "customer", customer ); 197:session.setAttribute( "customer_id", customerId ); 198:session.setAttribute( "nonidentifier_call_letters", nonIdentifierCallLetters ); 199:session.setAttribute( "call_letters", callLetters ); Stacktrace:] with root cause java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute [customer] I know why the error, it is because the customer object was never written to be serialiazable. The old application I am working on has a lot of such non serialized objects and I do not want to search out change them all to implement serialiazable I am hoping there is a way to configure Tomcat to just not try and replication sessions all object which are not serialiazable https://tomcat.apache.org/tomcat-10.1-doc/config/manager.html Search for sessionAttributeNameFilter Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat session replication issue - java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute :
Is there a way to configure DeltaManager or the Cluster element so it does not cause my application to throw this error. 22-Mar-2024 10:56:34.382 SEVERE [http-nio-8586-exec-5] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [jsp] in context with path [##0001] threw exception [An exception occurred processing [/services/include/properties.jsp] at line [196] 193: 194:session.setAttribute( "format", stationFormat ); 195:session.setAttribute( "employee_id", employeeId ); 196:session.setAttribute( "customer", customer ); 197:session.setAttribute( "customer_id", customerId ); 198:session.setAttribute( "nonidentifier_call_letters", nonIdentifierCallLetters ); 199:session.setAttribute( "call_letters", callLetters ); Stacktrace:] with root cause java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute [customer] I know why the error, it is because the customer object was never written to be serialiazable. The old application I am working on has a lot of such non serialized objects and I do not want to search out change them all to implement serialiazable I am hoping there is a way to configure Tomcat to just not try and replication sessions all object which are not serialiazable Rick Noel Systems Programmer | Westwood One rn...@westwoodone.com
Re: HttpSession tracking
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 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).
So... by went ahead and loaded-up this class with *everything* -
including putting the listener class instance into every session and I
do indeed get "session will passivate" and "session has activated" log
messgaes.
So I started removing things and it kept working until ... it didn't.
I'm trying to track-down exactly what difference makes it work, but it
doesn't many any sense to me.
The StandardManager code looks like this:
if (log.isTraceEnabled()) {
log.trace("Loading " + n + " persisted sessions");
}
for (int i = 0; i < n; i++) {
StandardSession session = getNewSession();
session.readObjectData(ois);
session.setManager(this);
sessions.put(session.getIdInternal(), session);
session.activate();
if (!session.isValidInternal()) {
// If session is already invalid,
// expire session to prevent memory leak.
session.setValid(true);
session.expire();
}
sessionCounter++;
}
and StandardSession.activate looks like this:
public void activate() {
// Initialize access count
if (ACTIVITY_CHECK) {
accessCount = new AtomicInteger();
}
// Notify interested session event listeners
fireSessionEvent(SESSION_ACTIVATED_EVENT, null);
// Notify ActivationListeners
HttpSessionEvent event = null;
String keys[] = keys();
for (String key : keys) {
Object attribute = attributes.get(key);
if (attribute instanceof HttpSessionActivationListener) {
if (event == null) {
event = new HttpSessionEvent(getSession());
}
try {
((HttpSessionActivationListener)
attribute).sessionDidActivate(event);
} catch (Throwable t) {
ExceptionUtils.handleThrowable(t);
Re: Memory leak in EncodingDetector?
Simon,
On 3/21/24 12:39, Simon Niederberger wrote:
Hi Chris
Personally I'd go with
XML_INPUT_FACTORY =
XMLInputFactory.newFactory(XMLInputFactory.class.getName(),
EncodingDetector.class.getClassLoader());
allowing me to place my own JAR in common/lib if I really want to (the
only scenario I can think of is an edge-case where there's a bug in
the JVM XMLInputFactory and no upgrade path is available, so I'd place
my own JAR in common/lib).
I wonder if there really are any use-cases for applications wanting Tomcat to
specify the XMLInputFactory *to be used for JSP*
That sounds pretty far-fetched. Our use case is simply that we deploy
frequently (several times a day) on a Tomcat 10.1 installation, and
have various reasons for not going down the Docker/container/FAT JAR
path. So, making sure we don't have memory leaks is relevant.
Done and done.
Feel free to put the fix in yourself, or grab 10.1.x from GitHub, or wit
for Tomcat 10.1.21 to be released (10.1.20 has already been rolled and
the voting will end shortly, so you'll have to wait for the next release).
-chris
On Thu, Mar 21, 2024 at 1:44 PM Christopher Schultz
wrote:
Simon,
On 3/20/24 15:36, Simon Niederberger wrote:
What if you create an empty jaxp.properties file and make it available to the
common ClassLoader (e.g. in lib/empty-jaxp.jar:/jaxp.properties) -- does that
prevent the problem?
>
I think that boils down to what I'm already doing with the system
property, getting to the FactoryFinder before it uses
findServiceProvider(). Haven't tried it, but I'm sure it would work.
The difference is that Tomcat can ship it as a part of the distribution,
while we shouldn't really be setting system properties like that. It
might prevent, for example, applications using their own preferred
implementation.
imho, Tomcat's EncodingDetector should init with either
XML_INPUT_FACTORY = XMLInputFactory.newDefaultFactory();
to just always use the JVM XMLInputFactory, or then
XML_INPUT_FACTORY =
XMLInputFactory.newFactory(XMLInputFactory.class.getName(),
EncodingDetector.class.getClassLoader());
to honor it's own classloader (maybe
EncodingDetector.class.getClassLoader() is the wrong approach,
basically something getTomcatCommonClassloader())
Yeah, that's probably better than an empty properties file wrapped in a
JAR file wrapped in an enigma.
We also have the option of using the JreMemoryLeakPreventionListener for
this. There are already some XML-related protections in there, though
this one is not specifically there.
Do you have a preferred technique for fixing this? All of those
suggestions seem equally reasonable. I think I have a slight preference
for passing the JSP compiler's ClassLoader in to the factory method:
XML_INPUT_FACTORY =
XMLInputFactory.newFactory(XMLInputFactory.class.getName(),
EncodingDetector.class.getClassLoader());
If you absolutey need to get your JSP compiler to have a custom
XMLInputFactory, you can copy the JSP compiler into your application and
it will use that ClassLoader instead.
What I just don't get is why there's so little online about others
havingEncodingDetector similar issues. Spring + libs like CXF or
jackson-dataformat-xml are common, both those libs have transitive
dependencies on woodstox-core. Throw in ehcache, also common, and your
webapp won't undeploy if it's the first webapp to load a JSP and thus
clinit EncodingDetector. Maybe the public has just given up on clean
undeploying.
My guess is that most people don't really care too much about clean
shutdowns of their applications. They either bring their applications up
and down along with the whole JVM (either standalone or via Docker,
etc.) or they use an embedded Tomcat where their own application hosts
Tomcat and they start/stop that.
Or they disable/ignore memory-leak detection log messages. *shrug*
I wonder if there really are any use-cases for applications wanting
Tomcat to specify the XMLInputFactory *to be used for JSP*. I suspect not.
-chris
On Wed, Mar 20, 2024 at 7:01 PM Christopher Schultz
wrote:
Simon,
On 3/20/24 09:59, Simon Niederberger wrote:
The whole thing is caused by Maven dependencies which pull in
com.fasterxml.woodstox:woodstox-core. The WstxInputFactory has a
@ServiceProvider(XMLInputFactory.class)
annotation, where ServiceProvider is
org.ehcache.spi.service.ServiceProvider. I didn't manage to trace the
key code section, but I do find that the
javax.xml.stream.FactoryFinder then ends up finding WstxInputFactory
as registered service provider. As WstxInputFactory is not on the
common classpath (it's in WEB-INF/lib), I assume it's the webapp
classloader which is used. Below is the stacktrace where
EncodingDetector clinit happens (I defined a
ch.want.funnel.FunnelApp$DelegatingXMLInputFactory to get
stacktraces):
Currently I'm setting
System.setProperty("javax.xml.stream.XMLInputFactory",
"com.sun.xml.internal.stream.XMLInputFactoryImpl");
to get a XMLInputFactory
Re: HttpSession tracking
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: Tomcat Internal Architect for JSP compilation?
Subodh, On 3/22/24 01:36, Subodh Joshi wrote: Hi Chris Thanks for your response. So i added below properties in application.properties file spring.mvc.cache-control.cache-allowed=false and then Deleted the /tmp/tomcat directory . So now when i restart the server A.jsp only fail with 500 error (ClassNotFoundException) as this is first page which i was trying to load, rest JSP pages working fine without any issue . Why i am doing this exercise? In our some of the deployed linux environment many clients are complaining about this issue , We tried to monitor who actually deleting these /tmp/tomcat folder but still we are not able to figure it out and we are not able to reproduce it . So i have to do reproduce it manually deleting the /tmp/tomcat directory. What if you don't use /tmp as your work directory location? /tmp is supposed to be for actually temporary files. These files could live for decades if you never changed your source .jsp files or re-deployed your application. -chris On Thu, Mar 21, 2024 at 7:24 PM Christopher Schultz < ch...@christopherschultz.net> wrote: Subudh, On 3/21/24 07:32, Subodh Joshi wrote: Expert, Recently i came across a issue and i was getting no clue what was going on wrong with the Application. So here is the issue , we were getting following issue in our web application(Springboot+Embedded Tomcat) which is deployed into Linux machine java.lang.ClassNotFoundException: org.apache.jsp.WEB_002dINF.jsp.ImportTab_jsp at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:445) at org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:129) at org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:58) at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:151) at org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:189) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:410) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:380) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:328) at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:205) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:174) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:110) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:174) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149) at org.springframework.web.filter.CompositeFilter$VirtualFilterChain.doFilter(CompositeFilter.java:108) at org.springframework.security.web.FilterChainProxy.lambda$doFilterInternal$3(FilterChainProxy.java:231) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:365) at org.springframework.security.web.access.intercept.AuthorizationFilter.doFilter(AuthorizationFilter.java:100) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374) at org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:126) at org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:120) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374) at org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:100) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374) at org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:179) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374) at org.springframework.security.web.savedrequest.RequestCacheAwareFilter.doFilter(RequestCacheAwareFilter.java:63) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374) at
Re: HttpSession tracking
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. 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. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [EXT]Re: [EXT]Re: Tomcat 10 waning that expireSessionsOnShutdown is not set
Thanks Chuck great link to lots of good stuff Rick Noel Systems Programmer | Westwood One rn...@westwoodone.com -Original Message- From: Chuck Caldarale Sent: Thursday, March 21, 2024 4:00 PM To: Tomcat Users List Subject: [EXT]Re: [EXT]Re: Tomcat 10 waning that expireSessionsOnShutdown is not set [You don't often get email from n82...@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > On Mar 21, 2024, at 14:50, Rick Noel wrote: > > Do you have a feel if DeltaManager is better than BackupManager? Depends on what your needs are. There are some presentations on the subject that you might want to look at: https://tomcat.apache.org/presentations.html ApacheCon 2018 NA: Deep dive into Tomcat Clustering, Keiichi Fujino TomcatCon London 2017: Reverse Proxies, Load-Balancing & Clustering, Mark Thomas - Chuck CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you know the sender and you are sure the content is safe. Please report the message using the Report Message feature in your email client if you believe the email is suspicious. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat Internal Architect for JSP compilation?
Linux has "auditd" tool to log file system changes: https://www.redhat.com/sysadmin/configure-linux-auditing-auditd -Harri -Original Message- From: Subodh Joshi Sent: perjantai 22. maaliskuuta 2024 7.36 To: Tomcat Users List Subject: Re: Tomcat Internal Architect for JSP compilation? [Et saa yleensä sähköpostia subodhcjosh...@gmail.com. Lisätietoja siitä, miksi tämä on tärkeää, on osoitteessa https://aka.ms/LearnAboutSenderIdentification ] Hi Chris Thanks for your response. So i added below properties in application.properties file > spring.mvc.cache-control.cache-allowed=false > > and then Deleted the /tmp/tomcat directory . So now when i restart the server A.jsp only fail with 500 error (ClassNotFoundException) as this is first page which i was trying to load, rest JSP pages working fine without any issue . Why i am doing this exercise? In our some of the deployed linux environment many clients are complaining about this issue , We tried to monitor who actually deleting these /tmp/tomcat folder but still we are not able to figure it out and we are not able to reproduce it . So i have to do reproduce it manually deleting the /tmp/tomcat directory. thanks & regards On Thu, Mar 21, 2024 at 7:24 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > Subudh, > > On 3/21/24 07:32, Subodh Joshi wrote: > > Expert, > > > > Recently i came across a issue and i was getting no clue what was > > going > on > > wrong with the Application. > > > > So here is the issue , we were getting following issue in our web > > application(Springboot+Embedded Tomcat) which is deployed into Linux > machine > > > > java.lang.ClassNotFoundException: > >> org.apache.jsp.WEB_002dINF.jsp.ImportTab_jsp > >> at > >> java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:445) > >> at > >> org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:129) > >> at > >> org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:58) > >> at > >> > org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultIns > tanceManager.java:151) > >> at > >> > org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapp > er.java:189) > >> at > >> > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper. > java:410) > >> at > >> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:380) > >> at > >> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:328) > >> at > jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658) > >> at > >> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli > cationFilterChain.java:205) > >> at > >> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi > lterChain.java:149) > >> at > >> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51) > >> at > >> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli > cationFilterChain.java:174) > >> at > >> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi > lterChain.java:149) > >> at > >> > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRe > questFilter.java:110) > >> at > >> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli > cationFilterChain.java:174) > >> at > >> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi > lterChain.java:149) > >> at > >> > org.springframework.web.filter.CompositeFilter$VirtualFilterChain.doFi > lter(CompositeFilter.java:108) > >> at > >> > org.springframework.security.web.FilterChainProxy.lambda$doFilterInter > nal$3(FilterChainProxy.java:231) > >> at > >> > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.d > oFilter(FilterChainProxy.java:365) > >> at > >> > org.springframework.security.web.access.intercept.AuthorizationFilter. > doFilter(AuthorizationFilter.java:100) > >> at > >> > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.d > oFilter(FilterChainProxy.java:374) > >> at > >> > org.springframework.security.web.access.ExceptionTranslationFilter.doF > ilter(ExceptionTranslationFilter.java:126) > >> at > >> > org.springframework.security.web.access.ExceptionTranslationFilter.doF > ilter(ExceptionTranslationFilter.java:120) > >> at > >> > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.d > oFilter(FilterChainProxy.java:374) > >> at > >> > org.springframework.security.web.authentication.AnonymousAuthenticatio > nFilter.doFilter(AnonymousAuthenticationFilter.java:100) > >> at > >> > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.d > oFilter(FilterChainProxy.java:374) > >> at > >> >
Re: Tomcat Internal Architect for JSP compilation?
One possible workaround is to precompile the JSP's at build time. https://tomcat.apache.org/tomcat-9.0-doc/jasper-howto.html#Web_Application_Compilation -Tim On Fri, Mar 22, 2024 at 1:37 AM Subodh Joshi wrote: > > Why i am doing this exercise? > In our some of the deployed linux environment many clients are complaining > about this issue , We tried to monitor who actually deleting these > /tmp/tomcat folder but still we are not able to figure it out and we are > not able to reproduce it . So i have to do reproduce it manually deleting > the /tmp/tomcat directory. > >
