Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not working with Liferay 7.2 DXP SP1 (and caches are not displayed anymore since Liferay 7.3 CE GA1) #14

Open
jatinderveer opened this issue Feb 10, 2020 · 4 comments

Comments

@jatinderveer
Copy link

Hi,
I am trying to integrate this plugin with Liferay 7.2 but we are not able to see any view.
We are working with Liferay 7.2 DXP SP1 which is equivalent to Liferay 7.2 DXP GA1 with Fix Pack 2

When we run the localhost:8080/monitoring URL. We get below log errors.

10-Feb-2020 09:58:03.061 SEVERE [http-nio-8080-exec-4] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [default] in context with path [] threw exception [Filter execution threw an exception] with root cause
java.lang.ClassNotFoundException: net.sf.ehcache.management.CacheStatistics cannot be found by liferay-javamelody-hook_7.2.10.1
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:508)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:419)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:411)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:151)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at net.bull.javamelody.internal.model.CacheInformations.(CacheInformations.java:77)
at net.bull.javamelody.internal.model.CacheInformations.buildCacheInformationsList(CacheInformations.java:175)
at net.bull.javamelody.internal.model.JavaInformations.(JavaInformations.java:203)
at net.bull.javamelody.internal.web.MonitoringController.doActionIfNeededAndReport(MonitoringController.java:158)
at net.bull.javamelody.MonitoringFilter.doMonitoring(MonitoringFilter.java:408)
at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:206)
at net.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:88)
at net.bull.javamelody.LiferayMonitoringFilter.doFilter(LiferayMonitoringFilter.java:109)
at sun.reflect.GeneratedMethodAccessor307.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.liferay.portal.kernel.bean.ClassLoaderBeanHandler.invoke(ClassLoaderBeanHandler.java:66)
at com.sun.proxy.$Proxy823.doFilter(Unknown Source)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:215)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:116)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDirectCallFilter(InvokerFilterChain.java:196)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:99)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilter.doFilter(InvokerFilter.java:104)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:200)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:490)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:408)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:834)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1415)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)

2020-02-10 09:58:03.069 WARN [http-nio-8080-exec-4][code_jsp:160] {code="500", msg="", uri=/monitoring}
javax.servlet.ServletException: Filter execution threw an exception
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:200)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:200)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:490)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:408)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:834)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1415)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NoClassDefFoundError: net/sf/ehcache/management/CacheStatistics
at net.bull.javamelody.internal.model.CacheInformations.(CacheInformations.java:77)
at net.bull.javamelody.internal.model.CacheInformations.buildCacheInformationsList(CacheInformations.java:175)
at net.bull.javamelody.internal.model.JavaInformations.(JavaInformations.java:203)
at net.bull.javamelody.internal.web.MonitoringController.doActionIfNeededAndReport(MonitoringController.java:158)
at net.bull.javamelody.MonitoringFilter.doMonitoring(MonitoringFilter.java:408)
at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:206)
at net.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:88)
at net.bull.javamelody.LiferayMonitoringFilter.doFilter(LiferayMonitoringFilter.java:109)
at sun.reflect.GeneratedMethodAccessor307.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.liferay.portal.kernel.bean.ClassLoaderBeanHandler.invoke(ClassLoaderBeanHandler.java:66)
at com.sun.proxy.$Proxy823.doFilter(Unknown Source)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:215)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:116)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDirectCallFilter(InvokerFilterChain.java:196)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:99)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilter.doFilter(InvokerFilter.java:104)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
... 17 more
Caused by: java.lang.ClassNotFoundException: net.sf.ehcache.management.CacheStatistics cannot be found by liferay-javamelody-hook_7.2.10.1
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:508)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:419)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:411)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:151)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 36 more

@evernat
Copy link
Member

evernat commented Feb 11, 2020

When using fresh install of Liferay CE portal 7.2.0 GA1 and javamelody hook 1.81.0, the localhost:8080/monitoring works well, including the list of caches with names and statistics at the bottom.

And when using fresh install of Liferay CE portal 7.3.0 GA1 and javamelody hook 1.81.0 (patched to declare 7.3.0+ compatibility), the localhost:8080/monitoring works also well, excluding the list of caches which are not displayed anymore.

It seems that the OSGI configuration of ehcache in Liferay has changed between CE 7.2.0 GA1 (Liferay CE Foundation - Liferay CE Portal Cache - API.lpkg/META-INF/MANIFEST.MF) and CE 7.3.0 GA1 (net.sf.ehcache-2.10.6.LIFERAY-PATCHED-2.jar/META-INF/MANIFEST.MF). And 7.2 DXP SP1 may be in the middle of this change too.

