Annoying problem when redeploying

[Marco Ferretti, geändert vor 7 Jahren.]

Hi all,

First of all, in case this is not the right place, please forgive me and kindly point me to the right place.
I have a set of jsf/primefaces portlets for which I have a template and a relative template bean.
Every time I redeploy any of those (on liferay 6.2) I get an error (portlet xyz is not available) and in the logs :

 Cannot convert com.freemove.managed.TemplateBean@52dfbde7 of type class com.freemove.managed.TemplateBean to class com.freemove.managed.TemplateBean

If I log out and log in or if I am not logged in when I re-deploy the portlet the problem vanishes.
I think I read something a couple of years ago on how to get rid of this but can't remember where or how and google is not helping (actually, I can't figure out a decent query string) as it's returning pages on different error messages and so on .

Anyone have an idea ??

Thanks in advance

Marco F.

[Juan Gonzalez, geändert vor 7 Jahren.]

Hi Marcos.

That class doesn't sound me right now. Are you using some specific framework/library for managing templates?

These issues are usually caused by putting libraries in multiple classpath places.

[Marco Ferretti, geändert vor 7 Jahren.]

Hi Juan,

I am using spring + hibernate + primefaces.
The project contains 3 portlets and one common "integration" project that contains the hibernate stuff.
Two portlets have a template and a TemplateBean class, each one uses its own contained in its own war, while the third one is a search engine that links to views in one of the other two :

marco@desktop:~/devel/freemove/workspace/wp1$ find . -name TemplateBean.java
./tools-portlet/src/main/java/com/freemove/managed/TemplateBean.java
./account-portlet/src/main/java/com/freemove/managed/TemplateBean.java

marco@desktop:~/devel/freemove/workspace/wp1$ find . -name TemplateBean.class
./tools-portlet/target/tools-portlet-1.0.0-SNAPSHOT/WEB-INF/classes/com/freemove/managed/TemplateBean.class
./tools-portlet/target/classes/com/freemove/managed/TemplateBean.class
./account-portlet/target/account-portlet-1.0.0-SNAPSHOT/WEB-INF/classes/com/freemove/managed/TemplateBean.class
./account-portlet/target/classes/com/freemove/managed/TemplateBean.class

I have tried to check if the problem could be related to what you suggested so I have tried to give a unique class name to the bean in order to make sure only one existed in case there was a multiple classpath loading problem ... the problem is still the same :

java.lang.IllegalArgumentException: Cannot convert com.freemove.managed.AccountTemplateBean@7b13281 of type class com.freemove.managed.AccountTemplateBean to class com.freemove.managed.AccountTemplateBean

marco@desktop:~/devel/freemove/portal/tomcat-7.0.42$ find . -name AccountTemplateBean.class
./webapps/account-portlet/WEB-INF/classes/com/freemove/managed/AccountTemplateBean.class
./temp/14-account-portlet/WEB-INF/classes/com/freemove/managed/AccountTemplateBean.class

As you can see there is only one AccountTemplateBean around the tomcat installation.

I have then changed the name black to TemplateBean and re-deployed ... and then that haha! moment :

java.lang.IllegalArgumentException: Cannot convert com.freemove.managed.AccountTemplateBean@131ec868 of type class com.freemove.managed.AccountTemplateBean to class com.freemove.managed.TemplateBean

so it looks like I have a problem when undeploying session scoped beans... as that's the only session bean I actually have.

Here's how the class is declared :

