March 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1245) Improve readability of missing dependency logs

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1245?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1245: ------------------------------------------------- Mike McCune <mmccune(a)redhat.com> changed the Status of [bug 1283294|https://bugzilla.redhat.com/show_bug.cgi?id=1283294] from MODIFIED to POST > Improve readability of missing dependency logs > ---------------------------------------------- > > Key: WFCORE-1245 > URL: https://issues.jboss.org/browse/WFCORE-1245 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Bartosz Spyrko-Śmietanko > Assignee: Bartosz Spyrko-Śmietanko > Attachments: after_1.log, after_2.log, before.log, bz1283294-reproducer.zip > > > When deploying an ear using initialize-in-order option, if one of the subdeployments contains an EJB that depends on an EJB from another subdeployment and the dependency subdeployment fails log output makes it hard to understand the root cause. > Structure of deployment is as follows: > {noformat} > reproducer.ear > |- service-locator.jar > | |- ServiceLocator (Stateless EJB) > | |- TestQueue (JNDI Resource) > |- client.jar > |- TestEjb (Stateless EJB) > |- ServiceLocator > {noformat} > If the TestQueue JNDI resource cannot be injected in the ServiceLocator, the deployment failure output lists a number of missing services per each EJB in the dependant subdeployment (.ORB, .HandleDelegate, .ValidatorFactory, etc). > When the dependant subdeployment has a larger number of EJBs the log output very quickly becomes hard to read. > Example with a single dependant EJB: > {noformat} > 14:27:43,092 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("deploy") failed - address: ({"deployment" => "reproducer-1.0-SNAPSHOT.ear"}) - failure description: { > "WFLYCTL0180: Services with missing/unavailable dependencies" => [ > "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".batch.environment is missing [jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".beanmanager]", > "jboss.naming.context.java.comp.testEar.client.TestEjb.ValidatorFactory is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]", > "jboss.naming.context.java.comp.testEar.client.TestEjb.ORB is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]", > "jboss.naming.context.java.comp.testEar.client.TestEjb.HandleDelegate is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]", > "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".weld.weldClassIntrospector is missing [jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".beanmanager]", > "jboss.deployment.unit.\"reproducer-1.0-SNAPSHOT.ear\".deploymentCompleteService is missing [jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".deploymentCompleteService]", > "jboss.naming.context.java.comp.testEar.client.TestEjb.InstanceName is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]", > "jboss.naming.context.java.comp.testEar.client.TestEjb.Validator is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]", > "jboss.naming.context.java.comp.testEar.service-locator.test_ServiceLocator.env.queue.TestQueue is missing [jboss.naming.context.java.jboss.resources.queue.TestQueue]", > "jboss.naming.context.java.comp.testEar.client.TestEjb.InAppClientContainer is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]" > ], > "WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => { > "Services that were unable to start:" => [ > "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".INSTALL", > "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".CLEANUP", > "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".component.test_ServiceLocator.JndiBindingsService", > "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".component.test_ServiceLocator.START", > "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".deploymentCompleteService", > "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".jndiDependencyService", > "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".moduleDeploymentRuntimeInformationStart", > "jboss.deployment.unit.\"reproducer-1.0-SNAPSHOT.ear\".CLEANUP" > ] > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-681) Incorrectly timeout values in ControllerLogger method timeoutCompletingOperation and ControllerMessages method serviceInstallTimedOut

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-681?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-681: ------------------------------------------------ Mike McCune <mmccune(a)redhat.com> changed the Status of [bug 1219273|https://bugzilla.redhat.com/show_bug.cgi?id=1219273] from MODIFIED to POST > Incorrectly timeout values in ControllerLogger method timeoutCompletingOperation and ControllerMessages method serviceInstallTimedOut > ------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-681 > URL: https://issues.jboss.org/browse/WFCORE-681 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 1.0.0.CR1 > Reporter: Chao Wang > Assignee: Chao Wang > Priority: Minor > Fix For: 1.0.0.CR2 > > > Incorrectly scaled timeout value passed to org.jboss.as.controller.ControllerLogger method timeoutCompletingOperation and org.jboss.as.controller.ControllerMessages method serviceInstallTimedOut > parameter value is ms, second is expected. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5242) Inconsistent format for IPv6 addresses in server log

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5242?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5242: ----------------------------------------------- Mike McCune <mmccune(a)redhat.com> changed the Status of [bug 1258298|https://bugzilla.redhat.com/show_bug.cgi?id=1258298] from MODIFIED to POST > Inconsistent format for IPv6 addresses in server log > ---------------------------------------------------- > > Key: WFLY-5242 > URL: https://issues.jboss.org/browse/WFLY-5242 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Beta2 > Reporter: Lyle Wang > Assignee: Chao Wang > Priority: Minor > Fix For: 10.0.0.CR1 > > > Description of problem: > When IPv6 is used, square brackets for IPv6 addresses are missed in some of log entries. Specifically, the address format from Undertow logs is different from those "WFLYSRV" logs. > How reproducible: > Always > Steps to Reproduce: > 1. Config IPv6 (example: https://docs.jboss.org/author/display/WFLY10/Interfaces+and+ports) > 2. Start WildFly and check the log > Actual results: > ---------------------------------------- > 2015-08-31 12:51:47,812 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0006: Undertow HTTP listener default listening on /0:0:0:0:0:0:0:1:8080 > ...... > 2015-08-31 12:51:48,431 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[::1]:9993/management > 2015-08-31 12:51:48,432 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[::1]:9993 > ---------------------------------------- > In Undertow logs it's like "/0:0:0:0:0:0:0:1:8080" but in WildFly server logs "http://[::1]:9993/management" > Expected results: > Consistent format should be used for IPv6 address across different components and the address is enclosed in square brackets [ ]. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1526) AS7 JConsole scripts ignore arguments

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1526?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1526: ----------------------------------------------- Mike McCune <mmccune(a)redhat.com> changed the Status of [bug 1238868|https://bugzilla.redhat.com/show_bug.cgi?id=1238868] from MODIFIED to POST > AS7 JConsole scripts ignore arguments > -------------------------------------- > > Key: WFLY-1526 > URL: https://issues.jboss.org/browse/WFLY-1526 > Project: WildFly > Issue Type: Enhancement > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Priority: Minor > > JConsole scripts ignore arguments, for instance, sh script: > jconsole -J-Djava.class.path="$CLASSPATH" > instead of > jconsole -J-Djava.class.path="$CLASSPATH" "$@" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3549) Deadlock during shutdown

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3549?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3549: ----------------------------------------------- Mike McCune <mmccune(a)redhat.com> changed the Status of [bug 1213817|https://bugzilla.redhat.com/show_bug.cgi?id=1213817] from MODIFIED to POST > Deadlock during shutdown > ------------------------ > > Key: WFLY-3549 > URL: https://issues.jboss.org/browse/WFLY-3549 > Project: WildFly > Issue Type: Bug > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Assignee: David Lloyd > Fix For: 8.2.0.Final > > > This deadlock appeared in an Arquillian test: > {noformat} > Found one Java-level deadlock: > ============================= > "undefined": > waiting to lock monitor 0x00007f67a421bfa8 (object 0x00000000e0700480, a org.jboss.as.threads.ScheduledThreadPoolService), > which is held by "MSC service thread 1-2" > "MSC service thread 1-2": > waiting for ownable synchronizer 0x00000000e0700618, (a java.util.concurrent.locks.ReentrantLock$NonfairSync), > which is held by "undefined" > Java stack information for the threads listed above: > =================================================== > "undefined": > at org.jboss.as.threads.ScheduledThreadPoolService$ExecutorImpl.terminated(ScheduledThreadPoolService.java:121) > - waiting to lock <0x00000000e0700480> (a org.jboss.as.threads.ScheduledThreadPoolService) > at java.util.concurrent.ThreadPoolExecutor.tryTerminate(ThreadPoolExecutor.java:704) > at java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExecutor.java:1006) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1163) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:724) > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > "MSC service thread 1-2": > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000000e0700618> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197) > at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214) > at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290) > at java.util.concurrent.ThreadPoolExecutor.interruptIdleWorkers(ThreadPoolExecutor.java:781) > at java.util.concurrent.ThreadPoolExecutor.tryTerminate(ThreadPoolExecutor.java:695) > at java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor.java:1397) > at java.util.concurrent.ScheduledThreadPoolExecutor.shutdown(ScheduledThreadPoolExecutor.java:759) > at org.jboss.as.threads.ManagedScheduledExecutorService.internalShutdown(ManagedScheduledExecutorService.java:53) > at org.jboss.as.threads.ScheduledThreadPoolService.stop(ScheduledThreadPoolService.java:67) > - locked <0x00000000e0700480> (a org.jboss.as.threads.ScheduledThreadPoolService) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017) > 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:724) > Found 1 deadlock. > {noformat} > Looks like two MSC service threads exited and tried to terminate the thread pool at the same time. And because the MSC threads are not daemon threads, the entire JVM hangs and blocks the Arquillian test that was waiting for the container to shut down. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-632) Subsystem deployment undeployed at startup

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-632?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-632: ------------------------------------------------ Mike McCune <mmccune(a)redhat.com> changed the Status of [bug 1271673|https://bugzilla.redhat.com/show_bug.cgi?id=1271673] from MODIFIED to POST > Subsystem deployment undeployed at startup > ------------------------------------------ > > Key: WFCORE-632 > URL: https://issues.jboss.org/browse/WFCORE-632 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Beta3, 1.0.0.Beta4 > Reporter: Stan Silvert > Assignee: Brian Stansberry > Labels: affects_elytron > Fix For: 1.0.0.Beta4 > > > {noformat} > @BrianStansberry The "mixed approach" doesn't seem to work any more. https://developer.jboss.org/wiki/ExtendingAS7 > @BrianStansberry I'm using this to deploy keycloak WAR from the subsystem. > @BrianStansberry As soon as the server is started, something is calling stopService() on the Keycloak WAR. > Tomaz Cerar > 1:15 PM > @StanSilvert are you still working on AS7? https://docs.jboss.org/author/display/WFLY8/Extending+WildFly+8 > Stan Silvert > 1:16 PM > @ctomc No. this is WildFly 9. It still works on WildFly 8. > Tomaz Cerar > 1:16 PM > ah the war deployment, that could be regression > Brian Stansberry > 1:17 PM > @ctomc how so? > Stan Silvert > 1:17 PM > FYI. I did a Thread.dumpStack() and got this: > 13:11:35,173 ERROR [stderr] (MSC service thread 1-3) java.lang.Exception: Stack trace > 13:11:35,173 ERROR [stderr] (MSC service thread 1-3) at java.lang.Thread.dumpStack(Thread.java:1329) > 13:11:35,174 ERROR [stderr] (MSC service thread 1-3) at org.wildfly.extension.undertow.Host.unregisterDeployment(Host.java:168) > 13:11:35,176 ERROR [stderr] (MSC service thread 1-3) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java: > 113) > 13:11:35,179 ERROR [stderr] (MSC service thread 1-3) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stop(UndertowDeploymentService.java:100) > 13:11:35,181 ERROR [stderr] (MSC service thread 1-3) at org.jboss.msc.service.Serv > iceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056) > 13:11:35,184 ERROR [stderr] (MSC service thread 1-3) at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017) > 13:11:35,186 ERROR [stderr] (MSC service thread 1-3) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > 13:11:35,188 ERROR [stderr] (MSC service thread 1-3) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > 13:11:35,190 ERROR [stderr] (MSC service thread 1-3) at java.lang.Thread.run(Thread.java:745) > Hide full text > Tomaz Cerar > 1:18 PM > @BrianStansberry just reffering that war deployment from subsystem should still work > 1:19 PM > Jason Greene joined the room. > Tomaz Cerar > 1:19 PM > @StanSilvert what happens? as that thread dump makes no sense > Stan Silvert > 1:21 PM > http://pastebin.com/xQ2DNzEe > The WAR is simply undeployed as soon as WildFly finishes startup. > Brian Stansberry > 1:22 PM > @StanSilvert can you give me a link to your code that's doing the deploy stuff? > Stan Silvert > 1:22 PM > just a sec > Stan Silvert > 1:24 PM > https://github.com/keycloak/keycloak/tree/master/integration > The code that creates the operation is https://github.com/keycloak/keycloak/blob/master/integration > AuthServerUtil ^^^ > click on the second link > 1:27 PM > Darran Lofthouse left the room. > Brian Stansberry > 1:27 PM > @StanSilvert are you doing overlay stuff? I see some code there re: overlays > Stan Silvert > 1:28 PM > Yes, but not in this instance. > Brian Stansberry > 1:28 PM > ok. I'm asking just because that would add more complexity, better scope for some service dependency going missing, triggering stop > Stan Silvert > 1:29 PM > For this simple case there are no overlays. > Brian Stansberry > 1:29 PM > @StanSilvert interesting, your log looks like it's a true undeploy op, not just a service stop > Tomaz Cerar > 1:30 PM > @BrianStansberry should we use 6.x.0 or 6.x.latest for tranformers testing? > Tomaz Cerar goes get some diner > Stan Silvert > 1:30 PM > @BrianStansberry If that's the case then maybe some condition is triggering my own undeploy operation. > @BrianStansberry I'll look into that and see what I find. > Brian Stansberry > 1:31 PM > @ctomc 6.x.0 is ok by me; chasing CPs is too much hassle > @StanSilvert note this: > 13:11:35,294 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0009: Undeployed "main-auth-server.war" (runtime-name: "main-auth-server.war") > the thread -- DeploymentScanner-threads - 1 > looks like your deployment is exposed to the scanner? > oh, here's a guess! > the scanner sees "persistent" => false and treats it as under scanner control > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4167) AS7Plugin dump-services command is failing

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4167?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4167: ----------------------------------------------- Mike McCune <mmccune(a)redhat.com> changed the Status of [bug 1195504|https://bugzilla.redhat.com/show_bug.cgi?id=1195504] from MODIFIED to POST > AS7Plugin dump-services command is failing > ------------------------------------------ > > Key: WFLY-4167 > URL: https://issues.jboss.org/browse/WFLY-4167 > Project: WildFly > Issue Type: Bug > Components: JDR > Affects Versions: 9.0.0.Alpha1 > Reporter: Brad Maxwell > Assignee: Brad Maxwell > Fix For: 9.0.0.Beta1 > > > Run JDR, the dump-services.json is always empty. This is because the operation is not being set when JDR tries to invoke the operation. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4168) jdr.sh CommandLineMain does not run jdr on the application server

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4168?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4168: ----------------------------------------------- Mike McCune <mmccune(a)redhat.com> changed the Status of [bug 1195507|https://bugzilla.redhat.com/show_bug.cgi?id=1195507] from MODIFIED to POST > jdr.sh CommandLineMain does not run jdr on the application server > ----------------------------------------------------------------- > > Key: WFLY-4168 > URL: https://issues.jboss.org/browse/WFLY-4168 > Project: WildFly > Issue Type: Bug > Components: JDR > Affects Versions: 9.0.0.Alpha1 > Reporter: Brad Maxwell > Assignee: Brad Maxwell > Fix For: 9.0.0.Beta1 > > > jdr.sh CommandLineMain does not run jdr on the application server > JDR run via the CLI / Managemenet API - runs the JDR report in the Application Server's JVM > /subsystem=jdr:generate-jdr-report() > Running jdr.sh / jdr.bat runs the JDR report in the JDR JVM > jdr.sh / jdr.bat should run the JDR report in the Application Server's JVM if it is running. If it is not running, then it should just collect the files that are available. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4217) JDR include system properties, jndi view, deployment module information

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4217?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4217: ----------------------------------------------- Mike McCune <mmccune(a)redhat.com> changed the Status of [bug 1195509|https://bugzilla.redhat.com/show_bug.cgi?id=1195509] from MODIFIED to POST > JDR include system properties, jndi view, deployment module information > ----------------------------------------------------------------------- > > Key: WFLY-4217 > URL: https://issues.jboss.org/browse/WFLY-4217 > Project: WildFly > Issue Type: Enhancement > Components: JDR > Affects Versions: 9.0.0.Alpha1 > Reporter: Brad Maxwell > Assignee: Brad Maxwell > Fix For: 9.0.0.Beta1 > > > JDR include system properties, jndi view, deployment module information -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2732) Injected EJB not available to MDB @PreDestroy methods

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2732?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2732: ----------------------------------------------- Mike McCune <mmccune(a)redhat.com> changed the Status of [bug 1120046|https://bugzilla.redhat.com/show_bug.cgi?id=1120046] from MODIFIED to POST > Injected EJB not available to MDB @PreDestroy methods > ----------------------------------------------------- > > Key: WFLY-2732 > URL: https://issues.jboss.org/browse/WFLY-2732 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.0.0.CR1 > Reporter: Mustafa Musaji > Assignee: Stuart Douglas > Fix For: 8.0.0.Final > > Attachments: MDBLifeCycleJAR.zip > > > MDB with method annotated with @PreDestroy and injected EJB. In this method we are calling an EJB. When the application is undeployed the PreDestroy method is called but it fails on the call to the injected EJB as it's already been undeployed. > This was fixed in an RFE for Session Beans but does not seem to work for MDB. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2016