[JBoss JIRA] (ARQ-1823) ChromeBinary is not picked by ChromeDriver
by Karel Piwko (JIRA)
Karel Piwko created ARQ-1823:
--------------------------------
Summary: ChromeBinary is not picked by ChromeDriver
Key: ARQ-1823
URL: https://issues.jboss.org/browse/ARQ-1823
Project: Arquillian
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Extension - Drone
Affects Versions: drone_2.0.0.Alpha2
Reporter: Karel Piwko
It looks like that capability is not used by upstream implementation. We need to make it a part of ChromeOptions instead.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (ARQ-1820) LoginContext cannot load login modules in certain scenarios when EAP server is started by Arquillian
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/ARQ-1820?page=com.atlassian.jira.plugin.s... ]
Miroslav Novak commented on ARQ-1820:
-------------------------------------
No, I'm using "Servlet 3.0" protocol. There is no deployment to EAP 6 server. Server is started manually in the test.
arquillian.xml:
{code}
<?xml version="1.0" encoding="UTF-8"?>
<arquillian xmlns="http://jboss.com/arquillian" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.jboss.org/arquillian-1.0 http://jboss.org/schema/arquillian/arquillian_1_0.xsd">
<defaultProtocol type="Servlet 3.0"/>
<group qualifier="cluster">
<container qualifier="node-1" default="true" mode="manual">
<configuration>
<property name="jbossHome">${JBOSS_HOME_1}</property>
<property name="javaVmArguments">-Xms64m -Xmx788m -XX:MaxPermSize=256m
-Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.dgc.server.gcInterval=3600000
-javaagent:${BYTEMAN_JAR}=prop:org.jboss.byteman.verbose=true,address:${MYTESTIP_1},port:9091
-Djboss.modules.system.pkgs=org.jboss.byteman -Xbootclasspath/a:${BYTEMAN_JAR}:${BYTEMAN_SUBMIT_JAR}
-Djboss.bind.address=${MYTESTIP_1}
-Djboss.bind.address.management=${MYTESTIP_1}
-Djboss.bind.address.unsecure=${MYTESTIP_1}
-Djboss.messaging.group.address=${MCAST_ADDR}
-Djboss.default.multicast.address=${MCAST_ADDR} -XX:+HeapDumpOnOutOfMemoryError
-Djava.net.preferIPv4Stack=false -Djboss.modules.policy-permissions=true
</property> <!-- -Xrunjdwp:transport=dt_socket,address=mnovak-laptop1:8586,server=y,suspend=n-->
<property name="serverConfig">standalone-full-ha.xml</property>
<property name="startupTimeoutInSeconds">60</property>
<property name="managementAddress" >${MYTESTIP_1}</property>
<property name="username">admin</property>
<property name="password">minono532/20</property>
</configuration>
</container>
<container qualifier="node-2" default="false" mode="manual">
<configuration>
<property name="jbossHome">${JBOSS_HOME_2}</property>
<property name="javaVmArguments">-Xms64m -Xmx788m -XX:MaxPermSize=256m
-Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.dgc.server.gcInterval=3600000
-javaagent:${BYTEMAN_JAR}=prop:org.jboss.byteman.verbose=true,address:${MYTESTIP_2},port:9191
-Djboss.modules.system.pkgs=org.jboss.byteman -Xbootclasspath/a:${BYTEMAN_JAR}:${BYTEMAN_SUBMIT_JAR}
-Djboss.bind.address=${MYTESTIP_2}
-Djboss.bind.address.management=${MYTESTIP_2}
-Djboss.bind.address.unsecure=${MYTESTIP_2}
-Djboss.messaging.group.address=${MCAST_ADDR}
-Djboss.default.multicast.address=${MCAST_ADDR}
-Djboss.modules.policy-permissions=true -XX:+HeapDumpOnOutOfMemoryError -Xrunjdwp:transport=dt_socket,address=127.0.0.1:8787,server=y,suspend=n
</property> <!-- -Xrunjdwp:transport=dt_socket,address=mnovak-laptop1:8586,server=y,suspend=n-->
<property name="serverConfig">standalone-full-ha.xml</property>
<property name="startupTimeoutInSeconds">60</property>
<property name="managementAddress" >${MYTESTIP_2}</property>
<property name="username">admin</property>
<property name="password">minono532/20</property>
</configuration>
</container>
<container qualifier="node-3" default="false" mode="manual">
<configuration>
<property name="jbossHome">${JBOSS_HOME_3}</property>
<property name="javaVmArguments">-Xms64m -Xmx788m -XX:MaxPermSize=256m
-Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.dgc.server.gcInterval=3600000
-javaagent:${BYTEMAN_JAR}=prop:org.jboss.byteman.verbose=true,address:${MYTESTIP_3},port:9291
-Djboss.modules.system.pkgs=org.jboss.byteman -Xbootclasspath/a:${BYTEMAN_JAR}:${BYTEMAN_SUBMIT_JAR}
-Djboss.bind.address=${MYTESTIP_3}
-Djboss.bind.address.management=${MYTESTIP_3}
-Djboss.bind.address.unsecure=${MYTESTIP_3}
-Djboss.messaging.group.address=${MCAST_ADDR}
-Djboss.default.multicast.address=${MCAST_ADDR} -XX:+HeapDumpOnOutOfMemoryError
-Djava.net.preferIPv4Stack=false
</property> <!-- -Xrunjdwp:transport=dt_socket,address=mnovak-laptop1:8586,server=y,suspend=n-->
<property name="serverConfig">standalone-full-ha.xml</property>
<property name="startupTimeoutInSeconds">60</property>
<property name="managementAddress" >${MYTESTIP_3}</property>
<property name="username">admin</property>
<property name="password">minono532/20</property>
</configuration>
</container>
<container qualifier="node-4" default="false" mode="manual">
<configuration>
<property name="jbossHome">${JBOSS_HOME_4}</property>
<property name="javaVmArguments">-Xms64m -Xmx788m -XX:MaxPermSize=256m
-Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.dgc.server.gcInterval=3600000
-javaagent:${BYTEMAN_JAR}=prop:org.jboss.byteman.verbose=true,address:${MYTESTIP_4},port:9391
-Djboss.modules.system.pkgs=org.jboss.byteman -Xbootclasspath/a:${BYTEMAN_JAR}:${BYTEMAN_SUBMIT_JAR}
-Djboss.bind.address=${MYTESTIP_4}
-Djboss.bind.address.management=${MYTESTIP_4}
-Djboss.bind.address.unsecure=${MYTESTIP_4}
-Djboss.messaging.group.address=${MCAST_ADDR}
-Djboss.default.multicast.address=${MCAST_ADDR} -XX:+HeapDumpOnOutOfMemoryError
-Djava.net.preferIPv4Stack=false
</property> <!-- -Xrunjdwp:transport=dt_socket,address=mnovak-laptop1:8586,server=y,suspend=n-->
<property name="serverConfig">standalone-full-ha.xml</property>
<property name="startupTimeoutInSeconds">60</property>
<property name="managementAddress" >${MYTESTIP_4}</property>
<property name="username">admin</property>
<property name="password">minono532/20</property>
</configuration>
</container>
</group>
</arquillian>
{code}
I'll provide a reproducer.
> LoginContext cannot load login modules in certain scenarios when EAP server is started by Arquillian
> -----------------------------------------------------------------------------------------------------
>
> Key: ARQ-1820
> URL: https://issues.jboss.org/browse/ARQ-1820
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Miroslav Novak
>
> There is problem with classloading when EAP 6.3.0.ER9 server is started by Arquillian. Problem was hit in following test scenario:
> - Start two EAP 6.3.0.ER9 servers
> - HornetQ is configured in collocated HA topology with shared store (EAP servers contains HornetQ backup for each other - so there are 2 live/backup pairs)
> - Start producer which sends messages to "jms/queue/testQueue0" to first EAP server
> - Start consumer which receives messages from "jms/queue/testQueue0" to first EAP server
> - Kill -9 "first EAP server"
> - Producer and consumer failovers to backup
> Problem:
> When producer and consumer failovers to backup then it fails with:
> {code}
> 13:58:40,146 Thread-2 (HornetQ-client-global-threads-2060674296) ERROR [org.hornetq.core.client.impl.ClientSessionImpl:1198] HQ214003: Failed to handle failover
> HornetQException[errorType=SECURITY_EXCEPTION message=HQ119031: Unable to validate user: null]
> at org.hornetq.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:394)
> at org.hornetq.core.client.impl.ClientSessionImpl.handleFailover(ClientSessionImpl.java:1087)
> at org.hornetq.core.client.impl.ClientSessionFactoryImpl.reconnectSessions(ClientSessionFactoryImpl.java:1075)
> at org.hornetq.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:717)
> at org.hornetq.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:587)
> at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionException(ClientSessionFactoryImpl.java:441)
> at org.hornetq.core.remoting.impl.netty.NettyConnector$Listener$2.run(NettyConnector.java:924)
> at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:105)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> {code}
> Second EAP server logs:
> {code}
> 13:58:40,144 ERROR [org.hornetq.core.server] (Old I/O server worker (parentId: 223510377, [id: 0x0d527f69, /192.168.40.2:5446])) HQ224018: Failed to create session: HornetQException[errorType=SECURITY_EXCEPTION message=HQ119031: Unable to validate user: null]
> at org.hornetq.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:146) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1]
> at org.hornetq.core.server.impl.HornetQServerImpl.createSession(HornetQServerImpl.java:979) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1]
> at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handleCreateSession(HornetQPacketHandler.java:150) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1]
> at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handlePacket(HornetQPacketHandler.java:78) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1]
> at org.hornetq.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:636) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1]
> at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:547) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1]
> at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:523) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1]
> at org.hornetq.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:564) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1]
> at org.hornetq.core.remoting.impl.netty.HornetQChannelHandler.messageReceived(HornetQChannelHandler.java:72) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1]
> at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:281) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1]
> at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.decode(HornetQFrameDecoder2.java:169) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1]
> at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.messageReceived(HornetQFrameDecoder2.java:134) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1]
> at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1]
> at org.jboss.netty.channel.socket.oio.OioWorker.process(OioWorker.java:71) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1]
> at org.jboss.netty.channel.socket.oio.AbstractOioWorker.run(AbstractOioWorker.java:73) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1]
> at org.jboss.netty.channel.socket.oio.OioWorker.run(OioWorker.java:51) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1]
> at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1]
> at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1]
> at org.jboss.netty.util.VirtualExecutorService$ChildExecutorRunnable.run(VirtualExecutorService.java:175) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15]
> {code}
> It failed because it was not authenticated on second EAP server. When debugging the problem I figured that root cause for this failure is that
> javax.security.auth.login.LoginContext.invoke(String methodName):746 is using reflection to load class - org.jboss.as.security.RealmDirectLoginModule which was not found in provided classloader:
> {code}Class c = Class.forName(moduleStack[i].entry.getLoginModuleName(), true, contextClassLoader);{code}
> When I try the same test scenario manually then producer and consumer failovers without problem (=authenticates). Is there a way how EAP 6 classloader can be influenced by Arquillian?
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (ARQ-1820) LoginContext cannot load login modules in certain scenarios when EAP server is started by Arquillian
by Aslak Knutsen (JIRA)
[ https://issues.jboss.org/browse/ARQ-1820?page=com.atlassian.jira.plugin.s... ]
Aslak Knutsen commented on ARQ-1820:
------------------------------------
You're running a in-container test using the AS7-JMX Protocol here?
> LoginContext cannot load login modules in certain scenarios when EAP server is started by Arquillian
> -----------------------------------------------------------------------------------------------------
>
> Key: ARQ-1820
> URL: https://issues.jboss.org/browse/ARQ-1820
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Miroslav Novak
>
> There is problem with classloading when EAP 6.3.0.ER9 server is started by Arquillian. Problem was hit in following test scenario:
> - Start two EAP 6.3.0.ER9 servers
> - HornetQ is configured in collocated HA topology with shared store (EAP servers contains HornetQ backup for each other - so there are 2 live/backup pairs)
> - Start producer which sends messages to "jms/queue/testQueue0" to first EAP server
> - Start consumer which receives messages from "jms/queue/testQueue0" to first EAP server
> - Kill -9 "first EAP server"
> - Producer and consumer failovers to backup
> Problem:
> When producer and consumer failovers to backup then it fails with:
> {code}
> 13:58:40,146 Thread-2 (HornetQ-client-global-threads-2060674296) ERROR [org.hornetq.core.client.impl.ClientSessionImpl:1198] HQ214003: Failed to handle failover
> HornetQException[errorType=SECURITY_EXCEPTION message=HQ119031: Unable to validate user: null]
> at org.hornetq.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:394)
> at org.hornetq.core.client.impl.ClientSessionImpl.handleFailover(ClientSessionImpl.java:1087)
> at org.hornetq.core.client.impl.ClientSessionFactoryImpl.reconnectSessions(ClientSessionFactoryImpl.java:1075)
> at org.hornetq.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:717)
> at org.hornetq.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:587)
> at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionException(ClientSessionFactoryImpl.java:441)
> at org.hornetq.core.remoting.impl.netty.NettyConnector$Listener$2.run(NettyConnector.java:924)
> at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:105)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> {code}
> Second EAP server logs:
> {code}
> 13:58:40,144 ERROR [org.hornetq.core.server] (Old I/O server worker (parentId: 223510377, [id: 0x0d527f69, /192.168.40.2:5446])) HQ224018: Failed to create session: HornetQException[errorType=SECURITY_EXCEPTION message=HQ119031: Unable to validate user: null]
> at org.hornetq.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:146) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1]
> at org.hornetq.core.server.impl.HornetQServerImpl.createSession(HornetQServerImpl.java:979) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1]
> at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handleCreateSession(HornetQPacketHandler.java:150) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1]
> at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handlePacket(HornetQPacketHandler.java:78) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1]
> at org.hornetq.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:636) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1]
> at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:547) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1]
> at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:523) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1]
> at org.hornetq.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:564) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1]
> at org.hornetq.core.remoting.impl.netty.HornetQChannelHandler.messageReceived(HornetQChannelHandler.java:72) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1]
> at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:281) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1]
> at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.decode(HornetQFrameDecoder2.java:169) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1]
> at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.messageReceived(HornetQFrameDecoder2.java:134) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1]
> at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1]
> at org.jboss.netty.channel.socket.oio.OioWorker.process(OioWorker.java:71) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1]
> at org.jboss.netty.channel.socket.oio.AbstractOioWorker.run(AbstractOioWorker.java:73) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1]
> at org.jboss.netty.channel.socket.oio.OioWorker.run(OioWorker.java:51) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1]
> at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1]
> at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1]
> at org.jboss.netty.util.VirtualExecutorService$ChildExecutorRunnable.run(VirtualExecutorService.java:175) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15]
> {code}
> It failed because it was not authenticated on second EAP server. When debugging the problem I figured that root cause for this failure is that
> javax.security.auth.login.LoginContext.invoke(String methodName):746 is using reflection to load class - org.jboss.as.security.RealmDirectLoginModule which was not found in provided classloader:
> {code}Class c = Class.forName(moduleStack[i].entry.getLoginModuleName(), true, contextClassLoader);{code}
> When I try the same test scenario manually then producer and consumer failovers without problem (=authenticates). Is there a way how EAP 6 classloader can be influenced by Arquillian?
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (ARQ-1821) equinox container does not install bundles specified in framework properties
by Raymond Auge (JIRA)
[ https://issues.jboss.org/browse/ARQ-1821?page=com.atlassian.jira.plugin.s... ]
Raymond Auge edited comment on ARQ-1821 at 7/17/14 5:03 PM:
------------------------------------------------------------
This may be partially due to the fact that arquillian is using an ancient equinox dependency and so perhaps the integration tests are all good because if this.
The pom for arquillian-container-equinox defines a dependency on:
{code}
<dependency>
<groupId>org.eclipse.osgi</groupId>
<artifactId>org.eclipse.osgi</artifactId>
</dependency>
{code}
the newest version of this artifact is 3.7.1, which is ancient in terms of equinox.
I recommend changing the dependency to this maven group:
{code}
<dependency>
<groupId>org.eclipse.tycho</groupId>
<artifactId>org.eclipse.osgi</artifactId>
</dependency>
{code}
However, this will cause the issue to come to light and then there might need either
* helper code to read properties to start the dependent bundles directly
* a small framework extension bundle which adds the auto start functionality
was (Author: rotty):
This may be partially due to the fact that arquillian is using an ancient equinox dependency and so perhaps the integration tests are all good because if this.
The pom for arquillian-container-equinox defines a dependency on:
{code}
<dependency>
<groupId>org.eclipse.osgi</groupId>
<artifactId>org.eclipse.osgi</artifactId>
</dependency>
{code}
the newest version of this artifact is 3.7.1, which is ancient in terms of equinox.
I recommend changing the dependency to this maven group:
{code}
<dependency>
<groupId>org.eclipse.tycho</groupId>
<artifactId>org.eclipse.osgi</artifactId>
</dependency>
{code}
However, this will cause the issue to come to light and then there might be either a helper code required since this module will not support any auto starting of bundles. Or perhaps a small framework extension bundle can be created which adds the functionality something like felix's framework + main bundles.
> equinox container does not install bundles specified in framework properties
> ----------------------------------------------------------------------------
>
> Key: ARQ-1821
> URL: https://issues.jboss.org/browse/ARQ-1821
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: OSGi Containers
> Environment: arquillian-container-equinox-embedded 2.1.0.CR15
> arquillian-junit-container 1.1.2.Final
> org.eclipse.osgi 3.9.1.v20130814-1242
> Reporter: Raymond Auge
> Assignee: Thomas Diesler
> Priority: Blocker
>
> The container assumes that equinox will start bundles passed in the framework properties as 'osgi.bundles'.
> However this loading feature is not available in equinox when using the osgi Framework API, but only when using the proprietary EclipseStarter class.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (ARQ-1821) equinox container does not install bundles specified in framework properties
by Raymond Auge (JIRA)
[ https://issues.jboss.org/browse/ARQ-1821?page=com.atlassian.jira.plugin.s... ]
Raymond Auge updated ARQ-1821:
------------------------------
Steps to Reproduce:
Configure the framework properties with some required bundles passed via {{osgi.bundles}} property.
Configure the test container using {{arquillian-container-equinox-embedded}}.
*Note* the required bundles are never installed.
*Note* must use a recent version of equinox.
was:
Configure the framework properties with some required bundles passed via {{osgi.bundles}} property.
Configure the test container using {{arquillian-container-equinox-embedded}}.
Note the required bundles are never installed.
> equinox container does not install bundles specified in framework properties
> ----------------------------------------------------------------------------
>
> Key: ARQ-1821
> URL: https://issues.jboss.org/browse/ARQ-1821
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: OSGi Containers
> Environment: arquillian-container-equinox-embedded 2.1.0.CR15
> arquillian-junit-container 1.1.2.Final
> org.eclipse.osgi 3.9.1.v20130814-1242
> Reporter: Raymond Auge
> Assignee: Thomas Diesler
> Priority: Blocker
>
> The container assumes that equinox will start bundles passed in the framework properties as 'osgi.bundles'.
> However this loading feature is not available in equinox when using the osgi Framework API, but only when using the proprietary EclipseStarter class.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (ARQ-1821) equinox container does not install bundles specified in framework properties
by Raymond Auge (JIRA)
[ https://issues.jboss.org/browse/ARQ-1821?page=com.atlassian.jira.plugin.s... ]
Raymond Auge commented on ARQ-1821:
-----------------------------------
This may be partially due to the fact that arquillian is using an ancient equinox dependency and so perhaps the integration tests are all good because if this.
The pom for arquillian-container-equinox defines a dependency on:
{code}
<dependency>
<groupId>org.eclipse.osgi</groupId>
<artifactId>org.eclipse.osgi</artifactId>
</dependency>
{code}
the newest version of this artifact is 3.7.1, which is ancient in terms of equinox.
I recommend changing the dependency to this maven group:
{code}
<dependency>
<groupId>org.eclipse.tycho</groupId>
<artifactId>org.eclipse.osgi</artifactId>
</dependency>
{code}
However, this will cause the issue to come to light and then there might be either a helper code required since this module will not support any auto starting of bundles. Or perhaps a small framework extension bundle can be created which adds the functionality something like felix's framework + main bundles.
> equinox container does not install bundles specified in framework properties
> ----------------------------------------------------------------------------
>
> Key: ARQ-1821
> URL: https://issues.jboss.org/browse/ARQ-1821
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: OSGi Containers
> Environment: arquillian-container-equinox-embedded 2.1.0.CR15
> arquillian-junit-container 1.1.2.Final
> org.eclipse.osgi 3.9.1.v20130814-1242
> Reporter: Raymond Auge
> Assignee: Thomas Diesler
> Priority: Blocker
>
> The container assumes that equinox will start bundles passed in the framework properties as 'osgi.bundles'.
> However this loading feature is not available in equinox when using the osgi Framework API, but only when using the proprietary EclipseStarter class.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months