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

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major 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.

      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.

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

                Created:
                Updated:
                Resolved: