JavaMelody Support for Confluence v5.31.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. JavaMelody 1.47.0 working well with Confluence v5.2.3
2. Upgrade Confluence to v5.3.1
3. Start JavaMelody plugin from UPM (no errors)
4. Navigate to /monitoring & login

What is the expected output? What do you see instead?

Expect to login & see normal JavaMelody output.  Instead, get exception.  From 
logs:

2013-11-02 19:02:09,801 ERROR [http-8090-4] 
[[Standalone].[localhost].[/].[default]] log Servlet.service() for servlet 
default threw exception
java.lang.IllegalStateException: java.lang.IllegalArgumentException: argument 
type mismatch
    at net.bull.javamelody.JiraMonitoringFilter.hasConfluenceAdminPermission(JiraMonitoringFilter.java:212)
    at net.bull.javamelody.JiraMonitoringFilter.checkConfluenceAdminPermission(JiraMonitoringFilter.java:137)
    at net.bull.javamelody.JiraMonitoringFilter.hasNotPermission(JiraMonitoringFilter.java:99)
    at net.bull.javamelody.JiraMonitoringFilter.doFilter(JiraMonitoringFilter.java:89)
    at com.atlassian.plugin.servlet.filter.DelegatingPluginFilter.doFilter(DelegatingPluginFilter.java:74)
    at com.atlassian.plugin.servlet.filter.IteratingFilterChain.doFilter(IteratingFilterChain.java:42)
    at com.atlassian.plugin.servlet.filter.DelegatingPluginFilter$1.doFilter(DelegatingPluginFilter.java:66)
    at com.atlassian.confluence.extra.webdav.servlet.filter.ReverseProxyFilter.doFilter(ReverseProxyFilter.java:427)
    at com.atlassian.confluence.extra.webdav.servlet.filter.AbstractHttpFilter.doFilter(AbstractHttpFilter.java:34)
    at com.atlassian.plugin.servlet.filter.DelegatingPluginFilter.doFilter(DelegatingPluginFilter.java:74)
    at com.atlassian.plugin.servlet.filter.IteratingFilterChain.doFilter(IteratingFilterChain.java:42)
    at com.atlassian.plugin.servlet.filter.ServletFilterModuleContainerFilter.doFilter(ServletFilterModuleContainerFilter.java:77)
    at com.atlassian.plugin.servlet.filter.ServletFilterModuleContainerFilter.doFilter(ServletFilterModuleContainerFilter.java:63)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at com.atlassian.confluence.web.filter.validateparam.RequestParamValidationFilter.doFilter(RequestParamValidationFilter.java:58)
    at com.atlassian.core.filters.AbstractHttpFilter.doFilter(AbstractHttpFilter.java:31)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at com.atlassian.confluence.web.filter.TranslationModeFilter.doFilter(TranslationModeFilter.java:43)
    at com.atlassian.core.filters.AbstractHttpFilter.doFilter(AbstractHttpFilter.java:31)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at com.atlassian.confluence.plugin.servlet.filter.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:71)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at com.atlassian.confluence.web.filter.LanguageExtractionFilter.doFilter(LanguageExtractionFilter.java:53)
    at com.atlassian.core.filters.AbstractHttpFilter.doFilter(AbstractHttpFilter.java:31)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at com.atlassian.confluence.util.RequestCacheThreadLocalFilter.doFilter(RequestCacheThreadLocalFilter.java:25)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at com.atlassian.confluence.web.filter.DebugFilter.doFilter(DebugFilter.java:50)
    at com.atlassian.core.filters.AbstractHttpFilter.doFilter(AbstractHttpFilter.java:31)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at com.atlassian.core.filters.HeaderSanitisingFilter.doFilter(HeaderSanitisingFilter.java:44)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at com.atlassian.confluence.servlet.FourOhFourErrorLoggingFilter.doFilter(FourOhFourErrorLoggingFilter.java:65)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602)
    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
    at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.IllegalArgumentException: argument type mismatch
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at net.bull.javamelody.JiraMonitoringFilter.hasConfluenceAdminPermission(JiraMonitoringFilter.java:207)
    ... 52 more

What version of the product are you using? On what application server, JDK, 
operating system?

JavaMelody v1.47.0
Confluence v5.3.1
Tomcat/6.0.35
Linux 2.6.18-194.26.1.el5
Java 1.7.0_15 JRE

