java.lang.UnsupportedOperationException

There are no available Samebug tips for this exception. Do you have an idea how to solve this issue? A short tip would help users who saw this issue last week.

  • Upgraded over the weekend from JIRA 5.2.x to 6.0.4: tested with a smaller system for final confirmation and decided to go with the upgrade. Upon upgrading, the plugin system failed to initialize with multiple errors, all appearing as: {noformat} 2013-07-20 21:19:41,130 localhost-startStop-1 ERROR [atlassian.plugin.loaders.ScanningPluginLoader] Unable to deploy plugin 'com.atlassian.plugins.remotable-plugins-api-0.8.2' from 'Unit: /var/atlassian/application-data/jira6/plugins/.bundled-plugins/remotable-plugins-api-0.8.2.jar (1372752790000)'. 2013-07-20 21:19:41,130 localhost-startStop-1 ERROR [atlassian.plugin.loaders.ScanningPluginLoader] Because of the following exception: java.lang.UnsupportedOperationException at java.util.AbstractMap$SimpleImmutableEntry.setValue(AbstractMap.java:759) at org.apache.felix.framework.BundleImpl.getCurrentLocalizedHeader(BundleImpl.java:442) at org.apache.felix.framework.Felix.getBundleHeaders(Felix.java:1404) at org.apache.felix.framework.BundleImpl.getHeaders(BundleImpl.java:312) at org.apache.felix.framework.BundleImpl.getHeaders(BundleImpl.java:294) at com.atlassian.plugin.osgi.util.OsgiHeaderUtil.getPluginKey(OsgiHeaderUtil.java:361) at com.atlassian.plugin.osgi.container.felix.FelixOsgiContainerManager$BundleRegistration.install(FelixOsgiContainerManager.java:649) at com.atlassian.plugin.osgi.container.felix.FelixOsgiContainerManager.installBundle(FelixOsgiContainerManager.java:503) at com.atlassian.plugin.osgi.factory.OsgiBundleFactory.create(OsgiBundleFactory.java:128) at com.atlassian.jira.plugin.MasterPluginFactory.create(MasterPluginFactory.java:78) at com.atlassian.plugin.loaders.ScanningPluginLoader.deployPluginFromUnit(ScanningPluginLoader.java:155) at com.atlassian.plugin.loaders.ScanningPluginLoader.loadAllPlugins(ScanningPluginLoader.java:89) at com.atlassian.plugin.loaders.PermissionCheckingPluginLoader.loadAllPlugins(PermissionCheckingPluginLoader.java:24) at com.atlassian.plugin.manager.DefaultPluginManager.init(DefaultPluginManager.java:203) at com.atlassian.jira.plugin.JiraPluginManager.start(JiraPluginManager.java:62) {noformat} Lots of iterations later, including starting from scratch, various PostgreSQL versions, OS X v. Ubuntu, it turns out that the _immediate_ proximate cause on my production server is the presence of the -XX:+AggressiveOpts option in the JVM extra args in setenv.sh, as below: {noformat} JVM_MINIMUM_MEMORY="4g" JVM_MAXIMUM_MEMORY="4g" # # The following are the required arguments for JIRA. # JVM_REQUIRED_ARGS="-Djava.awt.headless=true -Datlassian.standalone=JIRA -Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true -Dmail.mime.decodeparameters=true" # Uncomment this setting if you want to import data without notifications # #DISABLE_NOTIFICATIONS=" -Datlassian.mail.senddisabled=true -Datlassian.mail.fetchdisabled=true -Datlassian.mail.popdisabled=true" #----------------------------------------------------------------------------------- # # In general don't make changes below here # #----------------------------------------------------------------------------------- #----------------------------------------------------------------------------------- # This allows us to actually debug GC related issues by correlating timestamps # with other parts of the application logs. #----------------------------------------------------------------------------------- JVM_EXTRA_ARGS="" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:NewSize=1g" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:MaxNewSize=1g" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+UseConcMarkSweepGC" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+ExplicitGCInvokesConcurrent" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+UseParNewGC" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+UseTLAB" # JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+AggressiveOpts" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+OptimizeStringConcat" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+UseStringCache" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+UseCompressedOops" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -Xloggc:/usr/local/jira/logs/gc.log" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+PrintGCDetails" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+PrintGCDateStamps" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+HeapDumpOnOutOfMemoryError" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:HeapDumpPath=/usr/local/jira/logs" {noformat} In the end, I don't feel like this is highly likely to ever bite anyone, but I figured I'd record it because it might come in useful down the road. I don't _believe_ this affected 6.0.4 when connecting to the HSQL built in database, but I can't confirm that as I don't have good notes as to whether I'd changed the JVM args before switching to PostgreSQL.
    via by John Knight,
  • Upgraded over the weekend from JIRA 5.2.x to 6.0.4: tested with a smaller system for final confirmation and decided to go with the upgrade. Upon upgrading, the plugin system failed to initialize with multiple errors, all appearing as: {noformat} 2013-07-20 21:19:41,130 localhost-startStop-1 ERROR [atlassian.plugin.loaders.ScanningPluginLoader] Unable to deploy plugin 'com.atlassian.plugins.remotable-plugins-api-0.8.2' from 'Unit: /var/atlassian/application-data/jira6/plugins/.bundled-plugins/remotable-plugins-api-0.8.2.jar (1372752790000)'. 2013-07-20 21:19:41,130 localhost-startStop-1 ERROR [atlassian.plugin.loaders.ScanningPluginLoader] Because of the following exception: java.lang.UnsupportedOperationException at java.util.AbstractMap$SimpleImmutableEntry.setValue(AbstractMap.java:759) at org.apache.felix.framework.BundleImpl.getCurrentLocalizedHeader(BundleImpl.java:442) at org.apache.felix.framework.Felix.getBundleHeaders(Felix.java:1404) at org.apache.felix.framework.BundleImpl.getHeaders(BundleImpl.java:312) at org.apache.felix.framework.BundleImpl.getHeaders(BundleImpl.java:294) at com.atlassian.plugin.osgi.util.OsgiHeaderUtil.getPluginKey(OsgiHeaderUtil.java:361) at com.atlassian.plugin.osgi.container.felix.FelixOsgiContainerManager$BundleRegistration.install(FelixOsgiContainerManager.java:649) at com.atlassian.plugin.osgi.container.felix.FelixOsgiContainerManager.installBundle(FelixOsgiContainerManager.java:503) at com.atlassian.plugin.osgi.factory.OsgiBundleFactory.create(OsgiBundleFactory.java:128) at com.atlassian.jira.plugin.MasterPluginFactory.create(MasterPluginFactory.java:78) at com.atlassian.plugin.loaders.ScanningPluginLoader.deployPluginFromUnit(ScanningPluginLoader.java:155) at com.atlassian.plugin.loaders.ScanningPluginLoader.loadAllPlugins(ScanningPluginLoader.java:89) at com.atlassian.plugin.loaders.PermissionCheckingPluginLoader.loadAllPlugins(PermissionCheckingPluginLoader.java:24) at com.atlassian.plugin.manager.DefaultPluginManager.init(DefaultPluginManager.java:203) at com.atlassian.jira.plugin.JiraPluginManager.start(JiraPluginManager.java:62) {noformat} Lots of iterations later, including starting from scratch, various PostgreSQL versions, OS X v. Ubuntu, it turns out that the _immediate_ proximate cause on my production server is the presence of the -XX:+AggressiveOpts option in the JVM extra args in setenv.sh, as below: {noformat} JVM_MINIMUM_MEMORY="4g" JVM_MAXIMUM_MEMORY="4g" # # The following are the required arguments for JIRA. # JVM_REQUIRED_ARGS="-Djava.awt.headless=true -Datlassian.standalone=JIRA -Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true -Dmail.mime.decodeparameters=true" # Uncomment this setting if you want to import data without notifications # #DISABLE_NOTIFICATIONS=" -Datlassian.mail.senddisabled=true -Datlassian.mail.fetchdisabled=true -Datlassian.mail.popdisabled=true" #----------------------------------------------------------------------------------- # # In general don't make changes below here # #----------------------------------------------------------------------------------- #----------------------------------------------------------------------------------- # This allows us to actually debug GC related issues by correlating timestamps # with other parts of the application logs. #----------------------------------------------------------------------------------- JVM_EXTRA_ARGS="" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:NewSize=1g" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:MaxNewSize=1g" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+UseConcMarkSweepGC" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+ExplicitGCInvokesConcurrent" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+UseParNewGC" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+UseTLAB" # JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+AggressiveOpts" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+OptimizeStringConcat" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+UseStringCache" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+UseCompressedOops" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -Xloggc:/usr/local/jira/logs/gc.log" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+PrintGCDetails" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+PrintGCDateStamps" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+HeapDumpOnOutOfMemoryError" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:HeapDumpPath=/usr/local/jira/logs" {noformat} In the end, I don't feel like this is highly likely to ever bite anyone, but I figured I'd record it because it might come in useful down the road. I don't _believe_ this affected 6.0.4 when connecting to the HSQL built in database, but I can't confirm that as I don't have good notes as to whether I'd changed the JVM args before switching to PostgreSQL.
    via by John Knight,
  • java.lang.UnsupportedOperationException
    via by sebglon,
  • When trying to build a Java project (any Java project) using a Maven build step from within Hudson, the build fails with the following error: ERROR: Processing failed due to a bug in the code. Please report this to users@hudson.dev.java.net java.lang.UnsupportedOperationException at java.util.AbstractMap$SimpleImmutableEntry.setValue(AbstractMap.java:726) at hudson.EnvVars.resolve(EnvVars.java:156) at hudson.model.AbstractBuild.getEnvironment(AbstractBuild.java:708) at hudson.maven.MavenModuleSetBuild.getEnvironment(MavenModuleSetBuild.java:130) at hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:386) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:416) at hudson.model.Run.run(Run.java:1241) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:306) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:122) project=hudson.maven.MavenModuleSet@24ea5da2[IroniaCorp-Http] project.getModules()=[] project.getRootModule()=null FATAL: null java.lang.UnsupportedOperationException at java.util.AbstractMap$SimpleImmutableEntry.setValue(AbstractMap.java:726) at hudson.EnvVars.resolve(EnvVars.java:156) at hudson.model.AbstractBuild.getEnvironment(AbstractBuild.java:708) at hudson.maven.MavenModuleSetBuild.getEnvironment(MavenModuleSetBuild.java:130) at hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:386) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:416) at hudson.model.Run.run(Run.java:1241) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:306) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:122)
    via by magsilva2,
  • After installing the latest version of Hudson we get sometimes the following Exception. ERROR: Processing failed due to a bug in the code. Please report this to users@hudson.dev.java.net java.lang.UnsupportedOperationException at java.util.AbstractMap$SimpleImmutableEntry.setValue(AbstractMap.java:726) at hudson.EnvVars.resolve(EnvVars.java:156) at hudson.model.AbstractBuild.getEnvironment(AbstractBuild.java:689) at hudson.maven.MavenModuleSetBuild.getEnvironment(MavenModuleSetBuild.java:128) at hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:384) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:416) at hudson.model.Run.run(Run.java:1243) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:304) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:122) project=hudson.maven.MavenModuleSet@33c36633[TEL Parent] project.getModules()=[hudson.maven.MavenModule@341840ff[TEL Parent/org.theeuropeanlibrary:parent], hudson.maven.MavenModule@16692a88[TEL Parent/org.theeuropeanlibrary:tel-parent]] project.getRootModule()=hudson.maven.MavenModule@16692a88[TEL Parent/org.theeuropeanlibrary:tel-parent] FATAL: null java.lang.UnsupportedOperationException at java.util.AbstractMap$SimpleImmutableEntry.setValue(AbstractMap.java:726) at hudson.EnvVars.resolve(EnvVars.java:156) at hudson.model.AbstractBuild.getEnvironment(AbstractBuild.java:689) at hudson.maven.MavenModuleSetBuild.getEnvironment(MavenModuleSetBuild.java:128) at hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:384) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:416) at hudson.model.Run.run(Run.java:1243) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:304) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:122)
    via by ajuffinger,
  • Note: I was able to workaround this issue, and the workaround code is enclosed below. When trying to build a Java project (any Java project) using an Ant build step from within Hudson, the build fails with the following error: -------------------------------------------------- Started by user anonymous [workspace] $ cvsnt -q update -PdC -D "Saturday, March 27, 2010 4:11:43 AM UTC" ? ${build.dir} ? ${dist.dir} $ no changes detected Deleting old artifacts from #36 FATAL: null java.lang.UnsupportedOperationException at java.util.AbstractMap$SimpleImmutableEntry.setValue(AbstractMap.java:726) at hudson.EnvVars.resolve(EnvVars.java:156) at hudson.model.AbstractBuild.getEnvironment(AbstractBuild.java:689) at hudson.tasks.Ant.perform(Ant.java:134) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:582) at hudson.model.Build$RunnerImpl.build(Build.java:165) at hudson.model.Build$RunnerImpl.doRun(Build.java:132) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:416) at hudson.model.Run.run(Run.java:1243) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:122) -------------------------------------------------- This makes Hudson virtually useless, as Ant is obviously required to compile my Java applications. After many hours of troubleshooting, I was able to get build 1281 to work, but when I migrated to GlassFish 3, the security broke. After many more hours of troubleshooting, I was able to determine that the issue resides in the hudson/main/core/src/main/java/hudson/EnvVars.java file, with the resolve(Map<String, String> env) method. The workaround I developed was to eliminate the entry.setValue() from processing. The workaround code is: -------------------------------------------------- //JLV Software Development Workaround Code public static void resolve(Map<String, String> env) { java.util.logging.Logger jLog = java.util.logging.Logger.getLogger("hudson.tasks"); //Get a logger to help debug code jLog.fine("EnvVars.java // resolve // env.size()=\"" + env.size() + "\""); //Log the size of the Map for (Map.Entry<String,String> entry: env.entrySet()) { jLog.fine("EnvVars.java // resolve // entry.getValue()=\"" + entry.getValue() + "\"" + " .getKey() =\"" + entry.getKey() + "\""); //Log each Key/Value pair // entry.setValue(entry.getValue()); //Commented out as workaround. } } -------------------------------------------------- Reviewing the exception, I believe (and it's just a guess) that this is due to the fact that two of my system variables ("NODE_NAME", "CLASSPATH") are currently reported as empty values ("") when logged. If this is true, I recommend that the code be modified to check for empty values, and then only try to perform a .setValue on non-empty entries.
    via by jlvsd,
    • java.lang.UnsupportedOperationException at java.util.AbstractMap$SimpleImmutableEntry.setValue(AbstractMap.java:759) at org.apache.felix.framework.BundleImpl.getCurrentLocalizedHeader(BundleImpl.java:442) at org.apache.felix.framework.Felix.getBundleHeaders(Felix.java:1404) at org.apache.felix.framework.BundleImpl.getHeaders(BundleImpl.java:312) at org.apache.felix.framework.BundleImpl.getHeaders(BundleImpl.java:294) at com.atlassian.plugin.osgi.util.OsgiHeaderUtil.getPluginKey(OsgiHeaderUtil.java:361) at com.atlassian.plugin.osgi.container.felix.FelixOsgiContainerManager$BundleRegistration.install(FelixOsgiContainerManager.java:649) at com.atlassian.plugin.osgi.container.felix.FelixOsgiContainerManager.installBundle(FelixOsgiContainerManager.java:503) at com.atlassian.plugin.osgi.factory.OsgiBundleFactory.create(OsgiBundleFactory.java:128) at com.atlassian.jira.plugin.MasterPluginFactory.create(MasterPluginFactory.java:78) at com.atlassian.plugin.loaders.ScanningPluginLoader.deployPluginFromUnit(ScanningPluginLoader.java:155) at com.atlassian.plugin.loaders.ScanningPluginLoader.loadAllPlugins(ScanningPluginLoader.java:89) at com.atlassian.plugin.loaders.PermissionCheckingPluginLoader.loadAllPlugins(PermissionCheckingPluginLoader.java:24) at com.atlassian.plugin.manager.DefaultPluginManager.init(DefaultPluginManager.java:203) at com.atlassian.jira.plugin.JiraPluginManager.start(JiraPluginManager.java:62)

    Users with the same issue

    Unknown visitor1 times, last one,
    Unknown visitor1 times, last one,