-
Bug
-
Resolution: Unresolved
-
Critical
-
None
-
Win2003/Server 32bit
Java SDK 1.6.0_17
Tomcat 6.0.20
Hudson 1.339
experiencing the following error as reported in the Hudson Log:
07-Jan-2010 12:53:28 hudson.util.CopyOnWriteList$ConverterImpl unmarshal
WARNING: Failed to resolve class
com.thoughtworks.xstream.mapper.CannotResolveClassException: org.jvnet.hudson.plugins.DownstreamBuildViewPublisher : org.jvnet.hudson.plugins.DownstreamBuildViewPublisher
at com.thoughtworks.xstream.mapper.DefaultMapper.realClass(DefaultMapper.java:68)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.XStream11XmlFriendlyMapper.realClass(XStream11XmlFriendlyMapper.java:34)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.DynamicProxyMapper.realClass(DynamicProxyMapper.java:71)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.PackageAliasingMapper.realClass(PackageAliasingMapper.java:88)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.ClassAliasingMapper.realClass(ClassAliasingMapper.java:86)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.ArrayMapper.realClass(ArrayMapper.java:96)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
at com.thoughtworks.xstream.mapper.CachingMapper.realClass(CachingMapper.java:56)
at com.thoughtworks.xstream.core.util.HierarchicalStreams.readClassType(HierarchicalStreams.java:29)
at com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.readItem(AbstractCollectionConverter.java:70)
at hudson.util.CopyOnWriteList$ConverterImpl.unmarshal(CopyOnWriteList.java:184)
at hudson.util.DescribableList$ConverterImpl.unmarshal(DescribableList.java:224)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82)
at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:60)
at hudson.util.RobustReflectionConverter.unmarshallField(RobustReflectionConverter.java:261)
at hudson.util.RobustReflectionConverter.doUnmarshal(RobustReflectionConverter.java:221)
at hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:172)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82)
at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:60)
at com.thoughtworks.xstream.core.TreeUnmarshaller.start(TreeUnmarshaller.java:137)
at com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.unmarshal(AbstractTreeMarshallingStrategy.java:33)
at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:923)
at hudson.util.XStream2.unmarshal(XStream2.java:70)
at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:909)
at com.thoughtworks.xstream.XStream.fromXML(XStream.java:853)
at hudson.XmlFile.read(XmlFile.java:126)
at hudson.model.Items.load(Items.java:106)
at hudson.model.Hudson$12.run(Hudson.java:2108)
at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146)
at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259)
at hudson.model.Hudson$3.runTask(Hudson.java:648)
at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187)
at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
in the catalina log file the plugin also generates huge quantities of entries like this:
07-Jan-2010 12:57:29 org.jvnet.hudson.plugins.DownStreamProjectActionFactory createFor
INFO: ControllerTest_Stable » Q1,TermsAndConditions,dotnet2 #294 already has [org.jvnet.hudson.plugins.DownstreamBuildViewAction@74e5ba]
07-Jan-2010 12:57:29 org.jvnet.hudson.plugins.DownStreamProjectActionFactory createFor
INFO: ControllerTest_Stable » Q1,TermsAndConditions,dotnet2 #294:[hudson.model.CauseAction@961cb9, hudson.scm.SubversionTagAction@137ddfd, hudson.tasks.junit.TestResultAction@cf3ee8, hudson.plugins.disk_usage.BuildDiskUsageAction@2aff18, org.jvnet.hudson.plugins.DownstreamBuildViewAction@74e5ba]
would it be possible to resolve the experienced issues?
many thanks
- is related to
-
-
- Resolved
-
-
JENKINS-12236 Dont print warnings for disabled plugins when starting
-
- Resolved
-
[JENKINS-5207] DownstreamBuildViewPublisher fails to resolve class and also generates huge quantities of log entries in catalina log file
Andrea Barbieri
created issue -
mdonohue
made changes -
| Assignee | New: shinodkm [ shinodkm ] |
shinodkm
added a comment - The issues are resolved in version 1.4
The publisher is removed and a transient action is added so that no external configuration is required for the down stream build view.
If a build which has the old entries in the build.xml, try to use the new plugin version it will throw a class not found exception because the publisher is removed from the latest version. you can ignore it.
shinodkm
added a comment - The issues are resolved in version 1.4
The publisher is removed and a transient action is added so that no external configuration is required for the down stream build view.
If a build which has the old entries in the build.xml, try to use the new plugin version it will throw a class not found exception because the publisher is removed from the latest version. you can ignore it. shinodkm
made changes -
| Resolution | New: Fixed [ 1 ] | |
| Status | Original: Open [ 1 ] | New: Closed [ 6 ] |
Andrea Barbieri
added a comment - From the wording of the previous comment I don't think the issue can be closed because I cannot, as mentioned, ignore the fact that when projects with old builds and 'old entries' will still generate a huge quantity of log messages (in my case it was 110MB and counting and after 10 minutes Hudson service was not started yet!).
most likely the plugin itself needs to take remedial actions removing the 'bad' old entries in any existing builds build.xml files. It could well be a penalty hit the very first time the action needs taken but subsequently all the builds will be clean and successive starts/restarts will not be affected any more.
Andrea Barbieri
added a comment - From the wording of the previous comment I don't think the issue can be closed because I cannot, as mentioned, ignore the fact that when projects with old builds and 'old entries' will still generate a huge quantity of log messages (in my case it was 110MB and counting and after 10 minutes Hudson service was not started yet!).
most likely the plugin itself needs to take remedial actions removing the 'bad' old entries in any existing builds build.xml files. It could well be a penalty hit the very first time the action needs taken but subsequently all the builds will be clean and successive starts/restarts will not be affected any more. Andrea Barbieri
added a comment - Also, deleting all of the affected builds is definitely not an acceptable answer.
Andrea Barbieri
added a comment - Also, deleting all of the affected builds is definitely not an acceptable answer. 
ellisonch
added a comment - I apologize for opening up an old issue, but I seem to be getting the same problem.
I have Hudson 1.381 and downstream buildview plugin 1.4. I only just created hudson about a month ago, so my builds are quite new.
On startup, I am getting about a megabyte worth of entries in my log like this:
Nov 3, 2010 11:48:18 AM org.jvnet.hudson.plugins.DownStreamProjectActionFactory createFor
INFO: org.jvnet.hudson.plugins.DownStreamProjectActionFactory@5ecfe500 adds DownStreamProjectAction for hudson.model.FreeStyleProject@22c393a1[C-$
Nov 3, 2010 11:48:18 AM org.jvnet.hudson.plugins.DownStreamProjectActionFactory createFor
INFO: C-Semantics-Third-Party-Tests #20 already has [org.jvnet.hudson.plugins.DownstreamBuildViewAction@6153e0c0]
Nov 3, 2010 11:48:18 AM org.jvnet.hudson.plugins.DownStreamProjectActionFactory createFor
INFO: C-Semantics-Third-Party-Tests #20:[hudson.model.ParametersAction@49c88f2b, hudson.model.CauseAction@e2f75e5, hudson.scm.SubversionTagAction$
Nov 3, 2010 11:48:18 AM org.jvnet.hudson.plugins.DownStreamProjectActionFactory createFor
Does this seem to be the same issue? What other information can I provide?
ellisonch
added a comment - I apologize for opening up an old issue, but I seem to be getting the same problem.
I have Hudson 1.381 and downstream buildview plugin 1.4. I only just created hudson about a month ago, so my builds are quite new.
On startup, I am getting about a megabyte worth of entries in my log like this:
Nov 3, 2010 11:48:18 AM org.jvnet.hudson.plugins.DownStreamProjectActionFactory createFor
INFO: org.jvnet.hudson.plugins.DownStreamProjectActionFactory@5ecfe500 adds DownStreamProjectAction for hudson.model.FreeStyleProject@22c393a1[C-$
Nov 3, 2010 11:48:18 AM org.jvnet.hudson.plugins.DownStreamProjectActionFactory createFor
INFO: C-Semantics-Third-Party-Tests #20 already has [org.jvnet.hudson.plugins.DownstreamBuildViewAction@6153e0c0]
Nov 3, 2010 11:48:18 AM org.jvnet.hudson.plugins.DownStreamProjectActionFactory createFor
INFO: C-Semantics-Third-Party-Tests #20:[hudson.model.ParametersAction@49c88f2b, hudson.model.CauseAction@e2f75e5, hudson.scm.SubversionTagAction$
Nov 3, 2010 11:48:18 AM org.jvnet.hudson.plugins.DownStreamProjectActionFactory createFor
Does this seem to be the same issue? What other information can I provide? ellisonch
made changes -
| Resolution | Original: Fixed [ 1 ] | |
| Status | Original: Closed [ 6 ] | New: Reopened [ 4 ] |
I am running into the exact same issue. I think the answer may be to clean the all the build.xml files in the job archive by removing the <org.jvnet.hudson.plugins.DownstreamBuildViewAction> node. Does this make sense to anyone else? I am going to try to craft a script to do this, and I will post back to let you all know what happens.
I think the "real fix" would be to ignore any calls to plugins which are disabled/removed/not functioning; catch the exceptions and deal with them gracefully. Perhaps catch the exception and then provide a way for an admin user to "clean" any references that are made to the main plugin class in all configuration files (including old build.xml files in the job archive). This same option could also be presented to the user if the plugin is removed or disabled through the plugin management user interface.
and if one tries to disable the plugin tons of entries like this:
failed to locate class: com.thoughtworks.xstream.mapper.CannotResolveClassException: org.jvnet.hudson.plugins.DownstreamBuildViewAction : org.jvnet.hudson.plugins.DownstreamBuildViewAction
are logged in tomcat std_out log file
please have a look at the reported issue.