Closed GoogleCodeExporter closed 9 years ago
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
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
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
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
@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
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
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
@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
[deleted comment]
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
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
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
@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
Original issue reported on code.google.com by
msymo...@gmail.com
on 2 Nov 2013 at 8:24