[JBoss JIRA] (DROOLS-3278) No DO shown on right panel if only one is defined in project
by Gabriele Cardosi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3278?page=com.atlassian.jira.plugi... ]
Gabriele Cardosi closed DROOLS-3278.
------------------------------------
Resolution: Done
This is actually not a bug of the component. It is related on the "correctness" of the data object. If the single data object can not be "parsed" on the backed (for ex because it reference a missing class) then it is not shown in the panel.
> No DO shown on right panel if only one is defined in project
> ------------------------------------------------------------
>
> Key: DROOLS-3278
> URL: https://issues.jboss.org/browse/DROOLS-3278
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Reporter: Gabriele Cardosi
> Assignee: Gabriele Cardosi
> Priority: Major
>
> When there is only one data object defined in the project, none is shown in the right panel
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-5966) Validate requirement for modules previously exported by javax.ejb.api
by Yeray Borges (Jira)
[ https://issues.jboss.org/browse/WFLY-5966?page=com.atlassian.jira.plugin.... ]
Yeray Borges updated WFLY-5966:
-------------------------------
Description:
The WFLY-5922 fix removed the exporting of a number of modules from javax.ejb.api. That introduced some problems with modules that depended on those exported packages no longer having visibility to needed classes, so to prevent problems I blindly added a commit to the module.xml for each module that depended upon javax.ejb.api to add a dependency set like this:
{code}
<!-- TODO validate the need for these and remove if not needed.
Prior to WFLY-5922 they were exported by javax.ejb.api. -->
<module name="javax.api"/>
<module name="javax.transaction.api"/>
<module name="javax.xml.rpc.api"/>
<module name="javax.rmi.api"/>
<module name="org.omg.api"/>
{code}
If a module already had a dep on one of those, it's not in the block.
This task is to check each of these modules and replace that block with normal dependency declarations for any that are truly needed.
Affected modules:
feature-pack/src/main/resources/modules/system/layers/base/javaee/api/main/module.xml
feature-pack/src/main/resources/modules/system/layers/base/javax/management/j2ee/api/main/module.xml
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/ejb3/main/module.xml
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jsr77/main/module.xml-
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/webservices/main/module.xml
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/weld/main/module.xml
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/xts/main/module.xml-
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb3/main/module.xml
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/iiop-client/main/module.xml
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/appclient/main/module.xml
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/ejb/main/module.xml
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/compensations/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/rts/main/module.xml-
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/txframework/main/module.xml
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/weld/core/main/module.xml
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ws/common/main/module.xml
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/xts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/rts/main/module.xml-
The following modules were indirectly affected via their dependency on javaee.api, which in turn exports javax.ejb.api:
feature-pack/src/main/resources/modules/system/layers/base/com/sun/jsf-impl/main/module.xml
-feature-pack/src/main/resources/modules/system/layers/base/org/jberet/jberet-core/main/module.xml-
feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/jberet/main/module.xml
jsf/multi-jsf-installer/src/main/resources/mojarra-impl-module.xml
jsf/multi-jsf-installer/src/main/resources/myfaces-impl-module.xml
The following modules were fixed or verified as correct (moved from the first list):
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/main/module.xml
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/spi/main/module.xml
was:
The WFLY-5922 fix removed the exporting of a number of modules from javax.ejb.api. That introduced some problems with modules that depended on those exported packages no longer having visibility to needed classes, so to prevent problems I blindly added a commit to the module.xml for each module that depended upon javax.ejb.api to add a dependency set like this:
{code}
<!-- TODO validate the need for these and remove if not needed.
Prior to WFLY-5922 they were exported by javax.ejb.api. -->
<module name="javax.api"/>
<module name="javax.transaction.api"/>
<module name="javax.xml.rpc.api"/>
<module name="javax.rmi.api"/>
<module name="org.omg.api"/>
{code}
If a module already had a dep on one of those, it's not in the block.
This task is to check each of these modules and replace that block with normal dependency declarations for any that are truly needed.
Affected modules:
feature-pack/src/main/resources/modules/system/layers/base/javaee/api/main/module.xml
feature-pack/src/main/resources/modules/system/layers/base/javax/management/j2ee/api/main/module.xml
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/ejb3/main/module.xml
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jsr77/main/module.xml-
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/webservices/main/module.xml
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/weld/main/module.xml
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/xts/main/module.xml-
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb3/main/module.xml
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/iiop-client/main/module.xml
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/appclient/main/module.xml
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/ejb/main/module.xml
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/compensations/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/rts/main/module.xml-
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/txframework/main/module.xml
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/weld/core/main/module.xml
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ws/common/main/module.xml
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/xts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/rts/main/module.xml-
The following modules were indirectly affected via their dependency on javaee.api, which in turn exports javax.ejb.api:
feature-pack/src/main/resources/modules/system/layers/base/com/sun/jsf-impl/main/module.xml
feature-pack/src/main/resources/modules/system/layers/base/org/jberet/jberet-core/main/module.xml
feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/jberet/main/module.xml
jsf/multi-jsf-installer/src/main/resources/mojarra-impl-module.xml
jsf/multi-jsf-installer/src/main/resources/myfaces-impl-module.xml
The following modules were fixed or verified as correct (moved from the first list):
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/main/module.xml
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/spi/main/module.xml
> Validate requirement for modules previously exported by javax.ejb.api
> ---------------------------------------------------------------------
>
> Key: WFLY-5966
> URL: https://issues.jboss.org/browse/WFLY-5966
> Project: WildFly
> Issue Type: Task
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Yeray Borges
> Priority: Major
>
> The WFLY-5922 fix removed the exporting of a number of modules from javax.ejb.api. That introduced some problems with modules that depended on those exported packages no longer having visibility to needed classes, so to prevent problems I blindly added a commit to the module.xml for each module that depended upon javax.ejb.api to add a dependency set like this:
> {code}
> <!-- TODO validate the need for these and remove if not needed.
> Prior to WFLY-5922 they were exported by javax.ejb.api. -->
> <module name="javax.api"/>
> <module name="javax.transaction.api"/>
> <module name="javax.xml.rpc.api"/>
> <module name="javax.rmi.api"/>
> <module name="org.omg.api"/>
> {code}
> If a module already had a dep on one of those, it's not in the block.
> This task is to check each of these modules and replace that block with normal dependency declarations for any that are truly needed.
> Affected modules:
> feature-pack/src/main/resources/modules/system/layers/base/javaee/api/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/javax/management/j2ee/api/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/ejb3/main/module.xml
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jsr77/main/module.xml-
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/webservices/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/weld/main/module.xml
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/xts/main/module.xml-
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb3/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/iiop-client/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/appclient/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/ejb/main/module.xml
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/compensations/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/rts/main/module.xml-
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/txframework/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/weld/core/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ws/common/main/module.xml
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/xts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/rts/main/module.xml-
> The following modules were indirectly affected via their dependency on javaee.api, which in turn exports javax.ejb.api:
> feature-pack/src/main/resources/modules/system/layers/base/com/sun/jsf-impl/main/module.xml
> -feature-pack/src/main/resources/modules/system/layers/base/org/jberet/jberet-core/main/module.xml-
> feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/jberet/main/module.xml
> jsf/multi-jsf-installer/src/main/resources/mojarra-impl-module.xml
> jsf/multi-jsf-installer/src/main/resources/myfaces-impl-module.xml
> The following modules were fixed or verified as correct (moved from the first list):
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/spi/main/module.xml
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-11307) Message sent to JMSReplyTo from old client does not find correct binding
by Miroslav Novak (Jira)
Miroslav Novak created WFLY-11307:
-------------------------------------
Summary: Message sent to JMSReplyTo from old client does not find correct binding
Key: WFLY-11307
URL: https://issues.jboss.org/browse/WFLY-11307
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 14.0.0.Final
Reporter: Miroslav Novak
Assignee: Martyn Taylor
Fix For: 15.0.0.Alpha1
There is regression in backward compatibility of messaging client. JMSReplyTo destination set by older client contains incorrect address which causes that reply message does not have correct binding and such message is lost.
Impact: Applications will stop work after upgrade to WF14/EAP 7.2.0.CD14.
Test Scenario:
* Start EAP 7.2.0.CD14/WF14 server (Artemis 2.x) with deployed InQueue and OutQueue
* Send message to InQueue from older EAP 7.2.0.CD13/WF13/Artemis 1.5.5 client to InQueue. Message has JMSReplyTo header set to OutQueue. Client got "OutQueue" queue from JNDI lookup from EAP7.2.0.CD14/WF14
* Deploy MDB to server
** MDB consumes message from InQueue and sends new message to destination defined in JMSReplyTo header (so to OutQueue)
* Receive message from OutQueue
Result:
No message is received from OutQueue. There is debug message in server log:
{code}
11:36:09,565 DEBUG [org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl] (Thread-25 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@22848193)) Message CoreMessage[m
essageID=214,durable=true,userID=c0de8bd0-cba6-11e8-840f-f496342f6705,priority=4, timestamp=Tue Oct 09 11:36:09 CEST 2018,expiration=0, durable=true, address=jms.queue.OutQueue,size=580,properties=TypedPropertie
s[inMessageId=ID:c0383a39-cba6-11e8-95ad-f496342f6705,__AMQ_CID=c0d9349a-cba6-11e8-840f-f496342f6705,_AMQ_DUPL_ID=90d1e80e-116d-4eef-9513-84c6085549db,_AMQ_ROUTING_TYPE=0]]@1680840457 is not going anywhere as it
didn't have a binding on address:jms.queue.OutQueue
{code}
which indicates that jms.queue.OutQueue address does not have a binding.
The same happesn if older EAP/WF server (with Artemis 1.5.5x) is used and new EAP 7.2.0.CD14/WF14(Artemis 2.x) client is used.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (DROOLS-3271) [DMN Designer] Double-clicking connectors in DRD throws exceptions
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3271?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-3271:
----------------------------------------
[~tirelli] The _error_ is deliberate (or at least let's say it's a _managed_ violation of rules defining the construction of DMN files with Stunner).
The rule that has been violated checks that the DMN graph is does not contain circular references.
I'd have to guess that your "_accidental_ double click" tried in essence to attach the connector to itself leading to the circular reference (or something like that). The reporting mechanism is core-Stunner. However, as a low priority, we could investigate why you received the message (I could not replicate by "_deliberately_ double clicking" connectors).
> [DMN Designer] Double-clicking connectors in DRD throws exceptions
> ------------------------------------------------------------------
>
> Key: DROOLS-3271
> URL: https://issues.jboss.org/browse/DROOLS-3271
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.14.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
> Attachments: Screenshot 2018-11-07 20.46.53.png
>
>
> Reported by [~tirelli]
> {quote}
> When I accidentally double clicked on a connector action in the DRD, I got a bunch of error messages on the screen.
> {quote}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-10817) Incorrect data check when clearing body of large compressed message after failover
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-10817?page=com.atlassian.jira.plugin... ]
Miroslav Novak updated WFLY-10817:
----------------------------------
Affects Version/s: 13.0.0.Final
> Incorrect data check when clearing body of large compressed message after failover
> ----------------------------------------------------------------------------------
>
> Key: WFLY-10817
> URL: https://issues.jboss.org/browse/WFLY-10817
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 13.0.0.Final
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Priority: Critical
>
> *Scenario*
> * There are two WildFly (Artemis) servers in dedicated shared store HA topology
> * Connection factory is configured to compress large messages
> * Live server is killed
> * Clients do failover to backup
> After the clients do failover to backup, I can see following exceptions in the log when a receiver tries to clear body of large message. The test fails because of lost messages.
> I can see this issue with Artemis 1.5.5.jbossorg-012.
> I am not able to reproduce it locally but I hit it on Jenkins every time.
> {code}
> javax.jms.JMSException: AMQ119029: Error writing body of message
> at org.apache.activemq.artemis.jms.client.ActiveMQBytesMessage.clearBody(ActiveMQBytesMessage.java:337)
> at org.jboss.qa.hornetq.apps.clients.Client.cleanMessage(Client.java:144)
> at org.jboss.qa.hornetq.apps.clients.Receiver11.receiveMessage(Receiver11.java:153)
> at org.jboss.qa.hornetq.apps.clients.ReceiverTransAck.run(ReceiverTransAck.java:89)
> Caused by: java.lang.RuntimeException: AMQ119029: Error writing body of message
> at org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl.getBodyBuffer(ClientLargeMessageImpl.java:93)
> at org.apache.activemq.artemis.jms.client.ActiveMQBytesMessage.getBuffer(ActiveMQBytesMessage.java:363)
> at org.apache.activemq.artemis.jms.client.ActiveMQBytesMessage.clearBody(ActiveMQBytesMessage.java:335)
> ... 3 more
> Caused by: ActiveMQLargeMessageException[errorType=LARGE_MESSAGE_ERROR_BODY message=AMQ119029: Error writing body of message]
> at org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.sendPacketToOutput(LargeMessageControllerImpl.java:1077)
> at org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.setOutputStream(LargeMessageControllerImpl.java:258)
> at org.apache.activemq.artemis.core.client.impl.CompressedLargeMessageControllerImpl.setOutputStream(CompressedLargeMessageControllerImpl.java:75)
> at org.apache.activemq.artemis.core.client.impl.CompressedLargeMessageControllerImpl.saveBuffer(CompressedLargeMessageControllerImpl.java:80)
> at org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl.checkBuffer(ClientLargeMessageImpl.java:159)
> at org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl.getBodyBuffer(ClientLargeMessageImpl.java:91)
> ... 5 more
> Caused by: java.io.IOException: incorrect data check
> at org.apache.activemq.artemis.utils.InflaterWriter.close(InflaterWriter.java:81)
> at org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.sendPacketToOutput(LargeMessageControllerImpl.java:1074)
> ... 10 more
> Caused by: java.util.zip.DataFormatException: incorrect data check
> at java.util.zip.Inflater.inflateBytes(Native Method)
> at java.util.zip.Inflater.inflate(Inflater.java:259)
> at java.util.zip.Inflater.inflate(Inflater.java:280)
> at org.apache.activemq.artemis.utils.InflaterWriter.close(InflaterWriter.java:77)
> ... 11 more
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-11305) Transaction remained in prepared state
by Miroslav Novak (Jira)
Miroslav Novak created WFLY-11305:
-------------------------------------
Summary: Transaction remained in prepared state
Key: WFLY-11305
URL: https://issues.jboss.org/browse/WFLY-11305
Project: WildFly
Issue Type: Bug
Components: JMS
Reporter: Miroslav Novak
Assignee: Martyn Taylor
*Scenario*
* Start group A of two servers (node-1 and node-3) Servers are not in cluster.
* Send messages to queue on node-1.
* Start another group B of two servers(node-2 and node-4). Servers are not in cluster.
* Deploy mdb on both servers in A group. This mdb reads messages from local queue and perform insert into oracle 11 gr2 database, and also sends messages to remote queue on group B.
* Mdb deployed on nodes in group B inserts messages from local queue to oracle 11 gr2 database.
* Kill server node-1. Restart failed node. Process all messages and verify both mdbs performed database insert
After node-1 is killed and restarted, there are still transactions in prepare state and they are not cleared in 10 minutes. The transactions remains on servers from group B.
Logs from test can be found in build - https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/mnovak-verifier-...
*Investigation of issue is in progress. It is not known what component causes it.*
Clebert looked at the logs but there weren't traces from Arjuna. The above build contains also Arjuna traces. Copy paste Clebert's analyses.
{quote}I looked at the output from the clients, and filtered the processing
for one XA that's never commited..
I looked for the XID on
base64:AAAAAAAAAAAAAP__ChBkGmqipH1benkDAAAJdQAAAAMAAAAAAAAAAAAAAAAAAP__ChBkGmqipH1benkDAAAJaDUyODcHAgIA
and filtered the onMessage that generated it (attached the log as
processingOneMessage.txt):
This XID was never commited simply because the TM never did it.
Probably because of some issue on the JDBC.. but there are no errors,
no exceptions.. totally clean on artemis side.
There are no logging for TM or the MDB itself to correlate other
failures. With the information I have I am certain there were nothing
from Artemis side that would have caused it.
In any case.. this is not replicated at all.. and not related to 87.
This is simply the TM getting confused for some issue on the JDBC.
As far as I am concerned I have fixed the replicated shutdown case.
and i will send PRs upstream now.{quote}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months