[JBoss JIRA] (WFLY-4259) ClassNotFound exception when connecting a remote HornetQ client over SSL
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-4259?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-4259:
------------------------------
Fix Version/s: 9.0.0.Beta1
> ClassNotFound exception when connecting a remote HornetQ client over SSL
> ------------------------------------------------------------------------
>
> Key: WFLY-4259
> URL: https://issues.jboss.org/browse/WFLY-4259
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Reporter: Jon Kranes
> Assignee: Jeff Mesnil
> Fix For: 9.0.0.Beta1
>
>
> When using HornetQ with a remote client connecting with SSL (using a netty-connector with ssl-enabled=true) the server throws an exception in ModuleClassLoader when the client attempts to connect. The exception is:
> java.lang.ClassNotFoundException: javax.net.SSLException
> After doing some investigation I was able to resolve this issue by adding a dependency in the io.netty module.xml file
> <dependencies>
> <module name="javax.api"/>
> <dependencies
> Without this dependency, it appear that Netty is unable to load classes that it needs from javax.net.ssl.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (DROOLS-686) Documentation build: Upgrade pressgang-tools from 2 to 3
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-686?page=com.atlassian.jira.plugin... ]
Petr Široký commented on DROOLS-686:
------------------------------------
I did not plug out the the network cable physically, but rather disabled the networking interfaces in the system (which is effectively the same, I was not able to connect to any resource on the network/internet). I tried the build multiple times, so I think we should be ok.
> Documentation build: Upgrade pressgang-tools from 2 to 3
> --------------------------------------------------------
>
> Key: DROOLS-686
> URL: https://issues.jboss.org/browse/DROOLS-686
> Project: Drools
> Issue Type: Task
> Reporter: Geoffrey De Smet
> Assignee: Petr Široký
>
> We're still using pressgang-tools 2:
> https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom....
> but some years ago pressgang-tools 3.x was build and released (by Steve Ebersole), which fixes some issues and enables some new features (such as topics in docbook):
> https://github.com/pressgang/pressgang-tools
> However, pressgang-tools 3.x has an important regression in combination with the maven-docbook-plugin 2.3.8, which prevents building offline, which is a blocker for us:
> https://issues.jboss.org/browse/PRESSGANG-79
> The interesting note is that the gradle-docbook-plugin does build offline, and that both plugins (maven and gradle) use the same jdocbook-core:
> https://github.com/pressgang
> Goal: Fix that jira in maven-docbook-plugin and/or pressgang-tools, so droolsjbpm can upgrade to pressgang-tools 3.x. This is probably not easy.
> The reason that it doesn't build offline, is because the xslt's contain full-url imports, so it reaches out to download those, but the jdocbook-core is able to intercepts to calls and reroute them to the local resources in the pressgang-tools jar (instead of downloading them from the internet). For some reason that works (probably configured correctly) for the gradle plugin, but not for the maven plugin. It's also strange that the maven plugin does work correctly with pressgang 2 jars.
> In any case, the build should work offline (and doing "mvn -o" alone doesn't suffice to prove it, because the -o is ignored for the xslt stuff), plug out the network cable to verify it builds offline.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (DROOLS-686) Documentation build: Upgrade pressgang-tools from 2 to 3
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-686?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet commented on DROOLS-686:
-----------------------------------------
Petr in that SNAPSHOT setup, after building succesfully once, did you try pluggin out your network cable and building again?
The second time it should build offline problem free.
> Documentation build: Upgrade pressgang-tools from 2 to 3
> --------------------------------------------------------
>
> Key: DROOLS-686
> URL: https://issues.jboss.org/browse/DROOLS-686
> Project: Drools
> Issue Type: Task
> Reporter: Geoffrey De Smet
> Assignee: Petr Široký
>
> We're still using pressgang-tools 2:
> https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom....
> but some years ago pressgang-tools 3.x was build and released (by Steve Ebersole), which fixes some issues and enables some new features (such as topics in docbook):
> https://github.com/pressgang/pressgang-tools
> However, pressgang-tools 3.x has an important regression in combination with the maven-docbook-plugin 2.3.8, which prevents building offline, which is a blocker for us:
> https://issues.jboss.org/browse/PRESSGANG-79
> The interesting note is that the gradle-docbook-plugin does build offline, and that both plugins (maven and gradle) use the same jdocbook-core:
> https://github.com/pressgang
> Goal: Fix that jira in maven-docbook-plugin and/or pressgang-tools, so droolsjbpm can upgrade to pressgang-tools 3.x. This is probably not easy.
> The reason that it doesn't build offline, is because the xslt's contain full-url imports, so it reaches out to download those, but the jdocbook-core is able to intercepts to calls and reroute them to the local resources in the pressgang-tools jar (instead of downloading them from the internet). For some reason that works (probably configured correctly) for the gradle plugin, but not for the maven plugin. It's also strange that the maven plugin does work correctly with pressgang 2 jars.
> In any case, the build should work offline (and doing "mvn -o" alone doesn't suffice to prove it, because the -o is ignored for the xslt stuff), plug out the network cable to verify it builds offline.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (DROOLS-686) Documentation build: Upgrade pressgang-tools from 2 to 3
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-686?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet edited comment on DROOLS-686 at 2/19/15 6:22 AM:
------------------------------------------------------------------
Petr in that SNAPSHOT setup, after building successfully once, did you try pluggin out your network cable and building again?
The second time it must be able build offline (and that originally didn't work with pressgang 3).
was (Author: ge0ffrey):
Petr in that SNAPSHOT setup, after building succesfully once, did you try pluggin out your network cable and building again?
The second time it should build offline problem free.
> Documentation build: Upgrade pressgang-tools from 2 to 3
> --------------------------------------------------------
>
> Key: DROOLS-686
> URL: https://issues.jboss.org/browse/DROOLS-686
> Project: Drools
> Issue Type: Task
> Reporter: Geoffrey De Smet
> Assignee: Petr Široký
>
> We're still using pressgang-tools 2:
> https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom....
> but some years ago pressgang-tools 3.x was build and released (by Steve Ebersole), which fixes some issues and enables some new features (such as topics in docbook):
> https://github.com/pressgang/pressgang-tools
> However, pressgang-tools 3.x has an important regression in combination with the maven-docbook-plugin 2.3.8, which prevents building offline, which is a blocker for us:
> https://issues.jboss.org/browse/PRESSGANG-79
> The interesting note is that the gradle-docbook-plugin does build offline, and that both plugins (maven and gradle) use the same jdocbook-core:
> https://github.com/pressgang
> Goal: Fix that jira in maven-docbook-plugin and/or pressgang-tools, so droolsjbpm can upgrade to pressgang-tools 3.x. This is probably not easy.
> The reason that it doesn't build offline, is because the xslt's contain full-url imports, so it reaches out to download those, but the jdocbook-core is able to intercepts to calls and reroute them to the local resources in the pressgang-tools jar (instead of downloading them from the internet). For some reason that works (probably configured correctly) for the gradle plugin, but not for the maven plugin. It's also strange that the maven plugin does work correctly with pressgang 2 jars.
> In any case, the build should work offline (and doing "mvn -o" alone doesn't suffice to prove it, because the -o is ignored for the xslt stuff), plug out the network cable to verify it builds offline.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JGRP-1912) LockService can fail under heavy load
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1912?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1912.
----------------------------
Resolution: Cannot Reproduce Bug
Please reopen if the issue still persists
> LockService can fail under heavy load
> -------------------------------------
>
> Key: JGRP-1912
> URL: https://issues.jboss.org/browse/JGRP-1912
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.1
> Environment: both windows 8.1 and RHEL
> java 1.7.0_75
> Reporter: Chris Gentile
> Assignee: Bela Ban
> Fix For: 3.6.3
>
> Attachments: LockServiceTestClient.java, LockServiceTestClient.java, logFile, logFile2, runLockServiceTestClient.sh, udp.xml
>
>
> Once in awhile, the LockService will get stuck acquiring a lock.
> These seems to occur most often when two threads are simultaneously trying to acquire the same lock. (i.e.: exact same millisecond on a server with multiple processors).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JGRP-1912) LockService can fail under heavy load
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1912?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1912 at 2/19/15 6:14 AM:
---------------------------------------------------------
Why's {{CENTRAL_LOCK}} so far down in the stack ? That makes it unreliable, so {{GRANT_LOCK}} requests sent to the coordinator might simply get dropped and therefore a {{tryLock()}} could run into a timeout.
The documentation [1] recommends this (see last paragraph in 4.6).
[1] http://www.jgroups.org/manual/index.html#LockService
was (Author: belaban):
Why's {{CENTRAL_LOCK}} so far down in the stack ? That makes it unreliable, so {GRANT_LOCK} requests sent to the coordinator might simply get dropped and therefore a tryLock() could run into a timeout.
> LockService can fail under heavy load
> -------------------------------------
>
> Key: JGRP-1912
> URL: https://issues.jboss.org/browse/JGRP-1912
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.1
> Environment: both windows 8.1 and RHEL
> java 1.7.0_75
> Reporter: Chris Gentile
> Assignee: Bela Ban
> Fix For: 3.6.3
>
> Attachments: LockServiceTestClient.java, LockServiceTestClient.java, logFile, logFile2, runLockServiceTestClient.sh, udp.xml
>
>
> Once in awhile, the LockService will get stuck acquiring a lock.
> These seems to occur most often when two threads are simultaneously trying to acquire the same lock. (i.e.: exact same millisecond on a server with multiple processors).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JGRP-1912) LockService can fail under heavy load
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1912?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1912:
--------------------------------
Why's {{CENTRAL_LOCK}} so far down in the stack ? That makes it unreliable, so {GRANT_LOCK} requests sent to the coordinator might simply get dropped and therefore a tryLock() could run into a timeout.
> LockService can fail under heavy load
> -------------------------------------
>
> Key: JGRP-1912
> URL: https://issues.jboss.org/browse/JGRP-1912
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.1
> Environment: both windows 8.1 and RHEL
> java 1.7.0_75
> Reporter: Chris Gentile
> Assignee: Bela Ban
> Fix For: 3.6.3
>
> Attachments: LockServiceTestClient.java, LockServiceTestClient.java, logFile, logFile2, runLockServiceTestClient.sh, udp.xml
>
>
> Once in awhile, the LockService will get stuck acquiring a lock.
> These seems to occur most often when two threads are simultaneously trying to acquire the same lock. (i.e.: exact same millisecond on a server with multiple processors).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4364) add dependency to javax.api in io.netty module
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-4364?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil resolved WFLY-4364.
-------------------------------
Resolution: Duplicate Issue
duplicate WFLY-4259
> add dependency to javax.api in io.netty module
> ----------------------------------------------
>
> Key: WFLY-4364
> URL: https://issues.jboss.org/browse/WFLY-4364
> Project: WildFly
> Issue Type: Bug
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 9.0.0.Beta1
>
>
> io.netty module needs a dependency to javax.api module to use its SSL functionality.
> Otherwise, the code fails with a stack trace such as:
> {noformat}
> 11:20:50,161 WARN [org.jboss.modules] (Thread-0 (HornetQ-client-netty-threads-1249943084)) Failed to define class io.netty.handler.ssl.NotSslRecordException in Module "io.netty:main" from local module loader @52f63387 (finder: local module finder @21b10e9e (roots: /Users/ahmedhammad/tools/wildfly-8.1.0.Final/modules,/Users/ahmedhammad/tools/wildfly-8.1.0.Final/modules/system/layers/base)): java.lang.LinkageError: Failed to link io/netty/handler/ssl/NotSslRecordException (Module "io.netty:main" from local module loader @52f63387 (finder: local module finder @21b10e9e (roots: /Users/ahmedhammad/tools/wildfly-8.1.0.Final/modules,/Users/ahmedhammad/tools/wildfly-8.1.0.Final/modules/system/layers/base)))
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:487) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:277) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:92) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.Module.loadModuleClass(Module.java:568) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.3.Final]
> at org.hornetq.core.remoting.impl.netty.NettyConnector$1.initChannel(NettyConnector.java:563) [hornetq-core-client-2.4.1.Final.jar:]
> at io.netty.channel.ChannelInitializer.channelRegistered(ChannelInitializer.java:69) [netty-all-4.0.15.Final.jar:4.0.15.Final]
> at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRegistered(DefaultChannelHandlerContext.java:163) [netty-all-4.0.15.Final.jar:4.0.15.Final]
> at io.netty.channel.DefaultChannelHandlerContext.fireChannelRegistered(DefaultChannelHandlerContext.java:149) [netty-all-4.0.15.Final.jar:4.0.15.Final]
> at io.netty.channel.DefaultChannelPipeline.fireChannelRegistered(DefaultChannelPipeline.java:730) [netty-all-4.0.15.Final.jar:4.0.15.Final]
> at io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:442) [netty-all-4.0.15.Final.jar:4.0.15.Final]
> at io.netty.channel.AbstractChannel$AbstractUnsafe.access$100(AbstractChannel.java:374) [netty-all-4.0.15.Final.jar:4.0.15.Final]
> at io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:418) [netty-all-4.0.15.Final.jar:4.0.15.Final]
> at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:354) [netty-all-4.0.15.Final.jar:4.0.15.Final]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:353) [netty-all-4.0.15.Final.jar:4.0.15.Final]
> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:101) [netty-all-4.0.15.Final.jar:4.0.15.Final]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.NoClassDefFoundError: javax/net/ssl/SSLException
> at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.7.0_25]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:792) [rt.jar:1.7.0_25]
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:361) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:482) [jboss-modules.jar:1.3.3.Final]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4364) add dependency to javax.api in io.netty module
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-4364?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil reassigned WFLY-4364:
---------------------------------
Assignee: Jeff Mesnil (was: Jason Greene)
> add dependency to javax.api in io.netty module
> ----------------------------------------------
>
> Key: WFLY-4364
> URL: https://issues.jboss.org/browse/WFLY-4364
> Project: WildFly
> Issue Type: Bug
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 9.0.0.Beta1
>
>
> io.netty module needs a dependency to javax.api module to use its SSL functionality.
> Otherwise, the code fails with a stack trace such as:
> {noformat}
> 11:20:50,161 WARN [org.jboss.modules] (Thread-0 (HornetQ-client-netty-threads-1249943084)) Failed to define class io.netty.handler.ssl.NotSslRecordException in Module "io.netty:main" from local module loader @52f63387 (finder: local module finder @21b10e9e (roots: /Users/ahmedhammad/tools/wildfly-8.1.0.Final/modules,/Users/ahmedhammad/tools/wildfly-8.1.0.Final/modules/system/layers/base)): java.lang.LinkageError: Failed to link io/netty/handler/ssl/NotSslRecordException (Module "io.netty:main" from local module loader @52f63387 (finder: local module finder @21b10e9e (roots: /Users/ahmedhammad/tools/wildfly-8.1.0.Final/modules,/Users/ahmedhammad/tools/wildfly-8.1.0.Final/modules/system/layers/base)))
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:487) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:277) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:92) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.Module.loadModuleClass(Module.java:568) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.3.Final]
> at org.hornetq.core.remoting.impl.netty.NettyConnector$1.initChannel(NettyConnector.java:563) [hornetq-core-client-2.4.1.Final.jar:]
> at io.netty.channel.ChannelInitializer.channelRegistered(ChannelInitializer.java:69) [netty-all-4.0.15.Final.jar:4.0.15.Final]
> at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRegistered(DefaultChannelHandlerContext.java:163) [netty-all-4.0.15.Final.jar:4.0.15.Final]
> at io.netty.channel.DefaultChannelHandlerContext.fireChannelRegistered(DefaultChannelHandlerContext.java:149) [netty-all-4.0.15.Final.jar:4.0.15.Final]
> at io.netty.channel.DefaultChannelPipeline.fireChannelRegistered(DefaultChannelPipeline.java:730) [netty-all-4.0.15.Final.jar:4.0.15.Final]
> at io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:442) [netty-all-4.0.15.Final.jar:4.0.15.Final]
> at io.netty.channel.AbstractChannel$AbstractUnsafe.access$100(AbstractChannel.java:374) [netty-all-4.0.15.Final.jar:4.0.15.Final]
> at io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:418) [netty-all-4.0.15.Final.jar:4.0.15.Final]
> at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:354) [netty-all-4.0.15.Final.jar:4.0.15.Final]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:353) [netty-all-4.0.15.Final.jar:4.0.15.Final]
> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:101) [netty-all-4.0.15.Final.jar:4.0.15.Final]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.NoClassDefFoundError: javax/net/ssl/SSLException
> at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.7.0_25]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:792) [rt.jar:1.7.0_25]
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:361) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:482) [jboss-modules.jar:1.3.3.Final]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4364) add dependency to javax.api in io.netty module
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-4364:
---------------------------------
Summary: add dependency to javax.api in io.netty module
Key: WFLY-4364
URL: https://issues.jboss.org/browse/WFLY-4364
Project: WildFly
Issue Type: Bug
Reporter: Jeff Mesnil
Assignee: Jason Greene
Fix For: 9.0.0.Beta1
io.netty module needs a dependency to javax.api module to use its SSL functionality.
Otherwise, the code fails with a stack trace such as:
{noformat}
11:20:50,161 WARN [org.jboss.modules] (Thread-0 (HornetQ-client-netty-threads-1249943084)) Failed to define class io.netty.handler.ssl.NotSslRecordException in Module "io.netty:main" from local module loader @52f63387 (finder: local module finder @21b10e9e (roots: /Users/ahmedhammad/tools/wildfly-8.1.0.Final/modules,/Users/ahmedhammad/tools/wildfly-8.1.0.Final/modules/system/layers/base)): java.lang.LinkageError: Failed to link io/netty/handler/ssl/NotSslRecordException (Module "io.netty:main" from local module loader @52f63387 (finder: local module finder @21b10e9e (roots: /Users/ahmedhammad/tools/wildfly-8.1.0.Final/modules,/Users/ahmedhammad/tools/wildfly-8.1.0.Final/modules/system/layers/base)))
at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:487) [jboss-modules.jar:1.3.3.Final]
at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:277) [jboss-modules.jar:1.3.3.Final]
at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:92) [jboss-modules.jar:1.3.3.Final]
at org.jboss.modules.Module.loadModuleClass(Module.java:568) [jboss-modules.jar:1.3.3.Final]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205) [jboss-modules.jar:1.3.3.Final]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.3.Final]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.3.Final]
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.3.Final]
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.3.Final]
at org.hornetq.core.remoting.impl.netty.NettyConnector$1.initChannel(NettyConnector.java:563) [hornetq-core-client-2.4.1.Final.jar:]
at io.netty.channel.ChannelInitializer.channelRegistered(ChannelInitializer.java:69) [netty-all-4.0.15.Final.jar:4.0.15.Final]
at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRegistered(DefaultChannelHandlerContext.java:163) [netty-all-4.0.15.Final.jar:4.0.15.Final]
at io.netty.channel.DefaultChannelHandlerContext.fireChannelRegistered(DefaultChannelHandlerContext.java:149) [netty-all-4.0.15.Final.jar:4.0.15.Final]
at io.netty.channel.DefaultChannelPipeline.fireChannelRegistered(DefaultChannelPipeline.java:730) [netty-all-4.0.15.Final.jar:4.0.15.Final]
at io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:442) [netty-all-4.0.15.Final.jar:4.0.15.Final]
at io.netty.channel.AbstractChannel$AbstractUnsafe.access$100(AbstractChannel.java:374) [netty-all-4.0.15.Final.jar:4.0.15.Final]
at io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:418) [netty-all-4.0.15.Final.jar:4.0.15.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:354) [netty-all-4.0.15.Final.jar:4.0.15.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:353) [netty-all-4.0.15.Final.jar:4.0.15.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:101) [netty-all-4.0.15.Final.jar:4.0.15.Final]
at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
Caused by: java.lang.NoClassDefFoundError: javax/net/ssl/SSLException
at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.7.0_25]
at java.lang.ClassLoader.defineClass(ClassLoader.java:792) [rt.jar:1.7.0_25]
at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:361) [jboss-modules.jar:1.3.3.Final]
at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:482) [jboss-modules.jar:1.3.3.Final]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months