[JBoss JIRA] (WFCORE-65) Filesystem deployment scanner deployment failure removes other scanners ' deployments
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-65?page=com.atlassian.jira.plugin.... ]
Brian Stansberry edited comment on WFCORE-65 at 4/8/15 2:21 PM:
----------------------------------------------------------------
A fix for WFCORE-65 will likely fix WFCORE-632 as well. If in a deployment resource in the model we store a non-persistent "owner" attribute (doesn't need to be persisted) with a value of type LIST of PROPERTY, the scanner can pass in its own address when adding deployments, and use that to ignore unrelated deployments.
Any "owner" attribute should be treated like the "persistent" attribute -- not part of the "add" API description for a resource, not modifiable, not persisted to xml.
was (Author: brian.stansberry):
A fix for WFCORE-65 will likely fix WFCORE-632 as well. If in a deployment resource in the model we store a non-persistent "owner" attribute (doesn't need to be persisted) with a value of type LIST of PROPERTY, the scanner can pass in its own address when adding deployments, and use that to ignore unrelated deployments.
> Filesystem deployment scanner deployment failure removes other scanners ' deployments
> -------------------------------------------------------------------------------------
>
> Key: WFCORE-65
> URL: https://issues.jboss.org/browse/WFCORE-65
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha5
> Reporter: ehsavoie Hugonnet
>
> There is no way to associate a deployment to a specific scanner thus if one deployment fails for a scanner during startup all deployments not persistent will be removed
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (WFCORE-65) Filesystem deployment scanner deployment failure removes other scanners ' deployments
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-65?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFCORE-65:
----------------------------------------
A fix for WFCORE-65 will likely fix WFCORE-632 as well. If in a deployment resource in the model we store a non-persistent "owner" attribute (doesn't need to be persisted) with a value of type LIST of PROPERTY, the scanner can pass in its own address when adding deployments, and use that to ignore unrelated deployments.
> Filesystem deployment scanner deployment failure removes other scanners ' deployments
> -------------------------------------------------------------------------------------
>
> Key: WFCORE-65
> URL: https://issues.jboss.org/browse/WFCORE-65
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha5
> Reporter: ehsavoie Hugonnet
>
> There is no way to associate a deployment to a specific scanner thus if one deployment fails for a scanner during startup all deployments not persistent will be removed
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (WFCORE-632) Subsystem deployment undeployed at startup
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-632?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-632:
-----------------------------------------
A fix for WFCORE-65 will likely fix WFCORE-632 as well. If in a deployment resource in the model we store a non-persistent "owner" attribute (doesn't need to be persisted) with a value of type LIST of PROPERTY, the scanner can pass in its own address when adding deployments, and use that to ignore unrelated deployments.
> 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
>
> {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.3.11#6341)
11 years
[JBoss JIRA] (WFCORE-632) Subsystem deployment undeployed at startup
by Stan Silvert (JIRA)
Stan Silvert created WFCORE-632:
-----------------------------------
Summary: 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
{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.3.11#6341)
11 years
[JBoss JIRA] (WFCORE-629) Enabled automatic encryption of passwords stored in configuration
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-629?page=com.atlassian.jira.plugin... ]
Darran Lofthouse reassigned WFCORE-629:
---------------------------------------
Assignee: Darran Lofthouse
> Enabled automatic encryption of passwords stored in configuration
> -----------------------------------------------------------------
>
> Key: WFCORE-629
> URL: https://issues.jboss.org/browse/WFCORE-629
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Security
> Environment: Wildfly 9
> Reporter: Jason Shepherd
> Assignee: Darran Lofthouse
>
> Currently encrypting passwords such as Datasource passwords can only be done 'after the fact'. You have to create the datasource first, then retrospectively store the password in the vault and dereference it in the configuration.
> It would be great if could turn on automatic storage of passwords in the vault so that when you create a Datasource password, or add a resource adapter which specifies a remote resource password, those passwords were automatically added to the vault, and deferenced in the configuration file.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (DROOLS-749) Events deserialization is broken
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-749?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-749:
------------------------------------------------
Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1205666|https://bugzilla.redhat.com/show_bug.cgi?id=1205666] from ON_QA to VERIFIED
> Events deserialization is broken
> --------------------------------
>
> Key: DROOLS-749
> URL: https://issues.jboss.org/browse/DROOLS-749
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Priority: Critical
> Fix For: 6.3.0.Beta1
>
>
> When a KieSession is deserialized the events present in the old serialized session are reasserted into the new session. Then if one of this event causes a scheduler to be immediately triggered this is done in a callback out of the main evaluation loop. This implies that the left tuples resulting from the triggering of the scheduler aren't propagated to the sink of the TimerNode which created the scheduler itself. This missing propagation can, in some circumstances, cause a NullPointerException like the following:
> {code}
> java.lang.NullPointerException
> at org.drools.core.phreak.PhreakTimerNode.doLeftDeletes(PhreakTimerNode.java:197)
> at org.drools.core.phreak.PhreakTimerNode.doNode(PhreakTimerNode.java:63)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:364)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:163)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:118)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:254)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:108)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1022)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1352)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1318)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1301)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1280)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years