[jira] Resolved: (PLUTO-101) ClassCastException in PortletServlet.init()

["David DeWolf (JIRA)" <pl...@jakarta.apache.org>]

     [ http://issues.apache.org/jira/browse/PLUTO-101?page=history ]
     
David DeWolf resolved PLUTO-101:
--------------------------------

    Resolution: Won't Fix

I've been playing with different ideas on how we can remove the necessity of placing all container dependencies (not just the portlet-api-xx.jar) in a common/lib or similar directory and instead just place them in the portal driver's webapp. Unfortunately the only solutions I've come up with involve either some classloader magic which would go against the servlet-spec by programmatically modifying the app servers context class loader or by adding container specific logic.  I'm not happy with either approach.

Until someone comes up with a better solution (or we decide as a whole to support multiple implementations of container specific logic - uck!), this annoyance will have to remain.  If someone has any bright ideas, please let me know.

FWIW, when using an app server which supports ear deployments, you *can* package the dependencies as a shared library within the ear instead of in the app servers common classpath (which will allow visibility by ALL apps).

> ClassCastException in PortletServlet.init()
> -------------------------------------------
>
>          Key: PLUTO-101
>          URL: http://issues.apache.org/jira/browse/PLUTO-101
>      Project: Pluto
>         Type: Bug
>   Components: portlet container
>     Versions: 1.0.1-rc2
>  Environment: Windows 2000, SP4 with  Java 1.5
>     Reporter: Wayne Holder

>
> After downloading rc2 and installing it to run using Java 1.5, I created a new web app named wfh which contianed a portlet named TestPortletWFH but, when I tried to run it, I always got a ClassCastException in PortletServlet.init() on this line of code:
>   portletClass = (javax.portlet.Portlet) Thread.currentThread().getContextClassLoader().loadClass(classString).newInstance();
> I then moved the same portlet into the testSuite app and, after making the needed adjustments to the XML, founf that it ran fine there, but not in the wfh app.  Note: I changed portletcontexts.txt to include a path to wfh along with the path to testsuite.
> As I was unable to easily debug the code, I decided to rebuild rc2 from source, changing the code in PortletServlet.init(), as follows:
>   public void init (ServletConfig config) throws ServletException {
>     super.init(config);
>     portletInitialized = false;
>     String classString = config.getInitParameter("portlet-class");
>     try {
>       ClassLoader loader = Thread.currentThread().getContextClassLoader();
>       System.out.println("ClassLoader.toString(): " + loader);
>       System.out.println("classString: " + classString);
>       Class pClass = loader.loadClass(classString);
>       System.out.println("pClass: " + pClass);
>       Object pObj = pClass.newInstance();
>       System.out.println("pObj.getClass(): " + pObj.getClass());
>       System.out.println("pObj instanceof javax.portlet.Portlet: " + (pObj instanceof javax.portlet.Portlet));
>       portletClass = (javax.portlet.Portlet) pObj;
>       //portletClass = (javax.portlet.Portlet) Thread.currentThread().getContextClassLoader().loadClass(classString).newInstance();
>       ...
> and a related function, getInterfaces(), that lists the interfaces implemented by the loaded class.
> When I then access the portlet in the wfh app I get a traces like this in the console:
> ClassLoader.toString(): WebappClassLoader
>   delegate: false
>   repositories:
>     /WEB-INF/classes/
> ----------> Parent Classloader:
> org.apache.catalina.loader.StandardClassLoader@30d82d
> classString: com.nglm.fwk.sys.TestPortletWFH
> pClass: class com.nglm.fwk.sys.TestPortletWFH
>   implements: interface javax.portlet.Portlet, interface javax.portlet.PortletConfig
> pObj.getClass(): class com.nglm.fwk.sys.TestPortletWFH
> pObj instanceof javax.portlet.Portlet: false         <--- ???
> - StandardWrapper.Throwable
> java.lang.ClassCastException: com.nglm.fwk.sys.TestPortletWFH
>         at org.apache.pluto.core.PortletServlet.init(PortletServlet.java:69)
>         at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1053)
> which seems completely illogical since, as you can see, the code reports that the loaded class implements javax.portlet.Portlet, yet the "instanceof javax.portlet.Portlet" test returns false...  To make matters even stranger, running the exact same portlet in testsuite yields this trace:
> ClassLoader.toString(): WebappClassLoader
>   delegate: false
>   repositories:
>     /WEB-INF/classes/
> ----------> Parent Classloader:
> org.apache.catalina.loader.StandardClassLoader@30d82d
> classString: com.nglm.fwk.sys.TestPortletWFH
> pClass: class com.nglm.fwk.sys.TestPortletWFH
>   implements: interface javax.portlet.Portlet, interface javax.portlet.PortletConfig
> pObj.getClass(): class com.nglm.fwk.sys.TestPortletWFH
> pObj instanceof javax.portlet.Portlet: true
> So, either my computer has slipped into the twilight zone, or there's something really screwy going on with the classloader, or the JVM.
> BTW, the exact same wfh app runs fine under rc1, so this seems to be a new issue.  It's possible this may be related to Java 1.5, but I've yet to have enough time to delve that deeply into the issue.
> Wayne

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira