[JBoss JIRA] (WFCORE-5039) Compile using JDK 11
by Paul Ferraro (Jira)
Paul Ferraro created WFCORE-5039:
------------------------------------
Summary: Compile using JDK 11
Key: WFCORE-5039
URL: https://issues.redhat.com/browse/WFCORE-5039
Project: WildFly Core
Issue Type: Task
Components: Build System
Affects Versions: 13.0.0.Beta1
Reporter: Paul Ferraro
Assignee: Paul Ferraro
As discussed on wildfly-dev mailing list, to enable the use of multi-release wildfly modules, we will:
* Require JDK 11 to compile (for all modules except testsuite modules)
** Adjust compiler flags to use --release=8
*** This is equivalent to: -source N -target N -bootclasspath <bootclasspath-from-N>
* To ensure surefire tests are run against each supported JRE (wherever necessary), we will update the CI server maven settings to specify system properties for:
** java8.home
** java11.home
* Update JDK8 specific CI servers to build with JDK 11, but run integration tests using Java 8.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFCORE-5038) Compile using JDK 11
by Paul Ferraro (Jira)
Paul Ferraro created WFCORE-5038:
------------------------------------
Summary: Compile using JDK 11
Key: WFCORE-5038
URL: https://issues.redhat.com/browse/WFCORE-5038
Project: WildFly Core
Issue Type: Task
Components: Build System
Affects Versions: 13.0.0.Beta1
Reporter: Paul Ferraro
Assignee: Paul Ferraro
As discussed on wildfly-dev mailing list, to enable the use of multi-release wildfly modules, we will:
* Require JDK 11 to compile (for all modules except testsuite modules)
** Adjust compiler flags to use --release=8
*** This is equivalent to: -source N -target N -bootclasspath <bootclasspath-from-N>
* To ensure surefire tests are run against each supported JRE (wherever necessary), we will update the CI server maven settings to specify system properties for:
** java8.home
** java11.home
* Update JDK8 specific CI servers to build with JDK 11, but run integration tests using Java 8.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13651) Make AbstractEJBComponentResourceDefinition.METHODS an ObjectTypeAttributeDefinition (rather than ObjectListAD)
by Kabir Khan (Jira)
[ https://issues.redhat.com/browse/WFLY-13651?page=com.atlassian.jira.plugi... ]
Kabir Khan moved EAPSUP-207 to WFLY-13651:
------------------------------------------
Project: WildFly (was: EAP Support)
Key: WFLY-13651 (was: EAPSUP-207)
Issue Type: Feature Request (was: Question)
Workflow: GIT Pull Request workflow (was: classic default workflow)
Component/s: EJB
JMX
(was: EJB)
(was: JMX)
> Make AbstractEJBComponentResourceDefinition.METHODS an ObjectTypeAttributeDefinition (rather than ObjectListAD)
> ---------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13651
> URL: https://issues.redhat.com/browse/WFLY-13651
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB, JMX
> Reporter: Kabir Khan
> Assignee: Cheng Fang
> Priority: Major
>
> See EAPSUP-191 for details.
> This does not need a model version bump since the r-r-d output is the same for ObjectMap- and ObjectListAttributeDefinition. We need to use ObjectMapAttributeDefinition as a 'signal' to the improvements in WFCORE-5037.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (DROOLS-5494) Uploading Excel Spreadsheets using OpenJDK 11
by Ben-Johan van der Walt (Jira)
Ben-Johan van der Walt created DROOLS-5494:
----------------------------------------------
Summary: Uploading Excel Spreadsheets using OpenJDK 11
Key: DROOLS-5494
URL: https://issues.redhat.com/browse/DROOLS-5494
Project: Drools
Issue Type: Bug
Components: decision tables
Affects Versions: 7.33.0.Final
Reporter: Ben-Johan van der Walt
Assignee: Mario Fusco
Using Drools version 7.33.0.Final as well as 7.33.0.Final-redhat-00002.
When trying to upload an Excel Spreadsheet of type .xlsx I am getting a lot of error trying to upload the file. I am able to import the Excel file via the import Asset button, but not by using the "Add Asset" button and adding a new Spreadsheet asset and then uploading the Excel file.
So I am using OpenJDK 11.0.7 and I think that is the reason for the errors.
There are a lot of issues with the libraries from org.apache.poi version 3.17 (e.g. poi-3.17.jar, poi-ooxml-3.17.jar and poi-ooxml-schemas-3.17.jar) which are all part of the drools or decision-central war file. Using OpenJDK you have to use at least version 4.1.1 and update a few other dependancies like commons-compress-1.19.jar and xmlbeans-3.1.0.jar to get it to work.
I do not have a specific excel spreadsheet, but any spreadsheet of type .xlsx will cause the error when trying to upload it.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-9064) HibernateNativeAPINaturalIdTestCase fails with security manager
by Scott Marlow (Jira)
[ https://issues.redhat.com/browse/WFLY-9064?page=com.atlassian.jira.plugin... ]
Scott Marlow commented on WFLY-9064:
------------------------------------
Reopening, as a reminder that the test case can be tried again after HHH-13188 is resolved.
> HibernateNativeAPINaturalIdTestCase fails with security manager
> ---------------------------------------------------------------
>
> Key: WFLY-9064
> URL: https://issues.redhat.com/browse/WFLY-9064
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate, Test Suite
> Affects Versions: 11.0.0.Beta1
> Reporter: Ondrej Kotek
> Priority: Major
> Labels: security-manager
>
> {{HibernateNativeAPINaturalIdTestCase}} fails with security manager because of missing permission {{"("java.lang.RuntimePermission" "createClassLoader")"}}:
> {noformat}
> javax.ejb.EJBException: java.lang.RuntimeException: Could not setup config
> at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
> at org.jboss.as.ejb3.tx.StatefulBMTInterceptor.handleInvocation(StatefulBMTInterceptor.java:96)
> ...
> Caused by: java.lang.RuntimeException: Could not setup config
> at org.jboss.as.test.integration.hibernate.naturalid.SFSBHibernateSFNaturalId.setupConfig(SFSBHibernateSFNaturalId.java:69)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ...
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "createClassLoader")" in code source "(vfs:/content/hibernate4naturalid_test.ear/beans.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.hibernate4naturalid_test.ear.beans.jar" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.SecurityManager.checkCreateClassLoader(SecurityManager.java:611)
> at org.wildfly.security.manager.WildFlySecurityManager.checkCreateClassLoader(WildFlySecurityManager.java:308)
> ...
> {noformat}
> After adding the permission, there is another missing permission {{"("java.io.FilePermission" "/home/okotek/git/wildfly/dist/target/wildfly-11.0.0.Beta1-SNAPSHOT/modules/system/layers/base/org/hibernate/main/hibernate-envers-5.1.8.Final.jar" "read")"}}. A privileged section is missing probably.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-9064) HibernateNativeAPINaturalIdTestCase fails with security manager
by Scott Marlow (Jira)
[ https://issues.redhat.com/browse/WFLY-9064?page=com.atlassian.jira.plugin... ]
Scott Marlow reopened WFLY-9064:
--------------------------------
Assignee: (was: Scott Marlow)
> HibernateNativeAPINaturalIdTestCase fails with security manager
> ---------------------------------------------------------------
>
> Key: WFLY-9064
> URL: https://issues.redhat.com/browse/WFLY-9064
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate, Test Suite
> Affects Versions: 11.0.0.Beta1
> Reporter: Ondrej Kotek
> Priority: Major
> Labels: security-manager
>
> {{HibernateNativeAPINaturalIdTestCase}} fails with security manager because of missing permission {{"("java.lang.RuntimePermission" "createClassLoader")"}}:
> {noformat}
> javax.ejb.EJBException: java.lang.RuntimeException: Could not setup config
> at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
> at org.jboss.as.ejb3.tx.StatefulBMTInterceptor.handleInvocation(StatefulBMTInterceptor.java:96)
> ...
> Caused by: java.lang.RuntimeException: Could not setup config
> at org.jboss.as.test.integration.hibernate.naturalid.SFSBHibernateSFNaturalId.setupConfig(SFSBHibernateSFNaturalId.java:69)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ...
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "createClassLoader")" in code source "(vfs:/content/hibernate4naturalid_test.ear/beans.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.hibernate4naturalid_test.ear.beans.jar" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.SecurityManager.checkCreateClassLoader(SecurityManager.java:611)
> at org.wildfly.security.manager.WildFlySecurityManager.checkCreateClassLoader(WildFlySecurityManager.java:308)
> ...
> {noformat}
> After adding the permission, there is another missing permission {{"("java.io.FilePermission" "/home/okotek/git/wildfly/dist/target/wildfly-11.0.0.Beta1-SNAPSHOT/modules/system/layers/base/org/hibernate/main/hibernate-envers-5.1.8.Final.jar" "read")"}}. A privileged section is missing probably.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-11030) Transaction remained in prepared state
by Emmanuel Hugonnet (Jira)
[ https://issues.redhat.com/browse/WFLY-11030?page=com.atlassian.jira.plugi... ]
Emmanuel Hugonnet updated WFLY-11030:
-------------------------------------
Priority: Major (was: Critical)
> Transaction remained in prepared state
> --------------------------------------
>
> Key: WFLY-11030
> URL: https://issues.redhat.com/browse/WFLY-11030
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Erich Duda
> Assignee: Emmanuel Hugonnet
> Priority: Major
>
> *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.13.8#713008)
6 years
[JBoss JIRA] (WFLY-11029) Sometimes Artemis cluster with JGroups discovery is not formed after restart
by Emmanuel Hugonnet (Jira)
[ https://issues.redhat.com/browse/WFLY-11029?page=com.atlassian.jira.plugi... ]
Emmanuel Hugonnet updated WFLY-11029:
-------------------------------------
Priority: Major (was: Critical)
> Sometimes Artemis cluster with JGroups discovery is not formed after restart
> ----------------------------------------------------------------------------
>
> Key: WFLY-11029
> URL: https://issues.redhat.com/browse/WFLY-11029
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Justin Bertram
> Priority: Major
> Labels: downstream_dependency
>
> There are undelivered messages in scenario with where servers in remote JCA topology are restarted. There are undelivered message after test.
> Test scenario:
> * Start 2 server in Artemis cluster
> * Start 2 servers with MDB connected to Artemis cluster
> ** MDB resends messages from InQueue to OutQueue from/to remote cluster
> * Send messages to InQueue
> * Restart all server (one by one)
> * Consumes messages from OutQueue
> Results:
> After the test there are missing messages in OutQueue.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years