March 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1088) Add spring-jbpm-osgi-example to JBPM repository

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1088?page=com.atlassian.jira.plugi... ] Petr Široký commented on DROOLS-1088: ------------------------------------- There is https://issues.jboss.org/browse/ENTESB-3324 reported against this quickstart. It needs to be checked before adding the quickstart back. > Add spring-jbpm-osgi-example to JBPM repository > ----------------------------------------------- > > Key: DROOLS-1088 > URL: https://issues.jboss.org/browse/DROOLS-1088 > Project: Drools > Issue Type: Feature Request > Affects Versions: 6.4.0.CR1 > Reporter: David virgil naranjo > Assignee: Petr Široký > > The spring-jbpm-osgi-example is currently placed on Fuse-bxms-integ repository. It will be removed from this repository because it does not contain any kie-camel or another fuse-bxms-integ dependency. > It is required to include this quickstart and its feature to the jbpm repository: > <feature name="fuse-bxms-spring-jbpm-osgi-example" version="${project.version}"> > <feature version="${karaf.version.org.kie}">kie-spring</feature> > <bundle>mvn:org.jboss.integration.fuse.quickstarts/spring-jbpm-osgi-example/${project.version}</bundle> > </feature> -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6359) Investigate consequences of changes in JDK9 on JBoss Logging

by Richard Opalka (JIRA)

