Re: Tomcat 7.x.x, 8.x.x, 8.5.x and 9.x.x: Session serialization w/o authentication related information
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 that a) they'd be running on a single instance and b) they'd be using Tomcat's in memory session management. Yes, my comparison was not really fair. Just wanted to point out, that re-entering credentials is no longer common in today's applications. As an option, disabled by default I don't see why not. Agreed. A good place to start would be to open a Bugzilla enhancement request against 9.0.x (we always develop for the latest version first and then back-port). Makes sense. After that, we accept patches in Bugzilla or Pull Requests at GitHub. Expect a fair amount a feedback on your first version (my first patch needed to be completely re-written) but a couple of tips to reduce the rework: - enable checkstyle and make sure there are no errors when building - generally, follow the style of the code you are editing (the Tomcat code style is not always consistent) So, I will give that a try. Hope to come up with a patch within the next couple of weeks. The patch itself seems not to be too challenging. Thanks for your advice and tips. Carsten - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.x.x, 8.x.x, 8.5.x and 9.x.x: Session serialization w/o authentication related information
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 alive, > since with Ajax the server is only queried when data must be loaded or > updated). When such a keep-alive fails with a 401 code, the session has > gone and the application terminates (so, the Admin is able to > 'disconnect' clients by invalidating their session). Currently, this > happens for all active clients after reloading the context or restarting > Tomcat :-( > >>> That may be a security thing, but if, for example, passwords stored in >>> the GenericPrincipal instance are not serialized, I don't see a security >>> problem with persisting the session's principal. >> >> User names and passwords are generally viewed as more sensitive that the >> Principal object which is generally viewed as more sensitive than the >> session ID. >> >> Where users draw the line between what is acceptable and unacceptable is >> going to vary. > > 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 that a) they'd be running on a single instance and b) they'd be using Tomcat's in memory session management. > In some of our projects we use self-written replacements for Tomcat's > GenericPrincipal (ours is serializable, I know yours in version 8 or 8.5 > is too, but on Ubuntu 14.04 we're still on Tomcat 7), StandardSession > and StandardManager. However, it's some work to keep these classes up to > date for new versions of Tomcat. So my basic question was, couldn't > Tomcat do that for us? As an option, disabled by default I don't see why not. > I understand that different users have different requirements and for > some, persisting a Principal (likely including a password) on disk for > some seconds during a reload is really not acceptable. BTW, why ever do > you save passwords?? Good question. I suspect it might be related to single-sign-on but I'd need to do some svn archaeology to try and answer that more definitively. > So, the best solution to that would be to make this a configurable > option of the Manager, named 'persistPrincipal', for example. Maybe I > could even help developing that (if I had some time). Agreed. A good place to start would be to open a Bugzilla enhancement request against 9.0.x (we always develop for the latest version first and then back-port). After that, we accept patches in Bugzilla or Pull Requests at GitHub. Expect a fair amount a feedback on your first version (my first patch needed to be completely re-written) but a couple of tips to reduce the rework: - enable checkstyle and make sure there are no errors when building - generally, follow the style of the code you are editing (the Tomcat code style is not always consistent) Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.x.x, 8.x.x, 8.5.x and 9.x.x: Session serialization w/o authentication related information
On 28/11/2019 10:20, Mark Thomas wrote: On 28/11/2019 08:03, Klein, Carsten wrote: Hi there, Thanks for answering my questions. See my remarks inline: in all recent Tomcat versions the standard session implementation declares authentication related fields as 'transient', so both the session's authType as well as it's authenticated Principal is not saved and restored across restarts. It isn't just recent versions. It has been that way for 2 decades. All the way back to Tomcat 4.0.x I guessed as much. On those fields there is a comment that clearly describes that: /** * The authenticated Principal associated with this session, if any. * 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 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, because, after a restart, the client must re-login prior to use any resources having a security constraint. Useless seems a bit strong. The session data is still there. Nothing is lost. But the user does have to re-enter their credentials to continue (if the authentication mechanism doesn't do it automatically). If re-entering the credentials is an issue, have you considered using an alternative authentication mechanism? Yes, useless may be too strong. 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 alive, since with Ajax the server is only queried when data must be loaded or updated). When such a keep-alive fails with a 401 code, the session has gone and the application terminates (so, the Admin is able to 'disconnect' clients by invalidating their session). Currently, this happens for all active clients after reloading the context or restarting Tomcat :-( That may be a security thing, but if, for example, passwords stored in the GenericPrincipal instance are not serialized, I don't see a security problem with persisting the session's principal. User names and passwords are generally viewed as more sensitive that the Principal object which is generally viewed as more sensitive than the session ID. Where users draw the line between what is acceptable and unacceptable is going to vary. 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. In some of our projects we use self-written replacements for Tomcat's GenericPrincipal (ours is serializable, I know yours in version 8 or 8.5 is too, but on Ubuntu 14.04 we're still on Tomcat 7), StandardSession and StandardManager. However, it's some work to keep these classes up to date for new versions of Tomcat. So my basic question was, couldn't Tomcat do that for us? I understand that different users have different requirements and for some, persisting a Principal (likely including a password) on disk for some seconds during a reload is really not acceptable. BTW, why ever do you save passwords?? So, the best solution to that would be to make this a configurable option of the Manager, named 'persistPrincipal', for example. Maybe I could even help developing that (if I had some time). Do you have any ideas on that or do you know how to work around this? Tomcat restarts are required from time to time. But it's really a bad idea to kick out all currently logged-in users just because Tomcat needs to be reconfigured, for example. Re-entering credentials seems to be a major issue in this instance. Are you able to share what is driving that (with more information we might be able to identify a other solutions). There are various 3rd-party session managers available for Tomcat. One of those may well retain the Principal across restarts. Yes, that may be true. And most if not all those frameworks are rather complex, feature-overloaded and can do everything for you (if you know how). Actually, for our client applications, we use Tomcat only as a simple web server as well as for authentication and sessions. (Tomcat is also the container for GeoServer, which is part of most of our setups). So, a pure Tomcat solution would be my first choice. Carsten - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.x.x, 8.x.x, 8.5.x and 9.x.x: Session serialization w/o authentication related information
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Carsten, > in all recent Tomcat versions the standard session implementation > declares authentication related fields as 'transient', so both the > session's authType as well as it's authenticated Principal is not > saved and restored across restarts. What's interesting is that GenericPrincipal, the only concrete Principal class provided by Tomcat, does not have transient fields for username and password. And, oddly, when serialized, a SerializablePrincipal object is swapped-out in its place. Seems strange to me. The SerializablePrincipal is private static to it's not intended to be an extension point for user code. > On those fields there is a comment that clearly describes that: > > /** * The authenticated Principal associated with this session, if > any. * 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 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, because, after a restart, the client must re-login > prior to use any resources having a security constraint. > > That may be a security thing, but if, for example, passwords stored > in the GenericPrincipal instance are not serialized, I don't see a > security problem with persisting the session's principal. But they *would* be serialized along with the Principal object if no changes were made to the SerializedPrincipal class. Since it's private, it could be changed. > Do you have any ideas on that or do you know how to work around > this? Tomcat restarts are required from time to time. But it's > really a bad idea to kick out all currently logged-in users just > because Tomcat needs to be reconfigured, for example. I'm not sure why Tomcat needs to store the Principal's password (and I haven't checked to see if FormAuthenticator sets this value to the user's password, or null instead which would be way better), but serializing that to the disk would be Bad. There isn't any encryption being placed on those stored files which means that serializing them would be a security issue. Honestly, I think it's reasonable to (a) not store the password and (b) serialize the Principal, but it's not as simple as just "remove transient from the member declaration". I've been using another authentication mechanism for so long, I didn't realize that Tomcat worked this way. The same seems to be true for clustered sessions -- you have to re-login if you fail-over to another node in the cluster. That seems pretty inconvenient. If this could be configurable, it might be very nice to have, especially for the clustering use-case. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3f144ACgkQHPApP6U8 pFgD2hAAkV25fJuasaBq+4ByaDWX6nhef228NhiErOiKhcAAyVUJIkxzcqMsCrtQ BOxc60NF2zzLK/IxvSQv0xg13162jCK3EWhYSVH7nyj+KI8k6P1V4HALY8gWwTYy ENGm2J906fBDXniGvKzeptfPb49wVAovbJ2JYZlCxnahTcfKOWI49KzaqR+bfgT8 tidKYmzGVYxn6mmS8fuFFW8xCwrLs3nJ0aK1qxuyjz9XBimkDGPAq/w0vviP2LCC Pwuo8vJMNYdVqu4q5UMuszg1+QOGKIE+yX2ZOS+xWQ6L9rsc6Vy9EJ40vN5juNZP AT8oajjJ5dtbPzUT8bDGrAaBtLLVEttIcuuHyi8wBa3hjy9y/BxJpTHDP5kpR/iJ HTmibiNqEub/OI4NCS7WNiwrgsWrZhqECNPkZrzt1PA/qfCz4BS0UTJqs4kceCBu /1LUc0BzNHkjY8gNaNlyymeerDQQm74TV0uiBqhZRpXp2UlyCXBM7SadWqMauht9 VxsnGv6k+VdDwlA/CRhpXh6Jcfi2k7SZy36yz2lZ+1U9qwiqCZMdzXBhyPcDIrmy Vn/RB/0D/a2X+XrTlVZv6HceFeP62J8i4zRnjxC6NS4QgrDTnvmiQNDljrAaKwqu /rfZdq3Ft9a1CKGWoV1dR4Dq/j8TH54Du7kbocQUHUFnN/lpYPE= =7/bk -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.x.x, 8.x.x, 8.5.x and 9.x.x: Session serialization w/o authentication related information
On 28/11/2019 08:03, Klein, Carsten wrote: > Hi there, > > in all recent Tomcat versions the standard session implementation > declares authentication related fields as 'transient', so both the > session's authType as well as it's authenticated Principal is not saved > and restored across restarts. It isn't just recent versions. It has been that way for 2 decades. All the way back to Tomcat 4.0.x > On those fields there is a comment that clearly describes that: > > /** > * The authenticated Principal associated with this session, if any. > * 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 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, because, after a restart, the client must re-login prior to use > any resources having a security constraint. Useless seems a bit strong. The session data is still there. Nothing is lost. But the user does have to re-enter their credentials to continue (if the authentication mechanism doesn't do it automatically). If re-entering the credentials is an issue, have you considered using an alternative authentication mechanism? > That may be a security thing, but if, for example, passwords stored in > the GenericPrincipal instance are not serialized, I don't see a security > problem with persisting the session's principal. User names and passwords are generally viewed as more sensitive that the Principal object which is generally viewed as more sensitive than the session ID. Where users draw the line between what is acceptable and unacceptable is going to vary. > Do you have any ideas on that or do you know how to work around this? > Tomcat restarts are required from time to time. But it's really a bad > idea to kick out all currently logged-in users just because Tomcat needs > to be reconfigured, for example. Re-entering credentials seems to be a major issue in this instance. Are you able to share what is driving that (with more information we might be able to identify a other solutions). There are various 3rd-party session managers available for Tomcat. One of those may well retain the Principal across restarts. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 7.x.x, 8.x.x, 8.5.x and 9.x.x: Session serialization w/o authentication related information
Hi there, in all recent Tomcat versions the standard session implementation declares authentication related fields as 'transient', so both the session's authType as well as it's authenticated Principal is not saved and restored across restarts. On those fields there is a comment that clearly describes that: /** * The authenticated Principal associated with this session, if any. * 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 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, because, after a restart, the client must re-login prior to use any resources having a security constraint. That may be a security thing, but if, for example, passwords stored in the GenericPrincipal instance are not serialized, I don't see a security problem with persisting the session's principal. Do you have any ideas on that or do you know how to work around this? Tomcat restarts are required from time to time. But it's really a bad idea to kick out all currently logged-in users just because Tomcat needs to be reconfigured, for example. Regards Carsten -- Carsten Klein Lead Software Engineer DataGis GmbH Johann-Strauß-Str. 26 70794 Filderstadt T +49 7158 9490-106 F +49 7158 9490-111 E-Mail: c.kl...@datagis.com Internet: www.datagis.com Registergericht: Amtsgericht Stuttgart, HRB 225945 Geschäftsführung: Dr. Gunter Hahn, Markus Ruess, Carsten Klein - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: serialization and newest tomcat
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).
However I very much appreciate your explanation. I was employing ONE totally
static bean for constants, Utilities, (many could change during run time - e.g.
debugLevel) and general purpose methods that are useful to lots of beans (e.g
cleanNquote makes a string ready for SQL insertion). I HAD BEEN using another,
Application, to keep track of application dependent Vectors for quick look up.
Using your example, these two could be combined and I would NOT need to pass
around a handle to the bean called Application in my own version of UserInfo
(as an object without class for compilation purposes - I use javac not a tool
to build so cyclic compile problems must be handled carefully). I could just
use the one independent static bean - Utilities and simple Java imports - MUCH
easier.
On Thursday, January 16, 2014 5:45 PM, Christopher Schultz
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Ray,
On 1/12/14, 8:45 AM, Ray Holme wrote:
> [S]erialization causes some problems in apache-tomcat-7.0.35
>
> I have several applications and run on fedora linux. I have used
> many releases of fedora and tomcat.
>
> My applications are characterized by a) all use a DB (firebird) b)
> all use both jsp and java servlets c) all use transient java beans
> for a "round" of interaction (user request - user response) d) all
> have 1 or more session java beans for each user (login - logout) e)
> all have 1 or more application beans (initialized at startup, 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 machine, java changes build new jars and
> apache/tomcat must be restarted to work right. Starting with the
> new release, problems with connections happened.
>
> After research, I discovered that the applications were going nuts
> with connection requests and xinetd was shutting down the
> connection factory service. It took a 30 minute wait (or reboot) to
> fix this problem. My guess is that the application wide beans were
> not only being made fresh as always happens (they use one
> connection each to initialize), but that the serialized versions
> were coming back up and trying to refresh causing lots of strange
> connections to be created (if one is not passed, one is made and
> there are many routines each needing a connection).
>
> To solve this problem, I stopped serialization. This solved the
> problem.
>
> From the notes I got from others (thanks Mark and ...):
>
> serialization can be stopped by putting this in many places - here
> is one: appname/META-INF/context.xml
>
>
Can I venture a guess as to one other important detail you have left
out? It sounds like some of the objects you are putting into the
user's session (HttpSession: the stuff getting serialized to disk
across web application reload or Tomcat stop/start) may have
references to those application-scoped objects. Here's an example of
what I mean:
public class GlobalBean
implements Serializable
{
}
public class UserBean
implements Serializable
{
private GlobalBean _global;
public UserBean(GlobalBean gb)
{
_global = gb;
}
}
... in your webapp's ServletContextListener:
init() {
...
ServletContext application = getServletContext();
application.setAttribute("globalBean" new GlobalBean());
...
}
... in your servlet:
doGet() {
...
ServletContext application = getServletContext();
GlobalBean gb = (GlobalBean)application.getAttribute("globalBean");
HttpSession session = request.getSession();
session.setAttribute("userBean", new UserBean(gb));
...
}
If the above are all happening, then when you de-serialize the
UserBeans, they will de-serialize the GlobalBean instance along with
themselves. If your GlobalBean has to do a bunch of db access or
whatever to initialize itself, it will either have to do that on
deserialization to make itself sane, or it will be in a non-sane
state. In either case, you won't get the newly-created GlobalBean from
your ServletContextListener (or similar) and things may get ... weird.
If this is the case, and you don't really care about the user's
session info, then by all means: disable session serialization and be
done with it. If you need this to work -- or if you need your web
application's sessions to be distributable -- t
Re: serialization and newest tomcat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Ray,
On 1/12/14, 8:45 AM, Ray Holme wrote:
> [S]erialization causes some problems in apache-tomcat-7.0.35
>
> I have several applications and run on fedora linux. I have used
> many releases of fedora and tomcat.
>
> My applications are characterized by a) all use a DB (firebird) b)
> all use both jsp and java servlets c) all use transient java beans
> for a "round" of interaction (user request - user response) d) all
> have 1 or more session java beans for each user (login - logout) e)
> all have 1 or more application beans (initialized at startup, 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 machine, java changes build new jars and
> apache/tomcat must be restarted to work right. Starting with the
> new release, problems with connections happened.
>
> After research, I discovered that the applications were going nuts
> with connection requests and xinetd was shutting down the
> connection factory service. It took a 30 minute wait (or reboot) to
> fix this problem. My guess is that the application wide beans were
> not only being made fresh as always happens (they use one
> connection each to initialize), but that the serialized versions
> were coming back up and trying to refresh causing lots of strange
> connections to be created (if one is not passed, one is made and
> there are many routines each needing a connection).
>
> To solve this problem, I stopped serialization. This solved the
> problem.
>
> From the notes I got from others (thanks Mark and ...):
>
> serialization can be stopped by putting this in many places - here
> is one: appname/META-INF/context.xml
>
>
Can I venture a guess as to one other important detail you have left
out? It sounds like some of the objects you are putting into the
user's session (HttpSession: the stuff getting serialized to disk
across web application reload or Tomcat stop/start) may have
references to those application-scoped objects. Here's an example of
what I mean:
public class GlobalBean
implements Serializable
{
}
public class UserBean
implements Serializable
{
private GlobalBean _global;
public UserBean(GlobalBean gb)
{
_global = gb;
}
}
... in your webapp's ServletContextListener:
init() {
...
ServletContext application = getServletContext();
application.setAttribute("globalBean" new GlobalBean());
...
}
... in your servlet:
doGet() {
...
ServletContext application = getServletContext();
GlobalBean gb = (GlobalBean)application.getAttribute("globalBean");
HttpSession session = request.getSession();
session.setAttribute("userBean", new UserBean(gb));
...
}
If the above are all happening, then when you de-serialize the
UserBeans, they will de-serialize the GlobalBean instance along with
themselves. If your GlobalBean has to do a bunch of db access or
whatever to initialize itself, it will either have to do that on
deserialization to make itself sane, or it will be in a non-sane
state. In either case, you won't get the newly-created GlobalBean from
your ServletContextListener (or similar) and things may get ... weird.
If this is the case, and you don't really care about the user's
session info, then by all means: disable session serialization and be
done with it. If you need this to work -- or if you need your web
application's sessions to be distributable -- then you are necessarily
going to have to change something with your architecture in order to
get this kind of thing to work in a sane way. My recommendation would
be to pass a GlobalBean into any method on the UserBean that needs to
access it, rather than keeping a reference of any kind. It's kind of
like IOC except ... not really anything like that ;)
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJS2GDqAAoJEBzwKT+lPKRYOZcQAKEqbjKbJ3zYm8c6pShgltSj
IzJ0NwWEredE19MEB39p1JXRMP7AyfaPogyHLATQUyEcJWIP0MrWVDptRWXNlEYU
kbo3ybmJZGGn7MydLSzctzVZsLlgG58E+cta4WkShLtc72tTJq3Zv3T0XlH6RVaS
8LPuLluYwIGJ6OSPR4tH2/QDd26W6psIJdmqabh0Jbbw5rKaqr1l1+Ib2Yhj0XV1
W+LwAdZYc5RpHDvxKSsJd2lrql3yG2aRXAn2/BHxx0trO8ag25oBq9gfmezDOeyP
AwBWQI4ralPGr6cYDDKkgz5uILUsKWeoIneLXxeH9lN5qARm3le59waWPMnL/jjC
Md0BTIoLP8o1GAFboChDpVJWbLC029p4iLE7bzR1zzuz/g9dvsqcmKsT1mEEtdPi
usZ8sKg9X67KcYYfq2T0nKFtQTZF8YXUPjoUOPeC04p4VQsdi2saYLYJ7X2JPHDJ
A8odCpEm27u3aH7wUCb0EbQFqOce2KwCN3B9YPe0MBb709jBXmcb3Z00yQiZVecW
RaIC8/IU6seeOYG8PJTyLvNNLbcrRYU41mufmt+gx48EMZMPZe33yWa3mh
Re: serialization and newest tomcat
Nice, I do that for many things, but not all of it. You are right, I probably could do that. Nice food for thought! :=] On Monday, January 13, 2014 11:31 AM, Daniel Mikusa wrote: On Jan 13, 2014, at 8:37 AM, Ray Holme wrote: > OK, that makes perfect sense. We are NOT talking about SESSION objects (where > I am defining session as login to logout of a USER as I mentioned before, > perhaps you are defining this as "while tomcat is up" - I can see either > def.). These type beans are all fine, but I would actually never want them > serialized if Tomcat restarts as I would want the user to log back in for a > lot of reasons (but no damage would be caused if they were serialized). I'm referring to HttpSession. http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpSession.html Any thing you store on the session through the Servlet API will be persisted by Tomcat when it shuts down and restored when it restarts (unless you disable this behavior as you have). This allows you to restart Tomcat and not lose session data. If you want to see what your application is storing in the session, take a look at the Manager application. It allows you to browse through active sessions and view what has been stored there. > I am talking about java beans that are part of the "application" and shared > information available to all 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. 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 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 options. See last comment. > without me getting warnings in the log file when I don't mark them as > serializable. They *must* be serializable. Otherwise you're going to get an exception. This is a requirement of Java serialization. > > 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. As I've mentioned, your beans must implement Serializable or they won't be able to be serialized and you'll see error. This is not an issue with Tomcat. It's a requirement of Java serialization. Tomcat uses Java serialization to persist your session data between restarts so it inherits this requirement. I would suggest that you look into how Java serializes your objects. If you don't like the default behavior, it provides you with the ability to control that process. One example, if you want to prohibit a field from being serialized you can mark it transient. Dan > > > > > > On Monday, January 13, 2014 8:08 AM, Daniel Mikusa > wrote: > > On Jan 12, 2014, at 8:45 AM, Ray Holme 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 > > No. What causes problems is when application objects are placed in the > session and they are not serializable. This happens because, by default, > Tomcat will try to save your session data when it restarts. It does this by > serializing the data to disk. Then when it restarts, it deserializes the > data and restores the sessions. > > >http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Persistence_Across_Restarts > > The only other reason why your sessions would need to be serializable is if > you're using clustering (i.e. you add the distributable tag to web.xml). > >> I have several applications and run on fedora linux. I have used many >> releases of fedora and tomcat. >> >> My applications are characterized by >> a) all use a DB (firebird) >> b) all use both jsp and java servlets >> c) all use transient java beans for a "round" of interaction (user >>request - user response) >> d) all have 1 or more session java beans for each user (login - logout) >> e) all have 1 or more application beans (initialized at startup, 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 u
Re: serialization and newest tomcat
Another option would be to read them from the db once, at system startup, and then keep them static from there. You're still hitting your db, but not on an ongoing basis. On 1/13/2014 9:02 AM, Ray Holme wrote: Oh, I missed one comment from Daniel before (embedded and I did not see on the first pass, sorry). No, you don't know the application so I would like to explain that some information kept in the "shared application" beans is very static, needs to be loaded from the DB and is used everywhere by every user. The number of hits to the DB would quadruple (at minimum) without these small tables being in memory. I waste maybe 5k of memory to reduce DB use in an active system and speed up user response time. This would be silly for a system that it NOT active. On Monday, January 13, 2014 8:38 AM, Ray Holme wrote: OK, that makes perfect sense. We are NOT talking about SESSION objects (where I am defining session as login to logout of a USER as I mentioned before, perhaps you are defining this as "while tomcat is up" - I can see either def.). These type beans are all fine, but I would actually never want them serialized if Tomcat restarts as I would want the user to log back in for a lot of reasons (but no damage would be caused if they were serialized). I am talking about java beans that are part of the "application" and shared information available to all 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 NOT be resurrected without me getting warnings in the log file when I don't mark them as serialisable. 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. On Monday, January 13, 2014 8:08 AM, Daniel Mikusa wrote: On Jan 12, 2014, at 8:45 AM, Ray Holme 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 No. What causes problems is when application objects are placed in the session and they are not serializable. This happens because, by default, Tomcat will try to save your session data when it restarts. It does this by serializing the data to disk. Then when it restarts, it deserializes the data and restores the sessions. http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Persistence_Across_Restarts The only other reason why your sessions would need to be serializable is if you're using clustering (i.e. you add the distributable tag to web.xml). I have several applications and run on fedora linux. I have used many releases of fedora and tomcat. My applications are characterized by a) all use a DB (firebird) b) all use both jsp and java servlets c) all use transient java beans for a "round" of interaction (user request - user response) d) all have 1 or more session java beans for each user (login - logout) e) all have 1 or more application beans (initialized at startup, 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 machine, java changes build new jars and apache/tomcat must be restarted to work right. Starting with the new release, problems with connections happened. After research, I discovered that the applications were going nuts with connection requests and xinetd was shutting down the connection factory service. It took a 30 minute wait (or reboot) to fix this problem. My guess is that the application wide beans were not only being made fresh as always happens (they use one connection each to initialize), but that the serialized versions were coming back up and trying to refresh causing lots of strange connections to be created (if one is not passed, one is made and there are many routines each needing a connection). I'm not going to pretend to fully understand how your application works, but from what I took of this explanation it sounds like your application is stuffing a lot of unnecessary things into the session. Limiting that or taking a closer look at how those objects are being serialized is probably something you should consider. To solve this problem, I stopped serialization. This solved the problem. This certainly works, however it's worth nothing that you'll lose any session data when you restart Tomcat. For development that's fine, but in pro
Re: serialization and newest tomcat
On Jan 13, 2014, at 9:02 AM, Ray Holme wrote: > Oh, I missed one comment from Daniel before (embedded and I did not see on > the first pass, sorry). > > No, you don't know the application so I would like to explain that some > information kept in the "shared application" beans is very static, needs to > be loaded from the DB and is used everywhere by every user. The number of > hits to the DB would quadruple (at minimum) without these small tables being > in memory. I waste maybe 5k of memory to reduce DB use in an active system > and speed up user response time. This would be silly for a system that it NOT > active. This is fine and seems to make good sense. You certainly don't want to overload your DB. How does this relate to the problem at hand though? You need to provide more concrete details. How are you loading this information? How are you storing this information in memory? What do you mean by "shared application beans"? How does this related to sessions and Tomcat serializing the data? Dan > > > > > On Monday, January 13, 2014 8:38 AM, Ray Holme wrote: > > OK, that makes perfect sense. We are NOT talking about SESSION objects (where > I am defining session as login to logout of a USER as I mentioned before, > perhaps you are defining this as "while tomcat is up" - I can see either > def.). These type beans are all fine, but I would actually never want them > serialized if Tomcat restarts as I would want the user to log back in for a > lot of reasons (but no damage would be caused if they were serialized). > > I am talking about java beans that are part of the "application" and shared > information available to all 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 NOT be resurrected without me getting warnings in the log file when I > don't mark them as serialisable. > > 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. > > > > > > > On Monday, January 13, 2014 8:08 AM, Daniel Mikusa > wrote: > > On Jan 12, 2014, at 8:45 AM, Ray Holme 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 > > No. What causes problems is when application objects are placed in the > session and they are not serializable. This happens because, by default, > Tomcat will try to save your session data when it restarts. It does this by > serializing the data to disk. Then when it restarts, it deserializes the > data and restores the sessions. > > > http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Persistence_Across_Restarts > > The only other reason why your sessions would need to be serializable is if > you're using clustering (i.e. you add the distributable tag to web.xml). > >> I have several applications and run on fedora linux. I have used many >> releases of fedora and tomcat. >> >> My applications are characterized by >> a) all use a DB (firebird) >> b) all use both jsp and java servlets >> c) all use transient java beans for a "round" of interaction (user >> request - user response) >> d) all have 1 or more session java beans for each user (login - logout) >> e) all have 1 or more application beans (initialized at startup, 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 machine, java changes build new jars and apache/tomcat >> must be restarted to work right. Starting with the new release, problems >> with connections happened. >> >> After research, I discovered that the applications were going nuts with >> connection requests and xinetd was shutting down the connection factory >> service. It took a 30 minute wait (or reboot) to fix this problem. My guess >> is that the application wide beans were not only being made fresh as always >> happens (they use one connection each to initializ
Re: serialization and newest tomcat
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 wrote: >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 (beans) are not serialized and they are null when they are deserialized (so you need to refill them if they are needed) -- Johan Compagner Servoy
Re: serialization and newest tomcat
> > > 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 (beans) are not serialized and they are null when they are deserialized (so you need to refill them if they are needed) -- Johan Compagner Servoy
Re: serialization and newest tomcat
On Jan 13, 2014, at 8:37 AM, Ray Holme wrote: > OK, that makes perfect sense. We are NOT talking about SESSION objects (where > I am defining session as login to logout of a USER as I mentioned before, > perhaps you are defining this as "while tomcat is up" - I can see either > def.). These type beans are all fine, but I would actually never want them > serialized if Tomcat restarts as I would want the user to log back in for a > lot of reasons (but no damage would be caused if they were serialized). I'm referring to HttpSession. http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpSession.html Any thing you store on the session through the Servlet API will be persisted by Tomcat when it shuts down and restored when it restarts (unless you disable this behavior as you have). This allows you to restart Tomcat and not lose session data. If you want to see what your application is storing in the session, take a look at the Manager application. It allows you to browse through active sessions and view what has been stored there. > I am talking about java beans that are part of the "application" and shared > information available to all 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. 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 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 options. See last comment. > without me getting warnings in the log file when I don't mark them as > serializable. They *must* be serializable. Otherwise you're going to get an exception. This is a requirement of Java serialization. > > 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. As I've mentioned, your beans must implement Serializable or they won't be able to be serialized and you'll see error. This is not an issue with Tomcat. It's a requirement of Java serialization. Tomcat uses Java serialization to persist your session data between restarts so it inherits this requirement. I would suggest that you look into how Java serializes your objects. If you don't like the default behavior, it provides you with the ability to control that process. One example, if you want to prohibit a field from being serialized you can mark it transient. Dan > > > > > > On Monday, January 13, 2014 8:08 AM, Daniel Mikusa > wrote: > > On Jan 12, 2014, at 8:45 AM, Ray Holme 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 > > No. What causes problems is when application objects are placed in the > session and they are not serializable. This happens because, by default, > Tomcat will try to save your session data when it restarts. It does this by > serializing the data to disk. Then when it restarts, it deserializes the > data and restores the sessions. > > > http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Persistence_Across_Restarts > > The only other reason why your sessions would need to be serializable is if > you're using clustering (i.e. you add the distributable tag to web.xml). > >> I have several applications and run on fedora linux. I have used many >> releases of fedora and tomcat. >> >> My applications are characterized by >> a) all use a DB (firebird) >> b) all use both jsp and java servlets >> c) all use transient java beans for a "round" of interaction (user >> request - user response) >> d) all have 1 or more session java beans for each user (login - logout) >> e) all have 1 or more application beans (initialized at startup, 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 machine, java changes build new jars and apache/tomcat >> must be restarted to work right. Startin
Re: serialization and newest tomcat
Oh, I missed one comment from Daniel before (embedded and I did not see on the first pass, sorry). No, you don't know the application so I would like to explain that some information kept in the "shared application" beans is very static, needs to be loaded from the DB and is used everywhere by every user. The number of hits to the DB would quadruple (at minimum) without these small tables being in memory. I waste maybe 5k of memory to reduce DB use in an active system and speed up user response time. This would be silly for a system that it NOT active. On Monday, January 13, 2014 8:38 AM, Ray Holme wrote: OK, that makes perfect sense. We are NOT talking about SESSION objects (where I am defining session as login to logout of a USER as I mentioned before, perhaps you are defining this as "while tomcat is up" - I can see either def.). These type beans are all fine, but I would actually never want them serialized if Tomcat restarts as I would want the user to log back in for a lot of reasons (but no damage would be caused if they were serialized). I am talking about java beans that are part of the "application" and shared information available to all 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 NOT be resurrected without me getting warnings in the log file when I don't mark them as serialisable. 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. On Monday, January 13, 2014 8:08 AM, Daniel Mikusa wrote: On Jan 12, 2014, at 8:45 AM, Ray Holme 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 No. What causes problems is when application objects are placed in the session and they are not serializable. This happens because, by default, Tomcat will try to save your session data when it restarts. It does this by serializing the data to disk. Then when it restarts, it deserializes the data and restores the sessions. http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Persistence_Across_Restarts The only other reason why your sessions would need to be serializable is if you're using clustering (i.e. you add the distributable tag to web.xml). > I have several applications and run on fedora linux. I have used many > releases of fedora and tomcat. > > My applications are characterized by > a) all use a DB (firebird) > b) all use both jsp and java servlets > c) all use transient java beans for a "round" of interaction (user request >- user response) > d) all have 1 or more session java beans for each user (login - logout) > e) all have 1 or more application beans (initialized at startup, 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 machine, java changes build new jars and apache/tomcat must > be restarted to work right. Starting with the new release, problems with > connections happened. > > After research, I discovered that the applications were going nuts with > connection requests and xinetd was shutting down the connection factory > service. It took a 30 minute wait (or reboot) to fix this problem. My guess > is that the application wide beans were not only being made fresh as always > happens (they use one connection each to initialize), but that the serialized > versions were coming back up and trying to refresh causing lots of strange > connections to be created (if one is not passed, one is made and there are > many routines each needing a connection). I'm not going to pretend to fully understand how your application works, but from what I took of this explanation it sounds like your application is stuffing a lot of unnecessary things into the session. Limiting that or taking a closer look at how those objects are being serialized is probably something you should consider. > > To solve this problem, I stopped serialization. This solved the problem. This certainly works, however it's worth nothing that you'll lose any session data when you restart Tomcat. For development that's fine, but in production you might not want to do that. I guess it depends on your app and what
Re: serialization and newest tomcat
OK, that makes perfect sense. We are NOT talking about SESSION objects (where I am defining session as login to logout of a USER as I mentioned before, perhaps you are defining this as "while tomcat is up" - I can see either def.). These type beans are all fine, but I would actually never want them serialized if Tomcat restarts as I would want the user to log back in for a lot of reasons (but no damage would be caused if they were serialized). I am talking about java beans that are part of the "application" and shared information available to all 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 NOT be resurrected without me getting warnings in the log file when I don't mark them as serialisable. 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. On Monday, January 13, 2014 8:08 AM, Daniel Mikusa wrote: On Jan 12, 2014, at 8:45 AM, Ray Holme 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 No. What causes problems is when application objects are placed in the session and they are not serializable. This happens because, by default, Tomcat will try to save your session data when it restarts. It does this by serializing the data to disk. Then when it restarts, it deserializes the data and restores the sessions. http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Persistence_Across_Restarts The only other reason why your sessions would need to be serializable is if you're using clustering (i.e. you add the distributable tag to web.xml). > I have several applications and run on fedora linux. I have used many > releases of fedora and tomcat. > > My applications are characterized by > a) all use a DB (firebird) > b) all use both jsp and java servlets > c) all use transient java beans for a "round" of interaction (user request >- user response) > d) all have 1 or more session java beans for each user (login - logout) > e) all have 1 or more application beans (initialized at startup, 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 machine, java changes build new jars and apache/tomcat must > be restarted to work right. Starting with the new release, problems with > connections happened. > > After research, I discovered that the applications were going nuts with > connection requests and xinetd was shutting down the connection factory > service. It took a 30 minute wait (or reboot) to fix this problem. My guess > is that the application wide beans were not only being made fresh as always > happens (they use one connection each to initialize), but that the serialized > versions were coming back up and trying to refresh causing lots of strange > connections to be created (if one is not passed, one is made and there are > many routines each needing a connection). I'm not going to pretend to fully understand how your application works, but from what I took of this explanation it sounds like your application is stuffing a lot of unnecessary things into the session. Limiting that or taking a closer look at how those objects are being serialized is probably something you should consider. > > To solve this problem, I stopped serialization. This solved the problem. This certainly works, however it's worth nothing that you'll lose any session data when you restart Tomcat. For development that's fine, but in production you might not want to do that. I guess it depends on your app and what's in the sessions though. > > From the notes I got from others (thanks Mark and ...): > > serialization can be stopped by putting this in many places The "many places" are context files. There are several locations where you can configure your application's context. > - here is one: > appname/META-INF/context.xml > > Again, just watch out as this will prohibit Tomcat from saving session data on restart. In other words, all session data is going to be lost on restart. Dan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: serialization and newest tomcat
On Jan 12, 2014, at 8:45 AM, Ray Holme 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 No. What causes problems is when application objects are placed in the session and they are not serializable. This happens because, by default, Tomcat will try to save your session data when it restarts. It does this by serializing the data to disk. Then when it restarts, it deserializes the data and restores the sessions. http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Persistence_Across_Restarts The only other reason why your sessions would need to be serializable is if you're using clustering (i.e. you add the distributable tag to web.xml). > I have several applications and run on fedora linux. I have used many > releases of fedora and tomcat. > > My applications are characterized by >a) all use a DB (firebird) >b) all use both jsp and java servlets >c) all use transient java beans for a "round" of interaction (user request > - user response) >d) all have 1 or more session java beans for each user (login - logout) >e) all have 1 or more application beans (initialized at startup, 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 machine, java changes build new jars and apache/tomcat must > be restarted to work right. Starting with the new release, problems with > connections happened. > > After research, I discovered that the applications were going nuts with > connection requests and xinetd was shutting down the connection factory > service. It took a 30 minute wait (or reboot) to fix this problem. My guess > is that the application wide beans were not only being made fresh as always > happens (they use one connection each to initialize), but that the serialized > versions were coming back up and trying to refresh causing lots of strange > connections to be created (if one is not passed, one is made and there are > many routines each needing a connection). I'm not going to pretend to fully understand how your application works, but from what I took of this explanation it sounds like your application is stuffing a lot of unnecessary things into the session. Limiting that or taking a closer look at how those objects are being serialized is probably something you should consider. > > To solve this problem, I stopped serialization. This solved the problem. This certainly works, however it's worth nothing that you'll lose any session data when you restart Tomcat. For development that's fine, but in production you might not want to do that. I guess it depends on your app and what's in the sessions though. > > From the notes I got from others (thanks Mark and ...): > > serialization can be stopped by putting this in many places The "many places" are context files. There are several locations where you can configure your application's context. > - here is one: >appname/META-INF/context.xml > > Again, just watch out as this will prohibit Tomcat from saving session data on restart. In other words, all session data is going to be lost on restart. Dan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
serialization and newest tomcat
erialization causes some problems in apache-tomcat-7.0.35 I have several applications and run on fedora linux. I have used many releases of fedora and tomcat. My applications are characterized by a) all use a DB (firebird) b) all use both jsp and java servlets c) all use transient java beans for a "round" of interaction (user request - user response) d) all have 1 or more session java beans for each user (login - logout) e) all have 1 or more application beans (initialized at startup, 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 machine, java changes build new jars and apache/tomcat must be restarted to work right. Starting with the new release, problems with connections happened. After research, I discovered that the applications were going nuts with connection requests and xinetd was shutting down the connection factory service. It took a 30 minute wait (or reboot) to fix this problem. My guess is that the application wide beans were not only being made fresh as always happens (they use one connection each to initialize), but that the serialized versions were coming back up and trying to refresh causing lots of strange connections to be created (if one is not passed, one is made and there are many routines each needing a connection). To solve this problem, I stopped serialization. This solved the problem. From the notes I got from others (thanks Mark and ...): serialization can be stopped by putting this in many places - here is one: appname/META-INF/context.xml
Fw: apache tomcat serialization
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 serialization appears to do weir things. So far things work great with it stopped. Has calmed the waters. Thanks to Mark for once again steering me in the right direction. On Saturday, December 28, 2013 1:37 PM, Christopher Schultz wrote: -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 minutes to shut-down or 30 minutes to start-up? Have you tried to take a few thread dumps to find out what's going on? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSvxpSAAoJEBzwKT+lPKRY+5EP/3Bu4j80UJEqbfcew8c/WmD2 fITFoCq8fXfMVWZt8NmAXxAOJBnQ8Ddc64K4jLOXo3vkxL55OPay5FUiFT6OjPuZ 0AIFndQ62n7g6CjGXQwGAzGvwDIYt1c6xb1/xj3kEsp9/pbrKqE4SkX9y1aHIiOs XNt8cD7f6332H0si2BHv9nhylC0o5y0J7fND2ZJbHAwaDZgMHf3QGcvrnJzLoFqO sXvQ0gJEIstrlLWZkcufCjTKB9/5C8A3pbc9Kf5a+MFrY6cFszE6YBJq15RCc0X4 2gqJ8BBYHv8j60DGMmSvshA46TkjYDRD73UEgrx7dqEeLkXHC3iYeJTuA4cPL9Dw NH0DxS1j1sLPq8hEPSDpC5w40Dl7jJBkRrXiLNIEiRKGEEr76VVwXohwgC4rRVGQ /aMhUzqqaqpHtZdldjYWI3FHmkFH2ijMCIhjVk2TTJCJlsz9iur842wZwz/AY70U YxaYxZuYDohmdLuGec5SffeS9L4XdeSUs3kEHI4xBL2PTxM5hVhwYDWIiaihdN1k 9ytMGfpnTWwDrLq1GYPeveD4HP1GnAqxG1Eq/5L6A7A9Ci4WVSmjk4/2Np5Kh9R6 bz808da8ur0Uc2sUoNPODPhmi6hg3GAGnQ0SnLfXDZAlZlD++PCx2+II3YVrhqHW kMfOGBqksIVz1dgFh3p5 =t5Af -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: apache tomcat serialization
-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 minutes to shut-down or 30 minutes to start-up? Have you tried to take a few thread dumps to find out what's going on? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSvxpSAAoJEBzwKT+lPKRY+5EP/3Bu4j80UJEqbfcew8c/WmD2 fITFoCq8fXfMVWZt8NmAXxAOJBnQ8Ddc64K4jLOXo3vkxL55OPay5FUiFT6OjPuZ 0AIFndQ62n7g6CjGXQwGAzGvwDIYt1c6xb1/xj3kEsp9/pbrKqE4SkX9y1aHIiOs XNt8cD7f6332H0si2BHv9nhylC0o5y0J7fND2ZJbHAwaDZgMHf3QGcvrnJzLoFqO sXvQ0gJEIstrlLWZkcufCjTKB9/5C8A3pbc9Kf5a+MFrY6cFszE6YBJq15RCc0X4 2gqJ8BBYHv8j60DGMmSvshA46TkjYDRD73UEgrx7dqEeLkXHC3iYeJTuA4cPL9Dw NH0DxS1j1sLPq8hEPSDpC5w40Dl7jJBkRrXiLNIEiRKGEEr76VVwXohwgC4rRVGQ /aMhUzqqaqpHtZdldjYWI3FHmkFH2ijMCIhjVk2TTJCJlsz9iur842wZwz/AY70U YxaYxZuYDohmdLuGec5SffeS9L4XdeSUs3kEHI4xBL2PTxM5hVhwYDWIiaihdN1k 9ytMGfpnTWwDrLq1GYPeveD4HP1GnAqxG1Eq/5L6A7A9Ci4WVSmjk4/2Np5Kh9R6 bz808da8ur0Uc2sUoNPODPhmi6hg3GAGnQ0SnLfXDZAlZlD++PCx2+II3YVrhqHW kMfOGBqksIVz1dgFh3p5 =t5Af -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Fw: apache tomcat serialization
On Thursday, December 26, 2013 6:10 PM, Mark Thomas wrote: 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 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 no longer see these files and I am sure they are > someplace. Only if you have configured Tomcat to place them somewhere else. NOPE, I have NOT changed the configuration AND YES I download directly from ASF. > I have a couple java beans that are application wide resources. So > tomcat does NOT complain, they are compiled saying they can be > serialized (they can while the app is running, but not between > shutdown/startup. It it these beans which I really do not want OLD > copies found when tomcat restarts. But there is no reason to keep ANY > serialized data between tomcat instances. I assume you are placing these beans in the session. YES, they need to be found by other beans. > Can anyone tell me how to tell tomcat to NOT use old serialized data > at startup? Have you tried reading the manual for the session manager you are using? You could start here: http://tomcat.apache.org/tomcat-8.0-doc/config/manager.html#Disable_Session_Persistence Thanks, ON IT. > OR How to delete it so it cannot be found? If sessions are serialised, the file will be created wherever you tell Tomcat to create it. > I run on fedora. Ah. If you are using a Fedora packaged version of Tomcat I suggest you direct your enquires to whomever maintains that package and ask them where they opted to move the session serialization files to. Alternatively you could remove the 3rd party packaged version of Tomcat, download Tomcat from the ASF and install it in your location of choice so you know exactly where every single file is that Tomcat is using. Yes I download and run fedora, yes I download Tomcat DIRECTLY from ASF. No packages. Will read your link and thanks. Best. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Fw: apache tomcat serialization
On Thursday, December 26, 2013 6:10 PM, Mark Thomas wrote: 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 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 no longer see these files and I am sure they are > someplace. Only if you have configured Tomcat to place them somewhere else. NOPE, I have NOT changed the configuration AND YES I download directly from ASF. > I have a couple java beans that are application wide resources. So > tomcat does NOT complain, they are compiled saying they can be > serialized (they can while the app is running, but not between > shutdown/startup. It it these beans which I really do not want OLD > copies found when tomcat restarts. But there is no reason to keep ANY > serialized data between tomcat instances. I assume you are placing these beans in the session. YES, they need to be found by other beans. > Can anyone tell me how to tell tomcat to NOT use old serialized data > at startup? Have you tried reading the manual for the session manager you are using? You could start here: http://tomcat.apache.org/tomcat-8.0-doc/config/manager.html#Disable_Session_Persistence Thanks, ON IT. > OR How to delete it so it cannot be found? If sessions are serialised, the file will be created wherever you tell Tomcat to create it. > I run on fedora. Ah. If you are using a Fedora packaged version of Tomcat I suggest you direct your enquires to whomever maintains that package and ask them where they opted to move the session serialization files to. Alternatively you could remove the 3rd party packaged version of Tomcat, download Tomcat from the ASF and install it in your location of choice so you know exactly where every single file is that Tomcat is using. Yes I download and run fedora, yes I download Tomcat DIRECTLY from ASF. No packages. Will read your link and thanks. Best. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: apache tomcat serialization
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 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 no longer see these files and I am sure they are > someplace. Only if you have configured Tomcat to place them somewhere else. > I have a couple java beans that are application wide resources. So > tomcat does NOT complain, they are compiled saying they can be > serialized (they can while the app is running, but not between > shutdown/startup. It it these beans which I really do not want OLD > copies found when tomcat restarts. But there is no reason to keep ANY > serialized data between tomcat instances. I assume you are placing these beans in the session. > Can anyone tell me how to tell tomcat to NOT use old serialized data > at startup? Have you tried reading the manual for the session manager you are using? You could start here: http://tomcat.apache.org/tomcat-8.0-doc/config/manager.html#Disable_Session_Persistence > OR How to delete it so it cannot be found? If sessions are serialised, the file will be created wherever you tell Tomcat to create it. > I run on fedora. Ah. If you are using a Fedora packaged version of Tomcat I suggest you direct your enquires to whomever maintains that package and ask them where they opted to move the session serialization files to. Alternatively you could remove the 3rd party packaged version of Tomcat, download Tomcat from the ASF and install it in your location of choice so you know exactly where every single file is that Tomcat is using. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
apache tomcat serialization
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 I could remove these files before a startup. I no longer see these files and I am sure they are someplace. I have a couple java beans that are application wide resources. So tomcat does NOT complain, they are compiled saying they can be serialized (they can while the app is running, but not between shutdown/startup. It it these beans which I really do not want OLD copies found when tomcat restarts. But there is no reason to keep ANY serialized data between tomcat instances. Can anyone tell me how to tell tomcat to NOT use old serialized data at startup? OR How to delete it so it cannot be found? I run on fedora. Thanks
Re: [OT] Serialization
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 is important is to map reality steadily to numbers (i.e. small changes of real objects should be connected with small changes of the representing numbers). Then similarity search possible. Wolfgang Pid schrieb: 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 opportunity for doing this. Precise search on objective data, would seem to be fraught with problems*. *Assuming I'm understanding the context. p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Serialization
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 opportunity > for doing this. Precise search on objective data, would seem to be fraught with problems*. *Assuming I'm understanding the context. p 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [OT] Serialization
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 not sure I understand. p 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [OT] Serialization
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 (which is in the long run important for search), and needed not much time for programming, therefore it was my initial choice. „Vectorial Search“ is also not direct topic of this list, but because you asked me, Iet me point to http://www.orthuber.com/wpa.htm which contains a description. There is a simple technical reason why such numeric search will come in addition to conventional word based search: For every new word (symbol) you need a new definition, but not for a new number or sequence of numbers. It is sufficient to define the vector space, and implicitly uncountable many vectors in this space are defined, you can search them and talk about them. Symbolic and word based descriptions are simpler perceived by human brain, but they can never reach the resolution and precision of vectorial descriptions. Such resolution is for example important in medical diagnoses. In nontrivial cases you need a very fine description of a patient for decision support, that you can productively exchange experiences. The first application of vectorial search may be, that the rough diagnosis determines the vector space, and measurement results determine the fine description as vector within the space. This would allow to sort medical histories precisely and to learn systematically from past experience. So every patient who wants to share his experiences in precisely searchable form, can get the opportunity for doing this. So it would be technically feasible to systematically exchange medical experience, so that medical treatment will less strongly depend on the experience of the chosen doctor. Besides medicine there are further applications. May be that I have to program the first prototype for demonstration of the principle. But it seems also attractive for me that we form an open source community for the complete project, if this can be organized productively. Let me know if there is interest in this. Wolfgang Am 05.10.2010 22:59, schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wolfgang, (I'm cc'ing the tomcat-user mailing list in case others would like to read my response. Please try to keep things on the list rather than emailing contributors directly.) On 10/5/2010 9:34 AM, Wolfgang Orthuber wrote: thanks for your detailed answer. You are right, up to now I wrote e.g. C, C++ programs, since July I am working with Java because server programming and the java class library is necessary. There are many new conventions and my main problem is lack of time. I understand. Learning any new language has its caveats. 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 be to /not/ use Java's built-in serialization, and instead write your data out in a way that does not depend on a particular class's interpretation of the data. Just define a standard (binary, XML, whatever) and then read and write to that format. But the fundament of the plan is reliable (vectorial search) and I am interested in an up to date installation of tomcat and java. What is "vectorial search"? There is a great range of sources on the web for java and tomcat, partially incompatible, or old. Which source and selection do you recommend for an up to date and reliable installation of tomcat and java? If you're starting from scratch, get the latest and greatest Tomcat version, which is currently 6.0.29. This page has more information on the currently-supported versions of Tomcat: http://tomcat.apache.org/whichversion.html If you must stick with the 5.5.x line, you should upgrade to 5.5.31 after reading the changelog to see if anything might interfere with your webapp's functioning. As always, get Tomcat directly from the source: http://tomcat.apache.org/ Go to the "Download | Tomcat 6.0" page and get the latest version. All you need is the "core" package: choose whatever packaging makes sense for your environment. For a Java version, we always recommend running on Sun's JRE (or JDK if you prefer). The only currently-supported version is 1.6.something: to go java.sun.com and download whatever the most recent version is. Feel free to come back to this list if you have any problems installing or configuring Tomcat. Good luck, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyrkcUACgkQ9Ca
Re: [OT] Serialization
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wolfgang, (I'm cc'ing the tomcat-user mailing list in case others would like to read my response. Please try to keep things on the list rather than emailing contributors directly.) On 10/5/2010 9:34 AM, Wolfgang Orthuber wrote: > thanks for your detailed answer. You are right, up to now I wrote > e.g. C, C++ programs, since July I am working with Java because > server programming and the java class library is necessary. There are > many new conventions and my main problem is lack of time. I understand. Learning any new language has its caveats. 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 be to /not/ use Java's built-in serialization, and instead write your data out in a way that does not depend on a particular class's interpretation of the data. Just define a standard (binary, XML, whatever) and then read and write to that format. > But the fundament of the plan is reliable (vectorial search) and I am > interested in an up to date installation of tomcat and java. What is "vectorial search"? > There is a great range of sources on the web for java and tomcat, > partially incompatible, or old. Which source and selection do you > recommend for an up to date and reliable installation of tomcat and > java? If you're starting from scratch, get the latest and greatest Tomcat version, which is currently 6.0.29. This page has more information on the currently-supported versions of Tomcat: http://tomcat.apache.org/whichversion.html If you must stick with the 5.5.x line, you should upgrade to 5.5.31 after reading the changelog to see if anything might interfere with your webapp's functioning. As always, get Tomcat directly from the source: http://tomcat.apache.org/ Go to the "Download | Tomcat 6.0" page and get the latest version. All you need is the "core" package: choose whatever packaging makes sense for your environment. For a Java version, we always recommend running on Sun's JRE (or JDK if you prefer). The only currently-supported version is 1.6.something: to go java.sun.com and download whatever the most recent version is. Feel free to come back to this list if you have any problems installing or configuring Tomcat. Good luck, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyrkcUACgkQ9CaO5/Lv0PCM5gCgoDam11AZxLAiQGFBj/zk/ikL Q4UAn229pufQzRHOlgvQt86/TWag0cDI =5FB9 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re:[OT] Serialization
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wolfgang,
(Marking off-topic because this is a Java/JSP issue and not
Tomcat-related. See below for responses.)
On 10/4/2010 9:10 AM, Wolfgang Orthuber wrote:
> my tomcat version is 5.5.17
Upgrade.
> then all works fine, but if I use only read (on an formerly written
> file) with the same code included in another program module, I got the
> exceptions like this:
> java.lang.ClassCastException: org.apache.jsp.w.w4a_jsp$1ddm2 cannot be
> cast to org.apache.jsp.w.w4b_jsp$1ddm2
That funny error message occurs because you are trying to write one
class 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 that they are different classes, and are therefore
incompatible. You should use a class defined in a .java file and not in
a .jsp file.
Your other option is to provide customized serialization that can read
and write data without relying on Java's serialization mechanism (which
mandates that the classes be the same in order to work).
> The name of the program module is stored
> in the serialized object, but the name of the program module does not
> matter, because both modules include the same code.
No, the fact that they are the same code is irrelevant. Only the data
and the metadata are relevant, and the metadata doesn't match between
these two distinct classes.
> Do you know a simple solution which avoids the exception?
Use the same class for both reading and writing.
> The code section with read and write:
Is this inside a .jsp? If so, create a separate class. What are you
doing putting Java code into a JSP file, anyway? More comments below...
> class dm5t implements Serializable {
> public ArrayListv5;
>
> public dm5t () { v5 = new ArrayList (); }
>
> public String topicpath(){return
> getServletContext().getRealPath("")+"/tp/";}
Note that getRealPath isn't guaranteed to return a non-null value: a
filesystem isn't guaranteed by the servlet specification, but temporary
storage is guaranteed using the "temp dir". See the servlet spec for
details.
> public synchronized boolean write () {
Why synchronized?
> String fn=fntopics;
> boolean ok=true;
> try {
> String spath = topicpath();
>
> FileOutputStreamfs = new FileOutputStream (spath+fn);
> ObjectOutputStreamos = new ObjectOutputStream(fs);
> os.writeObject (v5);
> os.close ();}
> catch (IOException e) {ok=false;} return ok;}
>
> public synchronized booleanread () {
> String fn=fntopics;
> boolean ok=true;
> ArrayListv5tmp=null;
> try {
> String spath = topicpath();
>
> FileInputStreamfs = new FileInputStream (spath+fn);
> ObjectInputStreamos = new ObjectInputStream(fs);
>
> v5tmp = (ArrayList) os.readObject ();
> os.close ();
>
> } catch (IOException e) {ok=false;}
> catch (ClassNotFoundException e) {ok=false;}
> if (ok)if (v5tmp != null) v5=v5tmp;
> return ok;}
> }
Why do you catch exceptions and return error codes? You like C-style
return codes instead of the elegance and clarity of exceptions?
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkyqD2AACgkQ9CaO5/Lv0PCg4gCgni4RiDBJpyernjkWo48ENrCL
Pz4AoLu28l17XZwK22+sGW7AVQZcM19/
=B03Y
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Serialization
w4a.jsp and w4b.jsp are the names of two different jsp files. Both
contain
<%@ include file="wtovedi.jsp" %>
and the file wtovedi.jsp contains the listed read and write code with
the definitions of ddm2. ddm2 is a rather complex object of objects, but
it contains no reference to w4a.jsp or w4b.jsp which are just filenames.
Wolfgang
Am 04.10.2010 13:08, schrieb Ronald Klop:
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
:
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) with the same code included in another program module, I got
the exceptions like this:
java.lang.ClassCastException: org.apache.jsp.w.w4a_jsp$1ddm2 cannot
be cast to org.apache.jsp.w.w4b_jsp$1ddm2
in which w4a.jsp and w4b.jsp are two different modules which include
the same code for read and write. The name of the program module is
stored in the serialized object, but the name of the program module
does not matter, because both modules include the same code.
Do you know a simple solution which avoids the exception?
Wolfgang
The code section with read and write:
class dm5t implements Serializable {
public ArrayListv5;
public dm5t () { v5 = new ArrayList (); }
public String topicpath(){return
getServletContext().getRealPath("")+"/tp/";}
public synchronized boolean write () {
String fn=fntopics;
boolean ok=true;
try {
String spath = topicpath();
FileOutputStreamfs = new FileOutputStream (spath+fn);
ObjectOutputStreamos = new ObjectOutputStream(fs);
os.writeObject (v5);
os.close ();}
catch (IOException e) {ok=false;} return ok;}
public synchronized booleanread () {
String fn=fntopics;
boolean ok=true;
ArrayListv5tmp=null;
try {
String spath = topicpath();
FileInputStreamfs = new FileInputStream (spath+fn);
ObjectInputStreamos = new ObjectInputStream(fs);
v5tmp = (ArrayList) os.readObject ();
os.close ();
} catch (IOException e) {ok=false;}
catch (ClassNotFoundException e) {ok=false;}
if (ok)if (v5tmp != null) v5=v5tmp;
return ok;}
}
-
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: Serialization
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
:
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) with
the same code included in another program module, I got the exceptions like
this:
java.lang.ClassCastException: org.apache.jsp.w.w4a_jsp$1ddm2 cannot be cast to
org.apache.jsp.w.w4b_jsp$1ddm2
in which w4a.jsp and w4b.jsp are two different modules which include the same
code for read and write. The name of the program module is stored in the
serialized object, but the name of the program module does not matter, because
both modules include the same code.
Do you know a simple solution which avoids the exception?
Wolfgang
The code section with read and write:
class dm5t implements Serializable {
public ArrayListv5;
public dm5t () { v5 = new ArrayList (); }
public String topicpath(){return
getServletContext().getRealPath("")+"/tp/";}
public synchronized boolean write () {
String fn=fntopics;
boolean ok=true;
try {
String spath = topicpath();
FileOutputStreamfs = new FileOutputStream (spath+fn);
ObjectOutputStreamos = new ObjectOutputStream(fs);
os.writeObject (v5);
os.close ();}
catch (IOException e) {ok=false;} return ok;}
public synchronized booleanread () {
String fn=fntopics;
boolean ok=true;
ArrayListv5tmp=null;
try {
String spath = topicpath();
FileInputStreamfs = new FileInputStream (spath+fn);
ObjectInputStreamos = new ObjectInputStream(fs);
v5tmp = (ArrayList) os.readObject ();
os.close ();
} catch (IOException e) {ok=false;}
catch (ClassNotFoundException e) {ok=false;}
if (ok)if (v5tmp != null) v5=v5tmp;
return ok;}
}
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Fwd: Re: Serialization
Thanks to all for the quick response! I will compile ddm2 to a standalone class and import (and not include) it. Wolfgang
Serialization
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) with the same code included in another program module, I got the
exceptions like this:
java.lang.ClassCastException: org.apache.jsp.w.w4a_jsp$1ddm2 cannot be
cast to org.apache.jsp.w.w4b_jsp$1ddm2
in which w4a.jsp and w4b.jsp are two different modules which include the
same code for read and write. The name of the program module is stored
in the serialized object, but the name of the program module does not
matter, because both modules include the same code.
Do you know a simple solution which avoids the exception?
Wolfgang
The code section with read and write:
class dm5t implements Serializable {
public ArrayListv5;
public dm5t () { v5 = new ArrayList (); }
public String topicpath(){return
getServletContext().getRealPath("")+"/tp/";}
public synchronized boolean write () {
String fn=fntopics;
boolean ok=true;
try {
String spath = topicpath();
FileOutputStreamfs = new FileOutputStream (spath+fn);
ObjectOutputStreamos = new ObjectOutputStream(fs);
os.writeObject (v5);
os.close ();}
catch (IOException e) {ok=false;} return ok;}
public synchronized booleanread () {
String fn=fntopics;
boolean ok=true;
ArrayListv5tmp=null;
try {
String spath = topicpath();
FileInputStreamfs = new FileInputStream (spath+fn);
ObjectInputStreamos = new ObjectInputStream(fs);
v5tmp = (ArrayList) os.readObject ();
os.close ();
} catch (IOException e) {ok=false;}
catch (ClassNotFoundException e) {ok=false;}
if (ok)if (v5tmp != null) v5=v5tmp;
return ok;}
}
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Serialization
If I understand correctly both ddm2 and dm5t are defined in .jsp files?
If so, you could separate class definitions from .jsp files.
-Ognjen
On 4.10.2010 15:38, Wolfgang Orthuber wrote:
w4a.jsp and w4b.jsp are the names of two different jsp files. Both contain
<%@ include file="wtovedi.jsp" %>
and the file wtovedi.jsp contains the listed read and write code with
the definitions of ddm2. ddm2 is a rather complex object of objects, but
it contains no reference to w4a.jsp or w4b.jsp which are just filenames.
Wolfgang
Am 04.10.2010 13:08, schrieb Ronald Klop:
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
:
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) with the same code included in another program module, I got
the exceptions like this:
java.lang.ClassCastException: org.apache.jsp.w.w4a_jsp$1ddm2 cannot
be cast to org.apache.jsp.w.w4b_jsp$1ddm2
in which w4a.jsp and w4b.jsp are two different modules which include
the same code for read and write. The name of the program module is
stored in the serialized object, but the name of the program module
does not matter, because both modules include the same code.
Do you know a simple solution which avoids the exception?
Wolfgang
The code section with read and write:
class dm5t implements Serializable {
public ArrayList v5;
public dm5t () { v5 = new ArrayList (); }
public String topicpath(){return
getServletContext().getRealPath("")+"/tp/";}
public synchronized boolean write () {
String fn=fntopics;
boolean ok=true;
try {
String spath = topicpath();
FileOutputStream fs = new FileOutputStream (spath+fn);
ObjectOutputStream os = new ObjectOutputStream (fs);
os.writeObject (v5);
os.close ();}
catch (IOException e) {ok=false;} return ok;}
public synchronized boolean read () {
String fn=fntopics;
boolean ok=true;
ArrayList v5tmp=null;
try {
String spath = topicpath();
FileInputStream fs = new FileInputStream (spath+fn);
ObjectInputStream os = new ObjectInputStream (fs);
v5tmp = (ArrayList) os.readObject ();
os.close ();
} catch (IOException e) {ok=false;}
catch (ClassNotFoundException e) {ok=false;}
if (ok) if (v5tmp != null) v5=v5tmp;
return ok;}
}
-
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
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Serialization
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 and
you'll be fine. You'll never be able to cast w4a$ddm2 into w4b$ddm2 or
vice-versa, but you can cast an instance of w4a$ddm2 or w4b$ddm2 to
their common type, if they have one. Just having the same code does not
make then the same class when compiled.
-Original Message-
From: Wolfgang Orthuber [mailto:orthu...@kfo-zmk.uni-kiel.de]
Sent: Monday, October 04, 2010 8:10 AM
To: Tomcat Users List
Subject: Serialization
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) with the same code included in another program module, I got the
exceptions like this:
java.lang.ClassCastException: org.apache.jsp.w.w4a_jsp$1ddm2 cannot be
cast to org.apache.jsp.w.w4b_jsp$1ddm2
in which w4a.jsp and w4b.jsp are two different modules which include the
same code for read and write. The name of the program module is stored
in the serialized object, but the name of the program module does not
matter, because both modules include the same code.
Do you know a simple solution which avoids the exception?
Wolfgang
The code section with read and write:
class dm5t implements Serializable {
public ArrayListv5;
public dm5t () { v5 = new ArrayList (); }
public String topicpath(){return
getServletContext().getRealPath("")+"/tp/";}
public synchronized boolean write () {
String fn=fntopics;
boolean ok=true;
try {
String spath = topicpath();
FileOutputStreamfs = new FileOutputStream (spath+fn);
ObjectOutputStreamos = new ObjectOutputStream(fs);
os.writeObject (v5);
os.close ();}
catch (IOException e) {ok=false;} return ok;}
public synchronized booleanread () {
String fn=fntopics;
boolean ok=true;
ArrayListv5tmp=null;
try {
String spath = topicpath();
FileInputStreamfs = new FileInputStream (spath+fn);
ObjectInputStreamos = new ObjectInputStream(fs);
v5tmp = (ArrayList) os.readObject ();
os.close ();
} catch (IOException e) {ok=false;}
catch (ClassNotFoundException e) {ok=false;}
if (ok)if (v5tmp != null) v5=v5tmp;
return ok;}
}
-
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: Clustering, De-Serialization and Order of Operations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Howard, On 5/27/2010 8:01 PM, Howard Lewis Ship wrote: > 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. 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 IoC instead of lazy initialization (where the client knows what to grab and when to grab it). :( - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkv/z7gACgkQ9CaO5/Lv0PD2SQCeKznF8S2sy3etOHh12AnC9E5Q Tj8An0EpdlxrujGid+74gTCmWFoeZrR5 =CKp4 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Clustering, De-Serialization and Order of Operations
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 wrote: > 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 deserialize >> correctly >> if the Tapestry application (in the form of a Servlet Filter) has >> initialized first ... but it appears that when starting up a Tomcat >> instance, >> the HttpSession data is deserialized from disk *before* the filter is >> initialized. > > Is there a specific Tomcat version you're targeting? > > Session persistence is a Manager Valve function, so AFAIK the > deserialisation will occur before Filters (or any other web app stuff, > like ServletContextListeners) are started. > > > p > > >> Here's the stack trace: >> >> ERROR ( ManagerBase:412 ) - IOException while loading >> persisted sessions: java.io.InvalidObjectException: Service token for >> service 'ProductConfig' can not be converted back into a proxy because >> no proxy provider has been registered. This may indicate that an IoC >> Registry has not been started yet. >> java.io.InvalidObjectException: Service token for service >> 'ProductConfig' can not be converted back into a proxy because no >> proxy provider has been registered. This may indicate that an IoC >> Registry has not been started yet. >> at >> org.apache.tapestry5.ioc.internal.ServiceProxyToken.readResolve(ServiceProxyToken.java:41) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >> at java.lang.reflect.Method.invoke(Method.java:597) >> at >> java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061) >> at >> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762) >> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >> at >> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) >> at >> java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) >> at >> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) >> at >> org.apache.catalina.session.StandardSession.readObject(StandardSession.java:1407) >> at >> org.apache.catalina.session.StandardSession.readObjectData(StandardSession.java:931) >> at >> org.apache.catalina.session.StandardManager.doLoad(StandardManager.java:394) >> at >> org.apache.catalina.session.StandardManager.load(StandardManager.java:321) >> at >> org.apache.catalina.session.StandardManager.start(StandardManager.java:637) >> at >> org.apache.catalina.core.ContainerBase.setManager(ContainerBase.java:432) >> at >> org.apache.catalina.core.StandardContext.start(StandardContext.java:4160) >> at >> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014) >> at org.apache.catalina.core.StandardHost.start(StandardHost.java:736) >> at >> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014) >> at >> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) >> at >> org.apache.catalina.core.StandardService.start(StandardService.java:448) >> at >> org.apache.catalina.core.StandardServer.start(StandardServer.java:700) >> at org.apache.catalina.startup.Catalina.start(Catalina.java:552) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >> at java.lang.reflect.Method.invoke(Method.java:597) >> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295) >> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433) >> Caused by: java.lang.RuntimeException: Service token for service >> 'ProductConfig' can not be converted back into a proxy because no >> proxy provider has been registered. This may indicate that an IoC >> Registry has not been started yet. >> at >> org.apache.tapestry5.ioc.internal.SerializationSupport.readResolve(SerializationSupport.java:72) >> at >> org.apache.tapestry5.ioc.internal.ServiceProxyToken.readResolve
Re: Clustering, De-Serialization and Order of Operations
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 came into play during request processing, not context > initialization. I checked: /** * Standard implementation of the Manager interface that provides * simple session persistence across restarts of this component (such as * when the entire server is shut down and restarted, or when a particular * web application is reloaded. * * IMPLEMENTATION NOTE: Correct behavior of session storing and * reloading depends upon external calls to the start() and * stop() methods of this class at the correct times. * * @author Craig R. McClanahan * @author Jean-Francois Arcand * @version $Id$ */ from: http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/session/StandardManager.java however: lifecycle.fireLifecycleEvent(START_EVENT, null); started = true; is fired before the "load()" method which starts the session deserialisation, so I'll need to dig further to find out what happens. p > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you received > this in error, please contact the sender and delete the e-mail and its > attachments from all computers. > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > signature.asc Description: OpenPGP digital signature
RE: Clustering, De-Serialization and Order of Operations
> 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, not context initialization. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Clustering, De-Serialization and Order of Operations
package filters;
import java.io.*;
import java.sql.*;
import java.util.*;
import javax.servlet.*;
/**
* Example filter that dumps interesting state information about a request
* to the associated servlet context log file, before allowing the servlet
* to process the request in the usual way. This can be installed as needed
* to assist in debugging problems.
*
* @author Craig McClanahan
* @version $Revision: 500674 $ $Date: 2007-01-28 00:15:00 +0100 (Sun, 28 Jan
2007) $
*/
public final class RequestDumperFilter implements javax.servlet.Filter{
public void doFilter(ServletRequest request, ServletResponse
response,FilterChain chain) throws IOException, ServletException
{
// Render the HTTP servlet request properties
if (request instanceof HttpServletRequest)
{
HttpServletRequest hrequest = (HttpServletRequest) request;
HttpSession session=hrequest.getSession(true); //obtain the session
}
// Pass control on to the next filter
chain.doFilter(request, response);
}
?
Martin Gainty
__
Jogi és Bizalmassági kinyilatkoztatás/Verzicht und
Vertraulichkeitanmerkung/Note de déni et de confidentialité
Ez az üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy
jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának készítése
nem megengedett. Ez az üzenet csak ismeret cserét szolgál és semmiféle jogi
alkalmazhatósága sincs. Mivel az electronikus üzenetek könnyen
megváltoztathatóak, ezért minket semmi felelöség nem terhelhet ezen üzenet
tartalma miatt.
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung.
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est
interdite. Ce message sert à l'information seulement et n'aura pas n'importe
quel effet légalement obligatoire. Étant 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@tomcat.apache.org
>
> 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 (in the form of a Servlet Filter) has
> initialized first ... but it appears that when starting up a Tomcat
> instance,
> the HttpSession data is deserialized from disk *before* the filter is
> initialized.
>
>
> Here's the stack trace:
>
> ERROR ( ManagerBase:412 ) - IOException while loading
> persisted sessions: java.io.InvalidObjectException: Service token for
> service 'ProductConfig' can not be converted back into a proxy because
> no proxy provider has been registered. This may indicate that an IoC
> Registry has not been started yet.
> java.io.InvalidObjectException: Service token for service
> 'ProductConfig' can not be converted back into a proxy because no
> proxy provider has been registered. This may indicate that an IoC
> Registry has not been started yet.
> at
> org.apache.tapestry5.ioc.internal.ServiceProxyToken.readResolve(ServiceProxyToken.java:41)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061)
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.ja
Re: Clustering, De-Serialization and Order of Operations
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 deserialize
> correctly
> if the Tapestry application (in the form of a Servlet Filter) has
> initialized first ... but it appears that when starting up a Tomcat
> instance,
> the HttpSession data is deserialized from disk *before* the filter is
> initialized.
Is there a specific Tomcat version you're targeting?
Session persistence is a Manager Valve function, so AFAIK the
deserialisation will occur before Filters (or any other web app stuff,
like ServletContextListeners) are started.
p
> Here's the stack trace:
>
> ERROR ( ManagerBase:412 ) - IOException while loading
> persisted sessions: java.io.InvalidObjectException: Service token for
> service 'ProductConfig' can not be converted back into a proxy because
> no proxy provider has been registered. This may indicate that an IoC
> Registry has not been started yet.
> java.io.InvalidObjectException: Service token for service
> 'ProductConfig' can not be converted back into a proxy because no
> proxy provider has been registered. This may indicate that an IoC
> Registry has not been started yet.
>at
> org.apache.tapestry5.ioc.internal.ServiceProxyToken.readResolve(ServiceProxyToken.java:41)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>at java.lang.reflect.Method.invoke(Method.java:597)
>at
> java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061)
>at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762)
>at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>at
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>at
> java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>at
> org.apache.catalina.session.StandardSession.readObject(StandardSession.java:1407)
>at
> org.apache.catalina.session.StandardSession.readObjectData(StandardSession.java:931)
>at
> org.apache.catalina.session.StandardManager.doLoad(StandardManager.java:394)
>at
> org.apache.catalina.session.StandardManager.load(StandardManager.java:321)
>at
> org.apache.catalina.session.StandardManager.start(StandardManager.java:637)
>at
> org.apache.catalina.core.ContainerBase.setManager(ContainerBase.java:432)
>at
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4160)
>at
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014)
>at org.apache.catalina.core.StandardHost.start(StandardHost.java:736)
>at
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014)
>at
> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
>at
> org.apache.catalina.core.StandardService.start(StandardService.java:448)
>at
> org.apache.catalina.core.StandardServer.start(StandardServer.java:700)
>at org.apache.catalina.startup.Catalina.start(Catalina.java:552)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>at java.lang.reflect.Method.invoke(Method.java:597)
>at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295)
>at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433)
> Caused by: java.lang.RuntimeException: Service token for service
> 'ProductConfig' can not be converted back into a proxy because no
> proxy provider has been registered. This may indicate that an IoC
> Registry has not been started yet.
>at
> org.apache.tapestry5.ioc.internal.SerializationSupport.readResolve(SerializationSupport.java:72)
>at
> org.apache.tapestry5.ioc.internal.ServiceProxyToken.readResolve(ServiceProxyToken.java:37)
>
>
> The failure occurs inside this code:
>
> class ServiceProxyToken implements Serializable
> {
> private final String serviceId;
>
> ServiceProxyToken(String serviceId)
> {
> this.serviceId = serviceId;
> }
>
> Object readResolve() throws ObjectStreamException
> {
> try
> {
>
Clustering, De-Serialization and Order of Operations
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 (in the form of a Servlet Filter) has
initialized first ... but it appears that when starting up a Tomcat
instance,
the HttpSession data is deserialized from disk *before* the filter is
initialized.
Here's the stack trace:
ERROR ( ManagerBase:412 ) - IOException while loading
persisted sessions: java.io.InvalidObjectException: Service token for
service 'ProductConfig' can not be converted back into a proxy because
no proxy provider has been registered. This may indicate that an IoC
Registry has not been started yet.
java.io.InvalidObjectException: Service token for service
'ProductConfig' can not be converted back into a proxy because no
proxy provider has been registered. This may indicate that an IoC
Registry has not been started yet.
at
org.apache.tapestry5.ioc.internal.ServiceProxyToken.readResolve(ServiceProxyToken.java:41)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at
org.apache.catalina.session.StandardSession.readObject(StandardSession.java:1407)
at
org.apache.catalina.session.StandardSession.readObjectData(StandardSession.java:931)
at
org.apache.catalina.session.StandardManager.doLoad(StandardManager.java:394)
at
org.apache.catalina.session.StandardManager.load(StandardManager.java:321)
at
org.apache.catalina.session.StandardManager.start(StandardManager.java:637)
at
org.apache.catalina.core.ContainerBase.setManager(ContainerBase.java:432)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4160)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:736)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at
org.apache.catalina.core.StandardService.start(StandardService.java:448)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:700)
at org.apache.catalina.startup.Catalina.start(Catalina.java:552)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433)
Caused by: java.lang.RuntimeException: Service token for service
'ProductConfig' can not be converted back into a proxy because no
proxy provider has been registered. This may indicate that an IoC
Registry has not been started yet.
at
org.apache.tapestry5.ioc.internal.SerializationSupport.readResolve(SerializationSupport.java:72)
at
org.apache.tapestry5.ioc.internal.ServiceProxyToken.readResolve(ServiceProxyToken.java:37)
The failure occurs inside this code:
class ServiceProxyToken implements Serializable
{
private final String serviceId;
ServiceProxyToken(String serviceId)
{
this.serviceId = serviceId;
}
Object readResolve() throws ObjectStreamException
{
try
{
return SerializationSupport.readResolve(serviceId);
}
catch (Exception ex)
{
ObjectStreamException ose = new
InvalidObjectException(ex.getMessage());
ose.initCause(ex);
throw ose;
}
}
}
This occurs because the Tapestry IoC container has not been
initialized by the Tapestry Filter yet.
SerializationSupport.readResolve() requires that the Filter be
initialized.
In case you are curious: these ServiceProxyToken obj
Fw: Serialization error while deploying Axis2 Cluster
Hi Tomcat Users: I encountered a problem while using Axis2 cluster and asked for help in axis2 users group but seems like this may be related to Tomcat Tribes framework. I am getting the following error when I deploy a sinple service version to axis2 cluster. Here is the error Could not send command message ContextClusteringCommandCollection to group since it is not serializable. Also it seems that it cannot bind to one of the servers in the cluster: [INFO] New member 10.xxx.xxx.xxx:4001(apache.axis2.domain) joined cluster. Jan 29, 2010 2:40:07 PM org.apache.catalina.tribes.transport.ReceiverBase bind INFO: Unable to bind server socket to:abc.com/10.xxx.xxx.xxx:4 099 throwing error. Jan 29, 2010 2:40:07 PM org.apache.catalina.tribes.transport.nio.NioReceiver sta rt SEVERE: Unable to start cluster receiver java.net.BindException: Cannot assign requested address at sun.nio.ch.Net.bind(Native Method) at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java: 119) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:52) at org.apache.catalina.tribes.transport.ReceiverBase.bind(ReceiverBase.j ava:205) at org.apache.catalina.tribes.transport.ReceiverBase.bind(ReceiverBase.j ava:217) at org.apache.catalina.tribes.transport.ReceiverBase.bind(ReceiverBase.j The error persists even after I added excludes with the class that is not being serialized. Turning serialization off however, stops this error from getting reported. However, I would like to test serialization. Any thoughts? Thank You and Best Regards Sincerely Shailesh From: Shailesh Potnis To: axis-u...@ws.apache.org Sent: Fri, January 29, 2010 3:13:16 PM Subject: Serialization error while deploying Axis2 Cluster Hi All: I am getting the following error when I deploy a sinple service version to axis2 cluster. Here is the error Could not send command message ContextClusteringCommandCollection to group since it is not serializable. Also it seems that it cannot bind to one of the servers in the cluster: [INFO] New member 10.xxx.xxx.xxx:4001(apache.axis2.domain) joined cluster. Jan 29, 2010 2:40:07 PM org.apache.catalina.tribes.transport.ReceiverBase bind INFO: Unable to bind server socket to:abc.com/10.xxx.xxx.xxx:4 099 throwing error. Jan 29, 2010 2:40:07 PM org.apache.catalina.tribes.transport.nio.NioReceiver sta rt SEVERE: Unable to start cluster receiver java.net.BindException: Cannot assign requested address at sun.nio.ch.Net.bind(Native Method) at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java: 119) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:52) at org.apache.catalina.tribes.transport.ReceiverBase.bind(ReceiverBase.j ava:205) at org.apache.catalina.tribes.transport.ReceiverBase.bind(ReceiverBase.j ava:217) at org.apache.catalina.tribes.transport.ReceiverBase.bind(ReceiverBase.j I have attached my axis2.xml file (renamed as axis2.txt) Could someone please suggest what may be causing it. Thanks Shailesh Thank You and Best Regards Sincerely Shailesh
Re: session de-serialization issue
-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 happen. I'll try to describe some of
them.
> public class TestClass implements Serializable {
[snip]
> I can put this class directly into the session and it is successfully
> serialized and de-serialized across tomcat restarts. This is working just
> fine.
Good.
> However, if I create a containing class for my simple class:
>
> public class ContainingClass implements Serializable {
[snip]
> I receive the following error upon de-serialization after tomcat restarts:
>
> 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
> ContainingClass
>at java.io.ObjectInputStream.readClassDescriptor(libgcj.so.7rh)
This generally happens when you have modified the definition of
TestClass and had an object of the old definition already serialized.
You can demonstrate this yourself by doing the following:
1. Create a class (TestClass). Write a quick program to create a new
object then serialize it. Write another (separate) program to
de-serialize that object from a file. Verify everything works.
2. Change TestClass by re-arranging some of the method signatures.
Re-compile everything. Try re-running your de-serializer against the
previously-serialized TestClass object: you'll get the above error.
When you compile a Java class, the compiler looks for a "static long"
member called "serialVersionUID". If that hasn't been defined, it will
generate one for you by hashing a bunch of stuff together to create
something relatively unique. That number is supposed to uniquely
identify the version of the class, and it gets stored with serialized
objects. When you modify the class, the auto-generated version id
changes, and the old, serialized object doesn't match the version of the
new class.
One technique is to manually set this serialVersionUID. Another is to
simply not change the class when you want to read old versions of it. I
suspect what happened was:
1. You created the class and put an object into a session.
2. You changed the class and recompiled, resulting in a webapp reload.
Reloads trigger session persistence.
3. The new class was loaded into the new webapp.
4. Your stale object was loaded and didn't match the new class version.
If you delete your SESSIONS.ser file, can you persist your new objects?
As much as Chuck hates gjc, I don't think this is the culprit in this
particular case. Gjc has lots of other problems WRT running web
applications, but this shouldn't be one of them.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkk74oYACgkQ9CaO5/Lv0PDshgCgr1ThBOT0akYdgiwoEyhefQs5
yocAn0MIwIHJqd3guDNQTeFcFurc28YO
=JIQ0
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: session de-serialization issue
Send reply to: Tomcat Users List 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 > 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 > I've used the sun provided rpm to install jdk 1.6 on centos 5.1 and 5.2 without any problems. I uninstalled redhat packaged java (gnu java) first. -Steve O. > > >> 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 ContainingClass > >>at java.io.ObjectInputStream.readClassDescriptor(libgcj.so.7rh) > > > > You need to use a real JVM; gcj is inappropriate for serious work. > > Download and install a proper one from Sun and try it again. > > > > - Chuck > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: session de-serialization issue
> 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 things (from the Java viewpoint). Also, I'd recommend a newer JVM than 1.4; performance in 1.6 especially is much better. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: session de-serialization issue
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 field type for >> testClass in class >> ContainingClass >>at java.io.ObjectInputStream.readClassDescriptor(libgcj.so.7rh) > > You need to use a real JVM; gcj is inappropriate for serious work. > Download and install a proper one from Sun and try it again. > > - Chuck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: session de-serialization issue
> 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 > ContainingClass >at java.io.ObjectInputStream.readClassDescriptor(libgcj.so.7rh) You need to use a real JVM; gcj is inappropriate for serious work. Download and install a proper one from Sun and try it again. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
session de-serialization issue
Hi-
I have an issue with session persistence that I can't figure out.
I am running:
CentOS 5.2
Tomcat 5.5.23
JDK 1.4.2
I would like my user sessions to be persisted across tomcat restarts.
I would like this to happen using the default write-to-file (SESSIONS.ser)
method 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 TestClass implements Serializable {
private int test;
public TestClass() {
test = 1234;
}
public int getTest() {
return test;
}
}
I can put this class directly into the session and it is successfully
serialized and de-serialized across tomcat restarts. This is working just
fine.
However, if I create a containing class for my simple class:
import java.io.*;
public class ContainingClass implements Serializable {
private TestClass testClass;
public ContainingClass() {
testClass = new TestClass();
}
public TestClass getTestClass() {
return testClass;
}
}
I receive the following error upon de-serialization after tomcat restarts:
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
ContainingClass
at java.io.ObjectInputStream.readClassDescriptor(libgcj.so.7rh)
This behavior is extremely consistent across all of my testing.
Does anyone have any ideas as to why I can't de-serialize classes that
contain non-native JDK types?
Thank you!
-Tom
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
applet-servlet communication, object serialization (tomcat 5.5)
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 scenario i write a serialized standard java object (e.g. a String object) onto the ObjectOutputStream of the applet/test-application (it doesn't matters wheter to use the first or the latter one for test cases) and the doPost method of the servlet reads the object from the ObjectInputStream. That works fine. But if i use customized objects (which should also work fine) the same code produces an classnotfound exception (when i try to read and cast the object: TestMessage e = (TestMessage)objin.readObject();): java.lang.ClassNotFoundException: TestMessage at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1359) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1205) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) ... That seems strange to me, because if i instantiate an object of the same customized class (TestMessage) in the servlet code, the webappclassloader doesn't have any problems loading and handling the class and the code works fine! The class is located in the web-inf/classes directory of the application. I've already tried to put the class (with and without the package structure) into the common/classes and server/classes directory, but the exception stays the same (I've also tried to build a jar and put it in the appropriate lib directories). I've also tried to catch a Throwable object in order to get information on the cause. But i get a "null" value (the docu says, that this will may be caused by an unknown error). I've also inspected the log files intensively. But they gave me no hint. Until now I've spend a lot of time on searching and messing around but i always get this classnotfound exception. I hope this is the right place to post this problem and i hope that there is anyone out there who can give me some hint on solving this problem. Kindly regards, Daniel -- If we knew what it was we were doing, it would not be called research, would it? --Albert Einstein-- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Threaddeath logging during session serialization??
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 and those in our webapplication, but i was thinking catalina was separating them properly. Using tomcat 5.5.7 (Yes, i know it's not the most recent, but i can't upgrade production server for now). 18-juil.-2007 14:41:11 org.apache.catalina.loader.WebappClassLoader loadClass INFO: Illegal access: this web application instance has been stopped already. Could not load org.apache.log4j.spi.ThrowableInformation. The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact. java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:271) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:409) Caused by: java.lang.ThreadDeath at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1221) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1181) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) at org.apache.log4j.spi.LoggingEvent.(LoggingEvent.java:145) at org.apache.log4j.Category.forcedLog(Category.java:379) at org.apache.log4j.Category.log(Category.java:844) at org.apache.commons.logging.impl.Log4JLogger.warn(Log4JLogger.java:169) at org.apache.catalina.session.StandardSession.writeObject(StandardSession.java:1442) at org.apache.catalina.session.StandardSession.writeObjectData(StandardSession.java:911) at org.apache.catalina.session.StandardManager.doUnload(StandardManager.java:516) at org.apache.catalina.session.StandardManager.unload(StandardManager.java:462) at org.apache.catalina.session.StandardManager.stop(StandardManager.java:664) at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4261) at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:892) at org.apache.catalina.startup.HostConfig.undeployApps(HostConfig.java:1147) at org.apache.catalina.startup.HostConfig.stop(HostConfig.java:1119) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:312) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1051) at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1063) at org.apache.catalina.core.StandardEngine.stop(StandardEngine.java:445) at org.apache.catalina.core.StandardService.stop(StandardService.java:512) at org.apache.catalina.core.StandardServer.stop(StandardServer.java:717) at org.apache.catalina.startup.Catalina.stop(Catalina.java:586) at org.apache.catalina.startup.Catalina.start(Catalina.java:561) ... 6 more -- http://www.noooxml.org/ - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Service instance serialization question
-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 synchronous or asynchronous? If it's asynchronous,
then you have the option of queuing all requests and having a single
processor thread process them in order.
If you have th handle these requests synchronously, then you will need
to use some sort of synchronization monitor to control access to the
hardware device. This is not as simple as merely marking a method as
"synchronized", as another respondent suggested.
You need to make sure that the object being used as the synchronization
lock (the "monitor") is the one that is always being used. You have
several options:
1. Throw an object in the appropriate scope (probably 'application') and
do something like:
synchronized(application.getAttribute("MY_HARDWARE_LOCK"))
{
/// do your hardware call
}
2. Better than that, you could use a "hardware access" class that knew
how to manage its own synchronization, and put *that* into the
application scope:
application.getAttribute("MY_HARDWARE_CONTROLLER").doSomething();
In this case, make sure that you are only creating one instance of your
hardware controller and that you make the doSomething method
synchronized (synchronizing a method makes /this/ the monitor for the
synchronization).
3. Use a singleton like #2 above, which won't require you to have a
scope like the application available for storage. This is useful when
you have to access something like this from deep within different
components and you don't have a convenient place to store your hardware
controller.
> Is it possible to serialize between service instances, which have
> been created by tomcat?
Yes, you can do this too. Although I recommend using a single instance
of this hardware service, you can use multiple instances of you wish.
You just need to make sure that all instances are using the same monitor
for synchronization.
> Is there some external library to tomcat shared memory object which
> will allow me to do this?
No.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGB8yb9CaO5/Lv0PARAs57AJsGBLY27n0sklGDJ61SgspEr1GagQCeKahP
qOeDAwzkg/wSsEqFkC+BXdA=
=5Zwc
-END PGP SIGNATURE-
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Service instance serialization question
private String synchronization MyServletHardwareCallingRoutine(HttpRequest
BlaBla){
CALL THE HARDWARE HERE
return INFO
}
SYNCHRONIZATION will allow only one thread at a time, so they will Q.
BUT so will the clients wait.
If the clients do not need a reply from the hardware then
private void MyServletHardwareCallingRoutineAsBackGroundProcess(HttpRequest
BlaBla){
new HardwareSrvr().asyncStartServer();
}
public class HardwareSrvr implements Runnable {
private Thread runner;
public HardwareSrvr () {
}
public void asyncStartServer(){
runner = new Thread(this);
runner.start();
}
}
public void run() {
CALL HARWARE HERE
}
}
regards
Johnny
Free Software at http://coolese.100free.com/
- Original Message -
From: "Tom Kobialka" <[EMAIL PROTECTED]>
To:
Sent: Monday, March 26, 2007 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 which can only handle one query at a time. If I
have 5 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 external library to tomcat
shared memory object which will
allow me to do this? I have had a look around the web, but I'm not really
sure where to start. I've come
across messaging solutions, but all these seem to be targeted towards
serialization between services located
on completely different tomcat instances (JMS).
Cheers
Tom
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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 which can only handle one query at a time. If I have 5 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 external library to tomcat shared memory object which will allow me to do this? I have had a look around the web, but I'm not really sure where to start. I've come across messaging solutions, but all these seem to be targeted towards serialization between services located on completely different tomcat instances (JMS). Cheers Tom - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
session serialization issue?
I am working on my first Tomcat based application and while testing the application my boss entered some data into some fields. While he was doing that, I was doing the same thing - entering data into the very same fields in a different session. Unfortunately my values stored in session attributes got mixed in with his values in his session attributes . I don't see how it could have happened. My data should have been stored in a completely different session and should not have been visible to his session. So I came across a bug posting here: Bugzilla Bug 40114, Session 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 into the system, she picked up User B's session information (name, id, etc.) Tomcat 5.5, JVM 1.5_7 Is this the same issue as described above? What is the best way fix my problem? I am using Tomcat 5.5.20 on Suse Linux 10.1 - JVM 1.5.0_09 Thanks, -- John Wallace | Java / Web Developer [EMAIL PROTECTED] http://firesign.net - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: session serialization issue?
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. With a reproducible test case I'll take a look and fix any underlying bug. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cluster serialization issue
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 then this is almost certainly a bad idea. Mark On Thu, 2006-08-24 at 09:04 -0500, Bischoff, Mathew wrote: 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 turned up anything useful. Any help would be appreciated ... Tomcat 5.5.12 on Solaris 2006-08-23 15:22:48,096 DEBUG DeltaManager - Manager [/edjls]: Received SessionMessage of type=(SESSION-DELTA) from [org.apache.catalina.cluster.mcast.McastMember[...]] 2006-08-23 15:22:48,097 DEBUG DeltaManager - Manager [/edjls]: received session [4F2C1D4583B74B19E35243B76B2A35AF.a1] delta. 2006-08-23 15:22:57,837 ERROR DeltaManager - Unable to serialize delta request for sessionid [4F2C1D4583B74B19E35243B76B2A35AF.a1] java.io.NotSerializableException: org.apache.catalina.connector.RequestFacade at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:13 69) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1341) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1 284) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:13 69) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1341) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1 284) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:291) at org.apache.catalina.cluster.session.DeltaRequest$AttributeInfo.writeExte rnal(DeltaRequest.java:346) at org.apache.catalina.cluster.session.DeltaRequest.writeExternal(DeltaRequ est.java:263) at org.apache.catalina.cluster.session.DeltaManager.unloadDeltaRequest(Delt aManager.java:695) at org.apache.catalina.cluster.session.DeltaManager.requestCompleted(DeltaM anager.java:1249) at org.apache.catalina.cluster.tcp.ReplicationValve.sendSessionReplicationM essage(ReplicationValve.java:328) at org.apache.catalina.cluster.tcp.ReplicationValve.invoke(ReplicationValve .java:271) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java :105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve. java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:1 48) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:86 8) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.proc essConnection(Http11BaseProtocol.java:663) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint .java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollow erWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool .java:684) at java.lang.Thread.run(Thread.java:595) Matt Bischoff Software Developer - FDS External Systems Merrill Corporation - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This email has been scanned for all known viruses by the MessageLabs SkyScan service. This email has been scanned for all known viruses by the MessageLabs SkyScan service. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cluster serialization issue
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, > 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 turned up anything useful. Any help would be appreciated ... > > Tomcat 5.5.12 on Solaris > > 2006-08-23 15:22:48,096 DEBUG DeltaManager - > Manager [/edjls]: Received SessionMessage of type=(SESSION-DELTA) from > [org.apache.catalina.cluster.mcast.McastMember[...]] > 2006-08-23 15:22:48,097 DEBUG DeltaManager - > Manager [/edjls]: received session [4F2C1D4583B74B19E35243B76B2A35AF.a1] > delta. > 2006-08-23 15:22:57,837 ERROR DeltaManager - Unable > to serialize delta request for sessionid > [4F2C1D4583B74B19E35243B76B2A35AF.a1] > java.io.NotSerializableException: > org.apache.catalina.connector.RequestFacade > at > java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) > at > java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:13 > 69) > at > java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1341) > at > java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1 > 284) > at > java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073) > at > java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:13 > 69) > at > java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1341) > at > java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1 > 284) > at > java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073) > at > java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:291) > at > org.apache.catalina.cluster.session.DeltaRequest$AttributeInfo.writeExte > rnal(DeltaRequest.java:346) > at > org.apache.catalina.cluster.session.DeltaRequest.writeExternal(DeltaRequ > est.java:263) > at > org.apache.catalina.cluster.session.DeltaManager.unloadDeltaRequest(Delt > aManager.java:695) > at > org.apache.catalina.cluster.session.DeltaManager.requestCompleted(DeltaM > anager.java:1249) > at > org.apache.catalina.cluster.tcp.ReplicationValve.sendSessionReplicationM > essage(ReplicationValve.java:328) > at > org.apache.catalina.cluster.tcp.ReplicationValve.invoke(ReplicationValve > .java:271) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java > :105) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve. > java:107) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:1 > 48) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:86 > 8) > at > org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.proc > essConnection(Http11BaseProtocol.java:663) > at > org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint > .java:527) > at > org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollow > erWorkerThread.java:80) > at > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool > .java:684) > at java.lang.Thread.run(Thread.java:595) > > Matt Bischoff > Software Developer - FDS External Systems > Merrill Corporation > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > This email has been scanned for all known viruses by the MessageLabs SkyScan > service. This email has been scanned for all known viruses by the MessageLabs SkyScan service. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Cluster serialization issue
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 turned up anything useful. Any help would be appreciated ... Tomcat 5.5.12 on Solaris 2006-08-23 15:22:48,096 DEBUG DeltaManager - Manager [/edjls]: Received SessionMessage of type=(SESSION-DELTA) from [org.apache.catalina.cluster.mcast.McastMember[...]] 2006-08-23 15:22:48,097 DEBUG DeltaManager - Manager [/edjls]: received session [4F2C1D4583B74B19E35243B76B2A35AF.a1] delta. 2006-08-23 15:22:57,837 ERROR DeltaManager - Unable to serialize delta request for sessionid [4F2C1D4583B74B19E35243B76B2A35AF.a1] java.io.NotSerializableException: org.apache.catalina.connector.RequestFacade at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:13 69) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1341) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1 284) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:13 69) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1341) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1 284) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:291) at org.apache.catalina.cluster.session.DeltaRequest$AttributeInfo.writeExte rnal(DeltaRequest.java:346) at org.apache.catalina.cluster.session.DeltaRequest.writeExternal(DeltaRequ est.java:263) at org.apache.catalina.cluster.session.DeltaManager.unloadDeltaRequest(Delt aManager.java:695) at org.apache.catalina.cluster.session.DeltaManager.requestCompleted(DeltaM anager.java:1249) at org.apache.catalina.cluster.tcp.ReplicationValve.sendSessionReplicationM essage(ReplicationValve.java:328) at org.apache.catalina.cluster.tcp.ReplicationValve.invoke(ReplicationValve .java:271) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java :105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve. java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:1 48) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:86 8) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.proc essConnection(Http11BaseProtocol.java:663) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint .java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollow erWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool .java:684) at java.lang.Thread.run(Thread.java:595) Matt Bischoff Software Developer - FDS External Systems Merrill Corporation - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: enforcing serialization of session attributes
Maybe you need to have: ...SNIP... In your META-INF/context.xml or maybe the above is needed only in newer version of 5.5.x. Darryl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
enforcing serialization of session attributes
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 during integration testing. To achieve this I have added "" to our application's web.xml, and added a "Manager" with distributable set to true in the Tomcat server.xml (complete file included below). However, when testing an object that implements Serializable, but has non-transient instance variables that don't (e.g. org.w3c.dom.Document) Tomcat accepts setting it in the session - no stack traces in the console, nothing written to the log files. Also, if I shutdown the server mid-sequence, the "SESSIONS.ser" file is updated but is only ever 81 bytes, so I'm not sure it's working properly? Are we doing something wrong, or is this a known issue either resolved in more recent builds or planned to be resolved? Thanks, Chris Nappin Technical Architect ABM United Kingdom Limited Telephone: +44 (0) 115 977 6999 Facsimile: +44 (0) 115 977 6850 Web: http://www.abm-uk.com ABM for Intelligent Solutions CONFIDENTIALITY & PRIVILEGE NOTICE This e-mail is confidential to its intended recipient. It may also be privileged. Neither the confidentiality nor any privilege attaching to this e-mail is waived lost or destroyed by reason that it has been mistakenly transmitted to a person or entity other than its intended recipient. If you are not the intended recipient please notify us immediately by telephone or fax at the numbers provided above or e-mail by Reply To Author and return the printed e-mail to us by post at our expense. We believe, but do not warrant, that this e-mail and any attachments are virus-free, but you should check. We may monitor traffic data of both business and personal e-mails. We are not liable for any opinions expressed by the sender where this is a non-business e-mail. If you do not receive all the message, or if you have difficulty with the transmission, please telephone us immediately.
no listener method called when session restored from serialization
The method below is from org.apache.catalina.session.StandardSession
tomcat 5.0.28 source. Since the setId call is commented and the id is
simply set to the data member directly, no session listeners are
notified (notified from setId method via tellNew method). How can I get
access 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.
*
* IMPLEMENTATION NOTE: The reference to the owning Manager
* is not restored by this method, and must be set explicitly.
*
* @param stream The input stream to read from
*
* @exception ClassNotFoundException if an unknown class is
specified
* @exception IOException if an input/output error occurs
*/
protected void readObject(ObjectInputStream stream)
throws ClassNotFoundException, IOException {
// Deserialize the scalar instance variables (except Manager)
authType = null;// Transient only
creationTime = ((Long) stream.readObject()).longValue();
lastAccessedTime = ((Long) stream.readObject()).longValue();
maxInactiveInterval = ((Integer)
stream.readObject()).intValue();
isNew = ((Boolean) stream.readObject()).booleanValue();
isValid = ((Boolean) stream.readObject()).booleanValue();
thisAccessedTime = ((Long) stream.readObject()).longValue();
principal = null;// Transient only
//setId((String) stream.readObject());
id = (String) stream.readObject();
if (debug >= 2)
log("readObject() loading session " + id);
// Deserialize the attribute count and attribute values
if (attributes == null)
attributes = new HashMap();
int n = ((Integer) stream.readObject()).intValue();
boolean isValidSave = isValid;
isValid = true;
for (int i = 0; i < n; i++) {
String name = (String) stream.readObject();
Object value = (Object) stream.readObject();
if ((value instanceof String) &&
(value.equals(NOT_SERIALIZED)))
continue;
if (debug >= 2)
log(" loading attribute '" + name +
"' with value '" + value + "'");
synchronized (attributes) {
attributes.put(name, value);
}
}
isValid = isValidSave;
}
Re: AW: Problem disabling session serialization duing shutdown.
or shorter with at tomcat 5.5 add the description at your META-INF/context.xml or at the conf/context.xml :-) Peter Am 14.03.2006 um 15:31 schrieb Michael Südkamp: 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 className="org.apache.catalina.session.PersistentManager" saveOnRestart="false"> className="org.apache.catalina.session.FileStore"/> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Problem disabling session serialization duing shutdown.
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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem disabling session serialization duing shutdown.
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: I was unable to find any context.xml as such, so I put the XML snippet in the descriptor of my webapplication in the server.xml file. Yet no fruit. Was I supposed to add the afore-mentioned XML snipet in "context.xml" only? Or is it some other problem? Following is the stack trace if of any relavance: SEVERE: Exception unloading sessions to persistent storage java.io.FileNotFoundException: /opt/tomcat2/work/Catalina/localhost/manager/SESSIONS.ser (No such file or directory) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.(FileOutputStream.java:179) at java.io.FileOutputStream.(FileOutputStream.java:70) at org.apache.catalina.session.StandardManager.doUnload(StandardManager.java:511) at org.apache.catalina.session.StandardManager.unload(StandardManager.java:485) at org.apache.catalina.session.StandardManager.stop(StandardManager.java:687) at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4496) at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:952) at org.apache.catalina.core.StandardHostDeployer.remove(StandardHostDeployer.java:670) at org.apache.catalina.core.StandardHost.remove(StandardHost.java:946) at org.apache.catalina.startup.HostConfig.undeployApps(HostConfig.java:1028) at org.apache.catalina.startup.HostConfig.stop(HostConfig.java:1005) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:351) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1123) at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1135) at org.apache.catalina.core.StandardEngine.stop(StandardEngine.java:483) at org.apache.catalina.core.StandardService.stop(StandardService.java:542) at org.apache.catalina.core.StandardServer.stop(StandardServer.java:2347) at org.apache.catalina.startup.Catalina.stop(Catalina.java:605) at org.apache.catalina.startup.Catalina.start(Catalina.java:580) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:287) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:425) - Yahoo! Mail Bring photos to life! New PhotoMail makes sharing a breeze.