Please provide any additional information below.

Confluence was running Java 1.7.0_40 JDK prior to upgrade.  Confluence upgrade 
process switched Confluence to using internal JRE.  I do not think that this is 
the cause of the exception as the error seems very similar to that from issue 
#314 when JavaMelody would not run with JIRA v6.0.

Original issue reported on code.google.com by msymo...@gmail.com on 2 Nov 2013 at 8:24

[GoogleCodeExporter]

You are probably right.
The impl class was probably changed from com.atlassian.user.User to something 
like com.atlassian.confluence.user.ConfluenceUserImpl.

I need to test that.

Original comment by evernat@free.fr on 2 Nov 2013 at 11:59

[GoogleCodeExporter]

It's fixed in trunk (revision 3559).

In fact, this was caused by a change of the "user" in the session to 
"com.atlassian.confluence.security.seraph.ConfluenceUserPrincipal" and by a 
change of API in UserAccessor (and other classes). I think that api and impl 
were made just "to avoid bugs caused by the use of stale ConfluenceUser" (sic) 
and so may change again as usual.

I have made a new build and it is available at:
https://javamelody.googlecode.com/files/jira-javamelody-20131105.jar

Are you able to confirm the fix?

Original comment by evernat@free.fr on 5 Nov 2013 at 12:01

[GoogleCodeExporter]

Greater, after your correction, I noticed a problem to export as an xml. 
probably a library which has changed.
Call /monitoring?format=xml&period=jour

java.lang.NoSuchMethodError: 
com.thoughtworks.xstream.XStream.getMapper()Lcom/thoughtworks/xstream/mapper/Map
per;
    at net.bull.javamelody.TransportFormat$XmlIO.createXStream(TransportFormat.java:123)
    at net.bull.javamelody.TransportFormat$XmlIO.writeToXml(TransportFormat.java:78)
    at net.bull.javamelody.TransportFormat.writeSerializableTo(TransportFormat.java:221)

Original comment by thomas.f...@gmail.com on 7 Nov 2013 at 3:21

[GoogleCodeExporter]

For a json export, I have a 

java.lang.ClassNotFoundException: 
com.thoughtworks.xstream.io.json.JsonHierarchicalStreamDriver
    at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1680)
    at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1526)
    at net.bull.javamelody.TransportFormat$XmlIO.createXStream(TransportFormat.java:114)
    at net.bull.javamelody.TransportFormat$XmlIO.writeToJson(TransportFormat.java:102)
    at net.bull.javamelody.TransportFormat.writeSerializableTo(TransportFormat.java:224)

Original comment by thomas.f...@gmail.com on 7 Nov 2013 at 3:25

[GoogleCodeExporter]

@thomas
I think that your issue with xml and json exports is like that for many 
versions of the javamelody plugin and is not new.

Before the version 1.42.1 of the plugin, a recent version of the xstream 
library was included in the plugin. And so xml and json exports were possible 
before v1.42.1.
But this was causing compatibility issues with the version of xstream included 
in JIRA / Confluence / Bamboo (issue 269 and issue 231). To make things worse, 
JIRA, Confluence and Bamboo do not include the same version of the xstream 
library.

In summary, we can't include a recent version of xstream in the plugin 
(otherwise we would have issue 269) and the version of xstream currently 
included in Confluence is too old, compared to what the plugin needs and 
compared to the versions of xstream included in JIRA and in Bamboo.

So we can't fix your issue with exports.
As a workaround and if you don't fear the issue 269, you could open the jar 
files of the plugin and of xstream [1] with a zip manager and then copy and 
paste all the files of xstream, inside the jar file of the plugin, before 
installing the plugin in Confluence.

You can download the jar file of xstream at:
[1] 
http://search.maven.org/remotecontent?filepath=com/thoughtworks/xstream/xstream/
1.4.2/xstream-1.4.2.jar

Original comment by evernat@free.fr on 8 Nov 2013 at 2:16

[GoogleCodeExporter]

Resolving as fixed. It's ready for the next release (1.48).

As said above, a build including the fix is available at:
https://javamelody.googlecode.com/files/jira-javamelody-20131105.jar

Original comment by evernat@free.fr on 9 Nov 2013 at 3:32

• Changed state: Fixed

[GoogleCodeExporter]

A couple of things...

