[Red Hat JIRA] (DROOLS-6019) Using Java 8 stream lambda in RHS leads to compilation error
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-6019?page=com.atlassian.jira.plug... ]
Mario Fusco commented on DROOLS-6019:
-------------------------------------
I reproduced the problem with the following unit test
{code:java}
@Test
public void testLambdaInConsequence() {
// DROOLS-6019
String str =
"import " + List.class.getCanonicalName() + ";\n" +
"import " + Person.class.getCanonicalName() + ";\n" +
"rule R1 when\n" +
" $l: List()\n" +
" $p: Person()\n" +
"then\n" +
" $l.forEach( x -> { System.out.println(x); } );\n" +
" $p.setName(\"Mario\");\n" +
"end\n";
KieSession ksession = getKieSession( str );
Person person = new Person( "Mark", 45 );
ksession.insert( person );
ksession.insert( new ArrayList<>() );
assertEquals(1, ksession.fireAllRules());
assertEquals("Mario", person.getName());
} {code}
Note that this happens only if you have a lambda with an inner block, in this case if you rewrite it as
{code:java}
$l.forEach( x -> System.out.println(x) );{code}
then it works.
We planned to replace the old antlr3 based Java parser that we use in drools-compiler with the newer parser that we're already using to generate the executable model as explained here https://issues.redhat.com/browse/DROOLS-4397 and this rework will also implicitly solve this problem. I already checked that the drl above works with the executable model.
> Using Java 8 stream lambda in RHS leads to compilation error
> -------------------------------------------------------------
>
> Key: DROOLS-6019
> URL: https://issues.redhat.com/browse/DROOLS-6019
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.32.0.Final, 7.49.0.Final
> Reporter: Christoph Mayr-Dorn
> Assignee: Mario Fusco
> Priority: Major
> Attachments: DroolsLambdaDemo.zip
>
>
> When using a lambda expression in the left hand side, any variable that is first used after the lambda expression is not added as a method parameter of (defaultConsequence), and leads to error of the following type:
> Exception in thread "main" java.lang.RuntimeException: Rule Base Build Errors:Exception in thread "main" java.lang.RuntimeException: Rule Base Build Errors:Error Messages:Message [id=1, kieBase=defaultKieBase, level=ERROR, path=rules/demo.drl, line=9, column=0 text=Rule Compilation error $other cannot be resolved]---Warning Messages:---Info Messages:
> at demo.StartDemo.createKsessionFromFiles(StartDemo.java:51) at demo.StartDemo.main(StartDemo.java:20)
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (ELY-2087) Error code 12000 has been duplicated
by Darran Lofthouse (Jira)
Darran Lofthouse created ELY-2087:
-------------------------------------
Summary: Error code 12000 has been duplicated
Key: ELY-2087
URL: https://issues.redhat.com/browse/ELY-2087
Project: WildFly Elytron
Issue Type: Bug
Components: Audit, Credential Store
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
When new error codes were added to the audit module these did not reserve the full range just a subset so the credential store module has reserved an overlapping range.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (DROOLS-6020) Separate drools-model-compiler generator from interpreter
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-6020?page=com.atlassian.jira.plug... ]
Luca Molteni updated DROOLS-6020:
---------------------------------
Description:
Currently in the executable model the `drools-model-compiler` has the code to generate executable model DSL under the package `org.drools.modelcompiler.builder.generator` and the interpreter that takes the DSL as the input and outputs the RETE under the `org.drools.modelcompiler` package.
These two packages can be split in two modules, i.e.
drools-executable-model-compiler
drools-executable-model-runtime
So that when having a KJAR with the DSL compiled, only the latter is needed to execute it.
Note that currently the compiler outputs the DSL based on these classes
{code:java}
package org.drools.modelcompiler.dsl.flow;
public class D extends FlowDSL {
}
public class D extends PatternDSL {
}
{code}
And this has to be changed, as while executing it there'll be no modelcompiler jar.
At the same time we should keep a copy of those classes in that position so that we don't loose backwards compilation
was:
Currently in the executable model the `drools-model-compiler` has the code to generate executable model DSL under the package `org.drools.modelcompiler.builder.generator` and the interpreter that takes the DSL as the input and outputs the RETE under the `org.drools.modelcompiler` package.
These two packages can be split in two modules, i.e.
drools-executable-model-compiler
drools-executable-model-runtime
So that when having a KJAR with the DSL compiled, only the latter is needed to execute it.
Note that currently the compiler outputs the DSL based on these classes
{code:java}
package org.drools.modelcompiler.dsl.flow;
public class D extends FlowDSL {
}
public class D extends PatternDSL {
}
{code}
And this has to be changed, as while executing it there'll be no modelcompiler jar.
> Separate drools-model-compiler generator from interpreter
> ---------------------------------------------------------
>
> Key: DROOLS-6020
> URL: https://issues.redhat.com/browse/DROOLS-6020
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Reporter: Luca Molteni
> Assignee: Luca Molteni
> Priority: Major
>
> Currently in the executable model the `drools-model-compiler` has the code to generate executable model DSL under the package `org.drools.modelcompiler.builder.generator` and the interpreter that takes the DSL as the input and outputs the RETE under the `org.drools.modelcompiler` package.
> These two packages can be split in two modules, i.e.
> drools-executable-model-compiler
> drools-executable-model-runtime
> So that when having a KJAR with the DSL compiled, only the latter is needed to execute it.
> Note that currently the compiler outputs the DSL based on these classes
> {code:java}
> package org.drools.modelcompiler.dsl.flow;
> public class D extends FlowDSL {
> }
> public class D extends PatternDSL {
> }
> {code}
> And this has to be changed, as while executing it there'll be no modelcompiler jar.
> At the same time we should keep a copy of those classes in that position so that we don't loose backwards compilation
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (DROOLS-6020) Separate drools-model-compiler generator from interpreter
by Luca Molteni (Jira)
Luca Molteni created DROOLS-6020:
------------------------------------
Summary: Separate drools-model-compiler generator from interpreter
Key: DROOLS-6020
URL: https://issues.redhat.com/browse/DROOLS-6020
Project: Drools
Issue Type: Bug
Components: executable model
Reporter: Luca Molteni
Assignee: Luca Molteni
Currently in the executable model the `drools-model-compiler` has the code to generate executable model DSL under the package `org.drools.modelcompiler.builder.generator` and the interpreter that takes the DSL as the input and outputs the RETE under the `org.drools.modelcompiler` package.
These two packages can be split in two modules, i.e.
drools-executable-model-compiler
drools-executable-model-runtime
So that when having a KJAR with the DSL compiled, only the latter is needed to execute it.
Note that currently the compiler outputs the DSL based on these classes
{code:java}
package org.drools.modelcompiler.dsl.flow;
public class D extends FlowDSL {
}
public class D extends PatternDSL {
}
{code}
And this has to be changed, as while executing it there'll be no modelcompiler jar.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14420) Automatic credential store update not triggered when enabling single-sign-on using a credential-reference
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-14420?page=com.atlassian.jira.plugi... ]
Paul Ferraro commented on WFLY-14420:
-------------------------------------
[~fjuma] I think I see the problem.
The /subsystem=undertow/application-security-domain=other/setting=single-sign-on:add puts the server into reload-required, rather than trigger a restart of the parent's runtime handling. Since the SSO services are installed by the parent, the CredentialReference.getCredentialSourceSupplier(...) stuff is never triggered.
If the CLI in the description were to execute the /subsystem=undertow/application-security-domain=other:add and /subsystem=undertow/application-security-domain=other/setting=single-sign-on:add operations in a batch, this should work as expected.
IMO, there is not reason why a resource whose runtime services were never requested should force the server into reload-required. I'll see about fixing this within the context of this jira.
> Automatic credential store update not triggered when enabling single-sign-on using a credential-reference
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-14420
> URL: https://issues.redhat.com/browse/WFLY-14420
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Reporter: Farah Juma
> Assignee: Paul Ferraro
> Priority: Major
>
> When enabling {{single-sign-on}} with a {{credential-reference}} in the Undertow subsystem using the {{store}} and {{clear-text}} attributes, the automatic credential store update that should happen is never triggered. Looking closer, it appears that the appropriate model update takes place (e.g., the {{clear-text}} attribute is saved and removed from the model) but the actual runtime update to the credential store itself is never triggered. This issue can be reproduced using the following steps:
>
> {code:xml}
> ### Pre-requisite steps
> /subsystem=elytron/credential-store=myCredStore:add(location=mycredstore.cs, relative-to=jboss.server.config.dir, credential-reference={clear-text=StorePassword}, create=true)
> /subsystem=undertow/application-security-domain=other:add(security-domain=ApplicationDomain)
> /subsystem=elytron/key-store=myKS:add(path=keystore.jks, relative-to=jboss.server.config.dir, credential-reference={clear-text=secret}, type=JKS)
> ### Enable single-sign-on
> /subsystem=undertow/application-security-domain=other/setting=single-sign-on:add(key-store=myKS, key-alias=localhost, domain=localhost, credential-reference={store=myCredStore,alias=myNewAlias,clear-text=myNewPassword})
> # At this point, the output of the above operation is supposed to indicate that a credential-store update took place and executing the read-aliases() operation on the credential-store is supposed to show 'myNewAlias'. However, this doesn't happen.{code}
>
> This issue only affects credential store updates that take place when enabling {{single-sign-on}}. If the {{credential-reference.clear-text}} value is updated for an existing {{single-sign-on}} element using the {{write-attribute}} operation, the corresponding credential store update is successfully triggered.
> As a quick sanity check, I tried testing credential store updates with some other resources from the clustering subsystems (e.g., I tried adding the jgroups AUTH protocol resource with {{key-credential-reference}} and {{shared-secret-reference}}) but the credential store update was successfully triggered for these when adding the resource. The main difference appears to be that {{CredentialReference.getCredentialSourceSupplier(...)}} is successfully triggered during the runtime phase in this case but it does not get triggered for the {{single-sign-on}} case. This method triggers the credential store update.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14424) Add EJB client test case for interacting with two non-overlapping clusters
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-14424?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz commented on WFLY-14424:
--------------------------------------------
The server configurations are different (one has outbound connections, the other does not) and setting up the two clusters is really simple in any case, so reuse would be minimal. Part of the reason for creating this test case is to show in a simple way configuration of two clusters and interaction of the EJB client with the the clusters, so keeping things self-contained is an advantage.
> Add EJB client test case for interacting with two non-overlapping clusters
> ---------------------------------------------------------------------------
>
> Key: WFLY-14424
> URL: https://issues.redhat.com/browse/WFLY-14424
> Project: WildFly
> Issue Type: Task
> Components: Clustering
> Affects Versions: 22.0.0.Final
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
> Fix For: 23.0.0.Beta1
>
>
> Write a test case which shows:
> * how to configure two non-overlapping clusters
> * how to specify the cluster affinity value which will be generated by the cluster for use in topology updates
> * the creation of EJB client proxies which can interact with those clusters via the cluster specification
> * creation of proxies using EJBClient API and JNDI lookup for both stateful and stateless bean deployments
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14251) Consolidated JMS queue count not working on Cluster setup.
by rutu rutu (Jira)
[ https://issues.redhat.com/browse/WFLY-14251?page=com.atlassian.jira.plugi... ]
rutu rutu commented on WFLY-14251:
----------------------------------
Thanks, for work around we have used JMX access to each jvm in cluster to fetch Queue count.
> Consolidated JMS queue count not working on Cluster setup.
> ----------------------------------------------------------
>
> Key: WFLY-14251
> URL: https://issues.redhat.com/browse/WFLY-14251
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: rutu rutu
> Assignee: Emmanuel Hugonnet
> Priority: Major
>
> Cluster setup :
> Server 1 : Master i.e manager console.
> Server 2 : Slave 1
> Server 3 : Slave 2
> From Master single EAR gets deployed on al servers.
> When JMS message gets pushed then as per MDB limit it get distrubuted in any of the server 1 or 2 as per RoundRobinPolicy.
> Here msg distrubutution is happing properly.
> Now from any server when Queue is paused , its also getting reflected.
> i.e same queue gets paused from another server.
> But
> say 10 jms msg is pused on Queue.
> it got distrubuted as
> Server-1 : 3
> Server-2 : 7
> now when server-1 looks how many msg are present on Queue it gets only 3
> As this setup is in Cluster , why queue count information is not being shared.
>
> subsystem xmlns="urn:jboss:domain:messaging-activemq
>
> <pooled-connection-factory name="activemq-ra" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="http-connector in-vm" ha="true" auto-group="true" transaction="xa" "/>
> Here tried both
> connectors="http-connector in-vm"
> connectors="http-connector"
> Note :
> connectors="http-connector ---------> This controls start/pause across servers.
> connectors="in-vm" ---------> This controls start/pause on Local servers.
> Here what should be the setting so count can be same across servers in cluster
> <subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
> <server name="default">
> <security enabled="false"/>
> <cluster password="${jboss.messaging.cluster.password:rutu}"/>
> <management address="localhost" jmx-enabled="true" jmx-domain="org.apache.activemq.artemis"/>
> <message-expiry scan-period="130000"/>
> <security-setting name="#">
> <role name="guest" send="true" consume="true" create-non-durable-queue="true" delete-non-durable-queue="true"/>
> </security-setting>
> <address-setting name="#" dead-letter-address="jms.queue.mq.sys.dmq" expiry-address="jms.queue.ExpiryQueue" max-delivery-attempts="2" max-size-bytes="10485760" page-size-bytes="2097152" message-counter-history-day-limit="10"/>
> <http-connector name="http-connector" socket-binding="http" endpoint="http-acceptor"/>
> <http-connector name="http-connector-throughput" socket-binding="http" endpoint="http-acceptor-throughput">
> <param name="batch-delay" value="50"/>
> </http-connector>
> <in-vm-connector name="in-vm" server-id="0">
> <param name="buffer-pooling" value="false"/>
> </in-vm-connector>
> <http-acceptor name="http-acceptor" http-listener="default"/>
> <http-acceptor name="http-acceptor-throughput" http-listener="default">
> <param name="batch-delay" value="50"/>
> <param name="direct-deliver" value="false"/>
> </http-acceptor>
> <remote-acceptor name="internal-messaging-acceptor" socket-binding="internal-messaging"/>
> <in-vm-acceptor name="in-vm" server-id="0">
> <param name="buffer-pooling" value="false"/>
> </in-vm-acceptor>
> <broadcast-group name="bg-group1" jgroups-cluster="activemq-cluster" connectors="http-connector"/>
> <discovery-group name="dg-group1" jgroups-cluster="activemq-cluster"/>
> <cluster-connection name="my-cluster" address="jms" connector-name="http-connector" discovery-group="dg-group1"/>
> <jms-queue name="ExpiryQueue" entries="java:/jms/queue/ExpiryQueue"/>
> <jms-queue name="DLQ" entries="java:/jms/queue/DLQ"/>
> <jms-queue name="dummy" entries="java:/queue/dummy java:jboss/exported/jms/queue/dummy"/>
> <jms-queue name="mq.sys.dmq" entries="java:/queue/mq.sys.dmq java:jboss/exported/jms/queue/mq.sys.dmq"/>
> <jms-queue name="AccountingQueue" entries="java:/queue/AccountingQueue java:jboss/exported/jms/queue/AccountingQueue"/>
> <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/>
> <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory" connectors="http-connector" ha="true" block-on-acknowledge="true" reconnect-attempts="-1"/>
> <pooled-connection-factory name="activemq-ra" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="http-connector" transaction="xa"/>
>
> </server>
> </subsystem>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14251) Consolidated JMS queue count not working on Cluster setup.
by Emmanuel Hugonnet (Jira)
[ https://issues.redhat.com/browse/WFLY-14251?page=com.atlassian.jira.plugi... ]
Emmanuel Hugonnet commented on WFLY-14251:
------------------------------------------
Artemis doesn't share statistics around in a cluster. Those are bound to each broker.
> Consolidated JMS queue count not working on Cluster setup.
> ----------------------------------------------------------
>
> Key: WFLY-14251
> URL: https://issues.redhat.com/browse/WFLY-14251
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: rutu rutu
> Assignee: Emmanuel Hugonnet
> Priority: Major
>
> Cluster setup :
> Server 1 : Master i.e manager console.
> Server 2 : Slave 1
> Server 3 : Slave 2
> From Master single EAR gets deployed on al servers.
> When JMS message gets pushed then as per MDB limit it get distrubuted in any of the server 1 or 2 as per RoundRobinPolicy.
> Here msg distrubutution is happing properly.
> Now from any server when Queue is paused , its also getting reflected.
> i.e same queue gets paused from another server.
> But
> say 10 jms msg is pused on Queue.
> it got distrubuted as
> Server-1 : 3
> Server-2 : 7
> now when server-1 looks how many msg are present on Queue it gets only 3
> As this setup is in Cluster , why queue count information is not being shared.
>
> subsystem xmlns="urn:jboss:domain:messaging-activemq
>
> <pooled-connection-factory name="activemq-ra" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="http-connector in-vm" ha="true" auto-group="true" transaction="xa" "/>
> Here tried both
> connectors="http-connector in-vm"
> connectors="http-connector"
> Note :
> connectors="http-connector ---------> This controls start/pause across servers.
> connectors="in-vm" ---------> This controls start/pause on Local servers.
> Here what should be the setting so count can be same across servers in cluster
> <subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
> <server name="default">
> <security enabled="false"/>
> <cluster password="${jboss.messaging.cluster.password:rutu}"/>
> <management address="localhost" jmx-enabled="true" jmx-domain="org.apache.activemq.artemis"/>
> <message-expiry scan-period="130000"/>
> <security-setting name="#">
> <role name="guest" send="true" consume="true" create-non-durable-queue="true" delete-non-durable-queue="true"/>
> </security-setting>
> <address-setting name="#" dead-letter-address="jms.queue.mq.sys.dmq" expiry-address="jms.queue.ExpiryQueue" max-delivery-attempts="2" max-size-bytes="10485760" page-size-bytes="2097152" message-counter-history-day-limit="10"/>
> <http-connector name="http-connector" socket-binding="http" endpoint="http-acceptor"/>
> <http-connector name="http-connector-throughput" socket-binding="http" endpoint="http-acceptor-throughput">
> <param name="batch-delay" value="50"/>
> </http-connector>
> <in-vm-connector name="in-vm" server-id="0">
> <param name="buffer-pooling" value="false"/>
> </in-vm-connector>
> <http-acceptor name="http-acceptor" http-listener="default"/>
> <http-acceptor name="http-acceptor-throughput" http-listener="default">
> <param name="batch-delay" value="50"/>
> <param name="direct-deliver" value="false"/>
> </http-acceptor>
> <remote-acceptor name="internal-messaging-acceptor" socket-binding="internal-messaging"/>
> <in-vm-acceptor name="in-vm" server-id="0">
> <param name="buffer-pooling" value="false"/>
> </in-vm-acceptor>
> <broadcast-group name="bg-group1" jgroups-cluster="activemq-cluster" connectors="http-connector"/>
> <discovery-group name="dg-group1" jgroups-cluster="activemq-cluster"/>
> <cluster-connection name="my-cluster" address="jms" connector-name="http-connector" discovery-group="dg-group1"/>
> <jms-queue name="ExpiryQueue" entries="java:/jms/queue/ExpiryQueue"/>
> <jms-queue name="DLQ" entries="java:/jms/queue/DLQ"/>
> <jms-queue name="dummy" entries="java:/queue/dummy java:jboss/exported/jms/queue/dummy"/>
> <jms-queue name="mq.sys.dmq" entries="java:/queue/mq.sys.dmq java:jboss/exported/jms/queue/mq.sys.dmq"/>
> <jms-queue name="AccountingQueue" entries="java:/queue/AccountingQueue java:jboss/exported/jms/queue/AccountingQueue"/>
> <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/>
> <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory" connectors="http-connector" ha="true" block-on-acknowledge="true" reconnect-attempts="-1"/>
> <pooled-connection-factory name="activemq-ra" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="http-connector" transaction="xa"/>
>
> </server>
> </subsystem>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months