java.lang.UnsupportedOperationException

Jenkins JIRA | qiao feng | 3 years ago
tip
Your exception is missing from the Samebug knowledge base.
Here are the best solutions we found on the Internet.
Click on the to mark the helpful solution and get rewards for you help.
  1. 0

    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.

    Atlassian JIRA | 4 years ago | John Knight
    java.lang.UnsupportedOperationException
  2. Speed up your debug routine!

    Automated exception search integrated into your IDE

  3. 0

    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.

    Atlassian JIRA | 4 years ago | John Knight
    java.lang.UnsupportedOperationException
  4. 0

    java.lang.UnsupportedOperationException

    Google Groups | 6 years ago | sebglon
    java.lang.UnsupportedOperationException

    1 unregistered visitors
    Not finding the right solution?
    Take a tour to get the most out of Samebug.

    Tired of useless tips?

    Automated exception search integrated into your IDE

    Root Cause Analysis

    1. java.lang.UnsupportedOperationException

      No message provided

      at java.util.AbstractMap$SimpleImmutableEntry.setValue()
    2. Java RT
      AbstractMap$SimpleImmutableEntry.setValue
      1. java.util.AbstractMap$SimpleImmutableEntry.setValue(AbstractMap.java:759)
      1 frame
    3. Hudson
      AbstractBuild$AbstractBuildExecution.defaultCheckout
      1. hudson.EnvVars.resolve(EnvVars.java:340)
      2. hudson.scm.SubversionSCM.getLocations(SubversionSCM.java:521)
      3. hudson.scm.SubversionSCM.buildEnvVars(SubversionSCM.java:689)
      4. hudson.model.AbstractBuild.getEnvironment(AbstractBuild.java:938)
      5. hudson.scm.SubversionSCM.checkout(SubversionSCM.java:865)
      6. hudson.model.AbstractProject.checkout(AbstractProject.java:1411)
      7. hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:671)
      7 frames
    4. jenkins.scm
      SCMCheckoutStrategy.checkout
      1. jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
      1 frame
    5. Hudson
      Executor.run
      1. hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:580)
      2. hudson.model.Run.execute(Run.java:1670)
      3. hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
      4. hudson.model.ResourceController.execute(ResourceController.java:88)
      5. hudson.model.Executor.run(Executor.java:231)
      5 frames