1) I have downloaded the nightly build referenced in comment 6 & can confirm 
that it works with Confluence v5.3.1.  In fact, I see that I never disabled 
JavaMelody v1.47.0 after finding that I was unable to access the web interface 
(as per this defect).  So, today, on upgrading to the v1.48.0 snapshot, I 
suddenly find that I have all my Confluence stats going back to 2nd November 
reported in JavaMelody.  Nice!

2) Concerning the xstream issue, there are a few open issues on 
jira.atlassian.com that seem relevent.

== For Confluence: ==

Upgrade project dependencies to use XStream 1.2
https://jira.atlassian.com/browse/CONF-7278

In java 6 bandana manager fails to store an ArrayList object that was 
initialised as Arrays.asList("foo")
https://jira.atlassian.com/browse/CONF-15271

== For JIRA ==

DefaultGenericConfigManager is not able to resolve Plugin 2 classes in toXML 
method (XStream.fromXML)
https://jira.atlassian.com/browse/JRA-28597

xstream-1.3.1.jar provided with 5.2/6.0 is not compatible with JDK 1.7
https://jira.atlassian.com/browse/JRA-32823

Interesting comments from Atlassian on this last one:

* We only use one method method from xstream
* Upgrading to a later version breaks ondemand
* There is a lot of work involved in fixing this issue
* Replacing the jar with a more recent one should be fine for most customers.

...but another commenter later warns "do not use xstream-1.4.4".

As a user I can upvote one or more of these issues... but maybe it would help 
more if others (Emeric?) could add a comment or two to JAC to provide use cases 
on *why* xstream needs to be updated within various Atlassian products.  I am 
not a developer and would not word it so well =)

Original comment by msymo...@gmail.com on 12 Nov 2013 at 1:28

[GoogleCodeExporter]

@evernat
I have tried your solution to put into the plugin, xstream. The result is that 
confluence no more start.

Logs are not really relevant:
SEVERE: Error listenerStart
nov. 13, 2013 4:06:43 PM org.apache.catalina.core.StandardContext start
SEVERE: Erreur de démarrage du contexte [] suite aux erreurs précédentes
nov. 13, 2013 4:06:44 PM org.apache.catalina.loader.WebappClassLoader 
clearReferencesJdbc
SEVERE: The web application [] registered the JDBC driver 
[org.postgresql.Driver] but failed to unregister it when the web application 
was stopped. To prevent a memory leak, the JDBC Driver has been forcibly 
unregistered.
nov. 13, 2013 4:06:44 PM org.apache.catalina.loader.WebappClassLoader 
clearReferencesJdbc
SEVERE: The web application [] registered the JDBC driver 
[org.hsqldb.jdbc.JDBCDriver] but failed to unregister it when the web 
application was stopped. To prevent a memory leak, the JDBC Driver has been 
forcibly unregistered.
nov. 13, 2013 4:06:44 PM org.apache.catalina.loader.WebappClassLoader 
clearReferencesThreads
SEVERE: The web application [] appears to have started a thread named [HSQLDB 
Timer @34c15081] but has failed to stop it. This is very likely to create a 
memory leak.
nov. 13, 2013 4:06:44 PM org.apache.catalina.loader.WebappClassLoader 
clearReferencesThreads

Do you know how we can configure classloading priority into confluence plugins ?

Regards

Thomas

Original comment by thomas.f...@gmail.com on 13 Nov 2013 at 3:30

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I have tested to put the lib xstream.jar into the directory /META-INF/lib.
It is better as confluence start well, graph monitoring work also well. BUT the 
xml export return nothing and same error log as before :(

Original comment by thomas.f...@gmail.com on 13 Nov 2013 at 5:34

[GoogleCodeExporter]

I have added a note about xstream v1.1.1 in Confluence in the issue:
https://jira.atlassian.com/browse/CONF-7278

Original comment by evernat@free.fr on 16 Nov 2013 at 7:23

[GoogleCodeExporter]

What add javamelody plugin than webapp ? Apart how the deploiment is done ?
Maybe, the solution is simply to use de webapp - they will certainely be less 
problem of classloading ...

Original comment by thomas.f...@gmail.com on 21 Nov 2013 at 1:50

[GoogleCodeExporter]

@thomas
The collector webapp is not enough to monitor Confluence or JIRA. The plugin is 
needed in any case.

Original comment by evernat@free.fr on 1 Dec 2013 at 12:40