On 01/12/2019 23:04, Mark Thomas wrote:
I'm with you. And likely our setup is special in a way. However, I've
rarely seen that you have to re-enter credentials in a professional web
application like Google or Facebook, for example.
Yes. But if those apps were running on Tomcat I doubt
On 29/11/2019 11:48, Klein, Carsten wrote:
> However, we are developing Ajax-driven
> B2B client applications, which terminate / end the session when they
> detect loss of authentication. Technically, these apps periodically send
> keep-alive messages to the server (in order to keep the session
serialization.
It's fine to have session data persisted across restarts, however,
currently, a session is no longer authenticated after a restart (at
least with form login, with which credentials are not sent with every
request).
Actually, at least for my mind, that draws session persistence quite
useless
> and * restored across session serializations! */ protected
> transient Principal principal = null;
>
> However, the comment does not say WHY that information is omitted
> from serialization.
>
> It's fine to have session data persisted across restarts, however,
> curre
IMPLEMENTATION NOTE: This object is not saved and
> * restored across session serializations!
> */
> protected transient Principal principal = null;
>
> However, the comment does not say WHY that information is omitted from
> serialization.
>
> It's fine to have session data p
is omitted from
serialization.
It's fine to have session data persisted across restarts, however,
currently, a session is no longer authenticated after a restart (at
least with form login, with which credentials are not sent with every
request).
Actually, at least for my mind, that draws
To make the long and short of it. Nothing in my application(s) should LIVE over
a restart.
So serialization does NOT make sense for me at all. Users timeout after
inactivity too which otherwise might be a good reason for using it (maybe it
would be fine there as the timeout is pretty long
, can
refresh, passed around) f) all have an application specific jar and
share a common code jar
Long ago I added serialization to almost all of the java beans to
stop tomcat whining in the catalina.out file. This worked just fine
until the most recent tomcat release.
On my development
On Jan 12, 2014, at 8:45 AM, Ray Holme rayho...@yahoo.com wrote:
I haven't been following this thread, but I wanted to clarify a couple comments
here just to make sure someone reading this in the future doesn't get the wrong
ideas.
serialization causes some problems in apache-tomcat-7.0.35
at startup (they
are) and OLD serial copies are defunct (dangerous as they cause crazy
connections to happen) when tomcat is restarted.
S - here is the question:
I would like to allow serialization, but tell Tomcat that certain beans should
NOT be resurrected without me getting warnings in the log
users. These MUST be initialized at startup (they
are) and OLD serial copies are defunct (dangerous as they cause crazy
connections to happen) when tomcat is restarted.
S - here is the question:
I would like to allow serialization, but tell Tomcat that certain beans should
application.
S - here is the question:
I would like to allow serialization,
Ok. Make sure any object you put into the session implements Serializable.
but tell Tomcat that certain beans should NOT be resurrected
Certainly one option is to not put them in the session, but you do have other
IS THERE A WAY TO STOP WARNINGS AND TELL TOMCAT NOT TO SERIALIZE A BEAN?
Right now, I have stopped warnings but caused other problems.
just don't add those beans to a session or if you do add them make sure
that they are in containers and that those fields are transient
then those fields
I have (in the past) dealt with transient so OK, makes sense.
Not familiar with putting in container to shield from Apache serialization.
Will look for writeup. Thanks.
On Monday, January 13, 2014 10:12 AM, Johan Compagner jcompag...@servoy.com
wrote:
IS THERE A WAY TO STOP WARNINGS
as they cause crazy
connections to happen) when tomcat is restarted.
S - here is the question:
I would like to allow serialization, but tell Tomcat that certain beans
should NOT be resurrected without me getting warnings in the log file when I
don't mark them as serialisable
are defunct (dangerous as they cause crazy connections to happen) when
tomcat is restarted.
S - here is the question:
I would like to allow serialization, but tell Tomcat that certain beans should
NOT be resurrected without me getting warnings in the log file when I don't
mark them
as they cause crazy
connections to happen) when tomcat is restarted.
Not following you here. Tomcat only serializes what you put into a session
(javax.servlet.HttpSession). Anything else is up to your application.
S - here is the question:
I would like to allow serialization,
Ok. Make
code jar
Long ago I added serialization to almost all of the java beans to stop tomcat
whining in the catalina.out file. This worked just fine until the most recent
tomcat release.
On my development machine, java changes build new jars and apache/tomcat must
be restarted to work right. Starting
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Ray,
On 12/26/13, 12:14 PM, Ray Holme wrote:
It appears new revisions of tomcat (current for sure) are much
more sensitive to keeping serialized data BETWEEN restarts. I have
to wait at least 30 minutes to properly restart my applications.
30
Yes I have done various things to trace. The problem is DB connections. I
believe that the serialized versions of things went nuts trying to refresh.
Once serialization is off, the problem is gone.
Each of the four applications initializes using one connection. But re-loading
through
restart my applications.
Nope. Nothing has changed in the session serialization code since the
Tomcat 4.1.x days. It still works exactly the same way.
In the OLD days $CATALINA_HOME/work/Catalina/localhost/appName/*.ser
was where things were kept and I could remove these files before a
startup. I
restart my applications.
Nope. Nothing has changed in the session serialization code since the
Tomcat 4.1.x days. It still works exactly the same way.
In the OLD days $CATALINA_HOME/work/Catalina/localhost/appName/*.ser
was where things were kept and I could remove these files before a
startup. I
It appears new revisions of tomcat (current for sure) are much more sensitive
to keeping serialized data BETWEEN restarts. I have to wait at least 30 minutes
to properly restart my applications.
In the OLD days $CATALINA_HOME/work/Catalina/localhost/appName/*.ser was where
things were kept and
On 26/12/2013 17:14, Ray Holme wrote:
It appears new revisions of tomcat (current for sure) are much more
sensitive to keeping serialized data BETWEEN restarts. I have to wait
at least 30 minutes to properly restart my applications.
Nope. Nothing has changed in the session serialization code
Sorry that I could not answer earlier, currently I am away from my
working place. Concerning this topic I recommend to send future emails
directly to my, because it is only indirectly connected with tomcat. As
mentioned, details about this are described in
http://www.orthuber.com/wpa.htm . It
On 06/10/2010 11:55, Wolfgang Orthuber wrote:
The build in serialization tool of java has probably high performance
(which is in the long run important for search), and needed not much
time for programming, therefore it was my initial choice.
There's an assumption there, and some reasoning I'm
On 06/10/2010 11:55, Wolfgang Orthuber wrote:
This would allow to sort medical histories precisely and to learn
systematically from past experience.
Only relative assessment is possible, no*?
So every patient who wants to share
his experiences in precisely searchable form, can get the
Chris,
Not always it seems adequate to write to the mailing list - so you
marked my question with [OT] which was a further hint for me to write to
you directly. Concerning serialization I answered already on 04.10.2010.
The build in serialization tool of java has probably high performance
. The problem in
this case was that you didn't understand the nuances of Java
serialization. For instance, RTTI is written out as part of the
serialization process, so attempting to read-into a different class
(even with the same fields and code) causes an error.
My recommendation would
This has nothing to do with Tomcat it has to do with Java,
serialization and OO.
What are you trying to persist because it looks like you are persisting
what amounts to be an inner class to a JSP? Consider changing that to a
simple JavaBean not considered an inner class to the compiled JSP
it have a reference to the jsp object?
Ronald.
Op maandag, 4 oktober 2010 15:10 schreef Wolfgang Orthuber
orthu...@kfo-zmk.uni-kiel.de:
Hello,
my tomcat version is 5.5.17, my question concerns serialization of
objects, below is a code section for writing and reading an object.
If I call
Hello,
my tomcat version is 5.5.17, my question concerns serialization of
objects, below is a code section for writing and reading an object. If I
call write immediately before read:
d5.write();
d5.read();
then all works fine, but if I use only read (on an formerly written
file
Thanks to all for the quick response!
I will compile ddm2 to a standalone class and import (and not include) it.
Wolfgang
What does ddm2 look like? Does it have a reference to the jsp object?
Ronald.
Op maandag, 4 oktober 2010 15:10 schreef Wolfgang Orthuber
orthu...@kfo-zmk.uni-kiel.de:
Hello,
my tomcat version is 5.5.17, my question concerns serialization of objects,
below is a code section
question concerns serialization of
objects, below is a code section for writing and reading an object.
If I call write immediately before read:
d5.write();
d5.read();
then all works fine, but if I use only read (on an formerly written
file) with the same code included in another program module
object and read it in as another class object. You should read-up
on serialization for more information:
http://java.sun.com/developer/technicalArticles/Programming/serialization/
in which w4a.jsp and w4b.jsp are two different modules which include the
same code for read and write.
That means
to
find a way to work on that ordering.
I wonder if there's the potential for doing a two-phase
de-serialization where the first phase is done by Tomcat and the second
phase is done by another component -- the one that knows how to inject
these interface implementations.
This is one problem with using
I have a question, on behalf of a client, concerning Tomcat clustering
and deserialization, in the context of a Tapestry 5 application.
Here's the short form: some of the objects that a Tapestry
application may put into the HttpSession will only deserialize
correctly
if the Tapestry application
On 27/05/2010 16:31, Howard Lewis Ship wrote:
I have a question, on behalf of a client, concerning Tomcat clustering
and deserialization, in the context of a Tapestry 5 application.
Here's the short form: some of the objects that a Tapestry
application may put into the HttpSession will only
donné que les email peuvent facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
Date: Thu, 27 May 2010 08:31:53 -0700
Subject: Clustering, De-Serialization and Order of Operations
From: hls...@gmail.com
To: users
From: Pid [mailto:p...@pidster.com]
Subject: Re: Clustering, De-Serialization and Order of Operations
Session persistence is a Manager Valve function
Is that true even for the start() and stop() methods of StandardManager? I
thought valves came into play during request processing
On 27/05/2010 19:08, Caldarale, Charles R wrote:
From: Pid [mailto:p...@pidster.com]
Subject: Re: Clustering, De-Serialization and Order of Operations
Session persistence is a Manager Valve function
Is that true even for the start() and stop() methods of StandardManager? I
thought valves
I believe my client is using Tomcat 6; I'll check.
So, at startup, the Manager reads the saved HttpSession state into
memory, then starts init'ing filters and servlets? I really need to
find a way to work on that ordering.
On Thu, May 27, 2010 at 8:43 AM, Pid p...@pidster.com wrote:
On
that is not being
serialized. Turning serialization off however, stops this error from getting
reported. However, I would like to test serialization. Any thoughts?
defaults
exclude name=local_*/
exclude name=LOCAL_
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom,
Tom Mader wrote:
It appears that if I try to store a class in the session that contains
anything other than native JDK types, I get a de-serialization error when
the session is loaded after tomcat restarts.
There are several reasons this can
From: Tom Mader [mailto:[EMAIL PROTECTED]
Subject: RE: session de-serialization issue
Does the sun-packaged RPM work on CentOS 5.2 ?
No idea. I try to always get the product from the original vendor (Sun, in
this case), since the 3rd-party repackaged versions often to do very
non-standard
Send reply to: Tomcat Users List users@tomcat.apache.org
Date sent: Fri, 05 Dec 2008 23:45:14 -0500 (EST)
Subject:RE: session de-serialization issue
From: Tom Mader [EMAIL PROTECTED]
To: Tomcat Users List users
of org.apache.catalina.session.StandardManager
It appears that if I try to store a class in the session that contains
anything other than native JDK types, I get a de-serialization error when
the session is loaded after tomcat restarts.
For example, I created the following simple class:
import java.io.*;
public class
From: Tom Mader [mailto:[EMAIL PROTECTED]
Subject: session de-serialization issue
5-Dec-08 7:02:14 PM org.apache.catalina.session.StandardManager doLoad
SEVERE: IOException while loading persisted sessions:
java.io.InvalidClassException: invalid field type for
testClass in class
Thank you Chuck!
Does the sun-packaged RPM work on CentOS 5.2 ?
or do i execute:
./j2sdk-1_4_2_19-linux-i586.bin -localinstall
5-Dec-08 7:02:14 PM org.apache.catalina.session.StandardManager doLoad
SEVERE: IOException while loading persisted sessions:
java.io.InvalidClassException: invalid
hi,
I encountered a problem with tomcat 5.5. Grazing the whole web i didn't
find any solution (some guys are having the same problem but they also
got no useful hint up to now). The problem is as follows:
I try to build an applet-servlet communication using serialized objects.
In my test
Hello,
Trying to check serialization of our web application under tomcat, i get
the exception below. Basically, catalina is trying to use a
webappclassloader for it's logging purpose. Can somebody explain me how
this can happen? I suspect a bad interaction between logging facilities
in tomcat
7:38 AM
Subject: Service instance serialization question
Hi,
I have a web service which is running under the Tomcat container. Tomcat
creates a new instance of
this web service with each incoming simultaneous connection. The problem I
am having, is that my web service
calls a hardware device
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom,
Tom Kobialka wrote:
I have a web service which is running under the Tomcat container.
[snip]
I need to implement some sort of serialization such that only one
request is processed from each instance at a time.
Is your web service
instances of my web service
all querying it at the same time, it hangs. I need to implement some
sort of serialization such that only one
request is processed from each instance at a time. Is it possible to
serialize between service instances, which
have been created by tomcat? Is there some
John Wallace wrote:
Is this the same issue as described above? What is the best way fix my
problem?
Maybe. Could be also be a problem with your application. If you can
reproduce this error reliably, please provide the steps to reproduce
it and any associated test JSP/servlet in the bug report.
inadvertently hijacked by different after
server restart http://issues.apache.org/bugzilla/show_bug.cgi?id=40114
Session serialization in context.xml was commented by default, so
serialization was turned on. User A in the middle of a session when we
restart Tomcat. Upon logging back
Mark's assessment is correct, how did you end up storing your request
object in the session?
Mark Hagger wrote:
My best guess is that you've somehow stored the request object itself on
the session, and thus the replication is trying to replicate that to the
other nodes.
If this is the case
Hi,
I'm starting to get clustering running on Tomcat I think I've solved
most of my webapp's non-serialized object issues, but now I'm getting
the error below. From what I can see , the error is not originating from
my code in the webapp, and searching the web for this error message
hasn't
My best guess is that you've somehow stored the request object itself on
the session, and thus the replication is trying to replicate that to the
other nodes.
If this is the case then this is almost certainly a bad idea.
Mark
On Thu, 2006-08-24 at 09:04 -0500, Bischoff, Mathew wrote:
Hi,
Hi,
We're using Tomcat 5.5.9 on our development PCs because it closely
replicates our chosen production environment (JBoss 4.0.2). What we
would like to do is configure Tomcat to enforce that all session
variables must be Serializable, so any development errors are caught
early and not
Maybe you need to have:
Context
...SNIP...
Manager className=org.apache.catalina.session.PersistentManager
saveOnRestart=true distributable=true debug=0
Store className=org.apache.catalina.session.FileStore/
/Manager
/Context
In your META-INF/context.xml or maybe
to the session for what is sort of like a new or activate
event (i.e. session restore from serialization)?
Thanks,
Derrick
/**
* Read a serialized version of this session object from the
specified
* object input stream.
* p
* bIMPLEMENTATION NOTE/b: The reference to the owning
Hmm, context.xml? I know only of server.xml. At least on Windows. Here is a
context snippet for server.xml which disables session persistence.
Michael
Context docBase=/your-doc-base path=/your-context
Manager className=org.apache.catalina.session.PersistentManager
or shorter with
Context docBase=/your-doc-base path=/your-context
Manager pathname= /
/Context
at tomcat 5.5 add the description at your META-INF/context.xml
Context
Manager pathname= /
/Context
or at the conf/context.xml
:-)
Greetings everyone,
I am using Tomcat 5.0.19 on Fedora Linux, Core 2. My catalina.out shows the
ugly exceptions during shutdown.
Some Googling revealed that session serialization can be disabled by added
the following XML snipett in the context.xml:
Manager pathname=/
I
66 matches
Mail list logo
