[JBoss JIRA] (DROOLS-1404) Alpha node not shared with static function evaluation
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1404?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-1404:
-----------------------------------
Affects Version/s: 7.0.0.Beta5
6.3.0.Final
> Alpha node not shared with static function evaluation
> -----------------------------------------------------
>
> Key: DROOLS-1404
> URL: https://issues.jboss.org/browse/DROOLS-1404
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final, 7.0.0.Beta5
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
>
> The following code when placed in Misc2Test exhibit the problem
> {code:java}
> public static class TestStaticUtils {
> public static int return1() {
> return 1;
> }
> }
>
> @Test
> public void testCheck2() {
> String drl = "package c;\n" + // <<- keep this package name
> "\n" +
> "import " + TestObject.class.getCanonicalName() + "\n" +
> "\n" +
> "rule fileBrule1 when\n" +
> " TestObject(value == 1)\n" +
> "then\n" +
> "end"
> ;
>
> String drl2 = "package iTransiberian;\n" + // <<- keep this package name
> "\n" +
> "import " + TestObject.class.getCanonicalName() + "\n" +
> "import " + TestStaticUtils.class.getCanonicalName() + "\n" +
> "\n" +
> "rule fileArule1 when\n" +
> " $t : String()\n" +
> " TestObject(value == TestStaticUtils.return1() )\n" +
> "then\n" +
> "end\n"+
> "rule fileArule2 when\n" + // <<- keep this rule
> " $t : String()\n" +
> " TestObject(value == 0 )\n" +
> "then\n" +
> "end\n" +
> ""
> ;
> KieSession kieSession = new KieHelper()
> .addContent(drl2, ResourceType.DRL)
> .addContent(drl, ResourceType.DRL)
> .build().newKieSession();
>
> ReteDumper.dumpRete(kieSession);
> System.out.println(drl);
> System.out.println(drl2);
> kieSession.addEventListener(new DebugAgendaEventListener());
> kieSession.insert("test");
> kieSession.insert(new TestObject(1));
> assertEquals(2, kieSession.fireAllRules() );
> }
> {code}
> Conducting further analysis...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (DROOLS-1404) Alpha node not shared with static function evaluation
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1404?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-1404:
----------------------------------------
This issue was partially linked (not caused, not follow-up, simply in some forms of relations) to:
* [DROOLS-588] as in: we want the expression character-wise-the-same but from different package could evaluate differently and be aware of that (method {{MvelConstraint.equals(Object object, InternalKnowledgeBase kbase)}} )
* [JBRULES-3658] ref test case in [ https://github.com/droolsjbpm/drools/commit/0a5659ccf5696176453ffabd7a617... ] as in: we want to share the alpha node if their FieldValue evaluate to the same value
Attn: not only FieldValue(38) == FieldValue(37+1) but also in the test case above in this ticket [DROOLS-1404] as: FieldValue(1) == FieldValue( TestStaticUtils.return1() )
which has been implemented as part of [JBRULES-3658]:
{code:java}
public boolean equals(final Object object) {
...
MvelConstraint other = (MvelConstraint) object;
- if (!expression.equals(other.expression)) {
- return false;
+ if (isAlphaHashable()) {
+ if ( !other.isAlphaHashable() ||
+ !getLeftForEqualExpression().equals(other.getLeftForEqualExpression()) ||
+ !fieldValue.equals(other.fieldValue) ) {
+ return false;
+ }
+ } else {
+ if (!expression.equals(other.expression)) {
+ return false;
+ }
}
{code}
> Alpha node not shared with static function evaluation
> -----------------------------------------------------
>
> Key: DROOLS-1404
> URL: https://issues.jboss.org/browse/DROOLS-1404
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
>
> The following code when placed in Misc2Test exhibit the problem
> {code:java}
> public static class TestStaticUtils {
> public static int return1() {
> return 1;
> }
> }
>
> @Test
> public void testCheck2() {
> String drl = "package c;\n" + // <<- keep this package name
> "\n" +
> "import " + TestObject.class.getCanonicalName() + "\n" +
> "\n" +
> "rule fileBrule1 when\n" +
> " TestObject(value == 1)\n" +
> "then\n" +
> "end"
> ;
>
> String drl2 = "package iTransiberian;\n" + // <<- keep this package name
> "\n" +
> "import " + TestObject.class.getCanonicalName() + "\n" +
> "import " + TestStaticUtils.class.getCanonicalName() + "\n" +
> "\n" +
> "rule fileArule1 when\n" +
> " $t : String()\n" +
> " TestObject(value == TestStaticUtils.return1() )\n" +
> "then\n" +
> "end\n"+
> "rule fileArule2 when\n" + // <<- keep this rule
> " $t : String()\n" +
> " TestObject(value == 0 )\n" +
> "then\n" +
> "end\n" +
> ""
> ;
> KieSession kieSession = new KieHelper()
> .addContent(drl2, ResourceType.DRL)
> .addContent(drl, ResourceType.DRL)
> .build().newKieSession();
>
> ReteDumper.dumpRete(kieSession);
> System.out.println(drl);
> System.out.println(drl2);
> kieSession.addEventListener(new DebugAgendaEventListener());
> kieSession.insert("test");
> kieSession.insert(new TestObject(1));
> assertEquals(2, kieSession.fireAllRules() );
> }
> {code}
> Conducting further analysis...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2186) Salted password cannot be set through CLI for Elytron filesystem-realm identity
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2186?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-2186:
----------------------------------------------
[~michpetrov], taking over.
JF
> Salted password cannot be set through CLI for Elytron filesystem-realm identity
> -------------------------------------------------------------------------------
>
> Key: WFCORE-2186
> URL: https://issues.jboss.org/browse/WFCORE-2186
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 3.0.0.Alpha16
> Reporter: Ondrej Lukas
> Assignee: Michal Petrov
>
> Password encryption/hash mechanisms which contain {{salt}} attribute for filesystem-realm identity cannot be added through CLI. {{set-password}} operation fails and finishes with failure-description "WFLYCTL0155: password may not be null" even if password was set. It seems when {{salt}} attribute with {{bytes}} value is used then {{password}} attribute is ignored by CLI.
> Following password encryption/hash mechanisms from filesystem-realm identity are affected by issue:
> - {{bcrypt}}
> - {{salted-simple-digest}}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2186) Salted password cannot be set through CLI for Elytron filesystem-realm identity
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2186?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise reassigned WFCORE-2186:
--------------------------------------------
Assignee: Jean-Francois Denise (was: Michal Petrov)
> Salted password cannot be set through CLI for Elytron filesystem-realm identity
> -------------------------------------------------------------------------------
>
> Key: WFCORE-2186
> URL: https://issues.jboss.org/browse/WFCORE-2186
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 3.0.0.Alpha16
> Reporter: Ondrej Lukas
> Assignee: Jean-Francois Denise
>
> Password encryption/hash mechanisms which contain {{salt}} attribute for filesystem-realm identity cannot be added through CLI. {{set-password}} operation fails and finishes with failure-description "WFLYCTL0155: password may not be null" even if password was set. It seems when {{salt}} attribute with {{bytes}} value is used then {{password}} attribute is ignored by CLI.
> Following password encryption/hash mechanisms from filesystem-realm identity are affected by issue:
> - {{bcrypt}}
> - {{salted-simple-digest}}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JGRP-2150) More efficient message adding and draining
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2150?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2150.
----------------------------
Resolution: Done
Implemented for NAKACK2, UNICAST3 and SEQUENCER2, but not for MaxOneThreadPerSenderPolicy
> More efficient message adding and draining
> ------------------------------------------
>
> Key: JGRP-2150
> URL: https://issues.jboss.org/browse/JGRP-2150
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Labels: CR1
> Fix For: 4.0
>
>
> In NAKACK2, UNICAST3 and in MaxOneThreadPerSenderPolicy, we have a pattern where one or more producers add messages (to a table in NAKACK2 and UNICAST3, or to a MessageBatch in MaxOneThreadPerSenderPolicy) and then only *a single thread* can remove and deliver messages up the stack.
> This requires synchronization around (1) determining the thread which will remove messages, (2) adding messages to the table (or batch) and (3) removing messages from the table or batch.
> Unit tests DrainTest and MessageBatchDrainTest show how a simple AtomicInteger can be used to do this.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2186) Salted password cannot be set through CLI for Elytron filesystem-realm identity
by Michal Petrov (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2186?page=com.atlassian.jira.plugi... ]
Michal Petrov commented on WFCORE-2186:
---------------------------------------
[~jdenise] you can take over. I was working on it (and apparently heading in the right direction) but I'm not that familiar with CLI. :)
> Salted password cannot be set through CLI for Elytron filesystem-realm identity
> -------------------------------------------------------------------------------
>
> Key: WFCORE-2186
> URL: https://issues.jboss.org/browse/WFCORE-2186
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 3.0.0.Alpha16
> Reporter: Ondrej Lukas
> Assignee: Michal Petrov
>
> Password encryption/hash mechanisms which contain {{salt}} attribute for filesystem-realm identity cannot be added through CLI. {{set-password}} operation fails and finishes with failure-description "WFLYCTL0155: password may not be null" even if password was set. It seems when {{salt}} attribute with {{bytes}} value is used then {{password}} attribute is ignored by CLI.
> Following password encryption/hash mechanisms from filesystem-realm identity are affected by issue:
> - {{bcrypt}}
> - {{salted-simple-digest}}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (ELY-874) Make ServerAuthenticationContext implement AutoCloseable (with no exceptions)
by David Lloyd (JIRA)
David Lloyd created ELY-874:
-------------------------------
Summary: Make ServerAuthenticationContext implement AutoCloseable (with no exceptions)
Key: ELY-874
URL: https://issues.jboss.org/browse/ELY-874
Project: WildFly Elytron
Issue Type: Enhancement
Components: API / SPI
Reporter: David Lloyd
Priority: Minor
It's pretty easy to forget to clean up a ServerAuthenticationContext when using it directly for simple authentication. We can make this easier by making it implement AutoCloseable with a close() method that fails the authentication if it is still open.
The logic would basically be similar to {{if (! isDone()) fail();}} but with the difference that it should be atomic, and it should not be declared to throw any exceptions because none are possible in this scenario.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JGRP-2150) More efficient message adding and draining
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2150?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2150:
--------------------------------
Had to remove {{max_msg_batch}} from UNICAST3 and NAKACK2 as partial removal would have rendered the algorithm above incorrect (counter was decremented, but msgs were still left in the table!).
> More efficient message adding and draining
> ------------------------------------------
>
> Key: JGRP-2150
> URL: https://issues.jboss.org/browse/JGRP-2150
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Labels: CR1
> Fix For: 4.0
>
>
> In NAKACK2, UNICAST3 and in MaxOneThreadPerSenderPolicy, we have a pattern where one or more producers add messages (to a table in NAKACK2 and UNICAST3, or to a MessageBatch in MaxOneThreadPerSenderPolicy) and then only *a single thread* can remove and deliver messages up the stack.
> This requires synchronization around (1) determining the thread which will remove messages, (2) adding messages to the table (or batch) and (3) removing messages from the table or batch.
> Unit tests DrainTest and MessageBatchDrainTest show how a simple AtomicInteger can be used to do this.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-1752) The deployment-overlay command fails to redeploy affected deployments
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1752?page=com.atlassian.jira.plugi... ]
Brian Stansberry edited comment on WFCORE-1752 at 1/13/17 10:55 AM:
--------------------------------------------------------------------
And for myself. :) It was kind of a brainstorming question. A deployment-overlay resource could certainly have a "redeploy-affected" operation where it works out the set of affected deployments and adds steps to redeploy them. The full set of deployments, their runtime names, and their enabled status would all be available to the handler for such an operation.
I generally don't like adding lots of server-side operations that are just convenience ops for things the client could do. That leads to a cluttered API and might make it harder to evolve the server later without breaking compatibility. But in this case we may have to, since it seems this really isn't something the client can do in a reasonable manner.
was (Author: brian.stansberry):
And for myself. :) It was kind of a brainstorming question. A deployment-overlay resource could certainly have a "redeploy-affected" operation where it works out the set of affected deployments and adds steps to redeploy them. The full set of deployments, their runtime names, and their enabled status would all be available to the handler for such an operation.
I generally don't like adding lots of server-side operations that are just convenience ops for things the client could do. That leads to a cluttered API and might make it harder to evolve the server later without breaking compatibility. But in this case we may have to, since it seems this isn't something the client really can do in a reasonable manner.
> The deployment-overlay command fails to redeploy affected deployments
> ---------------------------------------------------------------------
>
> Key: WFCORE-1752
> URL: https://issues.jboss.org/browse/WFCORE-1752
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 3.0.0.Alpha5
> Reporter: ehsavoie Hugonnet
> Assignee: Jean-Francois Denise
>
> The deployment-overlay command fails to redeploy affected deployments if the runtime-name isn't the same as the deployment name. Since affected deployment to be redeployed should be running the couple runtime-name + enabled == true should be used to define which deployments are affected instead of using the deployment name since the name used in overlay is the runtime-name
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-1752) The deployment-overlay command fails to redeploy affected deployments
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1752?page=com.atlassian.jira.plugi... ]
Brian Stansberry edited comment on WFCORE-1752 at 1/13/17 10:54 AM:
--------------------------------------------------------------------
And for myself. :) It was kind of a brainstorming question. A deployment-overlay resource could certainly have a "redeploy-affected" operation where it works out the set of affected deployments and adds steps to redeploy them. The full set of deployments, their runtime names, and their enabled status would all be available to the handler for such an operation.
I generally don't like adding lots of server-side operations that are just convenience ops for things the client could do. That leads to a cluttered API and might make it harder to evolve the server later without breaking compatibility. But in this case we may have to, since it seems this isn't something the client really can do in a reasonable manner.
was (Author: brian.stansberry):
And for myself. :) It was kind of a brainstorming question. A deployment-overlay resource could certainly have a "redeploy-affected" operation where it works out the set of affected deployments and adds steps to redeploy them. The full set of deployments, their runtime names, and their enabled status would all be available to the handler for such an operation.
I generally don't like adding lots of server-side operations that are just convenience ops for things the client could do. That leads to a cluttered API and might make it harder to evolve the server later without breaking compatibility. But in this case we may have to, since it seems this isn't something the client really can't do in a reasonable manner.
> The deployment-overlay command fails to redeploy affected deployments
> ---------------------------------------------------------------------
>
> Key: WFCORE-1752
> URL: https://issues.jboss.org/browse/WFCORE-1752
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 3.0.0.Alpha5
> Reporter: ehsavoie Hugonnet
> Assignee: Jean-Francois Denise
>
> The deployment-overlay command fails to redeploy affected deployments if the runtime-name isn't the same as the deployment name. Since affected deployment to be redeployed should be running the couple runtime-name + enabled == true should be used to define which deployments are affected instead of using the deployment name since the name used in overlay is the runtime-name
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months