[JBoss JIRA] (WFLY-6174) Upgrade Weld to 2.3.3.Final
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-6174?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-6174:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> Upgrade Weld to 2.3.3.Final
> ---------------------------
>
> Key: WFLY-6174
> URL: https://issues.jboss.org/browse/WFLY-6174
> Project: WildFly
> Issue Type: Component Upgrade
> Components: CDI / Weld
> Reporter: Martin Kouba
> Assignee: Martin Kouba
> Fix For: 11.0.0.Final
>
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-4590) l1-lifespan attribute in distributed cache configuration does not enable l1 cache
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4590?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-4590:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> l1-lifespan attribute in distributed cache configuration does not enable l1 cache
> ---------------------------------------------------------------------------------
>
> Key: WFLY-4590
> URL: https://issues.jboss.org/browse/WFLY-4590
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 9.0.0.CR1
> Reporter: Dominik Pospisil
> Assignee: Dominik Pospisil
> Fix For: 11.0.0.Final
>
>
> l1-lifespan attribute in distributed cache configuration is not honored. If set to a non-zero value it just sets the underlying cache config parameter, but does not explicitly enable l1 which is by default disabled.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-8362) upgrade jboss-ejb-client to 4.0.0.Beta20
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-8362?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-8362:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> upgrade jboss-ejb-client to 4.0.0.Beta20
> ----------------------------------------
>
> Key: WFLY-8362
> URL: https://issues.jboss.org/browse/WFLY-8362
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Application Client, EJB
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
> Fix For: 11.0.0.Final
>
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-6796) Upgrade Weld to 2.3.5.Final
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-6796?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-6796:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> Upgrade Weld to 2.3.5.Final
> ---------------------------
>
> Key: WFLY-6796
> URL: https://issues.jboss.org/browse/WFLY-6796
> Project: WildFly
> Issue Type: Component Upgrade
> Components: CDI / Weld
> Reporter: Martin Kouba
> Assignee: Martin Kouba
> Fix For: 11.0.0.Final
>
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-6193) CustomProviderPreferenceTest fails due to ReflectPermission
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-6193?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-6193:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> CustomProviderPreferenceTest fails due to ReflectPermission
> -----------------------------------------------------------
>
> Key: WFLY-6193
> URL: https://issues.jboss.org/browse/WFLY-6193
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Hynek Švábek
> Assignee: Ivo Studensky
> Fix For: 11.0.0.Final
>
>
> *org.jboss.as.test.integration.jaxrs.provider.preference.CustomProviderPreferenceTest#testCustomMessageBodyWriterIsUsed*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.jaxrs.provider.preference.CustomProviderPreferenceTest#testCustomMessageBodyWriterIsUsed}}
> Fails with:
> {code}
> ERROR [io.undertow.request] (default task-100) UT005023: Exception handling request to /providers/api/user: org.jboss.resteasy.spi.UnhandledException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.reflect.ReflectPermission" "suppressAccessChecks")" in code source "(vfs:/content/providers.war/WEB-INF/classes <no signer certificates>)" of "null")
> at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76)
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212)
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:168)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:411)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180)
> at java.security.AccessController.doPrivileged(Native Method)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.reflect.ReflectPermission" "suppressAccessChecks")" in code source "(vfs:/content/providers.war/WEB-INF/classes <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:128)
> at org.jboss.resteasy.core.PropertyInjectorImpl.populateMap(PropertyInjectorImpl.java:69)
> at org.jboss.resteasy.core.PropertyInjectorImpl.<init>(PropertyInjectorImpl.java:54)
> at org.jboss.resteasy.cdi.JaxrsInjectionTarget.getPropertyInjector(JaxrsInjectionTarget.java:102)
> at org.jboss.resteasy.cdi.JaxrsInjectionTarget.inject(JaxrsInjectionTarget.java:50)
> at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:159)
> at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
> at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101)
> at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.get(ContextualInstanceStrategy.java:178)
> at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
> at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99)
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
> at org.jboss.as.test.integration.jaxrs.provider.preference.Resource$Proxy$_$$_WeldClientProxy.getUser(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395)
> ... 34 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-7631) Elytron ldap-realm does not support recursive role search
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-7631?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-7631:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> Elytron ldap-realm does not support recursive role search
> ---------------------------------------------------------
>
> Key: WFLY-7631
> URL: https://issues.jboss.org/browse/WFLY-7631
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
> Fix For: 11.0.0.Final
>
>
> Scenario:
> LDAP can include some roles which are members of other roles. I try to assigned also these "nested roles" to user during authentication/authorization process.
> In EAP 7.0 (with PicketBox) I am able to set configuration, which allows to assign these roles to user. LdapExtLoginModule with module option {{roleRecursion}} serves for this. It uses int value which determines how many levels should be searched and assigned to user. I am not able to achieve this scenario with Elytron and its ldap-realm.
> Missing this feature in Elytron can lead to situation when migration from PicketBox to Elytron will not be possible since LDAP structure for role assignment used by legacy solution will not be able to work correctly with Elytron.
> See example of LDIF for LDAP server:
> {code}
> dn: ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: People
> dn: uid=jduke,ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: jduke
> cn: Java Duke
> sn: Duke
> userPassword: Password1
> dn: ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: Roles
> dn: cn=R1,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R1
> member: uid=jduke,ou=People,dc=jboss,dc=org
> description: the R1 group
> dn: cn=R2,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R2
> member: cn=R1,ou=Roles,dc=jboss,dc=org
> description: the R2 group
> dn: cn=R3,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R3
> member: cn=R2,ou=Roles,dc=jboss,dc=org
> description: the R3 group
> {code}
> In Elytron I am able to assigned only {{R1}} role to user jduke. Legacy solution is able to use for example {{roleRecursion=1}} which results to assign roles {{R1}} and {{R2}} to user jduke.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-4818) WS-RM persistence with RMTxStore does not work with JNDI Lookup
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4818?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-4818:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> WS-RM persistence with RMTxStore does not work with JNDI Lookup
> ---------------------------------------------------------------
>
> Key: WFLY-4818
> URL: https://issues.jboss.org/browse/WFLY-4818
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 10.0.0.Alpha3
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
> Fix For: 11.0.0.Final
>
>
> This is copy of https://bugzilla.redhat.com/show_bug.cgi?id=1223698
> When using reliable messaging feature with RMTxStore, WS calls fail with:
> java.sql.SQLException: You cannot commit with autocommit set!
> at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.jdbcCommit(BaseWrapperManagedConnection.java:1071)
> at org.jboss.jca.adapters.jdbc.WrappedConnection.commit(WrappedConnection.java:758)
> at org.apache.cxf.ws.rm.persistence.jdbc.RMTxStore.commit(RMTxStore.java:709)
> at org.apache.cxf.ws.rm.persistence.jdbc.RMTxStore.removeSourceSequence(RMTxStore.java:495)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-7071) Changing default-realm of Elytron security-domain through CLI can put the server configuration to wrong state
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-7071?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-7071:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> Changing default-realm of Elytron security-domain through CLI can put the server configuration to wrong state
> -------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7071
> URL: https://issues.jboss.org/browse/WFLY-7071
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Fix For: 11.0.0.Final
>
>
> Values of write-attribute operation for default-realm of Elytron security-domain are not checked. It means that CLI allows users to set application server to wrong state. The same happens if realm, which is considered as default-realm, is removed from used security-domain realms. CLI should deny write attribute operation with wrong value (in the same way as it works for another security-domain attributes).
> After reload, server is not started and following logs occur in console:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 25) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("security-domain" => "ApplicationDomain")
> ]) - failure description: "WFLYELY00013: The default_realm 'WrongRealm' is not in the list or realms referenced by this domain."
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem elytron boot operations"
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem elytron boot operations\""
> FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-7730) Problem in undertow application-security-domain removing
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-7730?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-7730:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> Problem in undertow application-security-domain removing
> --------------------------------------------------------
>
> Key: WFLY-7730
> URL: https://issues.jboss.org/browse/WFLY-7730
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 11.0.0.Alpha1
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Fix For: 11.0.0.Final
>
>
> Following error when try to remove *undertow.application-security-domain*:
> {code:java}
> WFLYCTL0013: Operation ("remove") failed - address: ([
> ("subsystem" => "undertow"),
> ("application-security-domain" => "ejb3-tests")
> ]): java.lang.IllegalArgumentException: WFLYCTL0394: Capability 'org.wildfly.extension.undertow.application-security-domain.ejb3-tests' does not provide services of type 'class org.wildfly.security.auth.server.HttpAuthenticationFactory'
> {code}
> Problem is wrong type in obtaining service in RemoveHandler.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months