Have you added ehcache v2 jar files in Liferay by yourself in portlets ? Do you have a specific configuration for OSGI ? If yes, does it make a difference with a fresh install of 7.2 DXP SP1 ?

If not, I suggest to ask to Liferay about ehcache OSGI configuration in 7.3.0 GA1 and in 7.2 DXP SP1. In my view:

  • Either the javamelody hook should have access to ehcache classes, including net.sf.ehcache.management.CacheStatistics (like in CE 7.2.0 GA1).
  • Or the javamelody hook does not have access to ehcache classes at all (like in CE 7.3.0 GA1). The later is sad for us because Liferay caches will not be displayed anymore in the monitoring reports, but Liferay should not hide away only half of Ehcache API and it would make the javamelody hook work at least.

It would be better from a javamelody monitoring point of view, to restore the access to ehcache classes including net.sf.ehcache.management.CacheStatistics (like in CE 7.2.0 GA1), but I do not decide and I would accept that Liferay hides away their ehcache classes and their caches.

@H-Stylo
Copy link

H-Stylo commented May 22, 2020

Hi,

I asked directly Liferay support on this topic and this is their response:

7.2 fix pack 1 introduced changes regarding caching & clustering. As a highlighted change, LPS-97897 upgraded the JGroups library to 4.1.1. Default values for Cluster.link.channel.properties.* have changed. Please read this linked knowledge base article or JGroups documentation for more information. Please find the module version changes below as well I collected from this linked sheet (requires login to liferay.com). What I can suggest is to compare the source code of GA1 and fix pack1 using the ./patching-tool.sh diff command (this linked article), so you can find out how to adjust your custom code.

Name Group Fixpack 0.0 Fixpack 1.0
com.liferay.portal.cache.ehcache.impl com.liferay 2.0.1 2.0.3
com.liferay.portal.cache.ehcache.provider com.liferay 4.0.0 4.0.2
com.liferay.portal.cache.extender com.liferay 1.0.1 -
com.liferay.portal.cache.impl com.liferay 2.0.1 2.0.5
com.liferay.portal.cache.multiple com.liferay 3.0.5 3.0.7
com.liferay.portal.cluster.multiple com.liferay 3.0.6 3.0.10
com.liferay.portal.configuration.cluster com.liferay 5.0.2 5.0.4

I hope you may find this useful.

@H-Stylo
Copy link

H-Stylo commented May 22, 2020

And they add this too :

one of our experts in the field analyzed the plugin. It does not have an OSGI bundle, so there are no dependencies are included on deployment, which should be the main reason for the reported FrameworkEvent ERROR. Kindly note, Liferay Support is dedicated to work on issues in the portal itself and its plugins released by Liferay, these kinds of questions are beyond the range of our Support Services. I ask for your kind understanding.

CacheStatistics are properly exposed via JMX beans, you may confirm this using JConsole or JVisualm. For further information, please find this linked article

@evernat
Copy link
Member

evernat commented Jun 28, 2020

As I said above:

I suggest to ask to Liferay about ehcache OSGI configuration in 7.3.0 GA1 and in 7.2 DXP SP1. In my view:

  • Either the javamelody hook should have access to ehcache classes, including net.sf.ehcache.management.CacheStatistics (like in CE 7.2.0 GA1).
  • Or the javamelody hook does not have access to ehcache classes at all (like in CE 7.3.0 GA1). The later is sad for us because Liferay caches will not be displayed anymore in the monitoring reports, but Liferay should not hide away only half of Ehcache API and it would make the javamelody hook work at least.

There was no response for this issue in Liferay.

Anyway, given that:

  • the javamelody monitoring page works in Liferay CE 7.2.0 GA1
  • the javamelody monitoring page does not work in Liferay 7.2 DXP SP1, which is equivalent to Liferay 7.2 DXP GA1 with Fix Pack 2 (ClassNotFoundException: net.sf.ehcache.management.CacheStatistics cannot be found by liferay-javamelody-hook_7.2.10.1)
  • the javamelody monitoring page works in Liferay CE 7.3.0 GA1 (without informations on caches)

then this issue in 7.2 DXP SP1 is probably won't fix.

We may leave it open anyway, for background on why caches are not displayed anymore in the monitoring page since Liferay CE 7.3.0 GA1.
Please add a comment below if the monitoring page does not work either in later Liferay versions.

@evernat evernat changed the title Not working with Liferay 7.2 DXP SP1 Not working with Liferay 7.2 DXP SP1 (and caches are not displayed anymore since Liferay 7.3 CE GA1) Jun 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants