Java melody breaks web content edition

[sbihan]

Hello,

We are using java melody to monitor our Liferay server.

Currently we are using a Liferay 6.2 EE sp13, and if we install liferay javamelody hook, we have an exception during web content edition.

More precisely, when we save a content, next exception appears :

09:48:04,026 ERROR [http-bio-8080-exec-10][render_portlet_jsp:132] null java.lang.ClassCastException: [Ljava.lang.String; cannot be cast to java.lang.String at com.liferay.portlet.dynamicdatamapping.util.DDMImpl.getFields(DDMImpl.java:217) at com.liferay.portlet.dynamicdatamapping.util.DDMImpl.getFields(DDMImpl.java:200) at com.liferay.portlet.dynamicdatamapping.util.DDMImpl.getFields(DDMImpl.java:258) at com.liferay.portlet.dynamicdatamapping.util.DDMUtil.getFields(DDMUtil.java:73) at com.liferay.portlet.journal.action.ActionUtil.getContentAndImages(ActionUtil.java:270) at com.liferay.portlet.journal.action.EditArticleAction.updateArticle(EditArticleAction.java:638) at com.liferay.portlet.journal.action.EditArticleAction.processAction(EditArticleAction.java:148) ...

This issue concerns only content which have a structure. It seems, we receive in request a table of String instead of a simple String concerning "defaultLanguageId" :

String defaultLanguageId = (String)serviceContext.getAttribute( "defaultLanguageId");

Note that this issue is reproducible on all browser, on a vanilla Liferay.

Thanks,

Sébastien Bihan

[evernat]

javamelody does not touch serviceContext attributes, which are in fact servletRequest or portletRequest parameters. So I do not think that javamelody is the cause of the issue. I suggest to create an issue in the Liferay bugtracker. Are you ok with that ?

[sbihan]

Hello,

It seems this issue is reproducible and can be a blocking issue to use Java Melody on liferay portal :

https://www.liferay.com/community/forums/-/message_boards/message/69990328

Thanks,

Sébastien Bihan

[evernat]

Again, javamelody does not touch serviceContext attributes, which are in fact servletRequest or portletRequest parameters. So I do not think that javamelody is the cause of the issue. I suggest to create an issue in the Liferay bugtracker.

[sbihan]

Hello evernat,

I've tested this issue on a vanilla Liferay and a couple of liferay user has reproduced it too, so clearly, java melody is the cause of the issue. Unfortunetly, even with an enterprise edition (that's we are working with), few chances that liferay staff will adapt his code to your plugin.

Thanks,

Sébstien Bihan

[evernat]

@sbihan

1. Besides some other applications, I also manage Liferay servers (enterprise edition and community edition) where this plugin is installed. And the issue was never reproduced on them. So it does not seem so easy to reproduce. But you can give a step by step to reproduce it.
2. I do not say that Liferay staff has to adapt their code to my plugin. I say that given the stack-trace, it is probably not a bug in javamelody, and so that this plugin sometimes triggers an issue which may be a bug in Liferay. (I can assure you that it would not be the first bug in the Liferay code, as you know already if you are a developer using Liferay.)

[hufon]

We reproduce the issue with the latest Liferay 6.2 GA6 and latest SP14. It seems liferay finds duplicate LanguageId attribute in servicecontext. Many things from servicecontext comes from the session and javamelody plays with the session.

[hufon]

For information the bug is only reproduced on latest version of Liferay 6.2 it works well with SP11 and not with SP14.

The bug is not triggered without javamelody plugin

[evernat]

@hufon Can you give a step by step to reproduce the issue?

[hufon]

@evernat

1. Install / run Liferay 6.2 CE GA6 (tomcat bundle)
2. deploy javamelody hook
3. create/update a webcontent
4. crash.

[hufon]

After more investigation the problem seems to be here : https://github.com/liferay/liferay-portal/blob/6.2.x/portal-impl/src/com/liferay/portal/util/PortalImpl.java#L5256

JavaMelody wrap the request and liferay fails to create a wrapper when it see a "net.bull.*" request. No idea how to fix it without ext-ing PortalImpl...

[hufon]

maybe disabling jspcounter may help?

[evernat]

@hufon Merci, je savais bien que les lyonnais sont les meilleurs :-)

This code was in fact added by this commit in Liferay, since 6.2 GA5: https://github.com/liferay/liferay-portal/commit/43d552ea4142912254823b68ddc41baff9251869#diff-97d14104465a5b7ecb93c57d8ffbb75a for this issue: https://issues.liferay.com/browse/LPS-57997 A new issue could be created in Liferay bugtracker to ask if this change is really correct.

Otherwise disabling jspcounter could help, yes. Can you try to add a system property -Djavamelody.displayed-counters=http,sql,error,log to test that? I think that the JSP counter never displays anything in Liferay anyway.

[hufon]

@evernat OnlyLyon!!

I can confirm that adding -Djavamelody.displayed-counters=http,sql,error,log works well. is it possible to disable jsp counter directly in the hook (if it display nothing in Liferay...)?

[evernat]

Yes, it's possible to disable the jsp counter directly in the hook, with the parameter above, which also disables jsf, ejb, jpa, spring and job counters by the way. So it's fixed now and released in v1.59.2

[evernat]

This issue was identical to LPS-67793 which was fixed in Liferay: https://github.com/liferay/liferay-portal/commit/0288daee80198468b10ec3a06364c44615267c5e

[evernat]

Sorry, this issue #5 was unfortunately not fixed by dba091d in v1.59.2 (my bad). It is finally now fixed by 093752a as said in issue #6 and released in v1.62.1