ClassCast Exception on sharing the Local service Util for portlet B from A.

[Sanjeev Singh, geändert vor 13 Jahren.]

Hi,

We are using liferay 6. I am getting ClassCast Exception when i am sharing the Local service Util for portlet B from the portlet A. There seems to be class loading issue.

How to share the service jar of one portlet from another portlet deployed in the liferay tomcat context ? I tried copying the jar in the tomcat/lib/ext. Still i get ClassCast Exception. I even tried copying the jar in the tomcat-6.0.26\webapps\ROOT\WEB-INF\lib and the same error.
Thanks,
Sanjeev.

[iron maiden, geändert vor 13 Jahren.]

Sanjeev Singh:

Hi,

We are using liferay 6. I am getting ClassCast Exception when i am sharing the Local service Util for portlet B from the portlet A. There seems to be class loading issue.

How to share the service jar of one portlet from another portlet deployed in the liferay tomcat context ? I tried copying the jar in the tomcat/lib/ext. Still i get ClassCast Exception. I even tried copying the jar in the tomcat-6.0.26\webapps\ROOT\WEB-INF\lib and the same error.
Thanks,
Sanjeev.

Take a look here

Hope that help.
Best Regards!

[Sanjeev Singh, geändert vor 13 Jahren.]

Thanks for the reply.

I have one more issue. Is it possible to return a Custom Java Bean Object from the service <ClassName>LocalServiceImpl method.

I have a implementation method in class <ClassName>LocalServiceImpl in portletA

private List<Compliance_TopicOTO> getFirstLevelTree(StringBuilder qryString, Session session,List<Compliance_TopicOTO> list,String locale)
{
return compliance_TopicOTOList; // The list having OTO Compliance_TopicOTO.
}

I call this method from the another portletB using the <ClassName>LocalServiceUtil.getFirstLevelTree(...);

I have followed the steps metioned in
http://www.liferay.com/community/wiki/-/wiki/Main/Using+Class+Loader+Proxy+classes+to+share+plugins+services.

Now it expects the Compliance_TopicOTO both in the portletA-service.jar and portletA.war while building and deploying.
When portletB fetches List<Compliance_TopicOTO> compliance_TopicOTOList = <ClassName>LocalServiceUtil.getFirstLevelTree(...);

The fetching is correct. But while iteration the Compliance_TopicOTO throws ClassCastException as this method is called from portletB and the custom Compliance_TopicOTO is present in both the jar and war.

Is it possible to share a custom java bean. If not is there any alternative.

Thanks,
Sanjeev.

[Tina Agrawal, geändert vor 13 Jahren.]

I dont think you can define Custom Java Beans being returned from your LocalServiceImpl.
Because when you run your service builder again your custom beans will not be available to the Utility classes.

What you can try is adding your Custom Java Beans to the service jar rather than the src folder.

Let me know if that works.

Regards,
Tina

[Sanjeev Singh, geändert vor 13 Jahren.]

Hi,

I also added Custom Java Beans to the service jar, the classes were compiled successfully in portlet A. But when i used the LocalServiceUtil class from portlet B, it was able to fetch
the list of Custom Java bean Successfully. The problem is with ClassCast Exception is while type casting the custom java bean.

//The method getTopics is in Portlet B where Compliance_TopicOTO reference is both in //Portlet A and Portlet B.

public SelectItemList getTopics() {
topics = new SelectItemList();

//This line was able to fetch correctly firstLevelTopicList from portlet A
final List<Compliance_TopicOTO> firstLevelTopicList = Compliance_TopicLocalServiceUtil.getFirstLevelTreeOnly(); // TopicLocalServiceUtil is from portlet A

// The type cast of Compliance_TopicOTO by fetching from firstLevelTopicList throws Class Cast Exception.
for (Compliance_TopicOTO complianceTopicOTO : firstLevelTopicList) {
topics.add(new SelectItem(complianceTopicOTO.getOid(), complianceTopicOTO.getTopicName()));
}


On investigation of the above i found that the Custom Java Bean is present in both the portlet-service.jar and war file. The class loading both PortletA , Portlet B is different. Therefore Compliance_TopicOTO is loaded using different class loader.

Is there any better approach. Is it possible to directly to the the local service util class and return the List of object array in the Action Class of Managed Bean.

[Sanjeev Singh, geändert vor 13 Jahren.]

Hi,

I also added Custom Java Beans to the service jar, the classes were compiled successfully in portlet A. But when i used the LocalServiceUtil class from portlet B, it was able to fetch
the list of Custom Java bean Successfully. The problem is with ClassCast Exception is while type casting the custom java bean.

//The method getTopics is in Portlet B where Compliance_TopicOTO reference is both in //Portlet A and Portlet B.

public SelectItemList getTopics() {
topics = new SelectItemList();

//This line was able to fetch correctly firstLevelTopicList from portlet A
final List<Compliance_TopicOTO> firstLevelTopicList = Compliance_TopicLocalServiceUtil.getFirstLevelTreeOnly(); // TopicLocalServiceUtil is from portlet A

// The type cast of Compliance_TopicOTO by fetching from firstLevelTopicList throws Class Cast Exception.
for (Compliance_TopicOTO complianceTopicOTO : firstLevelTopicList) {
topics.add(new SelectItem(complianceTopicOTO.getOid(), complianceTopicOTO.getTopicName()));
}


On investigation of the above i found that the Custom Java Bean is present in both the portlet-service.jar and war file. The class loading both PortletA , Portlet B is different. Therefore Compliance_TopicOTO is loaded using different class loader.

Is there any better approach. Is it possible to directly to the the local service util class and return the List of object array in the Action Class of Managed Bean.


Thanks,
Sanjeev.

[Sanjeev Singh, geändert vor 13 Jahren.]

Hi,

I have done a workaround for this.
I have added multiple portlet in a single project application by adding the multiple entry in portlet.xml and other configuration files.
Then i create a common package and classes in the project workspace in src and service that could be shared by all the portlet. This provides a common classloader to the shared classes.

Thanks,
Sanjeev.