@ManagedBean(name="templateBean", eager=true)
@SessionScoped
public class TemplateBean implements Serializable {

The template bean is session scoped as I need to remember which type of view the user is/was in.

[Olaf Kock, geändert vor 7 Jahren.]

Marco Ferretti:

java.lang.IllegalArgumentException: Cannot convert com.freemove.managed.AccountTemplateBean@7b13281 
of type class com.freemove.managed.AccountTemplateBean to class com.freemove.managed.AccountTemplateBean

As you can see there is only one AccountTemplateBean around the tomcat installation.

Whenever you can't typecast an object to a legitimate class, there are duplicate instances of the class on the classpath. If they come from a classes directory on the filesystem or from within a jar file doesn't matter. My prediction is that you should look harder (e.g. unzip all the jar files and search within them)

I've first learned this in the very ancient past, when for some reasons two rt.jar ended up on the classpath, and the VM stated that an object that I had could not be casted to java.lang.Object. The problem is that both classes from both locations are just referenced by their (identical) name and not by the location they're loaded from. You might get some hints if you add a breakpoint and inspect the involved objects and their object.getClass().getClassloader() (note: pseudocode)

There are duplicate classes on the classpath. You just haven't found them yet. Also check tomcat's global classpath

[Marco Ferretti, geändert vor 7 Jahren.]

Hi Olaf
thanks for taking the time to go through the thread and lending a hand, it's extremely appreciated.

Olaf Kock:

There are duplicate classes on the classpath. You just haven't found them yet. Also check tomcat's global classpath

I am not 100% sure of this. In order to verify the duplication on the classpath I have changed the class name of TemplateBean to AccountTemplateBean. At this point I am 99% sure there are no other declarations of that bean within the portlet classpath. Nonetheless I have the same issue when re-deploying.
Also, changing back the name from AccountTemplateBean to TemplateBean leads to the same error only with telling me that AccountTemplateBean cannot be cast to TemplateBean.

Will keep on looking at the declarations on the classpath but I honestly feel like I should be looking somewhere else.

Regards,

Marco F.

[Marco Ferretti, geändert vor 7 Jahren.]

Hi Olaf,

i have just quickly checked within jar files too :

ferrema@pupfish:/srv/liferay-portal-6.2/tomcat-7.0.42$ find . -name '*.jar' | while read line; do unzip -l $line | grep TemplateBean.class; done
ferrema@pupfish:/srv/liferay-portal-6.2/tomcat-7.0.42$ find . -name TemplateBean.class
./webapps/account-portlet/WEB-INF/classes/com/freemove/managed/TemplateBean.class
./webapps/tools-portlet/WEB-INF/classes/com/freemove/managed/TemplateBean.class
./temp/5-account-portlet/WEB-INF/classes/com/freemove/managed/TemplateBean.class
./temp/8-tools-portlet/WEB-INF/classes/com/freemove/managed/TemplateBean.class

As you can see there are no TemplateBean.class within the jar files in the whole tomcat installation and there is only one declaration of the TemplateBean class per webapp/classloader

[Olaf Kock, geändert vor 7 Jahren.]

Marco Ferretti:

As you can see there are no TemplateBean.class within the jar files in the whole tomcat installation and there is only one declaration of the TemplateBean class per webapp/classloader

Further up in the thread you're saying

Two portlets have a template and a TemplateBean class, each one uses its own contained in its own war, while the third one is a search engine that links to views in one of the other two

I do suspect that you're somehow passing one object from one to the other webapp, resulting in this problem. Granted, they're serializable, but as long as you manage to stick them into a (global HTTP-)session, they never need to be serialized/deserialized. After all, the webapps run in the same JVM (just with different classloader hierarchies).

I still think that inspecting the object's and the target class's classloaders when this exception happens will reveal that they differ - probably the duplication is hiding in plain sight, e.g. you do list two occurrences of the class already.

An ugly quickfix might be to push the TemplateBean class to the global class path - this way both applications can access it and you won't run into these problems. Try it (temporarily) just to see if this fixes your issue. Note that I'm not mandating that this is a final solution, but it can help understand the underlying problem.

[Marco Ferretti, geändert vor 7 Jahren.]

I do suspect that you're somehow passing one object from one to the other webapp, resulting in this problem. Granted, they're serializable, but as long as you manage to stick them into a (global HTTP-)session, they never need to be serialized/deserialized. After all, the webapps run in the same JVM (just with different classloader hierarchies).

I still think that inspecting the object's and the target class's classloaders when this exception happens will reveal that they differ - probably the duplication is hiding in plain sight, e.g. you do list two occurrences of the class already.

Hi Olaf,
sorry for the late reply: I got extremely busy with some delivery and this "issue" got in the back of my head.
I am starting to think that the problem relies in the session scope rather than in passing the instance between the two portlets.
In order to check this I have undeployed one of the two portlets, restarted tomcat and logged in. Then I re-deployed the portlet that was still in and replicated the issue : there's no way I am passing the object from one portlet to another if the end point is not there

Then I tried something for the sake of trying: I changed the scope of the TemplateBean from session to view and the problem disappeared.
Now ... I would need to make extensive tests in order to check that view scope is sufficient for what the portlet has to do, but it's a start anyways.

Looking forward for any comment

Marco.

[Neil Griffin, geändert vor 7 Jahren.]

Hi Marco,

Is the "Cannot convert" associated with javax.el.ELException?

Also, do you happen to have the following in your WEB-INF/liferay-portlet.xml descriptor?

 <private-session-attributes>false</private-session-attributes>

If so, then please consider removing that, since it can cause compatibility problems with the Liferay Faces Bridge.

Kind Regards,

Neil