[JBoss JIRA] (WFLY-16) Intermittent failure in RemoteOutboundConnectionReconnectTestCase
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-16?page=com.atlassian.jira.plugin.sy... ]
Stuart Douglas updated WFLY-16:
-------------------------------
Assignee: Stuart Douglas (was: jaikiran pai)
> Intermittent failure in RemoteOutboundConnectionReconnectTestCase
> -----------------------------------------------------------------
>
> Key: WFLY-16
> URL: https://issues.jboss.org/browse/WFLY-16
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Reporter: Kabir Khan
> Assignee: Stuart Douglas
> Priority: Critical
> Fix For: 8.0.0.CR1
>
>
> Assigning to Jaikiran since I think this is ejb client
> This happened for IPv6 but I don't know if that has any relevance.
> The test has not been disabled
> {code}
> org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteOutboundConnectionReconnectTestCase.testRemoteServerRestarts
> Failing for the past 1 build (Since #3674 )
> Took 8.7 sec.
> add description
> Error Message
> Cannot deploy: server-two-module.jar
> Stacktrace
> org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: server-two-module.jar
> at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:83)
> at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64)
> at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46)
> at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:145)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
> at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.client.deployment.ClientDeployer.deploy(ClientDeployer.java:93)
> at org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteOutboundConnectionReconnectTestCase.testRemoteServerRestarts(RemoteOutboundConnectionReconnectTestCase.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
> at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
> at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
> at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> Caused by: java.lang.Exception: {"JBAS014771: Services with missing/unavailable dependencies" => [
> "jboss.naming.context.java.app.server-two-module.server-two-module.EchoOnServerTwo Missing[JBAS014861: <one or more transitive dependencies>]",
> "jboss.naming.context.java.global.server-two-module.\"EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\" Missing[JBAS014861: <one or more transitive dependencies>]",
> "jboss.deployment.unit.\"server-two-module.jar\".component.EchoOnServerTwo.VIEW.\"org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\".REMOTE Missing[JBAS014861: <one or more transitive dependencies>]",
> "jboss.deployment.unit.\"server-two-module.jar\".deploymentCompleteService Missing[JBAS014861: <one or more transitive dependencies>]",
> "jboss.naming.context.java.module.server-two-module.server-two-module.\"EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\" Missing[JBAS014861: <one or more transitive dependencies>]",
> "jboss.deployment.unit.\"server-two-module.jar\".component.EchoOnServerTwo.START Missing[JBAS014861: <one or more transitive dependencies>]",
> "jboss.deployment.unit.\"server-two-module.jar\".moduleDeploymentRuntimeInformation Missing[JBAS014861: <one or more transitive dependencies>]",
> "jboss.naming.context.java.module.server-two-module.server-two-module.EchoOnServerTwo Missing[JBAS014861: <one or more transitive dependencies>]",
> "jboss.naming.context.java.app.server-two-module.server-two-module.\"EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\" Missing[JBAS014861: <one or more transitive dependencies>]",
> "jboss.deployment.unit.\"server-two-module.jar\".jndiDependencyService Missing[JBAS014861: <one or more transitive dependencies>]",
> "jboss.naming.context.java.global.server-two-module.EchoOnServerTwo Missing[JBAS014861: <one or more transitive dependencies>]"
> ]}
> at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134)
> at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123)
> at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85)
> at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42)
> at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:52)
> at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77)
> ... 123 more
> Standard Output
> 02:31:11,030 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance
> 02:31:11,053 INFO [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/opt/jdk1.6.0_29/bin/java, -Xmx512m, -XX:MaxPermSize=256m, -Djboss.dist=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT, -Djava.net.preferIPv4Stack=false, -Djava.net.preferIPv6Addresses=true, -Dts.timeout.factor=100, -Dnode0=::1, -Dnode1=fccc::2, -Dmcast=ff01::1, -Djbossas.ts.submodule.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode, -Djbossas.ts.integ.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/.., -Djbossas.ts.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/../.., -Djbossas.project.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/../../.., -Djboss.dist=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT, -Djboss.inst=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/jbossas, -Djboss.node.name=default-jbossas, -ea, -Djboss.home.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/jbossas, -Dorg.jboss.boot.log.file=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/jbossas/standalone/log/boot.log, -Dlogging.configuration=file:/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/jbossas/standalone/configuration/logging.properties, -Djboss.bundles.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/bundles, -jar, /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/jbossas/jboss-modules.jar, -mp, /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/modules:/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/modules, -jaxpmodule, javax.xml.jaxp-provider, org.jboss.as.standalone, -server-config, standalone-ha.xml]
> 02:31:11,906 INFO [org.jboss.modules] JBoss Modules version 1.1.3.GA
> 02:31:12,166 INFO [org.jboss.msc] JBoss MSC version 1.0.2.GA
> 02:31:12,257 INFO [org.jboss.as] JBAS015899: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" starting
> 02:31:14,791 INFO [org.jboss.as.server] JBAS015888: Creating http management service using socket-binding (management-http)
> 02:31:14,798 INFO [org.xnio] XNIO Version 3.0.5.GA
> 02:31:14,827 INFO [org.xnio.nio] XNIO NIO Implementation Version 3.0.5.GA
> 02:31:14,848 INFO [org.jboss.as.configadmin] JBAS016200: Activating ConfigAdmin Subsystem
> 02:31:14,849 INFO [org.jboss.as.logging] JBAS011502: Removing bootstrap log handlers
> [0m02:31:14,889 INFO [org.jboss.remoting] (MSC service thread 1-3) JBoss Remoting version 3.2.8.GA
> [0m[0m02:31:14,916 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 34) JBAS010280: Activating Infinispan subsystem.
> [0m[0m02:31:14,979 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 38) JBAS010260: Activating JGroups subsystem.
> [0m[0m02:31:14,991 INFO [org.jboss.as.osgi] (ServerService Thread Pool -- 45) JBAS011906: Activating OSGi Subsystem
> [0m[0m02:31:15,009 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 44) JBAS011800: Activating Naming Subsystem
> [0m[0m02:31:15,015 INFO [org.jboss.as.security] (ServerService Thread Pool -- 50) JBAS013171: Activating Security Subsystem
> [0m[0m02:31:15,047 INFO [org.jboss.as.security] (MSC service thread 1-1) JBAS013170: Current PicketBox version=4.0.13.Final
> [0m[0m02:31:15,161 INFO [org.jboss.as.connector.logging] (MSC service thread 1-6) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.12.Final)
> [0m[0m02:31:15,164 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 54) JBAS015537: Activating WebServices Extension
> [0m[0m02:31:15,332 INFO [org.jboss.as.naming] (MSC service thread 1-2) JBAS011802: Starting Naming Service
> [0m[0m02:31:15,371 INFO [org.jboss.as.mail.extension] (MSC service thread 1-6) JBAS015400: Bound mail session [java:jboss/mail/Default]
> [0m[31m02:31:15,331 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC00001: Failed to start service jboss.remoting.endpoint.subsystem: org.jboss.msc.service.StartException in service jboss.remoting.endpoint.subsystem: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: java.lang.NullPointerException
> at sun.nio.ch.Util.atBugLevel(Util.java:448) [rt.jar:1.6.0_29]
> at sun.nio.ch.SelectorImpl.<init>(SelectorImpl.java:40) [rt.jar:1.6.0_29]
> at sun.nio.ch.EPollSelectorImpl.<init>(EPollSelectorImpl.java:47) [rt.jar:1.6.0_29]
> at sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:18) [rt.jar:1.6.0_29]
> at java.nio.channels.Selector.open(Selector.java:209) [rt.jar:1.6.0_29]
> at org.xnio.nio.NioXnioWorker.<init>(NioXnioWorker.java:112)
> at org.xnio.nio.NioXnio.createWorker(NioXnio.java:126)
> at org.jboss.remoting3.EndpointImpl.construct(EndpointImpl.java:137)
> at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:60)
> at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:73)
> at org.jboss.as.remoting.EndpointService.start(EndpointService.java:71)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> ... 3 more
> [0m[0m02:31:15,747 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 30) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> [0m[0m02:31:16,070 INFO [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-3) JBoss Web Services - Stack CXF Server 4.1.0.Beta2
> [0m[0m02:31:16,117 INFO [org.apache.coyote.ajp.AjpProtocol] (MSC service thread 1-4) Starting Coyote AJP/1.3 on ajp-/0:0:0:0:0:0:0:1%1:8009
> [0m[0m02:31:16,117 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-5) Starting Coyote HTTP/1.1 on http-/0:0:0:0:0:0:0:1%1:8080
> [0m[0m02:31:16,357 INFO [org.jboss.modcluster.ModClusterService] (ServerService Thread Pool -- 56) Initializing mod_cluster 1.2.1.Final
> [0m[0m02:31:16,437 INFO [org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl] (ServerService Thread Pool -- 56) Listening to proxy advertisements on ff01:0:0:0:0:0:0:3:23,364
> [0m[0m02:31:16,718 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 34) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [0m[0m02:31:16,742 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 34) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [0m[0m02:31:16,908 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-3) JBAS015012: Started FileSystemDeploymentService for directory /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/jbossas/standalone/deployments
> [0m[0m02:31:16,927 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "dep1.jar"
> [0m[0m02:31:16,960 INFO [org.jboss.as.remoting] (MSC service thread 1-6) JBAS017100: Listening on [::1]:9999
> [0m[0m02:31:16,977 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> [0m[0m02:31:17,615 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named ShutdownBean in deployment unit deployment "dep1.jar" are as follows:
> java:global/dep1/ShutdownBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
> java:app/dep1/ShutdownBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
> java:module/ShutdownBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
> java:jboss/exported/dep1/ShutdownBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
> java:global/dep1/ShutdownBean
> java:app/dep1/ShutdownBean
> java:module/ShutdownBean
> [0m[0m02:31:17,617 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named LatchBean in deployment unit deployment "dep1.jar" are as follows:
> java:global/dep1/LatchBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteLatch
> java:app/dep1/LatchBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteLatch
> java:module/LatchBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteLatch
> java:jboss/exported/dep1/LatchBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteLatch
> java:global/dep1/LatchBean
> java:app/dep1/LatchBean
> java:module/LatchBean
> [0m[0m02:31:17,619 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named RealEcho in deployment unit deployment "dep1.jar" are as follows:
> java:global/dep1/RealEcho!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
> java:app/dep1/RealEcho!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
> java:module/RealEcho!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
> java:jboss/exported/dep1/RealEcho!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
> java:global/dep1/RealEcho
> java:app/dep1/RealEcho
> java:module/RealEcho
> [0m[0m02:31:18,940 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS018559: Deployed "dep1.jar"
> [0m[0m02:31:18,951 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014777: Services which failed to start: service jboss.remoting.endpoint.subsystem: org.jboss.msc.service.StartException in service jboss.remoting.endpoint.subsystem: Failed to start service
> [0m[0m02:31:18,992 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://::1:9990/management
> [0m[0m02:31:18,994 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://::1:9990
> [0m[31m02:31:18,996 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" started (with errors) in 7657ms - Started 185 of 364 services (34 services failed or missing dependencies, 144 services are passive or on-demand)
> [0m[0m02:31:19,141 INFO [org.jboss.as.repository] (management-handler-thread - 1) JBAS014900: Content added at location /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/jbossas/standalone/data/content/34/cf5c1cb3656c84a2615763b9f95b3a16536c40/content
> [0m[0m02:31:19,164 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "server-two-module.jar"
> [0m[0m02:31:19,227 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-1) JNDI bindings for session bean named EchoOnServerTwo in deployment unit deployment "server-two-module.jar" are as follows:
> java:global/server-two-module/EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho
> java:app/server-two-module/EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho
> java:module/EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho
> java:jboss/exported/server-two-module/EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho
> java:global/server-two-module/EchoOnServerTwo
> java:app/server-two-module/EchoOnServerTwo
> java:module/EchoOnServerTwo
> [0m[0m02:31:19,578 INFO [org.jboss.as.server] (management-handler-thread - 1) JBAS015870: Deploy of deployment "server-two-module.jar" was rolled back with failure message {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.app.server-two-module.server-two-module.EchoOnServerTwo Missing[JBAS014861: <one or more transitive dependencies>]","jboss.naming.context.java.global.server-two-module.\"EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\" Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"server-two-module.jar\".component.EchoOnServerTwo.VIEW.\"org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\".REMOTE Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"server-two-module.jar\".deploymentCompleteService Missing[JBAS014861: <one or more transitive dependencies>]","jboss.naming.context.java.module.server-two-module.server-two-module.\"EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\" Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"server-two-module.jar\".component.EchoOnServerTwo.START Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"server-two-module.jar\".moduleDeploymentRuntimeInformation Missing[JBAS014861: <one or more transitive dependencies>]","jboss.naming.context.java.module.server-two-module.server-two-module.EchoOnServerTwo Missing[JBAS014861: <one or more transitive dependencies>]","jboss.naming.context.java.app.server-two-module.server-two-module.\"EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\" Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"server-two-module.jar\".jndiDependencyService Missing[JBAS014861: <one or more transitive dependencies>]","jboss.naming.context.java.global.server-two-module.EchoOnServerTwo Missing[JBAS014861: <one or more transitive dependencies>]"]}
> [0m[0m02:31:19,652 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment server-two-module.jar in 97ms
> [0m
> Help us localize this page Page generated: Aug 31, 2012 7:20:23 AMJenkins ver. 1.473
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 12 months
[JBoss JIRA] (WFLY-875) Singletons don't respect @TransactionAttribute/deployment descriptor in @PostConstruct.
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-875?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas updated WFLY-875:
--------------------------------
Assignee: Stuart Douglas (was: jaikiran pai)
> Singletons don't respect @TransactionAttribute/deployment descriptor in @PostConstruct.
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-875
> URL: https://issues.jboss.org/browse/WFLY-875
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Environment: JBoss 7.1.1
> Reporter: Sławomir Wojtasiak
> Assignee: Stuart Douglas
> Labels: rhq
> Attachments: jboss-as-helloworld-singleton.war
>
>
> Singletons don't respect any transaction attributes for their @PostConstruct methods and invokes them always with REQUIRED_NEW semantics. Following part of code is responsible for hardcoding these values for registered _SingletonLifecycleCMTTxInterceptor_ factories:
> {code:title=org.jboss.as.ejb3.component.singleton.SingletonComponentDescription.java|borderStyle=solid}
> @Override
> public void configure(final DeploymentPhaseContext context, final ComponentDescription description, final ComponentConfiguration configuration) throws DeploymentUnitProcessingException {
> configuration.addPostConstructInterceptor(new SingletonLifecycleCMTTxInterceptor.Factory(TransactionAttributeType.REQUIRES_NEW), InterceptorOrder.ComponentPostConstruct.TRANSACTION_INTERCEPTOR);
> configuration.addPreDestroyInterceptor(new SingletonLifecycleCMTTxInterceptor.Factory(TransactionAttributeType.REQUIRES_NEW), InterceptorOrder.ComponentPreDestroy.TRANSACTION_INTERCEPTOR);
> if(description.isPassivationApplicable()) {
> configuration.addPrePassivateInterceptor(new SingletonLifecycleCMTTxInterceptor.Factory(TransactionAttributeType.REQUIRES_NEW), InterceptorOrder.ComponentPassivation.TRANSACTION_INTERCEPTOR);
> configuration.addPostActivateInterceptor(new SingletonLifecycleCMTTxInterceptor.Factory(TransactionAttributeType.REQUIRES_NEW), InterceptorOrder.ComponentPassivation.TRANSACTION_INTERCEPTOR);
> }
> configuration.addTimeoutViewInterceptor(TimerCMTTxInterceptor.FACTORY, InterceptorOrder.View.CMT_TRANSACTION_INTERCEPTOR);
> }
> {code}
> EJB 3.1 specification says, REQUIRED, REQUIRED_NEW and NOT_SUPPORTED attributes should be supported, where in case of REQUIRED a semantic of REQUIRED_NEW trancation attribute should be used:
> {panel:title=4.8.3 Transaction Semantics of Initialization and Destruction| borderStyle=dashed| borderColor=#ccc| titleBGColor=#F7D6C1| bgColor=#FFFFCE}
> PostConstruct and PreDestroy methods of Singletons with container-managed transactions are transactional. From the bean developer’s view there is no client of a PostConstruct or PreDestroy method.
> A PostConstruct or PreDestroy method of a Singleton with container-managed transactions has transaction attribute REQUIRED, REQUIRES_NEW, or NOT_SUPPORTED (Required , RequiresNew, or NotSupported if the deployment descriptor is used to specify the transaction attribute).
> _Note that the container must start a new transaction if the REQUIRED (Required) transaction attribute is used. This guarantees, for example, that the transactional behavior of the PostConstruct method is the same regardless of whether it is initialized eagerly at container startup time or as a side effect of a first client invocation on the Singleton. The REQUIRED transaction attribute value is allowed so that specification of a transaction attribute for the Singleton PostConstruct/PreDestroy methods can be defaulted._
> {panel}
> So there is not a problem with REQUIRED and REQUIRED_NEW transaction attributes, but NOT_SUPPORTED attribute is just not supported :)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 12 months
[JBoss JIRA] (WFLY-1383) Disable pooling of stateless EJBs by default
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1383?page=com.atlassian.jira.plugin.... ]
Stuart Douglas updated WFLY-1383:
---------------------------------
Assignee: Stuart Douglas (was: jaikiran pai)
> Disable pooling of stateless EJBs by default
> --------------------------------------------
>
> Key: WFLY-1383
> URL: https://issues.jboss.org/browse/WFLY-1383
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Alpha1
> Reporter: jaikiran pai
> Assignee: Stuart Douglas
>
> A certain use case has shown that it's perhaps better to disable pooling of EJB stateless bean, by default. In AS7 we have always allowed disabling the pooling but we hadn't made it the default since we thought it might affect applications which have SLSBs with heavy @PostConstruct.
> A recent discussion has suggested that we disable the pooling by default and individual applications can enable it and set the relevant pool size themselves. The reasoning has been that, the default pool size that we ship with, anyway will have to be tweaked by the users since we can't really guess what an ideal pool size is.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 12 months
[JBoss JIRA] (WFLY-1183) Configure EJB3/MDB with an individual thread pool for each EJB.
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1183?page=com.atlassian.jira.plugin.... ]
Stuart Douglas updated WFLY-1183:
---------------------------------
Assignee: Stuart Douglas (was: jaikiran pai)
> Configure EJB3/MDB with an individual thread pool for each EJB.
> ---------------------------------------------------------------
>
> Key: WFLY-1183
> URL: https://issues.jboss.org/browse/WFLY-1183
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: EJB
> Reporter: Jeremy Whiting
> Assignee: Stuart Douglas
>
> For performance of an application to be scalable I need to configure sometimes a thread pool to an EJB. The pool is not shared with other EJB in the deployed application.
> For example
> PoolA - EJB Dog
> PoolB - EJB Cat
> To configure this the ability no define the thread pool name for an EJB. Rather than an EJB to the shared thread pool as it currently works.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 12 months
[JBoss JIRA] (WFLY-2161) JBAS014356 exception not thrown for @Asyncronous EJB methods
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2161?page=com.atlassian.jira.plugin.... ]
Stuart Douglas updated WFLY-2161:
---------------------------------
Assignee: Stuart Douglas (was: jaikiran pai)
> JBAS014356 exception not thrown for @Asyncronous EJB methods
> ------------------------------------------------------------
>
> Key: WFLY-2161
> URL: https://issues.jboss.org/browse/WFLY-2161
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Alpha4
> Reporter: James Livingston
> Assignee: Stuart Douglas
>
> If you call an ejb method with default visibility (e.g. from a servlet in the same package), an EJBException with code JBAS014356 is thrown because the method is not public.
> If the method is annotated with @Asynchronous and returns void, the exception is not seen because the interceptor from AsyncFutureInterceptorFactory is used before NotBusinessMethodInterceptor, the exception is thrown in the worker thread instead.
> With a void return, the exception is silently dropped. With a Future<?> return, it will be set as the failure exception on the future rather than being thrown from the call.
> As per the forum reference we need to check the spec, but the validity of the business method should probably be checked before the handoff to the worker thread.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 12 months
[JBoss JIRA] (WFLY-1716) NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache deploying ear with war inside
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1716?page=com.atlassian.jira.plugin.... ]
Stuart Douglas updated WFLY-1716:
---------------------------------
Assignee: Stuart Douglas (was: jaikiran pai)
> NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache deploying ear with war inside
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-1716
> URL: https://issues.jboss.org/browse/WFLY-1716
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EE
> Affects Versions: 8.0.0.Alpha3
> Environment: Win 7, JEE 6, JDK 7
> Reporter: Oliver Pfau
> Assignee: Stuart Douglas
> Labels: Deploy, classnotfound, war
>
> I tried to deploy my ear which works in JBoss 7 in wildfly and got the following error on deploy:
> 09:59:55,060 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.subunit."my.ear"."mywar.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."my.ear"."mywar.war".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment "mywar.war" of deployment "my.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Alpha3.jar:8.0.0.Alpha3]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache
> at org.wildfly.extension.undertow.deployment.ELExpressionFactoryProcessor.deploy(ELExpressionFactoryProcessor.java:78)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Alpha3.jar:8.0.0.Alpha3]
> ... 5 more
> 09:59:55,100 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "my.ear")]) - failure description: {
> "JBAS014671: Failed services" => {"jboss.deployment.subunit.\"my.ear\".\"mywar.war\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"my.ear\".\"mywar.war\".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment \"mywar.war\" of deployment \"my.ear\"
> Caused by: java.lang.NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache"},
> "JBAS014771: Services with missing/unavailable dependencies" => [
> "jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName.ValidatorFactory is missing [jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName]",
> "jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName.InstanceName is missing [jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName]",
> "jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName.Validator is missing [jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName]",
>
> <all other services>
> ]
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 12 months
[JBoss JIRA] (WFLY-1928) jboss-as-standalone.sh does not work on MacOS
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1928?page=com.atlassian.jira.plugin.... ]
Stuart Douglas updated WFLY-1928:
---------------------------------
Assignee: Stuart Douglas (was: jaikiran pai)
> jboss-as-standalone.sh does not work on MacOS
> ---------------------------------------------
>
> Key: WFLY-1928
> URL: https://issues.jboss.org/browse/WFLY-1928
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Scripts
> Affects Versions: 8.0.0.Alpha4
> Reporter: Thomas Diesler
> Assignee: Stuart Douglas
> Fix For: 8.0.0.CR1
>
>
> {code}
> FuseFabric:karaf@root> process-start root 3
> bin/init.d/jboss-as-standalone.sh: line 12: /etc/init.d/functions: No such file or directory
> Error executing command: [bin/init.d/jboss-as-standalone.sh, start] exited with 1
> bin/init.d/jboss-as-standalone.sh: line 12: /etc/init.d/functions: No such file or directory
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 12 months
[JBoss JIRA] (WFLY-959) Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-959?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas updated WFLY-959:
--------------------------------
Assignee: Stuart Douglas (was: jaikiran pai)
> Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-959
> URL: https://issues.jboss.org/browse/WFLY-959
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Reporter: Derek Horton
> Assignee: Stuart Douglas
>
> My confusion is around the remoting/security-realm setup in the use case
> where multiple EJBs are deployed that use different security-domains and
> the EJBs will be invoked by remote standalone clients. For example,
> ejbX needs to be in the sec-domain-X security-domain, while ejbY needs to
> be in the sec-domain-Y security-domain.
> In this situation, the authentication checks are going to be handled by
> the security-realm that is associated with the remote connector that is
> configured to be used by the EJB subsystem.
> It looks like the security-realm can either handle the authentication
> checks directly (properties file, ldap, etc) or it can defer to the
> jaas security-domain. In both of those situations, it seems that the
> EJBs are limited to a single authentication point. The EJB
> authentication is either going to be handled by a single security-realm
> or the security-realm will defer to a single security-domain.
> I could configure the security-domain to have multiple login modules. I
> assume the same thing could be done with the security-realm.
> Basically the problem that I am trying to solve boils down to this: the
> authentication checks for remote EJBs appear to be checked by either a
> single security-realm or a single security-domain. Is there a way to
> change this?
> One idea I had was to add another remote connector to the EJB subsystem.
> Unfortunately, this does not appear to be possible.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 12 months