[JBoss JIRA] (DROOLS-1564) Change oopath syntax
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1564?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-1564:
--------------------------------
Priority: Blocker (was: Major)
> Change oopath syntax
> --------------------
>
> Key: DROOLS-1564
> URL: https://issues.jboss.org/browse/DROOLS-1564
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Priority: Blocker
> Fix For: 7.0.0.Final
>
>
> It is required to change the oopath syntax to make it closer to xpath one. This means that constraints will have to be put between square brackets instead of curly ones and inline cast should be expressed out of constraints. In other words the following oopath:
> {code}
> /list{#SubClass, prop == 0}
> {code}
> should become:
> {code}
> /list#SubClass[prop == 0]
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (HAWKULARQE-71) Test Hawkular Java Agent
by Sunil kondkar (JIRA)
[ https://issues.jboss.org/browse/HAWKULARQE-71?page=com.atlassian.jira.plu... ]
Sunil kondkar commented on HAWKULARQE-71:
-----------------------------------------
Smoke tested EAP 7 with Hawkular Java Agent Openshift Container:
brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/jboss-eap-7/eap70-openshift:1.5
> Test Hawkular Java Agent
> ------------------------
>
> Key: HAWKULARQE-71
> URL: https://issues.jboss.org/browse/HAWKULARQE-71
> Project: Hawkular QE
> Issue Type: Task
> Reporter: Hayk Hovsepyan
> Assignee: Sunil kondkar
> Priority: Minor
>
> There is a new Java Agent (HJA) that you can run in any JVM (including
> but not limited to EAP-based projects). You do so by passing in a
> "-javaagent" command line option to your JVM (e.g. java
> -javaagent=hawkular-javaagent.jar=config=config.yaml -jar my-app.jar
> ...yadda...). There are two additional properties you must set in
> standalone.conf if you want to run it inside an EAP JVM. The README will
> have the details.
> This new HJA is configured with a yaml file that largely mimics all the
> standalone.xml data that HWFA has. There is no ${x} support in the YAML
> file right now.
> This new HJA can talk to any EAP or WildFly server over the DMR management
> API. It can do deployments to your EAP/WildFly servers and monitoring of
> EAP/WildFly subsystems just like HWFA can.
> This new HJA can talk to any JMX server just like HWFA can (it will talk to
> the local MBeanServer or, if remotely monitoring a JMX server, it will talk
> to it over Jolokia/REST API).
> This new HJA can NOT run directly inside of a Host Controller due to
> https://issues.jboss.org/browse/WFCORE-2526 - however, you can run HJA
> externally in its own JVM (e.g. java -jar hawkular-javaagent.jar
> config=config.yaml) and have its config.yaml point to a remote Host
> Controller and you'll get the same functionality.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (DROOLS-1563) Values are always said to be invalid even when the respect the enumeration
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1563?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-1563:
----------------------------------------
In order to more generally address this issue I [proposed a PR|https://github.com/kiegroup/drools/pull/1269] to align InputData values check using BaseDMNTypeImpl.isAssignableValue().
To be noticed as reported in the PR that:
* the user could deliberately set an inputdata in the context as null, and this would be a valid check against the inputdata type. Although this is a deliberate set.
Please notice this is NOT about missing to set an inputdata value in the context at all, in such case a REQ_NOT_FOUND error is still thrown.
* inputdata type check now obey the same rules as per the remainer of the evaluation type check and specifically the "special case" of single-value-list-as-singleton is a valid case. (During [DROOLS-1557] this case was deliberately omitted, at that time it was discussed to impose being a Collection [here|https://github.com/kiegroup/drools/commit/b4a6408a916e210e188b41571d...] )
> Values are always said to be invalid even when the respect the enumeration
> --------------------------------------------------------------------------
>
> Key: DROOLS-1563
> URL: https://issues.jboss.org/browse/DROOLS-1563
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Reporter: Mélanie Gauthier
> Assignee: Matteo Mortari
> Attachments: RBLoR test.dmn
>
>
> When running the attached file which has one input that is a collection of a complex structure, the constraints on the field is always said to be invalid.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8780) Server often becomes unresponsive after reloading JMS Bridge
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-8780?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil moved JBEAP-10938 to WFLY-8780:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8780 (was: JBEAP-10938)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JMS
(was: JMS)
Affects Version/s: (was: 7.1.0.DR16)
Affects Testing: (was: Blocks Testing)
> Server often becomes unresponsive after reloading JMS Bridge
> ------------------------------------------------------------
>
> Key: WFLY-8780
> URL: https://issues.jboss.org/browse/WFLY-8780
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
>
> Server is not able to finish reload and becomes unresponsive. Spotted in both standalone as well as domain mode. It's intermittent but happen often. It seems to be new issue in EAP 7.1.0.DR16 build.
> End of server log:
> {code}
> 2017-04-11 17:26:09,271 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 35) AMQ151003: resource adaptor stopped
> 2017-04-11 17:26:09,300 ERROR [org.apache.activemq.artemis.core.client] (Thread-0 (org.apache.activemq.artemis.core.remoting.impl.invm.InVMConnector-795435938)) AMQ214013: Failed to decode packet: java.util.concurrent.RejectedExecutionException: Task org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask@2bcc520f rejected from java.util.concurrent.ThreadPoolExecutor@228cbbed[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
> at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor.execute(OrderedExecutorFactory.java:86)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$SessionFactoryTopologyHandler.nodeDisconnected(ClientSessionFactoryImpl.java:1309)
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager$Channel0Handler.handlePacket(ActiveMQClientProtocolManager.java:454)
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:623)
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:373)
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:356)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$DelegatingBufferHandler.bufferReceived(ClientSessionFactoryImpl.java:1143)
> at org.apache.activemq.artemis.core.remoting.impl.invm.InVMConnection$1.run(InVMConnection.java:196)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:101)
> 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)
> 2017-04-11 17:26:09,302 ERROR [org.apache.activemq.artemis.core.client] (Thread-0 (org.apache.activemq.artemis.core.remoting.impl.invm.InVMConnector-795435938)) AMQ214013: Failed to decode packet: java.util.concurrent.RejectedExecutionException: Task org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask@4d26c3c3 rejected from java.util.concurrent.ThreadPoolExecutor@228cbbed[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
> at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor.execute(OrderedExecutorFactory.java:86)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$SessionFactoryTopologyHandler.nodeDisconnected(ClientSessionFactoryImpl.java:1309)
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager$Channel0Handler.handlePacket(ActiveMQClientProtocolManager.java:454)
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:623)
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:373)
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:356)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$DelegatingBufferHandler.bufferReceived(ClientSessionFactoryImpl.java:1143)
> at org.apache.activemq.artemis.core.remoting.impl.invm.InVMConnection$1.run(InVMConnection.java:196)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:101)
> 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)
> 2017-04-11 17:26:09,378 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 35) AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.5.4.002-redhat-1 [8825fae7-1ac1-11e7-ad33-3c970e193136] stopped, uptime 10.848 seconds
> 2017-04-11 17:26:09,379 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0008: Undertow HTTP listener default suspending
> 2017-04-11 17:26:09,380 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0007: Undertow HTTP listener default stopped, was bound to 127.0.0.1:8080
> 2017-04-11 17:26:09,380 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0004: Undertow 1.4.12.Final-redhat-1 stopping
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8779) Distributed statisics number varies among nodes (distributed workmanager
by Richard Janík (JIRA)
[ https://issues.jboss.org/browse/WFLY-8779?page=com.atlassian.jira.plugin.... ]
Richard Janík commented on WFLY-8779:
-------------------------------------
I'm cloning the issue because I'm adding a few links to upstream code and don't want to link JBEAP issue in upstream code. (TODOs to uncomment some checks once this is fixed).
> Distributed statisics number varies among nodes (distributed workmanager
> ------------------------------------------------------------------------
>
> Key: WFLY-8779
> URL: https://issues.jboss.org/browse/WFLY-8779
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Reporter: Richard Janík
> Assignee: Stefano Maestri
>
> Reproducing test in https://github.com/LittleJohnII/wildfly/tree/eap7-495
> {noformat}
> # build WFLY first
> cd testsuite/integration/basic
> mvn clean test -Dtest='Dwm*TestCase' -Djboss.server.config.file.name=standalone-ha.xml -DtrimStackTrace=false -Darquillian.launch=distributed-group
> {noformat}
> All the cases contain checks for distributed statistics and in some cases, these show unexpected numbers (usually, at least one test method fails for each case). For example, scheduling two work instances would produce distributed stats =2 for node1 and =3 for node 2.
> I already mentioned this to [~maeste], so this is mainly a tracker.
> This is a minor hamper to test writing for EAP7-495, but doesn't block it (not severe enough) - if this isn't resolved before I create a PR for tests, I'll have to comment out the distributed statistics checks.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8779) Distributed statisics number varies among nodes (distributed workmanager
by Richard Janík (JIRA)
[ https://issues.jboss.org/browse/WFLY-8779?page=com.atlassian.jira.plugin.... ]
Richard Janík moved JBEAP-10937 to WFLY-8779:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8779 (was: JBEAP-10937)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JCA
(was: JCA)
Affects Version/s: (was: 7.1.0.DR17)
> Distributed statisics number varies among nodes (distributed workmanager
> ------------------------------------------------------------------------
>
> Key: WFLY-8779
> URL: https://issues.jboss.org/browse/WFLY-8779
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Reporter: Richard Janík
> Assignee: Stefano Maestri
>
> Reproducing test in https://github.com/LittleJohnII/wildfly/tree/eap7-495
> {noformat}
> # build WFLY first
> cd testsuite/integration/basic
> mvn clean test -Dtest='Dwm*TestCase' -Djboss.server.config.file.name=standalone-ha.xml -DtrimStackTrace=false -Darquillian.launch=distributed-group
> {noformat}
> All the cases contain checks for distributed statistics and in some cases, these show unexpected numbers (usually, at least one test method fails for each case). For example, scheduling two work instances would produce distributed stats =2 for node1 and =3 for node 2.
> I already mentioned this to [~maeste], so this is mainly a tracker.
> This is a minor hamper to test writing for EAP7-495, but doesn't block it (not severe enough) - if this isn't resolved before I create a PR for tests, I'll have to comment out the distributed statistics checks.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2812) ls output is unfriendly if any element in return contents is longer than terminal width
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2812?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-2812:
----------------------------------------------
Your change looks good, be sure to do some manual non regression.
Output from second screenshot is fine. You can also test with additional options. Do: ls -l /subsystem=elytron/provider-loader=elytron <TAB>, and add more options to see how they will be displayed.
Thank-you.
JF
> ls output is unfriendly if any element in return contents is longer than terminal width
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-2812
> URL: https://issues.jboss.org/browse/WFCORE-2812
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Security
> Affects Versions: 3.0.0.Beta21
> Reporter: Chao Wang
> Assignee: Chao Wang
> Attachments: Screenshot from 2017-05-16 17-36-21.png, ls -l.png
>
>
> When 'ls' operation is performed over 'provider-loader' element, the output is very ugly - I get many empty lines with one very long attribute value and few more attributes with simple values.
> Expected: no empty lines between printed attributes so the output does not take like 4 screen size.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month