[ https://issues.jboss.org/browse/WFLY-6359?page=com.atlassian.jira.plugin.... ] Richard Opalka commented on WFLY-6359: -------------------------------------- It's not urgent because we have a workaround for it. > Investigate consequences of changes in JDK9 on JBoss Logging > ------------------------------------------------------------ > > Key: WFLY-6359 > URL: https://issues.jboss.org/browse/WFLY-6359 > Project: WildFly > Issue Type: Task > Components: Logging > Affects Versions: 10.0.0.Final > Reporter: Richard Opalka > Assignee: James Perkins > Fix For: 10.1.0.Final > > > When running: > $[wildfly-core/logging]>mvn test -Dtest=**/Log4jAppenderTestCase > on JDK9 the test is failing. After short debugging I identified the difference between JDK8 and JKD9 that is causing the test to fail. In JDK8 the relevant piece of code was: > {code} > // java.util.logging.Logger > private static Logger demandLogger(String name, String resourceBundleName, Class<?> caller) { > LogManager manager = LogManager.getLogManager(); > SecurityManager sm = System.getSecurityManager(); > if (sm != null && !SystemLoggerHelper.disableCallerCheck) { > if (caller.getClassLoader() == null) { > return manager.demandSystemLogger(name, resourceBundleName); > } > } > return manager.demandLogger(name, resourceBundleName, caller); > // ends up calling new Logger(name, resourceBundleName, caller) > // iff the logger doesn't exist already > } > {code} > in JDK9 the Security Manager check part disappeared: > {code} > // java.util.logging.Logger > private static Logger demandLogger(String name, String resourceBundleName, Class<?> caller) { > LogManager manager = LogManager.getLogManager(); > if (!SystemLoggerHelper.disableCallerCheck) { > if (caller.getClassLoader() == null) { > return manager.demandSystemLogger(name, resourceBundleName, caller); > } > } > return manager.demandLogger(name, resourceBundleName, caller); > // ends up calling new Logger(name, resourceBundleName, caller) > // iff the logger doesn't exist already > } > {code} > This change causes the platform java.util.logging.Logger is returned instead of expected one > org.jboss.logmanager.Logger. > It is possible to workaround this problem by setting sun.util.logging.disableCallerCheck JVM property, like: > $[wildfly-core/logging]>mvn test -Dtest=**/Log4jAppenderTestCase -Dsun.util.logging.disableCallerCheck=true > Please investigate, whether this is regression that should be addressed by Oracle and if there are not other potential problems affecting proper logging functionality on JDK9. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-441) LDAP and GSSAPI tests are very slow

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-441?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-441: --------------------------------- Fix Version/s: 1.1.0.Beta5 > LDAP and GSSAPI tests are very slow > ----------------------------------- > > Key: ELY-441 > URL: https://issues.jboss.org/browse/ELY-441 > Project: WildFly Elytron > Issue Type: Task > Components: Testsuite > Reporter: David Lloyd > Assignee: Darran Lofthouse > Priority: Minor > Fix For: 1.1.0.Beta5 > > > The LDAP and GSSAPI tests are very slow, which slows down the devel/build/test cycle fairly substantially. See if there is a way to reduce the overhead of these tests. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-441) LDAP and GSSAPI tests are very slow

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-441?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse reassigned ELY-441: ------------------------------------ Assignee: Darran Lofthouse > LDAP and GSSAPI tests are very slow > ----------------------------------- > > Key: ELY-441 > URL: https://issues.jboss.org/browse/ELY-441 > Project: WildFly Elytron > Issue Type: Task > Components: Testsuite > Reporter: David Lloyd > Assignee: Darran Lofthouse > Priority: Minor > > The LDAP and GSSAPI tests are very slow, which slows down the devel/build/test cycle fairly substantially. See if there is a way to reduce the overhead of these tests. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-441) LDAP and GSSAPI tests are very slow

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-441?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on ELY-441: --------------------------------- As of e46d5a9a4e7e572783374e0144a1b0dc552bb490, it is still quite slow unfortunately. Here are the slowest tests: {noformat} Running org.wildfly.security.sasl.gssapi.compatibility.BasicIntegrityTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.377 sec - in org.wildfly.security.sasl.gssapi.compatibility.BasicIntegrityTest Running org.wildfly.security.sasl.gssapi.compatibility.NoServerAuthTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.147 sec - in org.wildfly.security.sasl.gssapi.compatibility.NoServerAuthTest Running org.wildfly.security.sasl.gssapi.compatibility.BasicConfidenceTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 6 sec - in org.wildfly.security.sasl.gssapi.compatibility.BasicConfidenceTest Running org.wildfly.security.sasl.gssapi.compatibility.BasicAuthTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.08 sec - in org.wildfly.security.sasl.gssapi.compatibility.BasicAuthTest Running org.wildfly.security.sasl.gssapi.GssapiTestSuite Tests run: 24, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.829 sec - in org.wildfly.security.sasl.gssapi.GssapiTestSuite Running org.wildfly.security.sasl.gs2.Gs2Test Tests run: 18, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.917 sec - in org.wildfly.security.sasl.gs2.Gs2Test {noformat} > LDAP and GSSAPI tests are very slow > ----------------------------------- > > Key: ELY-441 > URL: https://issues.jboss.org/browse/ELY-441 > Project: WildFly Elytron > Issue Type: Task > Components: Testsuite > Reporter: David Lloyd > Priority: Minor > > The LDAP and GSSAPI tests are very slow, which slows down the devel/build/test cycle fairly substantially. See if there is a way to reduce the overhead of these tests. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-141) Add a Credential to Name Resolver SPI

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-141?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse commented on ELY-141: -------------------------------------- I think this is closely related to the EvidenceDecoder discussion we will have this week. > Add a Credential to Name Resolver SPI > ------------------------------------- > > Key: ELY-141 > URL: https://issues.jboss.org/browse/ELY-141 > Project: WildFly Elytron > Issue Type: Feature Request > Components: API / SPI > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta5 > > > We are predominantly considering this in the context of the validation side of the API. > However should still not exclude the possibility that after obtaining a RealmIdentity the validation may still be performed in the mechanism. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1288) installing CP over one-off fails if the modules patched by the one-off are not patched in the CP

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1288?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1288: ------------------------------------------------- Dominik Pospisil <dpospisi(a)redhat.com> changed the Status of [bug 1295999|https://bugzilla.redhat.com/show_bug.cgi?id=1295999] from POST to ASSIGNED > installing CP over one-off fails if the modules patched by the one-off are not patched in the CP > ------------------------------------------------------------------------------------------------ > > Key: WFCORE-1288 > URL: https://issues.jboss.org/browse/WFCORE-1288 > Project: WildFly Core > Issue Type: Bug > Components: Patching > Affects Versions: 1.0.1.Final > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > Priority: Critical > Fix For: 2.0.8.Final > > > If a CP is installed over active one-off patches, the patch application may fail if the CP does not contain updates for the modules that were patched by the one-offs. > Normally, CP patches accumulate the one-off patches released since the previous CP which is, probably, why this bug has not been discovered for a long time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-401) ELY01077: Invalid alias "TLS_RSA_WITH_DES_CBC_SHA" for missing mechanism database entry "TLS_RSA_FIPS_WITH_DES_CBC_SHA"

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-401?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse reassigned ELY-401: ------------------------------------ Assignee: Darran Lofthouse > ELY01077: Invalid alias "TLS_RSA_WITH_DES_CBC_SHA" for missing mechanism database entry "TLS_RSA_FIPS_WITH_DES_CBC_SHA" > ----------------------------------------------------------------------------------------------------------------------- > > Key: ELY-401 > URL: https://issues.jboss.org/browse/ELY-401 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL, Utils > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta5 > > > Getting the following warning logged when filtering the ciphers available from Oracle Java 8 with unlimited strength policy files in place: - > {noformat} > ELY01077: Invalid alias "TLS_RSA_WITH_DES_CBC_SHA" for missing mechanism database entry "TLS_RSA_FIPS_WITH_DES_CBC_SHA" > {noformat} > _The JCE policy is probably unrelated, mentioning it just in case._ -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-401) ELY01077: Invalid alias "TLS_RSA_WITH_DES_CBC_SHA" for missing mechanism database entry "TLS_RSA_FIPS_WITH_DES_CBC_SHA"

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-401?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse resolved ELY-401. ---------------------------------- Resolution: Duplicate Issue > ELY01077: Invalid alias "TLS_RSA_WITH_DES_CBC_SHA" for missing mechanism database entry "TLS_RSA_FIPS_WITH_DES_CBC_SHA" > ----------------------------------------------------------------------------------------------------------------------- > > Key: ELY-401 > URL: https://issues.jboss.org/browse/ELY-401 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL, Utils > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta5 > > > Getting the following warning logged when filtering the ciphers available from Oracle Java 8 with unlimited strength policy files in place: - > {noformat} > ELY01077: Invalid alias "TLS_RSA_WITH_DES_CBC_SHA" for missing mechanism database entry "TLS_RSA_FIPS_WITH_DES_CBC_SHA" > {noformat} > _The JCE policy is probably unrelated, mentioning it just in case._ -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-385) ELY01077: Invalid alias "TLS_RSA_WITH_DES_CBC_SHA"

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-385?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-385: --------------------------------- Fix Version/s: 1.1.0.Beta5 > ELY01077: Invalid alias "TLS_RSA_WITH_DES_CBC_SHA" > -------------------------------------------------- > > Key: ELY-385 > URL: https://issues.jboss.org/browse/ELY-385 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Affects Versions: 1.0.2.Final > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Optional > Fix For: 1.1.0.Beta5 > > Attachments: CipherSelectionTrace.txt > > > 05:48:13 [33m05:48:13,801 WARN [org.wildfly.security] (MSC service thread 1-2) ELY01077: Invalid alias "TLS_RSA_WITH_DES_CBC_SHA" for missing mechanism database entry "TLS_RSA_FIPS_WITH_DES_CBC_SHA" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2016