On Fri, 7 Feb 2003, Gavin Everson wrote:
> Date: Fri, 07 Feb 2003 14:25:24 +0800
> From: Gavin Everson <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Perhaps another class-loader issue... but not so sure...
>
> Hi There,
>
> We are experiencing a bit of a strange (to us anyhow) issue. We have
> 10 web servers running, which are clustered into 2 nodes via routers and
> gateways (*not* clustered by tomcat). We have a "sign-up" mechanism
> which is spread out over a few pages, and once you click on "continue"
> on a page (doesn't matter which one), 75% of the times a
> ClassCastException is thrown when the session details are attempted to
> be retrieved from a database (which stores all the session details so we
> can keep track of the user when they are switched onto a different node
> via the load balancing system).
>
> At first i thought it may have just been a classloader issue, but the
> class it is gagging on has been pre-compiled and distributed to each
> app's lib directory on each node, before they were all restarted.
>
> The ClassCastException is thrown on the following sort of line of
> code:
>
> MyBean mybean = (foo.bar.MyBean)pageContext.getAttribute("att_name",
> PageContext.REQUEST_SCOPE);
>
> I repeat that this does not always throw an error, and has worked
> before when switching between nodes on different pages of the form...
>
> All suggestions are greatly appreciated. Thanks :-)
>
> Gavin
>
I have no idea if this is the cause of your particular problem, but I can
provide a guaranteed way to cause the problem you are talking about ...
maybe it will give you some ideas to help you investigate.
There is a common belief in newbie Java developers that a fully qualified
Java class name like "com.mycompany.mypackage.FooClass" is totally and
universally unique within an application. That turns out to be true, but
only within the context of a single class loader.
Let's assume that you have two coopearting web apps that include the
"FooClass" class inside their /WEB-INF directories. That means that each
webapp will load a copy of FooClass from its own class loader -- and,
therefore, instances of FooClass from webapp "A" are ***not*** assignment
compatible with instances of FooClass from webapp "B". It is the
combination of class loader + class name that is required to establish
assignment compatibility, and therefore avoid ClassCastExceptions like the
one you describe.
Craig McClanahan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
