[JBoss JIRA] (DROOLS-5635) NPE in executable model using an existental pattern in an accumulate and binding the accumulated value with a from
by Mario Fusco (Jira)
Mario Fusco created DROOLS-5635:
-----------------------------------
Summary: NPE in executable model using an existental pattern in an accumulate and binding the accumulated value with a from
Key: DROOLS-5635
URL: https://issues.redhat.com/browse/DROOLS-5635
Project: Drools
Issue Type: Bug
Reporter: Mario Fusco
Assignee: Mario Fusco
Using an existental pattern in an accumulate and binding the accumulated value with a from like in the following LHS
{code:java}
accumulate ( $p: Person ( getName().startsWith(\"M\") ) and exists(String());
$sum : sum($p.getAge())
)
$s: String() from $sum.toString() {code}
causes this NPE in the executable model
{code:java}
java.lang.NullPointerException
at org.drools.core.rule.LogicTransformer.processElement(LogicTransformer.java:193)
at org.drools.core.rule.LogicTransformer.processElement(LogicTransformer.java:168)
at org.drools.core.rule.LogicTransformer.processElement(LogicTransformer.java:250)
at org.drools.core.rule.LogicTransformer.fixClonedDeclarations(LogicTransformer.java:153)
at org.drools.core.rule.LogicTransformer.transform(LogicTransformer.java:96)
at org.drools.core.definitions.rule.impl.RuleImpl.getTransformedLhs(RuleImpl.java:601)
at org.drools.core.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:115)
at org.drools.core.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:110){code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFWIP-355) Bootable JAR - bin folder of the server installation directory are not executable
by Tommaso Borgato (Jira)
[ https://issues.redhat.com/browse/WFWIP-355?page=com.atlassian.jira.plugin... ]
Tommaso Borgato updated WFWIP-355:
----------------------------------
Summary: Bootable JAR - bin folder of the server installation directory are not executable (was: Bootable JAR - scripts in install-dir bin folder are not executable)
> Bootable JAR - bin folder of the server installation directory are not executable
> ---------------------------------------------------------------------------------
>
> Key: WFWIP-355
> URL: https://issues.redhat.com/browse/WFWIP-355
> Project: WildFly WIP
> Issue Type: Bug
> Reporter: Tommaso Borgato
> Assignee: Kabir Khan
> Priority: Major
>
> Related RFE: EAP7-1385
> Scripts in the bin folder of the server's installation directory are not executable;
> If you start the server like the following:
> {noformat}
> java -jar target/default-hollow-jar-bootable.jar --install-dir=/tmp/wildfly-bootable-server-hollow-jar
> {noformat}
> and the look into the bin folder:
> {noformat}
> $ ls -ltr /tmp/wildfly-bootable-server-hollow-jar/bin
> total 1520
> -rw-rw-r--. 1 hudson hudson 2362 Sep 11 10:11 vault.sh
> -rw-rw-r--. 1 hudson hudson 709 Sep 11 10:11 vault.ps1
> -rw-rw-r--. 1 hudson hudson 2269 Sep 11 10:11 vault.bat
> -rw-rw-r--. 1 hudson hudson 823 Sep 11 10:11 common.bat
> -rw-rw-r--. 1 hudson hudson 1933 Sep 11 10:11 jboss-cli-logging.properties
> -rw-rw-r--. 1 hudson hudson 3271 Sep 11 10:11 jboss-cli.bat
> -rw-rw-r--. 1 hudson hudson 792 Sep 11 10:11 common.sh
> -rw-rw-r--. 1 hudson hudson 11549 Sep 11 10:11 common.ps1
> -rw-rw-r--. 1 hudson hudson 893 Sep 11 10:11 jboss-cli.ps1
> -rw-rw-r--. 1 hudson hudson 1793 Sep 11 10:11 elytron-tool.sh
> -rw-rw-r--. 1 hudson hudson 1079 Sep 11 10:11 elytron-tool.ps1
> -rw-rw-r--. 1 hudson hudson 1710 Sep 11 10:11 elytron-tool.bat
> -rw-rw-r--. 1 hudson hudson 2392 Sep 11 10:11 add-user.sh
> -rw-rw-r--. 1 hudson hudson 3035 Sep 11 10:11 jboss-cli.xml
> -rw-rw-r--. 1 hudson hudson 2635 Sep 11 10:11 jboss-cli.sh
> -rw-rw-r--. 1 hudson hudson 1069 Sep 11 10:11 add-user.ps1
> -rw-rw-r--. 1 hudson hudson 2444 Sep 11 10:11 add-user.properties
> -rw-rw-r--. 1 hudson hudson 2417 Sep 11 10:11 add-user.bat
> -rw-rw-r--. 1 hudson hudson 12843 Sep 11 10:11 standalone.sh
> -rw-rw-r--. 1 hudson hudson 1624 Sep 11 10:11 standalone.ps1
> -rw-rw-r--. 1 hudson hudson 3226 Sep 11 10:11 standalone.conf.ps1
> -rw-rw-r--. 1 hudson hudson 3402 Sep 11 10:11 standalone.conf.bat
> -rw-rw-r--. 1 hudson hudson 2965 Sep 11 10:11 standalone.conf
> -rw-rw-r--. 1 hudson hudson 9576 Sep 11 10:11 standalone.bat
> -rw-rw-r--. 1 hudson hudson 49 Sep 11 10:11 product.conf
> -rw-rw-r--. 1 hudson hudson 49721 Sep 11 10:11 launcher.jar
> -rw-rw-r--. 1 hudson hudson 1369074 Sep 11 10:11 wildfly-elytron-tool.jar
> {noformat}
> you can see e.g. jboss-cli.sh is not executable
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFWIP-355) Bootable JAR - scripts in install-dir bin folder are not executable
by Tommaso Borgato (Jira)
Tommaso Borgato created WFWIP-355:
-------------------------------------
Summary: Bootable JAR - scripts in install-dir bin folder are not executable
Key: WFWIP-355
URL: https://issues.redhat.com/browse/WFWIP-355
Project: WildFly WIP
Issue Type: Bug
Reporter: Tommaso Borgato
Assignee: Kabir Khan
Related RFE: EAP7-1385
Scripts in the bin folder of the server's installation directory are not executable;
If you start the server like the following:
{noformat}
java -jar target/default-hollow-jar-bootable.jar --install-dir=/tmp/wildfly-bootable-server-hollow-jar
{noformat}
and the look into the bin folder:
{noformat}
$ ls -ltr /tmp/wildfly-bootable-server-hollow-jar/bin
total 1520
-rw-rw-r--. 1 hudson hudson 2362 Sep 11 10:11 vault.sh
-rw-rw-r--. 1 hudson hudson 709 Sep 11 10:11 vault.ps1
-rw-rw-r--. 1 hudson hudson 2269 Sep 11 10:11 vault.bat
-rw-rw-r--. 1 hudson hudson 823 Sep 11 10:11 common.bat
-rw-rw-r--. 1 hudson hudson 1933 Sep 11 10:11 jboss-cli-logging.properties
-rw-rw-r--. 1 hudson hudson 3271 Sep 11 10:11 jboss-cli.bat
-rw-rw-r--. 1 hudson hudson 792 Sep 11 10:11 common.sh
-rw-rw-r--. 1 hudson hudson 11549 Sep 11 10:11 common.ps1
-rw-rw-r--. 1 hudson hudson 893 Sep 11 10:11 jboss-cli.ps1
-rw-rw-r--. 1 hudson hudson 1793 Sep 11 10:11 elytron-tool.sh
-rw-rw-r--. 1 hudson hudson 1079 Sep 11 10:11 elytron-tool.ps1
-rw-rw-r--. 1 hudson hudson 1710 Sep 11 10:11 elytron-tool.bat
-rw-rw-r--. 1 hudson hudson 2392 Sep 11 10:11 add-user.sh
-rw-rw-r--. 1 hudson hudson 3035 Sep 11 10:11 jboss-cli.xml
-rw-rw-r--. 1 hudson hudson 2635 Sep 11 10:11 jboss-cli.sh
-rw-rw-r--. 1 hudson hudson 1069 Sep 11 10:11 add-user.ps1
-rw-rw-r--. 1 hudson hudson 2444 Sep 11 10:11 add-user.properties
-rw-rw-r--. 1 hudson hudson 2417 Sep 11 10:11 add-user.bat
-rw-rw-r--. 1 hudson hudson 12843 Sep 11 10:11 standalone.sh
-rw-rw-r--. 1 hudson hudson 1624 Sep 11 10:11 standalone.ps1
-rw-rw-r--. 1 hudson hudson 3226 Sep 11 10:11 standalone.conf.ps1
-rw-rw-r--. 1 hudson hudson 3402 Sep 11 10:11 standalone.conf.bat
-rw-rw-r--. 1 hudson hudson 2965 Sep 11 10:11 standalone.conf
-rw-rw-r--. 1 hudson hudson 9576 Sep 11 10:11 standalone.bat
-rw-rw-r--. 1 hudson hudson 49 Sep 11 10:11 product.conf
-rw-rw-r--. 1 hudson hudson 49721 Sep 11 10:11 launcher.jar
-rw-rw-r--. 1 hudson hudson 1369074 Sep 11 10:11 wildfly-elytron-tool.jar
{noformat}
you can see e.g. jboss-cli.sh is not executable
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFWIP-354) Bootable JAR - jboss-maven-dist plugin param doesn't work as expected
by Jean Francois Denise (Jira)
[ https://issues.redhat.com/browse/WFWIP-354?page=com.atlassian.jira.plugin... ]
Jean Francois Denise commented on WFWIP-354:
--------------------------------------------
I would close this bug as not a bug, the options at build time and runtime are not used the way they should.
> Bootable JAR - jboss-maven-dist plugin param doesn't work as expected
> ----------------------------------------------------------------------
>
> Key: WFWIP-354
> URL: https://issues.redhat.com/browse/WFWIP-354
> Project: WildFly WIP
> Issue Type: Bug
> Reporter: Marek Kopecky
> Assignee: Jean Francois Denise
> Priority: Blocker
>
> Related RFE: EAP7-1385
> This usage of jboss-maven-dist plugin param doesn't work as expected:
> [<jboss-maven-dist>/home/mkopecky/jboss-eap-custom-maven-repository/maven-repository</jboss-maven-dist>|https://github.com/marekkopecky/Resteasy/commit/fb29381a9ef9a709f33481af8020a649db002980#diff-8c7ea03eb619e46657b96e8fe8d4f09eR248]
> Steps to reproduce:
> # clone resteasy 3.12 with this commit: https://github.com/marekkopecky/Resteasy/commit/fb29381a9ef9a709f33481af8...
> # update jboss-maven-dist plugin param to your custom repo path
> # rm -rf ~/.m2/repository/xerces/xercesImpl/2.12.0.SP03
> # set REPO variable (eg. "REPO=/home/mkopecky/jboss-eap-custom-maven-repository/maven-repository")
> # build start tests {code}mvn install -DskipTests -Dmaven.repo.local=$REPO
> cd testsuite
> mvn install:install-file -Dpackaging=pom -Dfile=pom.xml -DpomFile=pom.xml -Dmaven.repo.local=$REPO
> cd integration-tests
> mvn clean install -Dts.bootable -Ddefault=false -Ddisable.microprofile.tests -Dserver.version=21.0.0.Beta1-SNAPSHOT -Dserver.home=placeholder -Dmaven.repo.local=$REPO -Dmaven.test.redirectTestOutputToFile=false{code}
> # see the results: org.jboss.modules.ModuleLoadException, because xercesImpl 2.12.0.SP03 is downloaded in custom repo, but not present in .m2
> cc [~fburzigo], [~yersan]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFWIP-354) Bootable JAR - jboss-maven-dist plugin param doesn't work as expected
by Jean Francois Denise (Jira)
[ https://issues.redhat.com/browse/WFWIP-354?page=com.atlassian.jira.plugin... ]
Jean Francois Denise commented on WFWIP-354:
--------------------------------------------
At build time, user ask for jboss-maven-dist + jboss-maven-repo=myrepo. It means that the bootable JAR is a thin one and a local cache should be created.
At runtime, the user starts the jar providing the generated local cache path: java -Dmaven.repo.local=myrepo
> Bootable JAR - jboss-maven-dist plugin param doesn't work as expected
> ----------------------------------------------------------------------
>
> Key: WFWIP-354
> URL: https://issues.redhat.com/browse/WFWIP-354
> Project: WildFly WIP
> Issue Type: Bug
> Reporter: Marek Kopecky
> Assignee: Jean Francois Denise
> Priority: Blocker
>
> Related RFE: EAP7-1385
> This usage of jboss-maven-dist plugin param doesn't work as expected:
> [<jboss-maven-dist>/home/mkopecky/jboss-eap-custom-maven-repository/maven-repository</jboss-maven-dist>|https://github.com/marekkopecky/Resteasy/commit/fb29381a9ef9a709f33481af8020a649db002980#diff-8c7ea03eb619e46657b96e8fe8d4f09eR248]
> Steps to reproduce:
> # clone resteasy 3.12 with this commit: https://github.com/marekkopecky/Resteasy/commit/fb29381a9ef9a709f33481af8...
> # update jboss-maven-dist plugin param to your custom repo path
> # rm -rf ~/.m2/repository/xerces/xercesImpl/2.12.0.SP03
> # set REPO variable (eg. "REPO=/home/mkopecky/jboss-eap-custom-maven-repository/maven-repository")
> # build start tests {code}mvn install -DskipTests -Dmaven.repo.local=$REPO
> cd testsuite
> mvn install:install-file -Dpackaging=pom -Dfile=pom.xml -DpomFile=pom.xml -Dmaven.repo.local=$REPO
> cd integration-tests
> mvn clean install -Dts.bootable -Ddefault=false -Ddisable.microprofile.tests -Dserver.version=21.0.0.Beta1-SNAPSHOT -Dserver.home=placeholder -Dmaven.repo.local=$REPO -Dmaven.test.redirectTestOutputToFile=false{code}
> # see the results: org.jboss.modules.ModuleLoadException, because xercesImpl 2.12.0.SP03 is downloaded in custom repo, but not present in .m2
> cc [~fburzigo], [~yersan]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFLY-13779) MicroProfile Metrics tests started to fail since changes in ConfigSource
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFLY-13779?page=com.atlassian.jira.plugi... ]
Jeff Mesnil commented on WFLY-13779:
------------------------------------
I have thought about this more.
The main thing to consider is that with MicroProfile Config, the config sources are added to the Config the first time a class loader calls ConfigProviderResolver.getConfig().
Any addition/removal of a config-source provided by the subsystem will not modify existing Config associated to a ClassLoader.
In case of deployments, that means that the set of ConfigSources is determined when the deployment is deployed.
For WildFly subsystems, that means that the set of ConfigSources is determined when the use MicroProfile Config the first time. Any subsequent modifications to the microprofile-config-smallrye substem will not impact these Configs.
So I think we need to make 2 changes:
* in the WildFly codebase, flag the config-source and config-source-provider :remove operations with RESTART-ALL-SERVICES to properly notify that if these resources are removed, server must be reloaded
* in your test fixture, after removing a config-source-provider, you'll have to reload the server to get it in the proper state.
> MicroProfile Metrics tests started to fail since changes in ConfigSource
> ------------------------------------------------------------------------
>
> Key: WFLY-13779
> URL: https://issues.redhat.com/browse/WFLY-13779
> Project: WildFly
> Issue Type: Bug
> Components: MP Metrics
> Reporter: Sultan Zhantemirov
> Assignee: Jeff Mesnil
> Priority: Major
>
> WildFly build: 21.0.0.Beta1-SNAPSHOT
> Java: oracle-java-11
> A several failures appeared in our small standalone test suite [1] for MicroProfile on WF/EAP. To be more specific, a few failures in MP Metrics that have one common cause:
> {noformat}
> java.lang.RuntimeException: config.source.properties.path property not defined
> {noformat}
> caused by line [2].
> I have a reason to believe that this PR [3] could be reason of these failures. What should be done in this case?
> Thank you.
> [1] - https://github.com/jboss-eap-qe/eap-microprofile-test-suite/tree/master/m...
> [2] - https://github.com/jboss-eap-qe/eap-microprofile-test-suite/blob/8b726042...
> [3] - https://github.com/wildfly/wildfly/pull/13247
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFLY-13845) Attribute enable-amq1-prefix doesn't work (remote artemis)
by Emmanuel Hugonnet (Jira)
Emmanuel Hugonnet created WFLY-13845:
----------------------------------------
Summary: Attribute enable-amq1-prefix doesn't work (remote artemis)
Key: WFLY-13845
URL: https://issues.redhat.com/browse/WFLY-13845
Project: WildFly
Issue Type: Bug
Components: JMS, Management
Affects Versions: 20.0.1.Final
Reporter: Emmanuel Hugonnet
Assignee: Chao Wang
Fix For: 21.0.0.Beta1
I need to connect Wildfly 17.0.1 to a remote Artemis server. I follow the doc here: [https://docs.wildfly.org/17/Admin_Guide.html#Messaging_Connect_a_pooled-c...] No problem for point 1 to 3. But when I follow the instruction for disabling the compatibility mode (enable-amq1-prefix) I have this error:
{quote}{{[standalone@localhost:9990 /] /subsystem=messaging-activemq/pooled-connection-factory=remote-artemis:write-attribute(name="enable-amq1-prefix", value="false")}}
\{{{}}
\{{ "outcome" => "failed",}}
\{{ "failure-description" => "WFLYCTL0248: Invalid value false for enable-amq1-prefix; legal values are [XA_GENERIC, GENERIC, XA_T}}
{{OPIC, TOPIC, QUEUE, XA_QUEUE]",}}
\{{ "rolled-back" => true}}
{{}}}
{quote}
If I deploy my MDB that connects to queue myqueue, I see in artemis console my MDB is connected to jms.queue.myqueue.
I also tried to add the attribute manually but it seems it doesn't work:
{quote}{{<pooled-connection-factory name="remote-artemis" entries="java:/}}{{jms/remoteCF}}{{" connectors="remote-artemis" enable-amq1-prefix="false"/>}}
{quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFCORE-5131) (7.3.z) The embedded host and server handlers hang on start
by Ivo Studensky (Jira)
Ivo Studensky created WFCORE-5131:
-------------------------------------
Summary: (7.3.z) The embedded host and server handlers hang on start
Key: WFCORE-5131
URL: https://issues.redhat.com/browse/WFCORE-5131
Project: WildFly Core
Issue Type: Bug
Components: Embedded
Affects Versions: 12.0.0.Beta1
Reporter: Ivo Studensky
Assignee: Yeray Borges Santana
Fix For: 12.0.0.Beta2, 12.0.0.Final
Recently we changed the way the {{EmbedHostControllerHandler}} and {{EmbedServerHandler}} wait for the embedded host/server until it starts.
We were using a pooling executing management operations to check the process state. We needed a different solution to be able to check the process state when the embedded host/server was launched with and empty configuration file.
In the new approach we exposed the process state to the client so it can be directly pooling without requiring a management operation.
Currently the update of this internal field is racy, and a hang can occurs starting the embedded.
We saw this bug in the CI test suite: https://ci.wildfly.org/viewLog.html?buildId=197876&buildTypeId=WF_MasterW...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFCORE-5130) (7.3.z) Expose the process state from the embed server and controller
by Ivo Studensky (Jira)
Ivo Studensky created WFCORE-5130:
-------------------------------------
Summary: (7.3.z) Expose the process state from the embed server and controller
Key: WFCORE-5130
URL: https://issues.redhat.com/browse/WFCORE-5130
Project: WildFly Core
Issue Type: Enhancement
Components: Embedded
Reporter: Ivo Studensky
Assignee: Yeray Borges Santana
Fix For: 12.0.0.Beta1, 12.0.0.Final
When we are starting the embedded managed server or host controller we are polling for the process state to verify when the server or host controller are ready for the caller.
The polling is problematic to cover the case for an embedded managed host controller started with an empty host configuration file. The polling requires a host name to poll for its state and with an empty host configuration, we don't have such host to poll.
This situation ends up returning to the client the model controller as soon as we have requested to start the managed host controller, that means the model controller can be used by a client even when the host controller process state is still starting, which is problematic. This is a rare case found in s390 machines.
The embedded managed server / host has already a reference to the process state, the enhancement here is to expose its value so any client can check and poll based on the current value, instead of polling by executing a management operation.
This enhancement should help Galleon to return to the caller a model controller client that is ready to use.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFCORE-5129) (7.3.z) EmbeddedServer can't interact with version <12
by Ivo Studensky (Jira)
Ivo Studensky created WFCORE-5129:
-------------------------------------
Summary: (7.3.z) EmbeddedServer can't interact with version <12
Key: WFCORE-5129
URL: https://issues.redhat.com/browse/WFCORE-5129
Project: WildFly Core
Issue Type: Bug
Components: Embedded
Affects Versions: 12.0.1.Final
Reporter: Ivo Studensky
Assignee: Yeray Borges Santana
Fix For: 13.0.0.Beta2
I am in context where an embedded server version 12.x is started for a version 11 (or 10) of wildfly-core.
This occurs with Bootable JAR maven plugin that depends on 12.x for its CLI support.
This can also happen using CLI shaded client JAR of WildFly 20 to start an embedded server for a WildFly 19 installation.
The problem has been introduced by https://issues.redhat.com/browse/WFCORE-4893 that defined a new method not supported by older versions.
The EmbeddedServer should be able to fallback to legacy logic if the new method is not present.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months