Closed timja closed 10 years ago
Not a Jenkins core defect. Everything seems to work as intended.
Suggestions:
It's not just this plugin. It's all of them. And it seems to be related to when Jenkins is sent an ALRM signal. After that, you see these exceptions. Here is another example:
org.kohsuke.stapler.export.NotExportableException: class org.jenkinsci.plugins.schedulebuild.ScheduleBuildAction doesn't have @ExportedBean so cannot write hudson.model.Actionable.actions
And this one
org.kohsuke.stapler.export.NotExportableException: class hudson.plugins.depgraph_view.DependencyGraphProjectActionFactory$DependencyGraphProjectAction doesn't have @ExportedBean so cannot write hudson.model.Actionable.actions
and this one
org.kohsuke.stapler.export.NotExportableException: class com.sonyericsson.jenkins.plugins.bfa.graphs.ProjectGraphAction doesn't have @ExportedBean so cannot write hudson.model.Actionable.actions
and so on...
The ALRM signal is sent during log rotation to get Jenkins to reopen the log file. After this, Jenkins gets into a mess and just churns out these log entries. As I say, seemed to be fine prior to 1.577.
As per my previous comments. It's not related to any single plugin.
Actually, it is unrelated to the ALRM signal. It's just all the time. I quieted down Jenkins and restarted the process and straight away the log file is 9.6 MB within a few seconds. I have tried setting the log level to 1, but I am still seeing INFO messages too. How can I disable logging until this is fixed?
Just as an idea of how quickly the log is growing:
[root@d-buildmaster-01 ~]# ls -lh /var/log/jenkins/jenkins.log
rw-rr- 1 kcc users 9.6M Aug 27 12:10 /var/log/jenkins/jenkins.log
[root@d-buildmaster-01 ~]# ls -lh /var/log/jenkins/jenkins.log
rw-rr- 1 kcc users 44M Aug 27 12:11 /var/log/jenkins/jenkins.log
The warnings are created because Jenkins cannot serialize some objects in its hierarchy for the API. Find out who calls the API every five seconds and stop that. By default, nothing does that.
URLs are different as almost every URL has an API endpoint, but they always end in /api/xml or /api/json, possibly with query string.
Examples:
I am calling the API. I have automatic job maintenance that uses the CLI to remove and add jobs associated with branches. It's been working fine until now.
We also have a radiator written in JavaScript. It displays the photographs of culprits obtained from LDAP. We hook into the job API's to obtain the breakers and build states. Again, something we have done for months with no problems.
I have modified the init.d script and sysconfig to support a JENKINS_LOGFILE and JENKINS_WEBROOT option. This has allowed me to redirect the logging to /dev/null for now.
The API calls resulting in these exceptions do not actually produce JSON/XML output, so that's not a real solution for you.
Since you're writing that it's been "working fine until now" I have to ask: what changed? Jenkins update? If so, from which version to 1.577? Plugins installed? Updated? If so, which?
"It's not just this plugin. It's all of them" seems like an exaggeration – could you provide the list of plugins (or classes/fields from the first line of the exception message) affected here?
A possible workaround restoring functionality would be in looking to filter API output, e.g. the XML API has an argument "tree" that allows you to only retrieve a subset of fields.
I'll try and satisfy all your requests. Starting with the first question "what changed?". I upgraded to 1.576 to see if another bug I raised (File descriptor leaks) had been resolved. The original issue had been resolved and now I don't have to have a Jenkins job running to monitor the number of open file descriptors, forcing a graceful restart before it hits the limit and crashes. However, upgrading introduced the issue with the "//" double slash preceding icon paths for plugin icons. This resulted in lengthy loading times for every page, while the browser tried to resolve "//plugin" as a host name. I eagerly awaited 1.577 and upgraded as soon as it was available. It resolved the icon path issue, but has now introduced this problem. I don't normally just decide to upgrade at random. I upgrade if I require something from some issue I have logged. As part of the upgrade, I upgraded all plugins installed to their latest versions:
/pluginManager/api/xml?depth=2&xpath=//plugin/*[name()%20=%20%27shortName%27%20or%20name()%20=%20%27version%27]&wrapper=root
Which version did you have before upgrading to 1.576? Are you sure the exceptions did not occur on 1.576 but only started once you updated to 1.577?
Contents of the plugins directory for plugins I updated yesterday.
rw-rr- 1 root root 41838 Aug 21 12:32 claim.jpi.bak
rw-rr- 1 kcc users 949638 Aug 26 10:42 windows-slaves.jpi
rw-rr- 1 kcc users 321735 Aug 26 10:42 junit.bak
rw-rr- 1 kcc users 53839 Aug 26 10:42 external-monitor-job.jpi
rw-rr- 1 kcc users 90421 Aug 26 10:42 ant.jpi
drwxr-xr-x 4 kcc users 4096 Aug 26 10:42 ant
drwxr-xr-x 4 kcc users 4096 Aug 26 10:42 external-monitor-job
drwxr-xr-x 4 kcc users 4096 Aug 26 10:42 windows-slaves
rw-rr- 1 kcc users 4760442 Aug 26 10:45 subversion.jpi
rw-rr- 1 kcc users0 Aug 26 10:45 subversion.jpi.pinned
rw-rr- 1 kcc users 325117 Aug 26 10:45 junit.jpi
rw-rr- 1 kcc users0 Aug 26 10:45 junit.jpi.pinned
rw-rr- 1 kcc users 346092 Aug 26 10:46 delivery-pipeline-plugin.jpi
drwxr-xr-x 5 kcc users 4096 Aug 26 10:46 delivery-pipeline-plugin
rw-rr- 1 kcc users 5317336 Aug 26 10:47 build-pipeline-plugin.jpi
drwxr-xr-x 7 kcc users 4096 Aug 26 10:47 build-pipeline-plugin
drwxr-xr-x 4 kcc users 4096 Aug 26 14:16 junit
drwxr-xr-x 4 kcc users 4096 Aug 26 14:17 subversion
I can't be sure the exceptions weren't occurring in 1.576, but we were on 1.576 for at least a week and the disk didn't fill up and the log wasn't rotated. After upgrading to 1.576, the disk filled up within a couple of hours and I had to reconfigure logrotate to run every 5 minutes instead of daily. What I can do, is downgrade and see if I get the same errors. But as you say, the errors might have been occurring without being logged. Has anything changed related to logging in 1.577?
Okay, I think I've narrowed it down to this API call:
/job/scm-poll-drive-HEAD//300/api/xml?depth=4&wrapper=fingerprints&xpath=//fingerprint[../result/text()=%27SUCCESS%27%20and%20starts-with(fileName/text(),%27scm-poll-drive-HEAD-%27)%20and%20contains(fileName/text(),%27.tar.bz2%27)]/usage/name[starts-with(text(),%27drive-%27)]
Which translates to:
/job/scm-poll-drive-HEAD//300/api/xml?depth=4&wrapper=fingerprints&xpath=//fingerprint[../result/text()='SUCCESS' and starts-with(fileName/text(),'scm-poll-drive-HEAD-') and contains(fileName/text(),'.tar.bz2')]/usage/name[starts-with(text(),'drive-')]
What I am trying to do here is get the name of fingerprints that end with '.tar.bz2', that have been used by downstream builds with names beginning 'drive-'. This is to do with our pipeline and how we create change lists. The plugins that provide change lists, don't work in the way we need them to, so we generate our own.
The thing that causes all the exceptions appears to be the depth=4 parameter.
Do we really care that much about plugins that have no @ExportedBean to dump the entire stack trace at INFO level? Can't we treat exceptions for @ExportedBean as DEBUG level errors?
When I access the full XML api for that job, I get some XML output, but also get this error coming from the browser:
This page contains the following errors:
error on line 18 at column 5: internal error
Below is a rendering of the page up to the first error.
This is new. I never had this problem previously.
However, accessed with the full URL, it works just fine and returns the desired XML.
I disabled this and I am still seeing hundreds of these API exceptions when I start Jenkins.
I think the API exceptions are being caused by the requests generated by the radiators.
if (-1 !== data.color.search(/^(?:blue|notbuilt)/)) {
if (buildChanged) {
$.ajax("/job/" + job.name + "/lastCompletedBuild/api/json", {
dataType: "json",
success: function(data, stat, xhr)
{ base.timestamp(data.timestamp) .buildnum(data.number); }
});
}
culprits_set = {};
culprits_div.stopCarousel().empty();
} else if (buildChanged) {
$.ajax("/job/" + job.name + "/lastCompletedBuild/api/json", {
dataType: "json",
success: function(data, stat, xhr)
{ base.timestamp(data.timestamp) .buildnum(data.number) .culprits(data.culprits); }
});
$.ajax("/job/" + job.name + "/lastCompletedBuild/artifact/output/breakers.json", {
dataType: "json",
success: function(data, stat, xhr)
{ base.culprits(data); }
});
}
Not an unreasonable API request and not one that should generate any exceptions.
FYI, i performed an upgrade from 1.568->1.577 this morning (PDT) and noticed the stack trace spam from all plugins immediately. this was NOT happening in 1.568.
i'm probably going to need to redir jenkins logs to /dev/null as well...
I'm trying to determine what change could have caused this.
https://github.com/stapler/stapler/commit/ed2cb8b04c1514377f3a8bfbd567f050a67c6e1c
Also making sure to log a warning when skipping a NEE because we are writing out a collection.
Setting component to originally reported plugin; other plugins may need other bugs.
Even without any code change, there is a simple fix on the user side, which would be desirable for performance and robustness reasons anyway: stop using the deprecated depth parameter, and switch to tree instead.
Documented additional logging in changelog, with recommendation to use tree parameter.
Jesse pushed a change that limits logging to one line, so the next stapler release should be far less annoying.
https://github.com/stapler/stapler/commit/e2b39098ca1f61a58970b8a41a3ae79053cf30e3
The only workaround I found is to change default log level to SEVERE (/log/levels)
To be clear, this appears to be happening with many, many plugins, and the error message does not suggest a remediation:
root@jenkins:/var/lib/jenkins# grep ExportedBean /var/log/jenkins/jenkins.log | sort| uniq org.kohsuke.stapler.export.NotExportableException: class com.castlemon.jenkins.performance.CucumberProjectAction doesn't have @ExportedBean so cannot write hudson.model.Actionable.actions org.kohsuke.stapler.export.NotExportableException: class com.cloudbees.jenkins.GitHubPushTrigger$GitHubWebHookPollingAction doesn't have @ExportedBean so cannot write hudson.model.Actionable.actions org.kohsuke.stapler.export.NotExportableException: class com.coravy.hudson.plugins.github.GithubLinkAction doesn't have @ExportedBean so cannot write hudson.model.Actionable.actions org.kohsuke.stapler.export.NotExportableException: class htmlpublisher.HtmlPublisherTarget$HTMLAction doesn't have @ExportedBean so cannot write hudson.model.Actionable.actions org.kohsuke.stapler.export.NotExportableException: class hudson.plugins.rubyMetrics.flog.FlogBuildAction doesn't have @ExportedBean so cannot write hudson.model.Actionable.actions org.kohsuke.stapler.export.NotExportableException: class hudson.plugins.rubyMetrics.rcov.RcovBuildAction doesn't have @ExportedBean so cannot write hudson.model.Actionable.actions org.kohsuke.stapler.export.NotExportableException: class hudson.plugins.warnings.AggregatedWarningsProjectAction doesn't have @ExportedBean so cannot write hudson.model.Actionable.actions org.kohsuke.stapler.export.NotExportableException: class hudson.plugins.warnings.AggregatedWarningsResultAction doesn't have @ExportedBean so cannot write hudson.model.Actionable.actions org.kohsuke.stapler.export.NotExportableException: class hudson.plugins.warnings.WarningsProjectAction doesn't have @ExportedBean so cannot write hudson.model.Actionable.actions org.kohsuke.stapler.export.NotExportableException: class hudson.plugins.warnings.WarningsResultAction doesn't have @ExportedBean so cannot write hudson.model.Actionable.actions org.kohsuke.stapler.export.NotExportableException: class hudson.scm.SCMRevisionState$None doesn't have @ExportedBean so cannot write hudson.model.Actionable.actions org.kohsuke.stapler.export.NotExportableException: class hudson.tasks.MailMessageIdAction doesn't have @ExportedBean so cannot write hudson.model.Actionable.actions org.kohsuke.stapler.export.NotExportableException: class hudson.tasks.test.TestResultProjectAction doesn't have @ExportedBean so cannot write hudson.model.Actionable.actions org.kohsuke.stapler.export.NotExportableException: class hudson.triggers.SCMTrigger$BuildAction doesn't have @ExportedBean so cannot write hudson.model.Actionable.actions org.kohsuke.stapler.export.NotExportableException: class hudson.triggers.SCMTrigger$SCMAction doesn't have @ExportedBean so cannot write hudson.model.Actionable.actions org.kohsuke.stapler.export.NotExportableException: class net.masterthought.jenkins.CucumberReportBuildAction doesn't have @ExportedBean so cannot write hudson.model.Actionable.actions org.kohsuke.stapler.export.NotExportableException: class net.masterthought.jenkins.CucumberReportProjectAction doesn't have @ExportedBean so cannot write hudson.model.Actionable.actions org.kohsuke.stapler.export.NotExportableException: class org.jvnet.jenkins.plugins.nodelabelparameter.LabelBadgeAction doesn't have @ExportedBean so cannot write hudson.model.Actionable.actions
The issue here is that the JSON/XML description of a build (etc.) exports a list of things (here, actions), yet some of these have no declared format for export. Historically they were skipped without even the possibility of finding that information (without a debugger). I added logging to track down these problems. However it seems that there are a lot of build actions which have never been exported and perhaps no one needed them to be either, so tuning this down makes sense.
https://github.com/stapler/stapler/commit/143049bdbb6683d33d70b84ec7339a47ab4ac2a0 should be in Stapler 1.229, which core will pick up at some point (up to @kohsuke when).
The issue here is that the JSON/XML description of a build (etc.) exports a list of things (here, actions), yet some of these have no declared format for export.
Thanks Jesse – that explains a lot. What would be the way to fix these reported problems? Changing the code of each plugin itself?
A related question: what is running every few seconds that would be trying to export? (We run a very vanilla Jenkins installation and were surprised to see this.)
Changing the code of each plugin itself?
Yes.
what is running every few seconds that would be trying to export? (We run a very vanilla Jenkins installation and were surprised to see this.)
The logged stack trace should have a call to a doApi method somewhere, which corresponds to the .../api/(xml|json) URLs. Someone's using the Jenkins REST API.
The logged stack trace should have a call to a doApi method somewhere, which corresponds to the .../api/(xml|json) URLs. Someone's using the Jenkins REST API.
It was as you said. We've figured out this is the Wall Display plugin, which is JavaScript based and calls the Jenkins REST API.
I had also this issue on Windows 7 with Jenkins 1.580.
resolved by deactivating EzWall plugin.
In fact, deactivating it seems not necessary. Just stopping displaying this wall ...
I can't believe you closed the issue, that is such a cop out.
We are not using any wall plugin, we just happen to be accessing the REST API from a JavaScript web service, completely separate from Jenkins. So what you are saying is that as an unauthenticated user, I can hammer jenkins REST API's with requests that will fill it's logs and take the server down. Sounds like a DoS attack waiting to happen to me.
Oh, and btw. I updated all the API calls to use the 'tree' parameter and made sure depth isn't used. This made no difference whatsoever.
I'd be inclined to say, the Jenkins CLI is what is causing this, rather than the rest API. I just disabled all the dashboards that point to Jenkins and I was still seeing the errors. There was a build running that was updating job configuration using the CLI. Calls to this, seem to be generating these errors.
I can't believe you closed the issue, that is such a cop out.
Jesse already wrote that logging level will be reduced in a future release, and that level (FINE) is hidden by default. No more messages logged.
... Sounds like a DoS attack waiting to happen to me.
Don't allow anonymous read access to Jenkins (and remove any malicious users who have read access).
Jenkins CLI is what is causing this, rather than the rest API.
Provide a full stack trace that does not contain Api.doJson or Api.doXml (or both that and a call to CLI.execute), and confirm in the access logs that nobody calls .../api/json, .../api/xml, or .../api/python, and I'll look into it.
Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
changelog.html
core/pom.xml
http://jenkins-ci.org/commit/jenkins/c57f9ed577b9635f01aa5affabf1f770b689a115
Log:
[JENKINS-24458 JENKINS-11543] integrated the newer version of stapler with reduced log level
Do you know what release the logging change is scheduled for?
1.582
Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
core/pom.xml
http://jenkins-ci.org/commit/jenkins/8ae29e50c7356a8e2ec9be1126bad957dab0117a
Log:
[JENKINS-24458 JENKINS-11543] integrated the newer version of stapler with reduced log level
(cherry picked from commit c57f9ed577b9635f01aa5affabf1f770b689a115)
Conflicts:
changelog.html
Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
core/pom.xml
http://jenkins-ci.org/commit/jenkins/12a4b444a96d30a57e78c2427d07a46172aeb8e8
Log:
[JENKINS-24458 JENKINS-11543] integrated the newer version of stapler with reduced log level
(cherry picked from commit c57f9ed577b9635f01aa5affabf1f770b689a115)
Conflicts:
changelog.html
[Originally duplicated by: JENKINS-24617]
[Originally related to: JENKINS-24635]
[Originally related to: JENKINS-24476]
[Originally related to: JENKINS-24477]
[Originally related to: JENKINS-24698]
[Originally related to: JENKINS-23409]
[Originally related to: JENKINS-24494]
These exceptions are being written to the log file every 5 seconds and thus result in a very large log file. The only work around is to run logrotate every hour, but I still get extremely large log files.
Aug 27, 2014 8:49:10 AM org.kohsuke.stapler.export.Property writeValue(Model.java:73)
WARNING: null
org.kohsuke.stapler.export.NotExportableException: class org.jenkinsci.plugins.readonly.JobConfiguration doesn't have @ExportedBean so cannot write hudson.model.Actionable.actions
at org.kohsuke.stapler.export.Model.
at org.kohsuke.stapler.export.ModelBuilder.get(ModelBuilder.java:51)
at org.kohsuke.stapler.export.Property.writeValue(Property.java:231)
at org.kohsuke.stapler.export.Property.writeValue(Property.java:187)
at org.kohsuke.stapler.export.Property.writeValue(Property.java:139)
at org.kohsuke.stapler.export.Property.writeTo(Property.java:116)
at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:190)
at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:185)
at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:185)
at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:185)
at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:185)
at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:185)
at org.kohsuke.stapler.export.Model.writeTo(Model.java:157)
at org.kohsuke.stapler.ResponseImpl.serveExposedBean(ResponseImpl.java:267)
at hudson.model.Api.doXml(Api.java:98)
at sun.reflect.GeneratedMethodAccessor193.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:298)
at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:161)
at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:96)
at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:120)
at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858)
at org.kohsuke.stapler.MetaClass$4.doDispatch(MetaClass.java:210)
at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858)
at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:248)
at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:631)
at org.kohsuke.stapler.Stapler.service(Stapler.java:225)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:686)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1494)
at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:96)
at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:58)
at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:99)
at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:88)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482)
at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:48)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at jenkins.security.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:117)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at jenkins.security.BasicHeaderProcessor.success(BasicHeaderProcessor.java:95)
at jenkins.security.BasicHeaderProcessor.doFilter(BasicHeaderProcessor.java:75)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:67)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482)
at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:46)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482)
at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1474)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:533)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:370)
at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:949)
at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1011)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:668)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
Originally reported by iwonbigbro, imported from: doesn't have @ExportedBean so cannot write hudson.model.Actionable.actions