Uploaded image for project: 'Tools (JBoss Tools)'
  1. Tools (JBoss Tools)
  2. JBIDE-17437

When runtime's JRE is changed to Java 8, both JDKs are in runtime classpath

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • 4.2.0.Beta3
    • 4.2.0.Beta2
    • server
    • Hide

      1. Set up WildFly 8.0, be sure to use java 8 for the runtime
      2. Start the server - no problem
      3. Stop the server
      4. Open Server editor (double-click the server in server view)
      5. Click Runtime Environment and change java to java 7. Close and save.
      6. Start the server - no problem
      7. Stop the server
      8. Click Runtime Environment in server editor and change java to java 8. Close and save.
      9. Start server - you will see the error from this JIRA description reoccuring in the server log.
      10. Open Launch Config from server view and check the Classpath tab - you will see both jdk 1.7 and 1.8 are on the classpath.

      Show
      1. Set up WildFly 8.0, be sure to use java 8 for the runtime 2. Start the server - no problem 3. Stop the server 4. Open Server editor (double-click the server in server view) 5. Click Runtime Environment and change java to java 7. Close and save. 6. Start the server - no problem 7. Stop the server 8. Click Runtime Environment in server editor and change java to java 8. Close and save. 9. Start server - you will see the error from this JIRA description reoccuring in the server log. 10. Open Launch Config from server view and check the Classpath tab - you will see both jdk 1.7 and 1.8 are on the classpath.

    Description

      I was playing a bit with the java 8 facet added in JBIDE-17126 and for that I had a WildFly 8 server set up with java 8. Then I changed the runtime to use java 7. Then back again to java 8. This resulted in an exception when starting the server:

      2014-05-27 10:12:12,437 ERROR [org.xnio.listener] (XNIO-1 I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.NoClassDefFoundError: Could not initialize class sun.security.ec.CurveDB
	at sun.security.ec.SunECEntries.putEntries(SunECEntries.java:72)
	at sun.security.ec.SunEC.<init>(SunEC.java:76)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.8.0_05]
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [rt.jar:1.8.0_05]
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.8.0_05]
	at java.lang.reflect.Constructor.newInstance(Constructor.java:408) [rt.jar:1.8.0_05]
	at java.lang.Class.newInstance(Class.java:433) [rt.jar:1.8.0_05]
	at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:221) [rt.jar:1.8.0_05]
	at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:206) [rt.jar:1.8.0_05]
	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_05]
	at sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:206) [rt.jar:1.8.0_05]
	at sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:187) [rt.jar:1.8.0_05]
	at sun.security.jca.ProviderList.loadAll(ProviderList.java:282) [rt.jar:1.8.0_05]
	at sun.security.jca.ProviderList.removeInvalid(ProviderList.java:299) [rt.jar:1.8.0_05]
	at sun.security.jca.Providers.getFullProviderList(Providers.java:173) [rt.jar:1.8.0_05]
	at java.security.Security.getProviders(Security.java:452) [rt.jar:1.8.0_05]
	at org.xnio.sasl.SaslUtils.getFactories(SaslUtils.java:121) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.sasl.SaslUtils.getSaslServerFactories(SaslUtils.java:75) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.initialiseCapabilities(ServerConnectionOpenListener.java:165) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.sendCapabilities(ServerConnectionOpenListener.java:413) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:260) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:139) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:196) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:110) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)
	at org.xnio.nio.WorkerThread.run(WorkerThread.java:531)

      I found this issue WFLY-3079 and it turns out that the reason is that when you changed a runtime's java from java 8 to java 7 and then back again to java 8, you end up with both JDKs in classpath. �This should be fixed.

      Note that this issue is most probably not exclusive to WildFly.

      Attachments

        Issue Links

          is related to

          Feature Request - Feature requests from customers and/or users JBIDE-17646 Server runtimes should be able to customize execution-environment

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed

          Bug - A problem that impairs or prevents the functions of the product. WFLY-3079 Wildfly JDK 8

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed
          relates to

          Feature Request - Feature requests from customers and/or users JBIDE-17126 Add support for 1.8 java facet to JBoss runtimes

          • Blocker - To be worked above all other priorities. This term is chosen when the severity of the issue is very high, has no workaround, or the effort for the change is comparatively low. Issues that may be very publicly visible and could generate significant media attention may also drive a higher priority.
          • Closed

          Activity

            People

              rob.stryker Rob Stryker (Inactive)
              exd-mmalina Martin Malina
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: