January 2018 - jboss-jira - Jboss List Archives

[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 commented on ELY-1298: --------------------------------- In the end will remove compatibility tests of GSSAPI - the output is mostly generated by backing GSS mechanism and it is very sensitive on its implementation. I will only extend checking of negotiated MAX_BUFFER/RAW_SEND_SIZE, which is more or less only thing negotiated by the SASL mechanism itself. > 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: Jan Kalina > Priority: Critical > 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)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3396) Provide certificate authority integration

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3396?page=com.atlassian.jira.plugi... ] Farah Juma updated WFCORE-3396: ------------------------------- Description: Let's Encrypt provide API to fully automate (gain/renew) certificate retrieval using ACME protocol. Integrate this capability into wildfly. This can simplify administrator work. No need to perform certification renewal routine tasks. This is follow up on WFCORE-3305 and piece of bigger task "Simplify SSL configuration in wildfly". That said it is just "User experience" issue. Administrator still can work with Let's Encrypt by third party client and just reference wildfly to this certificate. [1] Latest draft: https://tools.ietf.org/html/draft-ietf-acme-acme-09 was: Let's Encrypt provide API to fully automate (gain/renew) certificate retrieval using ACME protocol. Integrate this capability into wildfly. This can simplify administrator work. No need to perform certification renewal routine tasks. This is follow up on WFCORE-3305 and piece of bigger task "Simplify SSL configuration in wildfly". That said it is just "User experience" issue. Administrator still can work with Let's Encrypt by third party client and just reference wildfly to this certificate. [1] Latest draft: https://tools.ietf.org/html/draft-ietf-acme-acme-08 > Provide certificate authority integration > ----------------------------------------- > > Key: WFCORE-3396 > URL: https://issues.jboss.org/browse/WFCORE-3396 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Affects Versions: 4.0.0.Alpha2 > Reporter: Martin Choma > Assignee: Farah Juma > > Let's Encrypt provide API to fully automate (gain/renew) certificate retrieval using ACME protocol. Integrate this capability into wildfly. > This can simplify administrator work. No need to perform certification renewal routine tasks. > This is follow up on WFCORE-3305 and piece of bigger task "Simplify SSL configuration in wildfly". That said it is just "User experience" issue. Administrator still can work with Let's Encrypt by third party client and just reference wildfly to this certificate. > [1] Latest draft: https://tools.ietf.org/html/draft-ietf-acme-acme-09 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9650) add persistence unit hint for JNDI lookup that returns object passed to persistence provider (for OGM to integrate with wildfly-nosql profiles)

by Scott Marlow (JIRA)

Scott Marlow created WFLY-9650: ---------------------------------- Summary: add persistence unit hint for JNDI lookup that returns object passed to persistence provider (for OGM to integrate with wildfly-nosql profiles) Key: WFLY-9650 URL: https://issues.jboss.org/browse/WFLY-9650 Project: WildFly Issue Type: Task Components: JPA / Hibernate Reporter: Scott Marlow Assignee: Scott Marlow -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3485) Misleading failure-description for capabilities in domain

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3485?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-3485: ------------------------------------------ The /host=master/subsystem=elytron/security-domain=* location *is* a possible registration point for the capability, i.e. it's a resource address that can provide that capability. It's a valid point though that that registration point can't satisfy the requirement, so mentioning it is distracting. It can't satisfy the requirement because that address is in a CapabilityScope that is not visible to the /profile=* resources. Whether we fix this will depend on how much complexity filtering the message output to account for scope adds. > Misleading failure-description for capabilities in domain > --------------------------------------------------------- > > Key: WFCORE-3485 > URL: https://issues.jboss.org/browse/WFCORE-3485 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.10.Final > Reporter: Ondrej Lukas > Assignee: Brian Stansberry > Priority: Minor > > In case when configuration in domain.xml tries to reference any capability from host.xml (or vice versa), but should not be able to reference it then it correctly fails, but there is failure-description which is misleading. > Start domain with default domain.xml and host.xml and run following CLI command and see: > {code} > /profile=full/subsystem=elytron/http-authentication-factory=some-factory:add(http-server-mechanism-factory=global,security-domain=ManagementDomain) > { > "outcome" => "failed", > "failure-description" => {"domain-failure-description" => "WFLYCTL0369: Required capabilities are not available: > org.wildfly.security.security-domain.ManagementDomain in context 'profile=full'; Possible registration points for this capability: > /host=master/subsystem=elytron/security-domain=* > /profile=*/subsystem=elytron/security-domain=*"}, > "rolled-back" => true > } > {code} > It should show only correct registration point {{/profile=\*/subsystem=elytron/security-domain=\*}}. It is misleading because ManagementDomain capability exists in {{/host=master/subsystem=elytron/security-domain=*}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3485) Misleading failure-description for capabilities in domain

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3485?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3485: ------------------------------------- Priority: Minor (was: Major) > Misleading failure-description for capabilities in domain > --------------------------------------------------------- > > Key: WFCORE-3485 > URL: https://issues.jboss.org/browse/WFCORE-3485 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.10.Final > Reporter: Ondrej Lukas > Assignee: Brian Stansberry > Priority: Minor > > In case when configuration in domain.xml tries to reference any capability from host.xml (or vice versa), but should not be able to reference it then it correctly fails, but there is failure-description which is misleading. > Start domain with default domain.xml and host.xml and run following CLI command and see: > {code} > /profile=full/subsystem=elytron/http-authentication-factory=some-factory:add(http-server-mechanism-factory=global,security-domain=ManagementDomain) > { > "outcome" => "failed", > "failure-description" => {"domain-failure-description" => "WFLYCTL0369: Required capabilities are not available: > org.wildfly.security.security-domain.ManagementDomain in context 'profile=full'; Possible registration points for this capability: > /host=master/subsystem=elytron/security-domain=* > /profile=*/subsystem=elytron/security-domain=*"}, > "rolled-back" => true > } > {code} > It should show only correct registration point {{/profile=\*/subsystem=elytron/security-domain=\*}}. It is misleading because ManagementDomain capability exists in {{/host=master/subsystem=elytron/security-domain=*}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9633) Add mixed domain tests for EAP 7.1.0

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-9633?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFLY-9633: -------------------------------------- Assignee: Kabir Khan (was: Brian Stansberry) > Add mixed domain tests for EAP 7.1.0 > ------------------------------------ > > Key: WFLY-9633 > URL: https://issues.jboss.org/browse/WFLY-9633 > Project: WildFly > Issue Type: Task > Components: Domain Management, Test Suite > Reporter: Kabir Khan > Assignee: Kabir Khan > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3492) MBean remove notification listener use wrong operation name

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3492?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-3492: ---------------------------------------- Assignee: Bartosz Baranowski Assigning to, Bartosz, as you already did a downstream PR. > MBean remove notification listener use wrong operation name > ----------------------------------------------------------- > > Key: WFCORE-3492 > URL: https://issues.jboss.org/browse/WFCORE-3492 > Project: WildFly Core > Issue Type: Bug > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9649) Clustering capabilities created via BinaryRequirementCapability need to define a dynamic name mapper

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-9649: ---------------------------------- Summary: Clustering capabilities created via BinaryRequirementCapability need to define a dynamic name mapper Key: WFLY-9649 URL: https://issues.jboss.org/browse/WFLY-9649 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 11.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro This is required so that any tooling can correctly construct the capability names from a PathAddress using only the registered RuntimeCapability object. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9529) Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry

by Scott Van Wart (JIRA)

[ https://issues.jboss.org/browse/WFLY-9529?page=com.atlassian.jira.plugin.... ] Scott Van Wart commented on WFLY-9529: -------------------------------------- [~emmartins] I don't suppose there's a workaround for this in the meantime? I'm at a couple of months and am still dealing with this regularly. > Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry > --------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9529 > URL: https://issues.jboss.org/browse/WFLY-9529 > Project: WildFly > Issue Type: Bug > Components: JMS, Naming > Affects Versions: 10.1.0.Final, 11.0.0.Final > Environment: Running on Windows 10, Java 64-bit 1.8.0_131 > Reporter: Scott Van Wart > Assignee: Eduardo Martins > Labels: ActiveMQ, jms, transaction > Attachments: injected-jms.zip, injected-jms2.zip, wildfly-11-injected-jms.txt > > > If I try to use an @Injected JMSContext while executing within a background task (ManagedExecutorService) or thread (ManagedThreadFactory), I get the attached stacktrace. I've experienced this a number of times with Wildfly 10.1.0, including messages sent in Infinispan's expiry task thread. > My original workaround was to submit an additional task on a separate thread to send the message, then wait for it to complete. That seemed unreliable (sometimes it would still produce NameNotFoundException). I've resorted to creating my own JMSContext by using @Resource( lookup="java:/ConnectionFactory" ) and sending messages that way. Both workarounds prevent the message sending logic from participating in any ongoing transactions. > I'm also attaching a sample EAR project. It can be built with Maven. It creates a background task that waits 3 seconds and then tries to send a JMS message in a new transaction using an injected JMS context. I use the standalone-full.xml profile to run it. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8917) EJB run-as identity gets lost if an unsecured ejb in the call stack

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-8917?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-8917: ----------------------------------------------- Jiří Bílek <jbilek(a)redhat.com> changed the Status of [bug 1460347|https://bugzilla.redhat.com/show_bug.cgi?id=1460347] from ON_QA to VERIFIED > EJB run-as identity gets lost if an unsecured ejb in the call stack > -------------------------------------------------------------------- > > Key: WFLY-8917 > URL: https://issues.jboss.org/browse/WFLY-8917 > Project: WildFly > Issue Type: Bug > Components: EJB, Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Derek Horton > Assignee: Darran Lofthouse > Fix For: 11.0.0.Beta1 > > Attachments: SimpleEAR_EJB3.ear > > > Having an unsecured EJB in the call stack will cause the RunAs identity to get lost. > An example might look like this: > unsecured web app (RunAs: JBossAdmin) -> unsecured HelloBean EJB -> secured GoodBye EJB (RolesAllowed: JBossAdmin) > This will fail as the unsecured ejb causes the RunAs identity to get dropped/lost. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

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 January 2018