[JBoss JIRA] (ELY-1298) GssapiCompatibilitySuiteChild fails on IBM JDK
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1298?page=com.atlassian.jira.plugin.s... ]
Jan Kalina updated ELY-1298:
----------------------------
Component/s: Testsuite
> GssapiCompatibilitySuiteChild fails on IBM JDK
> ----------------------------------------------
>
> Key: ELY-1298
> URL: https://issues.jboss.org/browse/ELY-1298
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Testsuite
> Reporter: Peter Palaga
> Assignee: Peter Palaga
> Labels: ibm-java
>
> A followup of ELY-1293
> {{System.currentTimeMillis()}} is native in IBM JDK and at the same time, IBM JDK does not support java.lang.instrument API for native methods. Therefore, {{System.currentTimeMillis()}} cannot be mocked on IBM JDK using jmockit.
> {code}
> export JAVA_HOME=path/to/ibm/java8
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT - tr.r14.java.green_20160818_122998
> GC - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
> mvn clean test
> {code}
> Expected: the tests mocking {{System.currentTimeMillis()}} should pass
> Actual: the tests mocking {{System.currentTimeMillis()}} throw the following exception or similar:
> {code}
> java.lang.UnsupportedOperationException: class redefinition failed: attempted to change method modifiers
> at org.wildfly.security.audit.PeriodicRotatingFileAuditEndpointTest$1.<init>(PeriodicRotatingFileAuditEndpointTest.java:212)
> at org.wildfly.security.audit.PeriodicRotatingFileAuditEndpointTest.mockTime(PeriodicRotatingFileAuditEndpointTest.java:212)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.lang.reflect.Method.invoke(Method.java:508)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> {code}
> This is currently the case with
> * GssapiCompatibilitySuiteChild
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (ELY-1295) KeyStoreCredentialStoreTest fails on IBM JDK
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1295?page=com.atlassian.jira.plugin.s... ]
Jan Kalina updated ELY-1295:
----------------------------
Labels: ibm-java (was: )
> KeyStoreCredentialStoreTest fails on IBM JDK
> --------------------------------------------
>
> Key: ELY-1295
> URL: https://issues.jboss.org/browse/ELY-1295
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Peter Palaga
> Labels: ibm-java
>
> {code}
> export JAVA_HOME=path/to/ibm/java8
>
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT - tr.r14.java.green_20160818_122998
> GC - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
>
> mvn clean test -Dtest=KeyStoreCredentialStoreTest
> {code}
> Expected: KeyStoreCredentialStoreTest should pass
> Actual: First, the "hack to make JCE believe that it has verified the signature of the WildFlyElytronProvider JAR" [1] throws
> {code}
> java.lang.ClassNotFoundException: javax.crypto.JceSecurity
> at java.lang.Class.forNameImpl(Native Method)
> at java.lang.Class.forName(Class.java:278)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:89)
> ...
> {code}
> because {{javax.crypto.JceSecurity}} does not exist in IBM JRE.
> It looks like the hack is actually not necessary anymore, because {{KeyStoreCredentialStoreTest}} is passing also without the hack on both Oracle JDK and OpenJDK.
> But once the hack is removed, on IBM JDK, {{shouldSupportKeyStoreFormat}} passes with format=JCEKS but fails with format=PKCS12 throwing the following exeception:
> {code}
> org.wildfly.security.credential.store.CredentialStoreException: ELY09504: Cannot acquire a credential from the credential store
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:464)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.shouldSupportKeyStoreFormat(KeyStoreCredentialStoreTest.java:137)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.lang.reflect.Method.invoke(Method.java:508)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: java.security.UnrecoverableKeyException: Get Key failed: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> at java.security.KeyStore.getEntry(KeyStore.java:1532)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:462)
> ... 10 more
> Caused by: java.security.NoSuchAlgorithmException: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> ... 12 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/661/commits/7296...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (ELY-1299) X509EvidenceVerificationSuiteChild.testX509Auth() fails on IBM JDK
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1299?page=com.atlassian.jira.plugin.s... ]
Jan Kalina updated ELY-1299:
----------------------------
Labels: ibm-java (was: )
> X509EvidenceVerificationSuiteChild.testX509Auth() fails on IBM JDK
> ------------------------------------------------------------------
>
> Key: ELY-1299
> URL: https://issues.jboss.org/browse/ELY-1299
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Peter Palaga
> Assignee: Peter Palaga
> Labels: ibm-java
> Fix For: 1.2.0.Beta1
>
>
> {code}
> export JAVA_HOME=path/to/ibm/java8
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT - tr.r14.java.green_20160818_122998
> GC - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
> mvn clean test -Dtest=LdapTestSuite
> {code}
> Expected: the selected test suite passes
> Actual: {{X509EvidenceVerificationSuiteChild.testX509Auth()}} fails with the following exception:
> {code}
> java.security.cert.CertificateException: Unable to initialize, java.io.IOException: insufficient data
> at com.ibm.security.x509.X509CertImpl.<init>(X509CertImpl.java:268)
> at java.security.cert.CertificateFactory.generateCertificate(CertificateFactory.java:407)
> at org.wildfly.security.ldap.X509EvidenceVerificationSuiteChild.loadCertificate(X509EvidenceVerificationSuiteChild.java:74)
> at org.wildfly.security.ldap.X509EvidenceVerificationSuiteChild.testX509Auth(X509EvidenceVerificationSuiteChild.java:65)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.lang.reflect.Method.invoke(Method.java:508)
> at org.wildfly.security.ldap.DirContextFactoryRule$1.evaluate(DirContextFactoryRule.java:61)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (ELY-1458) SelfSignedX509CertificateAndSigningKeyTest.testSelfSignedCertificateWithStringExtensionValues fails on IBM JDK
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1458?page=com.atlassian.jira.plugin.s... ]
Jan Kalina updated ELY-1458:
----------------------------
Labels: ibm-java (was: )
> SelfSignedX509CertificateAndSigningKeyTest.testSelfSignedCertificateWithStringExtensionValues fails on IBM JDK
> --------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1458
> URL: https://issues.jboss.org/browse/ELY-1458
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Certificate Authority
> Affects Versions: 1.2.0.Beta10
> Reporter: Martin Choma
> Assignee: Farah Juma
> Labels: ibm-java
>
> With IBM java
> {noformat}
> java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr4fp6-20170518_02(SR4 FP6))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20170516_348050 (JIT enabled, AOT enabled)
> J9VM - R28_20170516_1905_B348050
> JIT - tr.r14.java_20170516_348050
> GC - R28_20170516_1905_B348050_CMPRSS
> J9CL - 20170516_348050)
> JCL - 20170516_01 based on Oracle jdk8u131-b11
> {noformat}
> run test
> {noformat}
> mvn test -Dtest=SelfSignedX509CertificateAndSigningKeyTest
> [INFO] Running org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest
> [ERROR] Tests run: 9, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.372 s <<< FAILURE! - in org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest
> [ERROR] testSelfSignedCertificateWithStringExtensionValues(org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest) Time elapsed: 0.274 s <<< FAILURE!
> java.lang.AssertionError
> at org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest.testSelfSignedCertificateWithStringExtensionValues(SelfSignedX509CertificateAndSigningKeyTest.java:197)
> {noformat}
> This is test line failing
> {code:java|title=SelfSignedX509CertificateAndSigningKeyTest.java}
> byte[] authorityInfoAccessExtension = certificate.getExtensionValue(X500.OID_PE_AUTHORITY_INFO_ACCESS);
> assertNotNull(authorityInfoAccessExtension);
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFCORE-3447) CLI security commands.
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3447?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise updated WFCORE-3447:
-----------------------------------------
Description:
In order to help configure server side security, a set of CLI commands should be defined to drive users to realise the main use cases:
- SSL keystore management
- SSL/HTTPS enablement/disablement
- SASL/HTTP authentication (based on certificate).
An analysis doc, work in progress: https://developer.jboss.org/wiki/SSLCommandsForCLI
was:
In order to help configure server side security, a set of CLI commands should be defined to drive users to realise the main use cases:
- SSL keystore management
- SSL/HTTPS enablement/disablement
- SASL/HTTP authentication (based on certificate).
> CLI security commands.
> ----------------------
>
> Key: WFCORE-3447
> URL: https://issues.jboss.org/browse/WFCORE-3447
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> In order to help configure server side security, a set of CLI commands should be defined to drive users to realise the main use cases:
> - SSL keystore management
> - SSL/HTTPS enablement/disablement
> - SASL/HTTP authentication (based on certificate).
> An analysis doc, work in progress: https://developer.jboss.org/wiki/SSLCommandsForCLI
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFCORE-3447) CLI security commands.
by Jean-Francois Denise (JIRA)
Jean-Francois Denise created WFCORE-3447:
--------------------------------------------
Summary: CLI security commands.
Key: WFCORE-3447
URL: https://issues.jboss.org/browse/WFCORE-3447
Project: WildFly Core
Issue Type: Feature Request
Components: CLI
Reporter: Jean-Francois Denise
Assignee: Jean-Francois Denise
In order to help configure server side security, a set of CLI commands should be defined to drive users to realise the main use cases:
- SSL keystore management
- SSL/HTTPS enablement/disablement
- SASL/HTTP authentication (based on certificate).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFLY-9596) Update domain mode tests to use NIO journal type for messaging
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFLY-9596:
--------------------------------------
Summary: Update domain mode tests to use NIO journal type for messaging
Key: WFLY-9596
URL: https://issues.jboss.org/browse/WFLY-9596
Project: WildFly
Issue Type: Task
Components: Test Suite
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 12.0.0.Alpha1
This is in relation to WFLY-9595 where failures are experienced on different environments in relation to the blocksize - however switching to NIO would make sense anyway.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFLY-9595) Incorrect Journal filesize calculation where specified size is lest that the block size when using AIO
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFLY-9595:
--------------------------------------
Summary: Incorrect Journal filesize calculation where specified size is lest that the block size when using AIO
Key: WFLY-9595
URL: https://issues.jboss.org/browse/WFLY-9595
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 11.0.0.Final
Reporter: Darran Lofthouse
Assignee: Jeff Mesnil
Fix For: 12.0.0.Alpha1
This issue was discovered as a side effect of: -
https://github.com/wildfly/wildfly/commit/df9e16241207ebc412ddd16c790c4b7...
This change updated the size to be 1024 for the tests as a large file was not necessary. For continuous integration the agents have a blocksize of 512 so as the configured size is a multiple of the blocksize this was fine.
However running the test 'org.jboss.as.test.integration.domain.ExpressionSupportSmokeTestCase' on a machine with a blocksize of 4096 this test would fail as the servers would fail to boot.
After some debugging it became aparant this was the underlying error: -
{noformat}
{"jboss.messaging-activemq.default.jms.manager" => "java.lang.IllegalArgumentException: File size cannot be less than 1024 bytes
Caused by: java.lang.IllegalArgumentException: File size cannot be less than 1024 bytes"}
{noformat}
After further debugging I have tracked it down to this class 'org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager' - I can confirm the configured value does make it to this class but it is the following block of code which then looses the value: -
{code:java}
int fileSize = config.getJournalFileSize();
// we need to correct the file size if its not a multiple of the alignement
int modulus = fileSize % journalFF.getAlignment();
if (modulus != 0) {
int difference = modulus;
int low = config.getJournalFileSize() - difference;
int high = low + journalFF.getAlignment();
fileSize = difference < journalFF.getAlignment() / 2 ? low : high;
ActiveMQServerLogger.LOGGER.invalidJournalFileSize(config.getJournalFileSize(), fileSize, journalFF.getAlignment());
}
Journal localMessage = new JournalImpl(ioExecutors, fileSize, config.getJournalMinFiles(), config.getJournalPoolFiles(), config.getJournalCompactMinFiles(), config.getJournalCompactPercentage(), journalFF, "activemq-data", "amq", journalFF.getMaxIO(), 0);
{code}
The file size comes in as 1024, the default is AIO so getAlignment returns the blocksize which in this case is 4096. So modulus and subsequently difference become 1024.
The file size and difference are both 1024 so low becomes 0, high becomes 4096. Due to the difference being less than half the block size low is selected and the file size is set to 0.
To select a correct filesize it looks like if low is less than the alignment always select high should be an option.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFLY-9595) Incorrect Journal filesize calculation where specified size is lest that the block size when using AIO
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-9595?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-9595:
----------------------------------------
I am going to go and create another issue as I have a fix for the test case to avoid triggering this so this issue is just to track the calculation issue.
> Incorrect Journal filesize calculation where specified size is lest that the block size when using AIO
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9595
> URL: https://issues.jboss.org/browse/WFLY-9595
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 11.0.0.Final
> Reporter: Darran Lofthouse
> Assignee: Jeff Mesnil
> Fix For: 12.0.0.Alpha1
>
>
> This issue was discovered as a side effect of: -
> https://github.com/wildfly/wildfly/commit/df9e16241207ebc412ddd16c790c4b7...
> This change updated the size to be 1024 for the tests as a large file was not necessary. For continuous integration the agents have a blocksize of 512 so as the configured size is a multiple of the blocksize this was fine.
> However running the test 'org.jboss.as.test.integration.domain.ExpressionSupportSmokeTestCase' on a machine with a blocksize of 4096 this test would fail as the servers would fail to boot.
> After some debugging it became aparant this was the underlying error: -
> {noformat}
> {"jboss.messaging-activemq.default.jms.manager" => "java.lang.IllegalArgumentException: File size cannot be less than 1024 bytes
> Caused by: java.lang.IllegalArgumentException: File size cannot be less than 1024 bytes"}
> {noformat}
> After further debugging I have tracked it down to this class 'org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager' - I can confirm the configured value does make it to this class but it is the following block of code which then looses the value: -
> {code:java}
> int fileSize = config.getJournalFileSize();
> // we need to correct the file size if its not a multiple of the alignement
> int modulus = fileSize % journalFF.getAlignment();
> if (modulus != 0) {
> int difference = modulus;
> int low = config.getJournalFileSize() - difference;
> int high = low + journalFF.getAlignment();
> fileSize = difference < journalFF.getAlignment() / 2 ? low : high;
> ActiveMQServerLogger.LOGGER.invalidJournalFileSize(config.getJournalFileSize(), fileSize, journalFF.getAlignment());
> }
> Journal localMessage = new JournalImpl(ioExecutors, fileSize, config.getJournalMinFiles(), config.getJournalPoolFiles(), config.getJournalCompactMinFiles(), config.getJournalCompactPercentage(), journalFF, "activemq-data", "amq", journalFF.getMaxIO(), 0);
> {code}
> The file size comes in as 1024, the default is AIO so getAlignment returns the blocksize which in this case is 4096. So modulus and subsequently difference become 1024.
> The file size and difference are both 1024 so low becomes 0, high becomes 4096. Due to the difference being less than half the block size low is selected and the file size is set to 0.
> To select a correct filesize it looks like if low is less than the alignment always select high should be an option.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (DROOLS-1846) Allow real time verification of Fact's constraints in Guided Editor
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1846?page=com.atlassian.jira.plugi... ]
Michael Biarnes Kiefer updated DROOLS-1846:
-------------------------------------------
Fix Version/s: 7.6.0.Final
(was: 7.5.0.Final)
> Allow real time verification of Fact's constraints in Guided Editor
> -------------------------------------------------------------------
>
> Key: DROOLS-1846
> URL: https://issues.jboss.org/browse/DROOLS-1846
> Project: Drools
> Issue Type: Feature Request
> Components: Guided Decision Table Editor, Guided Rule Editor, Guided Template Editor
> Reporter: Esteban Aliverti
> Assignee: Guilherme Carreiro
> Priority: Minor
> Labels: guvnor, real_time, real_time_verification
> Fix For: 7.6.0.Final
>
>
> It would be good to have real time validation of Fact's Constraints in Guvnor's Guided Editor.
> We can use the same verifier rules created by the constraints that are used right now in the "on demand" verification.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month