Forum

Accueil » Liferay Portal » English » 3. Development

Vue combinée Vue Plate Arborescence
Sujets [ Précédent | Suivant ]
toggle
Alex Belt
Class cannot be cast to com.liferay.portlet.RenderRequestImpl
17 juillet 2013 09:48
Réponse

Alex Belt

Rang: Junior Member

Publications: 49

Date d'inscription: 9 octobre 2012

Publications Récentes

I'm working on an upgrade from Liferay 5.2.3 to Liferay 6.1.1 running on Tomcat. In the portlet plugin we developed, we wrap all the portlet requests and responses. For render requests, it extends the javax.portlet.filter.RenderRequestWrapper class. This worked fine under 5.2.3. After the upgrade to 6.1.1, I now get this message:

java.lang.ClassCastException: com.gc.filter.GCRenderRequestWrapper cannot be cast to com.liferay.portlet.RenderRequestImpl


The class has a couple of methods not contained in the RenderRequest interface or the RenderRequestWrapper class that are used extensively through the plugin. Since the Lilferay class is contained in portal-impl.jar and there's a classloader issue, how do I get around it?

Has anyone else run into this?

Thanks,
Alex
David H Nebinger
RE: Class cannot be cast to com.liferay.portlet.RenderRequestImpl
17 juillet 2013 10:41
Réponse

David H Nebinger

Community Moderator

Rang: Liferay Legend

Publications: 9234

Date d'inscription: 1 septembre 2006

Publications Récentes

Use an EXT plugin and put your wrapping code in there.
Alex Belt
RE: Class cannot be cast to com.liferay.portlet.RenderRequestImpl
17 juillet 2013 10:56
Réponse

Alex Belt

Rang: Junior Member

Publications: 49

Date d'inscription: 9 octobre 2012

Publications Récentes

Thanks David, but I'm not sure that will solve the problem. I changed the class the wrapper extended to RenderRequestImpl and redeployed. Now I get this whenever it tries to process a request:
SEVERE: Servlet.service() for servlet HomePageSummaryReports threw exception
java.lang.NullPointerException
at com.liferay.portlet.PortletRequestImpl.getAttribute(PortletRequestImpl.java:141)


It seems whatever data it's trying to retrieve is always null - I see this error for every portlet it tries to process that's on the home page after login.

Thanks,
Alex
David H Nebinger
RE: Class cannot be cast to com.liferay.portlet.RenderRequestImpl
17 juillet 2013 12:02
Réponse

David H Nebinger

Community Moderator

Rang: Liferay Legend

Publications: 9234

Date d'inscription: 1 septembre 2006

Publications Récentes

I guess it depends upon how your wrapper is defined and used...

I'm seeing a lot of references in portal-impl to the actual PortletRequestImpl class, so I think your wrapper must subclass it and cannot just be an interface wrapper of some kind. It also looks like the internal Liferay code expects every PortletRequest instance to be a PortletRequestImpl implementation...

You may end up being better off by replacing your direct access to RenderRequestImpl with reflection on the instance to gain access to the method(s) that you need. It will be much less intrusive...
Alex Belt
RE: Class cannot be cast to com.liferay.portlet.RenderRequestImpl
18 juillet 2013 05:57
Réponse

Alex Belt

Rang: Junior Member

Publications: 49

Date d'inscription: 9 octobre 2012

Publications Récentes

I'm confused about how reflection would solve the problem of the wrapper needing to subclass the impl.

Also, I commented out the filters in my portlet.xml, which seems to have temporarily taken care of the issue. I think I know a way to work around the problem. Something else is causing the plugin to unload though, so I need to troubleshoot it.

Thanks,
Alex
Alex Belt
RE: Class cannot be cast to com.liferay.portlet.RenderRequestImpl
18 juillet 2013 11:58
Réponse

Alex Belt

Rang: Junior Member

Publications: 49

Date d'inscription: 9 octobre 2012

Publications Récentes

I've followed the trail as far as I can. I'm officially giving up. The changes in how the portlet requests and sessions were too much - too many bugs, too many issues. We're going to have to overhaul our plugin to work with newer versions. I don't even want to think about how many months of effort that's going to be.
David H Nebinger
RE: Class cannot be cast to com.liferay.portlet.RenderRequestImpl
22 juillet 2013 05:03
Réponse

David H Nebinger

Community Moderator

Rang: Liferay Legend

Publications: 9234

Date d'inscription: 1 septembre 2006

Publications Récentes

Since you're looking at reworking it, I'd suggest trying to do so in a portal-friendly manner; otherwise you may be facing rewrite again when the next version comes out...

In Liferay there tends to be many ways to skin the same cat; whatever functionality you achieved under 5 you can achieve in 6, but I'm betting there must be an easier way...
Alex Belt
RE: Class cannot be cast to com.liferay.portlet.RenderRequestImpl
23 juillet 2013 06:34
Réponse

Alex Belt

Rang: Junior Member

Publications: 49

Date d'inscription: 9 octobre 2012

Publications Récentes

I agree, there are probably several easier ways than the one we used in our current version. My understanding is that long before I came to work at my current employer, we hired a consulting company for some initial portal work then took what they did and used it as a template for the rest of the portal. Supposedly, the portal followed what were best practices at the time I don't know whose idea it was to use Struts, but I wish they hadn't.

Hopefully we can get rid of Struts for something simpler, I just hope it doesn't take too long to do.

Thanks,
Alex
David H Nebinger
RE: Class cannot be cast to com.liferay.portlet.RenderRequestImpl
23 juillet 2013 07:25
Réponse

David H Nebinger

Community Moderator

Rang: Liferay Legend

Publications: 9234

Date d'inscription: 1 septembre 2006

Publications Récentes

Struts is still used extensively by Liferay. Their argument is that it is a lightweight framework that fits well in the portal environment.

While that argument is true, the reality is the world has moved on. We, as web developers in general, have discarded struts a long time ago for better frameworks that are more agile and take on more of the lifecycle handling.

And since we, as developers, have moved on, it's hard to find struts resources. Kids don't want to do it (there's no future in it), experienced devs don't want to go back to it (who wants to take a step backwards on their career path), ...

In my mind, struts is akin to cobol in many respects...