[JBoss JIRA] (WFLY-6441) naming context is not setup when starting the persistence unit
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-6441?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-6441:
-----------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1320132|https://bugzilla.redhat.com/show_bug.cgi?id=1320132] from MODIFIED to ON_QA
> naming context is not setup when starting the persistence unit
> --------------------------------------------------------------
>
> Key: WFLY-6441
> URL: https://issues.jboss.org/browse/WFLY-6441
> Project: WildFly
> Issue Type: Enhancement
> Components: JPA / Hibernate
> Affects Versions: JBoss AS7 7.1.1.Final, JBoss AS7 7.2.0.Final, 9.0.2.Final, 10.0.0.Final
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Fix For: 10.1.0.CR1
>
>
> ookup of env-entry throws NameNotFoundException during persistence unit startup
> Version-Release number of selected component (if applicable):
> How reproducible:
> always
> Steps to Reproduce:
> 1. add env-entry in application.xml
> 2. try to lookup during persistent unit startup, e.g.
> public class MyType implements UserType {
> ...
> @Override
> public int[] sqlTypes() {
> try {
> Object ctx = new InitialContext().lookup("java:app/env");
> log.info("java:app/env from JPA = " + ctx);
> } catch (Exception e) {
> log.error("unable to get java:app/env from JPA", e);
> }
> return new int[] { Types.VARCHAR };
> }
> Actual results:
> NameNotFoundException
> Expected results:
> value of env-entry is available
> Additional info:
> On 21.03.2016 23:47, Stuart Douglas wrote:
> > This should fix it (I think): https://github.com/stuartwdouglas/wildfly/tree/jpa-java-namespace
> >
> > Stuart
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1304) WFLYCTL0013: Operation ("clean-obsolete-content") failed .. StringIndexOutOfBoundsException when OS puts metadata files in content repo
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1304?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1304:
-------------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1299189|https://bugzilla.redhat.com/show_bug.cgi?id=1299189] from POST to MODIFIED
> WFLYCTL0013: Operation ("clean-obsolete-content") failed .. StringIndexOutOfBoundsException when OS puts metadata files in content repo
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1304
> URL: https://issues.jboss.org/browse/WFCORE-1304
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brad Maxwell
> Assignee: Chao Wang
> Fix For: 2.0.8.Final
>
>
> Mac OS can put .DS_Store files into the content repo directory. This can also be reproduced on Linux by creating a file under the content dir and when clean-obsolete-content() runs it will log this error. It seems it runs every 10 minutes.
> {code}
> 22:59:48,289 INFO [org.jboss.as.repository] (ServerService Thread Pool -- 1) WFLYDR0009: Content /Users/bradley/Desktop/wildfly-10.0.0.CR5/standalone/data/content/9b/.DS_Store is obsolete and will be removed
> 22:59:48,290 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 1) WFLYCTL0013: Operation ("clean-obsolete-content") failed - address: ([]): java.lang.StringIndexOutOfBoundsException: String index out of range: 11
> at java.lang.String.charAt(String.java:658)
> at org.jboss.as.repository.HashUtil.hexStringToByteArray(HashUtil.java:62)
> at org.jboss.as.repository.ContentReference.getHash(ContentReference.java:68)
> at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.removeContent(ContentRepository.java:365)
> at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.markAsObsolete(ContentRepository.java:427)
> at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.cleanObsoleteContent(ContentRepository.java:403)
> at org.jboss.as.server.operations.CleanObsoleteContentHandler.execute(CleanObsoleteContentHandler.java:76)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:204)
> at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:659)
> at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:649)
> at org.jboss.as.server.deployment.ContentRepositoryCleaner.cleanObsoleteContent(ContentRepositoryCleaner.java:132)
> at org.jboss.as.server.deployment.ContentRepositoryCleaner$ContentRepositoryCleanerTask.run(ContentRepositoryCleaner.java:67)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 22:59:48,292 ERROR [org.jboss.as.server] (ServerService Thread Pool -- 1) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0158: Operation handler failed: java.lang.StringIndexOutOfBoundsException: String index out of range: 11
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1304) WFLYCTL0013: Operation ("clean-obsolete-content") failed .. StringIndexOutOfBoundsException when OS puts metadata files in content repo
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1304?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1304:
-------------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1299189|https://bugzilla.redhat.com/show_bug.cgi?id=1299189] from MODIFIED to ON_QA
> WFLYCTL0013: Operation ("clean-obsolete-content") failed .. StringIndexOutOfBoundsException when OS puts metadata files in content repo
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1304
> URL: https://issues.jboss.org/browse/WFCORE-1304
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brad Maxwell
> Assignee: Chao Wang
> Fix For: 2.0.8.Final
>
>
> Mac OS can put .DS_Store files into the content repo directory. This can also be reproduced on Linux by creating a file under the content dir and when clean-obsolete-content() runs it will log this error. It seems it runs every 10 minutes.
> {code}
> 22:59:48,289 INFO [org.jboss.as.repository] (ServerService Thread Pool -- 1) WFLYDR0009: Content /Users/bradley/Desktop/wildfly-10.0.0.CR5/standalone/data/content/9b/.DS_Store is obsolete and will be removed
> 22:59:48,290 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 1) WFLYCTL0013: Operation ("clean-obsolete-content") failed - address: ([]): java.lang.StringIndexOutOfBoundsException: String index out of range: 11
> at java.lang.String.charAt(String.java:658)
> at org.jboss.as.repository.HashUtil.hexStringToByteArray(HashUtil.java:62)
> at org.jboss.as.repository.ContentReference.getHash(ContentReference.java:68)
> at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.removeContent(ContentRepository.java:365)
> at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.markAsObsolete(ContentRepository.java:427)
> at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.cleanObsoleteContent(ContentRepository.java:403)
> at org.jboss.as.server.operations.CleanObsoleteContentHandler.execute(CleanObsoleteContentHandler.java:76)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:204)
> at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:659)
> at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:649)
> at org.jboss.as.server.deployment.ContentRepositoryCleaner.cleanObsoleteContent(ContentRepositoryCleaner.java:132)
> at org.jboss.as.server.deployment.ContentRepositoryCleaner$ContentRepositoryCleanerTask.run(ContentRepositoryCleaner.java:67)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 22:59:48,292 ERROR [org.jboss.as.server] (ServerService Thread Pool -- 1) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0158: Operation handler failed: java.lang.StringIndexOutOfBoundsException: String index out of range: 11
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1119) ManagedDatagramSocketBinding throw NPE
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1119?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1119:
-------------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1280235|https://bugzilla.redhat.com/show_bug.cgi?id=1280235] from POST to MODIFIED
> ManagedDatagramSocketBinding throw NPE
> --------------------------------------
>
> Key: WFCORE-1119
> URL: https://issues.jboss.org/browse/WFCORE-1119
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.CR8
> Reporter: Stefan Dilk
> Assignee: Brian Stansberry
> Fix For: 2.0.2.Final
>
>
> i think i have found the same bug as in WFCORE-1033 but in another method.
> in the previous bug the bind method was the problem, here i have the same NPE in the close method. there is no null check to registry as in the bind method.
> {noformat}
> [Server:mgmt-1-prod] 2015-11-10 00:37:15,454 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.jgroups.channel.ee.connector: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee.connector:
> java.lang.NullPointerException
> [Server:mgmt-1-prod] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:9
> 6)
> [Server:mgmt-1-prod] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [Server:mgmt-1-prod] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [Server:mgmt-1-prod] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:mgmt-1-prod] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:mgmt-1-prod] at java.lang.Thread.run(Thread.java:745)
> [Server:mgmt-1-prod] Caused by: java.lang.NullPointerException
> [Server:mgmt-1-prod] at org.jboss.as.network.ManagedDatagramSocketBinding.close(ManagedDatagramSocketBinding.java:73)
> [Server:mgmt-1-prod] at java.net.DatagramSocket.<init>(DatagramSocket.java:245)
> [Server:mgmt-1-prod] at org.jboss.as.network.ManagedDatagramSocketBinding.<init>(ManagedDatagramSocketBinding.java:41)
> [Server:mgmt-1-prod] at org.jboss.as.network.SocketBindingManagerImpl.createDatagramSocket(SocketBindingManagerImpl.java:87)
> [Server:mgmt-1-prod] at org.jboss.as.clustering.jgroups.ManagedSocketFactory.createDatagramSocket(ManagedSocketFactory.java:103)
> [Server:mgmt-1-prod] at org.jboss.as.clustering.jgroups.ManagedSocketFactory.createDatagramSocket(ManagedSocketFactory.java:113)
> [Server:mgmt-1-prod] at org.jgroups.protocols.UDP.createDatagramSocketWithBindPort(UDP.java:487)
> [Server:mgmt-1-prod] at org.jgroups.protocols.UDP.createSockets(UDP.java:361)
> [Server:mgmt-1-prod] at org.jgroups.protocols.UDP.start(UDP.java:270)
> [Server:mgmt-1-prod] at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965)
> [Server:mgmt-1-prod] at org.jgroups.JChannel.startStack(JChannel.java:890)
> [Server:mgmt-1-prod] at org.jgroups.JChannel._preConnect(JChannel.java:553)
> [Server:mgmt-1-prod] at org.jgroups.JChannel.connect(JChannel.java:288)
> [Server:mgmt-1-prod] at org.jgroups.JChannel.connect(JChannel.java:279)
> [Server:mgmt-1-prod] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:94)
> [Server:mgmt-1-prod] ... 5 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1119) ManagedDatagramSocketBinding throw NPE
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1119?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1119:
-------------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1280235|https://bugzilla.redhat.com/show_bug.cgi?id=1280235] from MODIFIED to ON_QA
> ManagedDatagramSocketBinding throw NPE
> --------------------------------------
>
> Key: WFCORE-1119
> URL: https://issues.jboss.org/browse/WFCORE-1119
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.CR8
> Reporter: Stefan Dilk
> Assignee: Brian Stansberry
> Fix For: 2.0.2.Final
>
>
> i think i have found the same bug as in WFCORE-1033 but in another method.
> in the previous bug the bind method was the problem, here i have the same NPE in the close method. there is no null check to registry as in the bind method.
> {noformat}
> [Server:mgmt-1-prod] 2015-11-10 00:37:15,454 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.jgroups.channel.ee.connector: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee.connector:
> java.lang.NullPointerException
> [Server:mgmt-1-prod] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:9
> 6)
> [Server:mgmt-1-prod] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [Server:mgmt-1-prod] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [Server:mgmt-1-prod] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:mgmt-1-prod] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:mgmt-1-prod] at java.lang.Thread.run(Thread.java:745)
> [Server:mgmt-1-prod] Caused by: java.lang.NullPointerException
> [Server:mgmt-1-prod] at org.jboss.as.network.ManagedDatagramSocketBinding.close(ManagedDatagramSocketBinding.java:73)
> [Server:mgmt-1-prod] at java.net.DatagramSocket.<init>(DatagramSocket.java:245)
> [Server:mgmt-1-prod] at org.jboss.as.network.ManagedDatagramSocketBinding.<init>(ManagedDatagramSocketBinding.java:41)
> [Server:mgmt-1-prod] at org.jboss.as.network.SocketBindingManagerImpl.createDatagramSocket(SocketBindingManagerImpl.java:87)
> [Server:mgmt-1-prod] at org.jboss.as.clustering.jgroups.ManagedSocketFactory.createDatagramSocket(ManagedSocketFactory.java:103)
> [Server:mgmt-1-prod] at org.jboss.as.clustering.jgroups.ManagedSocketFactory.createDatagramSocket(ManagedSocketFactory.java:113)
> [Server:mgmt-1-prod] at org.jgroups.protocols.UDP.createDatagramSocketWithBindPort(UDP.java:487)
> [Server:mgmt-1-prod] at org.jgroups.protocols.UDP.createSockets(UDP.java:361)
> [Server:mgmt-1-prod] at org.jgroups.protocols.UDP.start(UDP.java:270)
> [Server:mgmt-1-prod] at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965)
> [Server:mgmt-1-prod] at org.jgroups.JChannel.startStack(JChannel.java:890)
> [Server:mgmt-1-prod] at org.jgroups.JChannel._preConnect(JChannel.java:553)
> [Server:mgmt-1-prod] at org.jgroups.JChannel.connect(JChannel.java:288)
> [Server:mgmt-1-prod] at org.jgroups.JChannel.connect(JChannel.java:279)
> [Server:mgmt-1-prod] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:94)
> [Server:mgmt-1-prod] ... 5 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1093) TempFileProviderService threads consume high CPU
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1093?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1093:
-------------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1277699|https://bugzilla.redhat.com/show_bug.cgi?id=1277699] from POST to MODIFIED
> TempFileProviderService threads consume high CPU
> ------------------------------------------------
>
> Key: WFCORE-1093
> URL: https://issues.jboss.org/browse/WFCORE-1093
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Aaron Ogburn
> Assignee: Jason Greene
> Fix For: 2.0.3.Final
>
>
> TempFileProviderService threads consume high CPU as they poll their non empty task queue. This is ultimately due to a flaw in the JDK ThreadPoolExecutor code (https://bugs.openjdk.java.net/browse/JDK-8129861), impacting ScheduledThreadPoolExecutors that use a core size of 0 and a default 0 keepalive timeout.
> While the executor queue is not empty, the executor does not allow the pool to go below 1 thread. So the one remaining work thread keeps looping over its poll call with a 0 timeout. Options to protect JBoss from this are:
> 1) Set a keepalive timeout on the executor so the poll has a duration and the worker run loop isn't so busy
> 2) Or set the Executor core pool size to >0. The worker thread would then use a blocking take() call on its queue instead of a constant 0 second poll calls. The side effect of this change is that the thread pool wouldn't ever drop back down to 0.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1093) TempFileProviderService threads consume high CPU
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1093?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1093:
-------------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1277699|https://bugzilla.redhat.com/show_bug.cgi?id=1277699] from MODIFIED to ON_QA
> TempFileProviderService threads consume high CPU
> ------------------------------------------------
>
> Key: WFCORE-1093
> URL: https://issues.jboss.org/browse/WFCORE-1093
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Aaron Ogburn
> Assignee: Jason Greene
> Fix For: 2.0.3.Final
>
>
> TempFileProviderService threads consume high CPU as they poll their non empty task queue. This is ultimately due to a flaw in the JDK ThreadPoolExecutor code (https://bugs.openjdk.java.net/browse/JDK-8129861), impacting ScheduledThreadPoolExecutors that use a core size of 0 and a default 0 keepalive timeout.
> While the executor queue is not empty, the executor does not allow the pool to go below 1 thread. So the one remaining work thread keeps looping over its poll call with a 0 timeout. Options to protect JBoss from this are:
> 1) Set a keepalive timeout on the executor so the poll has a duration and the worker run loop isn't so busy
> 2) Or set the Executor core pool size to >0. The worker thread would then use a blocking take() call on its queue instead of a constant 0 second poll calls. The side effect of this change is that the thread pool wouldn't ever drop back down to 0.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[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:
------------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1271673|https://bugzilla.redhat.com/show_bug.cgi?id=1271673] from MODIFIED to ON_QA
> 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