[JBoss JIRA] (WFCORE-1332) Referrals 'throw' does not work correctly for ldap authentication to mgmt console with MS Active Directory
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1332?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved JBEAP-3048 to WFCORE-1332:
-------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1332 (was: JBEAP-3048)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
Security
(was: Domain Management)
(was: Security)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 2.0.7.Final
(was: 7.0.0.ER4)
> Referrals 'throw' does not work correctly for ldap authentication to mgmt console with MS Active Directory
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1332
> URL: https://issues.jboss.org/browse/WFCORE-1332
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 2.0.7.Final
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
>
> In case when crossRef object to different domain is configured on MS Active Directory for handling referrals and JBoss EAP 7 uses ldap authentication to mgmt console with configured referrals 'throw' then authentication fails for referral users. It is inconsistent with behavior of EAP with another LDAP providers (e.g. Red Hat Directory Server). In correct behavior authentication should pass.
> It seems it is caused by thrown LdapReferralException search method of org.jboss.as.domain.management.security.LdapUserSearcherFactory.LdapUserSearcherImpl before it is handled by try-catch block. Stack trace of thrown LdapReferralException:
> com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2975)
> com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2888)
> com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1846)
> com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1769)
> com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1786)
> com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:418)
> com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:396)
> com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:378)
> javax.naming.directory.InitialDirContext.search(InitialDirContext.java:286)
> javax.naming.directory.InitialDirContext.search(InitialDirContext.java:286)
> org.jboss.as.domain.management.security.LdapUserSearcherFactory$LdapUserSearcherImpl.search(LdapUserSearcherFactory.java:125)
> org.jboss.as.domain.management.security.LdapUserSearcherFactory$LdapUserSearcherImpl.search(LdapUserSearcherFactory.java:66)
> org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:225)
> org.jboss.as.domain.management.security.UserLdapCallbackHandler$LdapCallbackHandler.handle(UserLdapCallbackHandler.java:205)
> org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:178)
> org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:162)
> org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:141)
> io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:118)
> org.jboss.as.domain.http.server.security.AuthenticationMechanismWrapper.authenticate(AuthenticationMechanismWrapper.java:52)
> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233)
> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250)
> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219)
> io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121)
> io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96)
> io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89)
> io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50)
> io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6070) Can not deploy a @ConnectionFactoryDefinition if the RA has more <connection-definitions>
by Lin Gao (JIRA)
Lin Gao created WFLY-6070:
-----------------------------
Summary: Can not deploy a @ConnectionFactoryDefinition if the RA has more <connection-definitions>
Key: WFLY-6070
URL: https://issues.jboss.org/browse/WFLY-6070
Project: WildFly
Issue Type: Bug
Components: JCA
Affects Versions: 10.0.0.CR5
Reporter: Lin Gao
Assignee: Lin Gao
Steps to reproduce:
* add a 2nd connection-defintion to testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jca/deployment/ra.xml:
{noformat}
<connection-definition>
<managedconnectionfactory-class>org.jboss.as.test.integration.jca.rar.MultipleManagedConnectionFactory2</managedconnectionfactory-class>
<connectionfactory-interface>org.jboss.as.test.integration.jca.rar.MultipleConnectionFactory2</connectionfactory-interface>
<connectionfactory-impl-class>org.jboss.as.test.integration.jca.rar.MultipleConnectionFactory2Impl</connectionfactory-impl-class>
<connection-interface>org.jboss.as.test.integration.jca.rar.MultipleConnection2</connection-interface>
<connection-impl-class>org.jboss.as.test.integration.jca.rar.MultipleConnection2Impl</connection-impl-class>
</connection-definition>
{noformat}
* Run the WarServletDeploymentTestCase test
=> it fails because the ConnectionFactoryDefinition objects are no longer deployed.
After debugging, the test fails because the deployed connection definitions are not activated.
The code at org/jboss/as/connector/services/resourceadapters/ResourceAdapterActivatorService.java:232 is preventing the activation and looks suspicious.
It expects that all the MCF in the RA (raMcfClasses) must *all* be in the activation (ijMcfClasses).
With a 2nd <connection-definition> in the RA, it is no longer the case (as the activation only contains a single MCF (MultipleManagedConnectionFactory1).
If I change the code so that it checks that all the MCF in the activations are in the RA, the test passes again.
This issue is preventing me to reuse the code handling the @ConnectionFactoryDefinition to support the @JMSConnectionFactoryDefinition (my JMS RA defines 3 MCF for generic/queue/topic CFs but my activation only defines a single MCF per @JMSConnectionFactoryDefinition).
I've not run it but the same issue is likely for admin objects too (the code in checkActivation is similar)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-1037) Parsing of a complex constraint with an || causes a RuntimeException
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1037?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on DROOLS-1037:
-------------------------------------------------
Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1300692|https://bugzilla.redhat.com/show_bug.cgi?id=1300692] from NEW to MODIFIED
> Parsing of a complex constraint with an || causes a RuntimeException
> --------------------------------------------------------------------
>
> Key: DROOLS-1037
> URL: https://issues.jboss.org/browse/DROOLS-1037
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.4.0.CR1
>
>
> Trying to compile a rule like the following
> {code}
> rule R when
> $p : Person( name == null || (name in (\"Alice\", \"Charlie\", \"David\"))==false )
> then
> list.add($p.getName());
> end
> {code}
> causes the following RuntimeException:
> {code}
> java.lang.RuntimeException
> at org.drools.compiler.rule.builder.PatternBuilder.rewriteCompositeExpressions(PatternBuilder.java:924)
> at org.drools.compiler.rule.builder.PatternBuilder.rewriteCompositeExpressions(PatternBuilder.java:919)
> at org.drools.compiler.rule.builder.PatternBuilder.rewriteOrExpressions(PatternBuilder.java:893)
> at org.drools.compiler.rule.builder.PatternBuilder.buildExpression(PatternBuilder.java:889)
> at org.drools.compiler.rule.builder.PatternBuilder.buildCcdDescr(PatternBuilder.java:860)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:715)
> at org.drools.compiler.rule.builder.PatternBuilder.processConstraintsAndBinds(PatternBuilder.java:580)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6069) Duplicated jipijapa module
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6069?page=com.atlassian.jira.plugin.... ]
Scott Marlow updated WFLY-6069:
-------------------------------
Description:
modules/system/layers/base/org/hibernate/jipijapa-hibernate4-3/main/jipijapa-hibernate4-3-10.0.0.CR6-redhat-1.jar
modules/system/layers/base/org/hibernate/4.3/jipijapa-hibernate4-3-10.0.0.CR6-redhat-1.jar
was:
modules/system/layers/base/org/hibernate/jipijapa-hibernate4-3/main/jipijapa-hibernate4-3-10.0.0.CR6-redhat-1.jar
modules/system/layers/base/org/hibernate/4.3/jipijapa-hibernate4-3-10.0.0.CR6-redhat-1.jar
Refer to this tattletale report:
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Accep...
> Duplicated jipijapa module
> --------------------------
>
> Key: WFLY-6069
> URL: https://issues.jboss.org/browse/WFLY-6069
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Affects Versions: 10.0.0.CR5
> Reporter: Jan Martiska
> Assignee: Scott Marlow
> Priority: Critical
> Fix For: 10.0.0.Final
>
>
> modules/system/layers/base/org/hibernate/jipijapa-hibernate4-3/main/jipijapa-hibernate4-3-10.0.0.CR6-redhat-1.jar
> modules/system/layers/base/org/hibernate/4.3/jipijapa-hibernate4-3-10.0.0.CR6-redhat-1.jar
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JGRP-2007) Adapt code to use new Java 8 features
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2007?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2007 at 1/26/16 8:50 AM:
---------------------------------------------------------
Also look at
* -MessageBatch-: DONE
* Table (Visitor)
* Use default methods in interfaces
* -Condition / CondVar- : DONE
was (Author: belaban):
Also look at
* -MessageBatch-: DONE
* Table (Visitor)
* Use default methods in interfaces
* Replace NotifyingFuture with CompletableFuture
* -Condition / CondVar- : DONE
> Adapt code to use new Java 8 features
> -------------------------------------
>
> Key: JGRP-2007
> URL: https://issues.jboss.org/browse/JGRP-2007
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0
>
>
> E.g replace loops for forEach() etc
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JGRP-1605) API changes
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1605?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1605:
---------------------------
Description:
API changes to be done in 4.0, which break code:
* MessageDispatcher: remove MessageListener
* Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
* Remove @Deprecated methods, properties or classes
* Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
* Make {{RspFilter}} --> {{RspFilter<T>}}
* {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class.
* Request<T>
* RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
* RpcDispatcher: use CompletableFuture instead of NotifiyingFuture
was:
API changes to be done in 4.0, which break code:
* MessageDispatcher: remove MessageListener
* Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
* Remove @Deprecated methods, properties or classes
* Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
* Make {{RspFilter}} --> {{RspFilter<T>}}
* {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class.
* Request<T>
* RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
> API changes
> -----------
>
> Key: JGRP-1605
> URL: https://issues.jboss.org/browse/JGRP-1605
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> API changes to be done in 4.0, which break code:
> * MessageDispatcher: remove MessageListener
> * Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
> * Remove @Deprecated methods, properties or classes
> * Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
> * Make {{RspFilter}} --> {{RspFilter<T>}}
> * {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class.
> * Request<T>
> * RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
> * RpcDispatcher: use CompletableFuture instead of NotifiyingFuture
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JGRP-2007) Adapt code to use new Java 8 features
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2007?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2007 at 1/26/16 8:48 AM:
---------------------------------------------------------
Also look at
* -MessageBatch-: DONE
* Table (Visitor)
* Use default methods in interfaces
* Replace NotifyingFuture with CompletableFuture
* -Condition / CondVar- : DONE
was (Author: belaban):
Also look at
* MessageBatch
* Table (Visitor)
* Use default methods in interfaces
* Replace NotifyingFuture with CompletableFuture
* -Condition / CondVar- : DONE
> Adapt code to use new Java 8 features
> -------------------------------------
>
> Key: JGRP-2007
> URL: https://issues.jboss.org/browse/JGRP-2007
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0
>
>
> E.g replace loops for forEach() etc
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
