Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-5207

DownstreamBuildViewPublisher fails to resolve class and also generates huge quantities of log entries in catalina log file

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Critical Critical
    • downstream-buildview-plugin
    • 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

          [JENKINS-5207] DownstreamBuildViewPublisher fails to resolve class and also generates huge quantities of log entries in catalina log file

          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.

          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?

          Doug Borg added a comment -

          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.

          Doug Borg added a comment - 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.

          Doug Borg added a comment - - edited

          I think this is actually an issue which has the potential to affect any plugin where:

          1. Plugin is installed.
          2. Jobs are run with plugin enabled; Plugin adds information to config.xml or build.xml
          3. Plugin is determined to be no longer needed or is causing other problems in Hudson;
          4. Plugin is removed or disabled; plugin does not remove references to itself upon removal or being disabled.

          I could be off-base on this, so let me know what you all think.

          Doug Borg added a comment - - edited I think this is actually an issue which has the potential to affect any plugin where: 1. Plugin is installed. 2. Jobs are run with plugin enabled; Plugin adds information to config.xml or build.xml 3. Plugin is determined to be no longer needed or is causing other problems in Hudson; 4. Plugin is removed or disabled; plugin does not remove references to itself upon removal or being disabled. I could be off-base on this, so let me know what you all think.

          Andrea Barbieri added a comment -

          I think you have hit the right spot.

          ultimately Hudson core itself should be more tolerant with invalid (or disabled) plugin configuration elements injected in configuration files (main or project) and provide a mechanism to remove these stale elements wherever they occur.

          Andrea Barbieri added a comment - I think you have hit the right spot. ultimately Hudson core itself should be more tolerant with invalid (or disabled) plugin configuration elements injected in configuration files (main or project) and provide a mechanism to remove these stale elements wherever they occur.

          Axel Heider added a comment -

          Setting this to critial as the Plugin handling should be better with more and more plugins beeing available.

          Axel Heider added a comment - Setting this to critial as the Plugin handling should be better with more and more plugins beeing available.

          samuel nobs added a comment -

          i ran this ugly one-liner to remove all the references to the DownstreamBuildViewAction:

          find . -name build.xml -exec perl -i -p -e 'undef $/; s/\s*<org.jvnet.hudson.plugins.DownstreamBuildViewAction>.*<\/org.jvnet.hudson.plugins.DownstreamBuildViewAction>//s' "{}" \;

          samuel nobs added a comment - i ran this ugly one-liner to remove all the references to the DownstreamBuildViewAction: find . -name build.xml -exec perl -i -p -e 'undef $/; s/\s*<org.jvnet.hudson.plugins.DownstreamBuildViewAction>.*<\/org.jvnet.hudson.plugins.DownstreamBuildViewAction>//s' "{}" \;

          Erik Riemers added a comment -

          If you have strange $ signs in one of your dirs it might not work.

          find . -name build.xml | xargs -I %f% perl -i -p -e 'undef $/; s/\s*<org.jvnet.hudson.plugins.DownstreamBuildViewAction.*<\/org.jvnet.hudson.plugins.DownstreamBuildViewAction>//s' '%f%'

          Seems to work better for that. (still ugly)

          Erik Riemers added a comment - If you have strange $ signs in one of your dirs it might not work. find . -name build.xml | xargs -I %f% perl -i -p -e 'undef $/; s/\s*<org.jvnet.hudson.plugins.DownstreamBuildViewAction.*<\/org.jvnet.hudson.plugins.DownstreamBuildViewAction>//s' '%f%' Seems to work better for that. (still ugly)

            shinodkm shinodkm
            abarbieri Andrea Barbieri
            Votes:
            9 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: