I posted this on the Liferay IDE forum yesterday, but it might be more suited for this forum as it may relate to an underlying issue with the Liferay portlet hot deploy feature rather than Liferay IDE.

http://www.liferay.com/community/forums/-/message_boards/message/6989731

I've run this past the Orbeon forms community too and opinion has been expressed that this may relate to the Liferay classloader having issues loading inner classes properly during hot deploy. This seems sensible considering the filter class itself appears to have been loaded fine.

Any thoughts/insight would be greatly appreciated

-Stian

Hi Stian.

We encountered the same problem on LP CE 6.0.6 and i spent the last 2-3 days debugging into it.
Following situation:
When the InvokerPortletImpl first initializes the PortletFilters, it looks in the corresponding PortletContextBag if the required filter proxy is already created. They are already created in almost any case.
When you are hot redeploying a portlet, the PortletHotDeployListener first calls the initPortlet method and second the initPortletApp mehod. The new PortletContextBag with the new filter proxies is created within initPortletApp method, but the root instance of the InvokerPortlet gets created on call of initPortlet method and when it wants to create its portlet filters, it finds the old PortletContextBag from the previously deployed portlet with the old filter proxies that contain a reference to a ClassLoader that has become invalid.

There may be multiple solutions to this, i think the best solution is the following because it leads to the exact same behaviour as if you don't perform a hot redeploy but just a hot deploy (portlet wasn't previously deployed) which works fine for us:
In PortletHotDeployListener.doInvokeUndeploy call PortletContextBagPool.remove()
I suggest inserting it after all portlets are destroyed which is after line 414:

while (itr.hasNext()) {
Portlet portlet = itr.next();

destroyPortlet(portlet, portletIds);
}
// new code
PortletContextBagPool.remove(servletContextName);
// end new code

Maybe this should be done anyways and it was just forgotten or it got lost on some refactoring.


Another solution could be:
In PortletBagFactory.java remove the lines 289 to 294
try {
PortletInstanceFactoryUtil.create(portlet, _servletContext);
}
catch (Exception e) {
_log.error(e, e);
}

This call creates the root instance of the InvokerPortlet. The root instance will be created later when the HotDeployListener calls initPortletApp if it isn't created yet, so this shouldn't cause much problems.

I hope I could help you with this and that it wasn't too late or maybe I can help anyone else encountering this issue.

It would also be great if the liferay team could look into this and develop a real solution if my assumption of the missing "PortletContextBagPool.remove(servletContextName);" is wrong.

Regards, Christoph

Hi Everyone !!


the current format of the WEBFORM is like every field is coming one by one(in a single column), i mean vertically aligned....like first name then down to that last name then down to that and so on...........if i want first name and last name in one row, then in other row role and company and so on, where to make the configurations..........


thnx !!

Christoph,
Thank you, good job!
This seams to work, I could deploy portlets on running server.

Could you please file a Jira for this?

Thank you
Hubert

I ran into the same problem a while back, and filed http://issues.liferay.com/browse/LPS-17037 for it

My patch was applied to the trunk a while back

Hi every1 !!

i finally able to create a search box on top of my liferay page.........now my manager has asked me to move that search box over the top banner such that the banner image should visible as a background image to that search box........plz help me guyz....how to acheive this requirement......???????

Really glad that this issue has been resolved! Now I will be able to hot deploy to a production environment without any downtime (for Liferay server restart). Thanks so much for sharing the solution on here and great that there is a fix ready to go for the next post 6.0.6 GA! Another reason to eagerly await the release of 6.1

Jelmer why didn't you tell any1 earlier? It surely would have saved some people a lot if time.

Thanks....
Nice explanation...