June 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-11716) Deployment Fails with @Transactional in Passivating Scope Bean

by Ingo Weiss (Jira)

[ https://issues.jboss.org/browse/WFLY-11716?page=com.atlassian.jira.plugin... ] Ingo Weiss updated WFLY-11716: ------------------------------ Labels: downstream_dependency (was: ) > Deployment Fails with @Transactional in Passivating Scope Bean > -------------------------------------------------------------- > > Key: WFLY-11716 > URL: https://issues.jboss.org/browse/WFLY-11716 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, Transactions > Affects Versions: 16.0.0.Beta1 > Environment: Java 8, Ubuntu Xenial > Reporter: Cody Lerum > Assignee: Matěj Novotný > Priority: Major > Labels: downstream_dependency > Fix For: 16.0.0.Final > > Attachments: jsf-npe.zip > > > On Wildfly 16.0.0.Beta1 deployment fails > {code} > org.jboss.weld.exceptions.UnserializableDependencyException: WELD-001477: The bean Managed Bean [class co.cfly.oss.lerg.rateCenter.inventoryRequest.InventoryRequestView] with qualifiers [@Default @Any @Named] declares a passivating scope but has a(n) Interceptor [class com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired intercepts @Transactional] with a non-passivation-capable dependency com.arjuna.ats.jta.cdi.JNDIBean@12e2cb9f > at org.jboss.weld.bootstrap.Validator.validateInterceptorDecoratorInjectionPointPassivationCapable(Validator.java:480) > at org.jboss.weld.bootstrap.Validator.validateInterceptors(Validator.java:225) > at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:175) > at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:526) > at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:64) > at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:62) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1810) (Intermittent) stuck start with secmgr after enabling Elytron JACC for undertow/application-security-domain

by Ingo Weiss (Jira)

[ https://issues.jboss.org/browse/ELY-1810?page=com.atlassian.jira.plugin.s... ] Ingo Weiss updated ELY-1810: ---------------------------- Labels: downstream_dependency (was: ) > (Intermittent) stuck start with secmgr after enabling Elytron JACC for undertow/application-security-domain > ----------------------------------------------------------------------------------------------------------- > > Key: ELY-1810 > URL: https://issues.jboss.org/browse/ELY-1810 > Project: WildFly Elytron > Issue Type: Bug > Components: EE > Affects Versions: 1.6.2.Final, 1.9.0.Final > Reporter: Ondrej Kotek > Assignee: Darran Lofthouse > Priority: Blocker > Labels: downstream_dependency > Fix For: 1.6.3.Final, 1.9.1.Final > > Attachments: Second.txt > > > After enabling JACC on {{undertow/application-security-domain=other}}, the server can get stuck when starting with Security Manager turned on. It stops responding and cannot be terminated by Ctrl-C. > After disabling JACC, or when starting without Security Manager, the server starts as expected. > This behaviour blocks customers that uses JACC with Security Manager. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1826) Cannot connect to management interface with Java Security Manager enabled

by Ingo Weiss (Jira)

[ https://issues.jboss.org/browse/ELY-1826?page=com.atlassian.jira.plugin.s... ] Ingo Weiss updated ELY-1826: ---------------------------- Labels: downstream_dependency (was: ) > Cannot connect to management interface with Java Security Manager enabled > ------------------------------------------------------------------------- > > Key: ELY-1826 > URL: https://issues.jboss.org/browse/ELY-1826 > Project: WildFly Elytron > Issue Type: Bug > Components: Security Manager > Affects Versions: 1.6.2.Final > Reporter: Ilia Vassilev > Assignee: Ilia Vassilev > Priority: Major > Labels: downstream_dependency > Fix For: 1.6.3.Final > > > When JBoss EAP is configured to authenticate management interfaces with LDAPS and RBAC enabled authentication works unless the security manager is enabled. When security manager is enabled the exception [1] occurs in console and exception [2] is logged in server.log > [1] > {code} > "Failed to connect to the controller: Unable to authenticate against controller at ... Authentication failed: all available authentication mechanisms failed: PLAIN: javax.security.sasl.SaslException: PLAIN: Server rejected authentication" > {code} > [2] > {code} > 2019-05-15 09:30:45,434 DEBUG [org.wildfly.security] (management task-3) Could not create [class javax.naming.ldap.InitialLdapContext]. Failed to connect to LDAP server.: javax.naming.CommunicationException: myldap.mydomain:636 [Root exception is java.lang.ClassNotFoundException: org/wildfly/security/auth/realm/ldap/ThreadLocalSSLSocketFactory] > at com.sun.jndi.ldap.Connection.<init>(Connection.java:238) > at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137) > at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1609) > at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2749) > at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319) > at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192) > at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210) > at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153) > at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83) > at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:116) > at org.jboss.as.naming.InitialContext.init(InitialContext.java:101) > at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154) > ... > at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:245) > at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:217) > at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:486) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:949) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.ClassNotFoundException: org/wildfly/security/auth/realm/ldap/ThreadLocalSSLSocketFactory > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:348) > at com.sun.jndi.ldap.VersionHelper12.loadClass(VersionHelper12.java:72) > at com.sun.jndi.ldap.Connection.createSocket(Connection.java:293) > at com.sun.jndi.ldap.Connection.<init>(Connection.java:215) > ... 42 more > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4514) ProxyMetadataSource breaks contract of ClassMetadataSource#getDeclaredMethods (resulting in "illegal reflective access operation" in Java 11)

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFCORE-4514?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-4514: ------------------------------------------ [~jaikiran] You are my hero! I've wondered what was behind WFLY-11717 for a while now. I'd looked at some testsuite logs and didn't seen any warns like this despite the many deployments that get tested so I figured it wasn't easy to reproduce, and without any reproducer I was down to fruitless code analysis. > ProxyMetadataSource breaks contract of ClassMetadataSource#getDeclaredMethods (resulting in "illegal reflective access operation" in Java 11) > --------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-4514 > URL: https://issues.jboss.org/browse/WFCORE-4514 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 9.0.1.Final > Environment: Java 11 > Reporter: Jaikiran Pai > Assignee: Jeff Mesnil > Priority: Major > > While investigating this issue reported in the forum thread[1], where the user states that using Java 11 shows up a warning about illegal reflective access: > {code} > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by org.jboss.invocation.proxy.AbstractProxyFactory$1 (jar:file:/C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/invocation/main/jboss-invocation-1.5.2.Final.jar!/) to method java.lang.Object.clone() > WARNING: Please consider reporting this to the maintainers of org.jboss.invocation.proxy.AbstractProxyFactory$1 > WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations > WARNING: All illegal access operations will be denied in a future release > {code} > I realized that, that issue is in fact triggered by, what I believe, is a bug and a violation of an (internal) API contract in WildFly. > What seems to be happening is - when the proxy class is being defined for (EJB) component, in the jboss-invocation library here[2], the implementation there overrides the component classes' methods. It does that for the entire class hierarchy of the component class and stops at the Object.class (rightly so) through the use of this check[3] (currentClass != Object.class). In this implementation, within the loop, it then calls: > {code} > ClassMetadataSource data = reflectionMetadataSource.getClassMetadata(currentClass); > {code} > which is an API exposed by the org.jboss.invocation.proxy.reflection.ReflectionMetadataSource interface. The returned ClassMetadataSource is then used within that loop as follows: > {code} > for (Method method : data.getDeclaredMethods()) { > .... > {code} > The getDeclaredMethods() API, exposed by ClassMetadataSource[5] is expected to (only) return the methods that are declared by that class. Turns out, the implementation in WildFly[6], for this interface, doesn't honour that contract and instead returns all methods (including the ones that are in the super class) on that class: > {code} > public Collection<Method> getDeclaredMethods() { > return index.getClassMethods(); > } > {code} > The index.getClassMethods() is a call to the ClassReflectionIndex#getClassMethods() whose implementation[7] walks through the entire class hierarchy and returns all the methods on that class. > This (unexpected) implemetation of ProxyMetadataSource#getDeclaredMethods()[6] causes the check in [3] to end up being irrelevant and as a result the code in [2] ends up trying to take control over methods on the Object class (by calling method.setAccessible(true)[8]) and one such method is the "clone" method. This ultimately results in that illegal reflective access warning. > Looking at the history of ProxyMetadataSource#getDeclaredMethods() in WildFly, it looks like the implementation was changed to accomodate/fix this issue https://issues.jboss.org/browse/WFCORE-579 in this commit https://github.com/wildfly/wildfly-core/commit/4382f0c28dab2d0494926b8a34.... The previous implementation was returning the correct methods (only the declared ones). Looking at that JIRA and linked bugzilla to it, I think the original issue might need a different fix. I haven't yet had a chance to look more into that issue. > Of course, one way to solve the current issue at hand (the illegal reflective access one) would be to add a check in > jboss-invocation's AbstractProxyFactory similar to this https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/..., but IMO, that would be more of a hack than an actual fix since the API contract violation in ProxyMetadataSource will still be an issue and can (and probably does) cause some unexpected problems. > [1] https://developer.jboss.org/message/989623#989623 > [2] https://github.com/jbossas/jboss-invocation/blob/master/src/main/java/org... > [3] https://github.com/jbossas/jboss-invocation/blob/master/src/main/java/org... > [4] https://github.com/jbossas/jboss-invocation/blob/master/src/main/java/org... > [5] https://github.com/jbossas/jboss-invocation/blob/master/src/main/java/org... > [6] https://github.com/wildfly/wildfly-core/blob/5391b40b79f72d2a57d4e32234af... > [7] https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/... > [8] https://github.com/jbossas/jboss-invocation/blob/master/src/main/java/org... -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12211) Upstream test case for JBEAP-16919

by Daniel Cihak (Jira)

Daniel Cihak created WFLY-12211: ----------------------------------- Summary: Upstream test case for JBEAP-16919 Key: WFLY-12211 URL: https://issues.jboss.org/browse/WFLY-12211 Project: WildFly Issue Type: Task Components: Test Suite Reporter: Daniel Cihak Assignee: Daniel Cihak Create upstream test case for JBEAP-16919. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12210) Upgrade Infinispan to 9.4.15.Final

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-12210: ----------------------------------- Summary: Upgrade Infinispan to 9.4.15.Final Key: WFLY-12210 URL: https://issues.jboss.org/browse/WFLY-12210 Project: WildFly Issue Type: Component Upgrade Components: Clustering Affects Versions: 17.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro https://issues.jboss.org/projects/ISPN/versions/12342165 -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12202) Need to use principal-transformer in aggregate-realm in between authentication-realm and authorization-realm

by Ashley Abdel-Sayed (Jira)

[ https://issues.jboss.org/browse/WFLY-12202?page=com.atlassian.jira.plugin... ] Ashley Abdel-Sayed updated WFLY-12202: -------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/12371 > Need to use principal-transformer in aggregate-realm in between authentication-realm and authorization-realm > ------------------------------------------------------------------------------------------------------------ > > Key: WFLY-12202 > URL: https://issues.jboss.org/browse/WFLY-12202 > Project: WildFly > Issue Type: Feature Request > Components: Security > Reporter: Ashley Abdel-Sayed > Assignee: Ashley Abdel-Sayed > Priority: Major > > It is requirement to use principal-transformer in aggregate-realm in between authentication-realm and authorization-realm . > -------------------------------------- > <security-domain name="TestDomain" default-realm="TestAggRealm" permission-mapper="default-permission-mapper" pre-realm-principal-transformer="test-transformer" security-event-listener="local-audit"> > <realm name="TestAggRealm" role-decoder="from-roles-attribute"/> > </security-domain> > . > . > <aggregate-realm name="TestAggRealm" authentication-realm="TestLdapRealm" authorization-realm="Test_Auth_LdapRealm"/> > -------------------------------------- > I think to achieve this there need to be something like "mid-realm-principal-transformer" in <aggregate-realm> only . -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4496) Need to use principal-transformer in aggregate-realm in between authentication-realm and authorization-realm

by Ashley Abdel-Sayed (Jira)

[ https://issues.jboss.org/browse/WFCORE-4496?page=com.atlassian.jira.plugi... ] Ashley Abdel-Sayed updated WFCORE-4496: --------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/3825 > Need to use principal-transformer in aggregate-realm in between authentication-realm and authorization-realm > ------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-4496 > URL: https://issues.jboss.org/browse/WFCORE-4496 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Indrajit Ingawale > Assignee: Ashley Abdel-Sayed > Priority: Major > > It is requirement to use principal-transformer in aggregate-realm in between authentication-realm and authorization-realm . > -------------------------------------- > <security-domain name="TestDomain" default-realm="TestAggRealm" permission-mapper="default-permission-mapper" pre-realm-principal-transformer="test-transformer" security-event-listener="local-audit"> > <realm name="TestAggRealm" role-decoder="from-roles-attribute"/> > </security-domain> > . > . > <aggregate-realm name="TestAggRealm" authentication-realm="TestLdapRealm" authorization-realm="Test_Auth_LdapRealm"/> > -------------------------------------- > I think to achieve this there need to be something like "mid-realm-principal-transformer" in <aggregate-realm> only . -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4150) Support automatically adding / updating credentials in the CredentialStore

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFCORE-4150?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on WFCORE-4150: ------------------------------------------ [~fjuma] You may already have a duplicate issue but this is related to the task you are looking into. > Support automatically adding / updating credentials in the CredentialStore > -------------------------------------------------------------------------- > > Key: WFCORE-4150 > URL: https://issues.jboss.org/browse/WFCORE-4150 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Darran Lofthouse > Assignee: Farah Juma > Priority: Major > Fix For: 10.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4150) Support automatically adding / updating credentials in the CredentialStore

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFCORE-4150?page=com.atlassian.jira.plugi... ] Darran Lofthouse reassigned WFCORE-4150: ---------------------------------------- Assignee: Farah Juma (was: Darran Lofthouse) > Support automatically adding / updating credentials in the CredentialStore > -------------------------------------------------------------------------- > > Key: WFCORE-4150 > URL: https://issues.jboss.org/browse/WFCORE-4150 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Darran Lofthouse > Assignee: Farah Juma > Priority: Major > Fix For: 10.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 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 June 2019