[JBoss JIRA] (ELY-1668) LDAP searchScope=OBJECT_SCOPE Elytron alternative
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-1668?page=com.atlassian.jira.plugin.s... ]
Martin Choma updated ELY-1668:
------------------------------
Summary: LDAP searchScope=OBJECT_SCOPE Elytron alternative (was: LDAP search_scope=OBJECT_SCOPE Elytron alternative)
> LDAP searchScope=OBJECT_SCOPE Elytron alternative
> -------------------------------------------------
>
> Key: ELY-1668
> URL: https://issues.jboss.org/browse/ELY-1668
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.6.1.Final
> Reporter: Martin Choma
>
> During comparing PicketBox an Elytron we came to one scenario which I am not sure if is covered by Elytron.
> "As a user I am able to authenticate and authorize into web application secured by LDAP (where the same is used for storing identities and roles) and roles are stored in tree structure and should be only referenced object." Author is Ondra Lukas which is not with us anymore so I tried to think about what could this be about? Based on context I came to conclusion this is about OBJECT_SCOPE value of property searchScope.
> Could you revise if same is possible with Elytron? But anyway I am not sure how that feature can be useful. But maybe there is some corner case it can be useful I am not aware of.
> {code}
> dn: ou=People,${dnSuffix}
> objectclass: top
> objectclass: organizationalUnit
> ou: People
> dn: uid=jduke,ou=People,${dnSuffix}
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: jduke
> cn: Java Duke
> sn: Duke
> userPassword: Password1
> dn: ou=RolesLevel1,${dnSuffix}
> objectclass: top
> objectclass: organizationalUnit
> ou: RolesLevel1
> dn: cn=RoleUnderLevel1,ou=RolesLevel1,${dnSuffix}
> objectclass: top
> objectclass: groupOfNames
> cn: RoleUnderLevel1
> member: uid=jduke,ou=People,${dnSuffix}
> description: the RoleUnderLevel1 group
> {code}
> [1] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (ELY-1668) LDAP search_scope=OBJECT_SCOPE Elytron alternative
by Martin Choma (JIRA)
Martin Choma created ELY-1668:
---------------------------------
Summary: LDAP search_scope=OBJECT_SCOPE Elytron alternative
Key: ELY-1668
URL: https://issues.jboss.org/browse/ELY-1668
Project: WildFly Elytron
Issue Type: Bug
Components: Realms
Affects Versions: 1.6.1.Final
Reporter: Martin Choma
During comparing PicketBox an Elytron we came to one scenario which I am not sure if is covered by Elytron.
"As a user I am able to authenticate and authorize into web application secured by LDAP (where the same is used for storing identities and roles) and roles are stored in tree structure and should be only referenced object." Author is Ondra Lukas which is not with us anymore so I tried to think about what could this be about? Based on context I came to conclusion this is about OBJECT_SCOPE value of property searchScope.
Could you revise if same is possible with Elytron? But anyway I am not sure how that feature can be useful. But maybe there is some corner case it can be useful I am not aware of.
{code}
dn: ou=People,${dnSuffix}
objectclass: top
objectclass: organizationalUnit
ou: People
dn: uid=jduke,ou=People,${dnSuffix}
objectclass: top
objectclass: person
objectclass: inetOrgPerson
uid: jduke
cn: Java Duke
sn: Duke
userPassword: Password1
dn: ou=RolesLevel1,${dnSuffix}
objectclass: top
objectclass: organizationalUnit
ou: RolesLevel1
dn: cn=RoleUnderLevel1,ou=RolesLevel1,${dnSuffix}
objectclass: top
objectclass: groupOfNames
cn: RoleUnderLevel1
member: uid=jduke,ou=People,${dnSuffix}
description: the RoleUnderLevel1 group
{code}
[1] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (DROOLS-2940) It is not possible to run all scenarios in the old test scenarios.
by Klara Kufova (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2940?page=com.atlassian.jira.plugi... ]
Klara Kufova updated DROOLS-2940:
---------------------------------
Tester: Klara Kufova (was: Juraj Soltes)
> It is not possible to run all scenarios in the old test scenarios.
> ------------------------------------------------------------------
>
> Key: DROOLS-2940
> URL: https://issues.jboss.org/browse/DROOLS-2940
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Reporter: Juraj Soltes
> Assignee: Toni Rikkola
>
> When trying to run all scenarios, and error dialog is produced:
> {noformat}
> Unable to complete your request. The following exception occurred: org.jboss.weld.exceptions.AmbiguousResolutionException:WELD-001318: Cannot resolve an ambiguous dependency between: - Managed Bean [class org.drools.workbench.screens.scenariosimulation.backend.server.ScenarioRunnerServiceImpl] with qualifiers [@Any @Default], - Managed Bean [class org.drools.workbench.screens.testscenario.backend.server.ScenarioRunnerService] with qualifiers [@Any @Default].
> {noformat}
> Currently only present in the drools-showcase (from obvious reasons).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-10629) Server startup wrongly deploys all xml files and never stops
by Nelson Antunes (JIRA)
[ https://issues.jboss.org/browse/WFLY-10629?page=com.atlassian.jira.plugin... ]
Nelson Antunes commented on WFLY-10629:
---------------------------------------
Thank you [~nuno.godinhomatos] this work for me. :)
> Server startup wrongly deploys all xml files and never stops
> ------------------------------------------------------------
>
> Key: WFLY-10629
> URL: https://issues.jboss.org/browse/WFLY-10629
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 13.0.0.Final
> Reporter: Arnie Morein
> Assignee: Jason Greene
>
> I have downloaded WF 12 and 13, then imported each into Eclipse (Oxygen.3a Release (4.7.3a)), OS is Win 7/x64; then used add-user to set up admin user. Then from both the command line and from within Eclipse, when the software starts up all of the xml configuration files get deployed at the same time despite the fact that the --server-config=standalone.xml parameter is present in either environment. What's worse, it starts versioning them and re-deploying them over and over and over again.
> {quote}
> 15:45:42,229 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 66) WFLYCLINF0002: Started client-mappings cache from ejb container
> 15:45:42,319 INFO [org.jboss.as.server] (ServerService Thread Pool -- 39) WFLYSRV0010: Deployed "standalone.xml" (runtime-name : "standalone.xml")
> 15:45:42,320 INFO [org.jboss.as.server] (ServerService Thread Pool -- 39) WFLYSRV0010: Deployed "standalone-load-balancer.xml" (runtime-name : "standalone-load-balancer.xml")
> 15:45:42,324 INFO [org.jboss.as.server] (ServerService Thread Pool -- 39) WFLYSRV0010: Deployed "standalone-ha.xml" (runtime-name : "standalone-ha.xml")
> 15:45:42,324 INFO [org.jboss.as.server] (ServerService Thread Pool -- 39) WFLYSRV0010: Deployed "standalone-full.xml" (runtime-name : "standalone-full.xml")
> 15:45:42,325 INFO [org.jboss.as.server] (ServerService Thread Pool -- 39) WFLYSRV0010: Deployed "standalone-full-ha.xml" (runtime-name : "standalone-full-ha.xml")
> 15:45:42,326 INFO [org.jboss.as.server] (ServerService Thread Pool -- 39) WFLYSRV0010: Deployed "standalone-ee8.xml" (runtime-name : "standalone-ee8.xml")
> 15:45:42,407 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
> 15:45:42,410 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
> 15:45:42,411 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
> 15:45:42,411 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 13.0.0.Final (WildFly Core 5.0.0.Final) started in 6285ms - Started 549 of 746 services (326 se
> rvices are lazy, passive or on-demand)
> 15:45:42,575 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0027: Starting deployment of "standalone.last.xml" (runtime-name: "standalone.last.xml")
> 15:45:42,578 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "standalone.boot.xml" (runtime-name: "standalone.boot.xml")
> 15:45:42,581 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0027: Starting deployment of "standalone.initial.xml" (runtime-name: "standalone.initial.xml")
> 15:45:42,724 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0010: Deployed "standalone.last.xml" (runtime-name : "standalone.last.xml")
> 15:45:42,725 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0010: Deployed "standalone.initial.xml" (runtime-name : "standalone.initial.xml")
> 15:45:42,726 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0010: Deployed "standalone.boot.xml" (runtime-name : "standalone.boot.xml")
> 15:45:47,921 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0028: Stopped deployment standalone.xml (runtime-name: standalone.xml) in 28ms
> 15:45:47,928 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0027: Starting deployment of "standalone.xml" (runtime-name: "standalone.xml")
> 15:45:47,930 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "standalone.v1.xml" (runtime-name: "standalone.v1.xml")
> 15:45:47,982 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0028: Stopped deployment standalone.last.xml (runtime-name: standalone.last.xml) in 55ms
> 15:45:47,984 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0027: Starting deployment of "standalone.last.xml" (runtime-name: "standalone.last.xml")
> 15:45:48,059 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0016: Replaced deployment "standalone.last.xml" with deployment "standalone.last.xml"
> 15:45:48,060 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0010: Deployed "standalone.v1.xml" (runtime-name : "standalone.v1.xml")
> 15:45:48,060 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0016: Replaced deployment "standalone.xml" with deployment "standalone.xml"
> 15:45:53,233 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0028: Stopped deployment standalone.xml (runtime-name: standalone.xml) in 13ms
> 15:45:53,236 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0027: Starting deployment of "standalone.v2.xml" (runtime-name: "standalone.v2.xml")
> 15:45:53,237 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0027: Starting deployment of "standalone.xml" (runtime-name: "standalone.xml")
> 15:45:53,249 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0028: Stopped deployment standalone.last.xml (runtime-name: standalone.last.xml) in 15ms
> 15:45:53,252 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0027: Starting deployment of "standalone.last.xml" (runtime-name: "standalone.last.xml")
> 15:45:53,340 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0016: Replaced deployment "standalone.last.xml" with deployment "standalone.last.xml"
> 15:45:53,341 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0010: Deployed "standalone.v2.xml" (runtime-name : "standalone.v2.xml")
> 15:45:53,342 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0016: Replaced deployment "standalone.xml" with deployment "standalone.xml"{quote}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-10630) HttpSessionListener.sessionDestroyed() not called if session invalidated in another WAR
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-10630?page=com.atlassian.jira.plugin... ]
Kabir Khan updated WFLY-10630:
------------------------------
Fix Version/s: 15.0.0.Alpha1
(was: 14.0.0.Final)
> HttpSessionListener.sessionDestroyed() not called if session invalidated in another WAR
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-10630
> URL: https://issues.jboss.org/browse/WFLY-10630
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final, 13.0.0.Final
> Environment: Windows 10, Java 1.8.0_131
> Reproducible with both WildFly-10.0.0.Final and Wildfly-13.0.0.Final
> Reporter: Bernhard Kabelka
> Assignee: Paul Ferraro
> Fix For: 15.0.0.Alpha1
>
> Attachments: LoginForm.png, roles.properties, sessionlistener-test.ear, standalone.xml, users.properties
>
>
> For sessions shared across different WARs in a single EAR, the notification of HttpSessionListener works differently in WildFly 10.0.0.Final (and Wildfly 13.0.0.Final) than it it used to work in WildFly 8.2.0.Final:
> I have an EAR containing two WARs with enabled session sharing across the WARs. Basically, one WAR contains the web UI, and the other WAR contains the REST interfaces for AJAX calls made by the UI. The user authenticates against the UI-WAR. On logout, a REST method in the AJAX-WAR is triggered which calls HttpSession.invalidate() on the user session.
> In WildFly 8.2.0.Final, a HttpSessionListener in the UI-WAR gets notified immediately about session creation and destruction.
> In WildFly 13.0.0.Final, however, a HttpSessionListener in either WAR only gets one of the two notifications:
> * In the UI-WAR, I get a notification about the created session immediately when the login form is loaded. However, I do not receive any notification about the session destruction (unless it times out).
> * In the AJAX-WAR, I do not get any notification about the session creation at all, but I immediately receive a notification about the session destruction.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (JGRP-2286) VERIFY_SUSPECT can return false positives if member is killed and immediately restarted
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/JGRP-2286?page=com.atlassian.jira.plugin.... ]
Radoslav Husar reopened JGRP-2286:
----------------------------------
This has been reverted.
> VERIFY_SUSPECT can return false positives if member is killed and immediately restarted
> ---------------------------------------------------------------------------------------
>
> Key: JGRP-2286
> URL: https://issues.jboss.org/browse/JGRP-2286
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.13
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> When a member is killed, it is suspected and VERIFY_SUSPECT attempts to send a message to the member to verify that it has left. If, however, the member is restarted before the VERIFY_SUSPECT sends its message, the newly started member (with same physical address, but different UUID) can receive it and erroneously reply with an I_AM_NOT_DEAD response. This results in a zombie member in the view that will remain until the reincarnated member leaves.
> To fix this, we should add the address of the suspected member to the VerifyHeader and validate that the member is us before sending an I_AM_NOT_DEAD response.
> Additionally, we can respond with a new MBR_IS_DEAD response on behalf of the suspected member, in the case that the message was receive by the reincarnated member to expedite the removal of the suspected member from the view.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (JGRP-2286) VERIFY_SUSPECT can return false positives if member is killed and immediately restarted
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/JGRP-2286?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated JGRP-2286:
---------------------------------
Fix Version/s: (was: 4.0.14)
> VERIFY_SUSPECT can return false positives if member is killed and immediately restarted
> ---------------------------------------------------------------------------------------
>
> Key: JGRP-2286
> URL: https://issues.jboss.org/browse/JGRP-2286
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.13
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> When a member is killed, it is suspected and VERIFY_SUSPECT attempts to send a message to the member to verify that it has left. If, however, the member is restarted before the VERIFY_SUSPECT sends its message, the newly started member (with same physical address, but different UUID) can receive it and erroneously reply with an I_AM_NOT_DEAD response. This results in a zombie member in the view that will remain until the reincarnated member leaves.
> To fix this, we should add the address of the suspected member to the VerifyHeader and validate that the member is us before sending an I_AM_NOT_DEAD response.
> Additionally, we can respond with a new MBR_IS_DEAD response on behalf of the suspected member, in the case that the message was receive by the reincarnated member to expedite the removal of the suspected member from the view.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-6627) Runtime handling for protocol-manager-factory is not implemented on "connection-factory"
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-6627?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet updated WFLY-6627:
------------------------------------
Fix Version/s: 11.0.0.Final
(was: 14.0.0.Final)
> Runtime handling for protocol-manager-factory is not implemented on "connection-factory"
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-6627
> URL: https://issues.jboss.org/browse/WFLY-6627
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Chen Maoqian
> Assignee: Chen Maoqian
> Fix For: 11.0.0.Final
>
> Attachments: WFLY-6627.patch
>
>
> When trying to update attribute _protocol-manager-factory_ of _/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory_ it raises the following exception
> {code:java}
> 17:36:06,807 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("undefine-attribute") failed - address: ([
> ("subsystem" => "messaging-activemq"),
> ("server" => "default"),
> ("connection-factory" => "RemoteConnectionFactory")
> ]): java.lang.UnsupportedOperationException: WFLYMSGAMQ0053: Runtime handling for protocol-manager-factory is not implemented
> at org.wildfly.extension.messaging.activemq.jms.ConnectionFactoryWriteAttributeHandler.applyOperationToActiveMQService(ConnectionFactoryWriteAttributeHandler.java:189)
> at org.wildfly.extension.messaging.activemq.jms.ConnectionFactoryWriteAttributeHandler.applyUpdateToRuntime(ConnectionFactoryWriteAttributeHandler.java:96)
> at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:104)
> 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:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-6627) Runtime handling for protocol-manager-factory is not implemented on "connection-factory"
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-6627?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet resolved WFLY-6627.
-------------------------------------
Fix Version/s: 14.0.0.Final
Resolution: Out of Date
> Runtime handling for protocol-manager-factory is not implemented on "connection-factory"
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-6627
> URL: https://issues.jboss.org/browse/WFLY-6627
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Chen Maoqian
> Assignee: Chen Maoqian
> Fix For: 14.0.0.Final
>
> Attachments: WFLY-6627.patch
>
>
> When trying to update attribute _protocol-manager-factory_ of _/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory_ it raises the following exception
> {code:java}
> 17:36:06,807 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("undefine-attribute") failed - address: ([
> ("subsystem" => "messaging-activemq"),
> ("server" => "default"),
> ("connection-factory" => "RemoteConnectionFactory")
> ]): java.lang.UnsupportedOperationException: WFLYMSGAMQ0053: Runtime handling for protocol-manager-factory is not implemented
> at org.wildfly.extension.messaging.activemq.jms.ConnectionFactoryWriteAttributeHandler.applyOperationToActiveMQService(ConnectionFactoryWriteAttributeHandler.java:189)
> at org.wildfly.extension.messaging.activemq.jms.ConnectionFactoryWriteAttributeHandler.applyUpdateToRuntime(ConnectionFactoryWriteAttributeHandler.java:96)
> at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:104)
> 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:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (DROOLS-1742) NPE in RuleNetworkEvaluator after incremental compilation
by Jiri Locker (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1742?page=com.atlassian.jira.plugi... ]
Jiri Locker updated DROOLS-1742:
--------------------------------
Summary: NPE in RuleNetworkEvaluator after incremental compilation (was: NPE in RuleNEtworkEvaluator after incremental compilation)
> NPE in RuleNetworkEvaluator after incremental compilation
> ---------------------------------------------------------
>
> Key: DROOLS-1742
> URL: https://issues.jboss.org/browse/DROOLS-1742
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.3.0.Final
> Reporter: Théophane Charbonnier
> Assignee: Mario Fusco
> Attachments: drools-path-memory-reproducer.zip
>
>
> Having the following drl files :
> {code:drl}
> package org.hightea.a
> import org.drools.compiler.Message
> import org.drools.compiler.FirstClass
> rule "RG_1"
> when
> $event : Message()
> FirstClass(item1 == $event.message1)
> then
> System.out.println("RG_1");
> end
> {code}
> and
> {code:drl}
> package org.hightea.b
> import org.drools.compiler.Message
> import org.drools.compiler.SecondClass
> rule "RG_2"
> when
> $event: Message()
> SecondClass(item1 == $event.message1)
> then
> System.out.println("RG_2");
> end
> {code}
> We create a module containing the two packages in two drl files and insert a `SecondClass` fact in the WM.
> Then we want to incrementally update to a new module containing only the second DRL.
> At first fireAllrules after update, we encounter a NPE in RuleNetwork evaluator (a Segment memory is not defined in the path memory)
> {code:java}
> java.lang.NullPointerException
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:114)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:212)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:87)
> at org.drools.core.concurrent.AbstractRuleEvaluator.internalEvaluateAndFire(AbstractRuleEvaluator.java:34)
> at org.drools.core.concurrent.SequentialRuleEvaluator.evaluateAndFire(SequentialRuleEvaluator.java:43)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1067)
> at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1014)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1006)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1295)
> at org.hightea.IncrementalRemoveRuleTest.testNpeInRuleNetworkEvaluator(IncrementalRemoveRuleTest.java:66)
> {code}
> Note that we don't encounter this issue when the packages names are the same, or if we exchange the order of drl file name in the first module.
> A reproducer is attached with its source code at [https://github.com/hightea/drools-reproducer/tree/path-memory-issue|https...]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months