[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)
8 years, 5 months
[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)
8 years, 5 months
[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)
8 years, 5 months
[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)
8 years, 5 months
[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)
8 years, 5 months
[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)
8 years, 5 months
[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)
8 years, 5 months
[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)
8 years, 5 months
[JBoss JIRA] (DROOLS-1811) [Guided Decision Table] Column Wizard usability improvements
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1811?page=com.atlassian.jira.plugi... ]
Michael Biarnes Kiefer updated DROOLS-1811:
-------------------------------------------
Fix Version/s: 7.6.0.Final
(was: 7.5.0.Final)
> [Guided Decision Table] Column Wizard usability improvements
> ------------------------------------------------------------
>
> Key: DROOLS-1811
> URL: https://issues.jboss.org/browse/DROOLS-1811
> Project: Drools
> Issue Type: Enhancement
> Components: Guided Decision Table Editor
> Affects Versions: 7.2.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Carreiro
> Labels: UX
> Fix For: 7.6.0.Final
>
> Attachments: Screenshot from 2017-11-08 10-34-17.png
>
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> On the _BRMS 7.0 - Getting Started Experience_ meeting, there were mentioned these points that could improve the column wizard:
> - Placement of input fields
> -- *Field binding* should be on the same page as *Field*
> -- Pages like *Operator* and *Field* could be merged or at least recapitulate what was selected on previous pages of the wizard
> - *[UPDATED SOLVED]* Input fields should be explained somehow. For newbies it is really hard to understand what is the *Calculation Type* or *Value List*. I liked concept of small _i_ in blue circle that shows hint after mouse is over this info sign.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (DROOLS-1792) [Guided Decision Table] Default value of a column is not validated with the field data type
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1792?page=com.atlassian.jira.plugi... ]
Michael Biarnes Kiefer updated DROOLS-1792:
-------------------------------------------
Fix Version/s: 7.6.0.Final
(was: 7.5.0.Final)
> [Guided Decision Table] Default value of a column is not validated with the field data type
> -------------------------------------------------------------------------------------------
>
> Key: DROOLS-1792
> URL: https://issues.jboss.org/browse/DROOLS-1792
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor
> Affects Versions: 7.0.0.Beta5
> Reporter: Jozef Marko
> Assignee: Jozef Marko
> Labels: dtable_testday_preparation, qe-suggest-pre-7.0.0.Final, qe-test-day, reported-by-qe
> Fix For: 7.6.0.Final
>
>
> During definition of a condition or an action column, user has possibility to specify 'Default value' for this column. The problem is that the default value is not validated with the field data type. In practice it means that even when the column expects only _Integer_ values (because of the field data type), the default value still can be some _String_ value. The 'Default value' inputs should be validated like particular cells of the guided decision table. In those cells the user is not able to put _String_ value into the cell where are expected only _Integer_ values.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months