[jbosstools-issues] [JBoss JIRA] (JBIDE-17437) When runtime's JRE is changed to Java 8, both JDKs are in runtime classpath

[Rob Stryker (JIRA)]

    [ https://issues.jboss.org/browse/JBIDE-17437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984834#comment-12984834 ] 

Rob Stryker commented on JBIDE-17437:
-------------------------------------

I'm not able to replicate. I did it three times and also traced through it. The java7 entry does exist, but is removed by the line which fixed this issue previously.  The line removes classpath entries that match the following:  

if( t.contains("org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType"))  { //$NON-NLS-1$
                               i.remove();

The java7 jvm matches this string, so it is removed. The java8 is then added. 


> When runtime's JRE is changed to Java 8, both JDKs are in runtime classpath
> ---------------------------------------------------------------------------
>
>                 Key: JBIDE-17437
>                 URL: https://issues.jboss.org/browse/JBIDE-17437
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: server
>    Affects Versions: 4.2.0.Beta2
>         Environment: OS X 10.9 Mavericks
> WildFly 8.0
> JBDS 8.0.0.Beta2 B104
>            Reporter: Martin Malina
>            Assignee: Rob Stryker
>             Fix For: 4.2.0.Beta3
>
>
> 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:
> {code}
> 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)
> {code}
> 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.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)