Ch Praveena wrote:
Thank you all for your responses..
But still I am at lot of confusion as I was not the actual person who have
designed the code. Anyway, I will try to solve the issue at the earliest.
And here is an issue for the Tomcat designers. It was already known that
Jboss internally use Tomcat as a web container.
I already found that RequestFacade.java be be not serialised class. And
also I found that RequestFacade.java file with in the internal jars of
Jboss at JBOSS_HOME/server/all/deploy/jboss-web.deployer/jbossweb.jar file.
Now, I would like to ask you if there would be any technical problem to the
jboss architecture or Tomcat when we serialize this RequestFacade.java
file?
Option 2/3 are not good options. The problem is that you should not try
to store the Request object (or the facade) in a session.
I seem to remember this coming up recently and one of the TC dev's
recommending against doing this. As soon as it the original
request/response cycle has finished, the object you are storing is in an
undefined state, (or something, errr, anyone?).
If there is data in the request that you need to reuse, put it in a Map,
List or Enumeration (even creating your own properly serialized object
to hold it would be OK) and store that instead.
p
2008/5/23 Eric Lennon Bowman <[EMAIL PROTECTED]>:
On Thu, May 22, 2008 2:36 pm, Scott Courtney wrote:
There really are only two solutions:
1. Modify your application so that RequestFacade is not stored in the
session
object. You probably won't learn much from the stack trace, because
that is
tracing the replication process that failed, not the application code
that
stored the object. Look for a Serializable object in your app which
has
a
reference to RequestFacade, perhaps in a member variable. Find a way
not to
use that reference, or not to store your containing object in the
session.
2. Modify the Echo2 or Catalina source code so that RequestFacade is
declared
Serializable. I would be *very* cautious about doing that, because
just
declaring the Serializable interface doesn't mean that your object can
be sensibly serialized -- it just means *you* think it can. As someone
else
suggested, read up on the serialization process before trying this.
And
in
any case, this means forking a library module, which is usually a
horrible
idea.
As others have said, this question is really more related to Tomcat than
it
is to Apache, so you will probably have better luck on the Tomcat forums.
I'm
hoping the above hints will give you a headstart on a Google search of
those
forums and/or a closer look at your application code.
There's actually a 3rd option -- if you need to hang on to a request
object, mark it transient. It makes NO sense to move a request object
around the cluster; I wouldn't recommend trying to make that work.
(Sorry about the formatting...:) )
--
Eric Lennon Bowman
Bobo Company Ltd
[EMAIL PROTECTED]
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: [EMAIL PROTECTED]
" from the digest: [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]
