> I've noticed a couple of threads about strange ClassCastException
> problems ("Call EJB in OC4J from Tomcat",
> "pulling my hair out re: EJB in tomcat").
>
> I've run into a strange ClassCastException in a slightly different
> context, but it seems that it might be related and might help
> narrow down the problem.
>
> I have an application that is broken into two tomcat web-apps
> (contexts) ("MainApp", "HelperApp").
>
> One thing I am trying to do is have the MainApp populate a
> request with some beans and then include a jsp from HelperApp:
>
> populateRequestWithBeans(); // uses RequestDispatcher.include()
> sc.getRequestDispatcher(TargetPage).include(request, response);
>
> If the TargetPage is in MainApp this works fine.
>
> If the TargetPage is in HelperApp and I run it from my development
> environment (Tomcat 3.2.1) it runs fine (gets context of HelperApp).
>
> If the TargetPage is in HelperApp and I run it in Tomcat 4.0 then
> I get a ClassCastException in TargetPage on the line where the
> TargetPage jsp tries to retrieve the bean (2nd line below):
>
> com.athensgroup.autoweb_projects.ClientInfo ClientInfo = null;
> ...
> ClientInfo= (com.athensgroup.autoweb_projects.ClientInfo)
> pageContext.getAttribute("ClientInfo",PageContext.REQUEST_SCOPE);
>
> The runtime error complains that the object is actually of type
> com.athensgroup.autoweb_projects.ClientInfo
> which is clearly the SAME (textually)!
>
> Since this works in some environments it eliminates issues of typos,
> logic errors, etc in the code.
>
> The key seems to be that the two web-apps think that the same class
> is a different class! (Both have copies of the SAME class file in their
> WEB-INF\classes directories.
This is normal then. Class foo loaded by class loader A is not castable to
class foo loaded by class loader B (if they are really independent, of
course - if A is the parent of B and B delegates, it will work). You have to
put the class in a spot shared by both webapps (that means the shared class
loader.
> Is there something in Tomcat or the JVM which would make two
> different web-apps think that the same class is not the same class?
> Obviously there is something MORE than just the class name that
> is being used to distinguish them.
Remy
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
