[JBoss JIRA] (SECURITY-711) LdapExtAdLoginModule proposal for inclusion
by Péter Radics (JIRA)
[ https://issues.jboss.org/browse/SECURITY-711?page=com.atlassian.jira.plug... ]
Péter Radics updated SECURITY-711:
----------------------------------
Attachment: picketbox-r359-LdapExtLoginModule.patch
This patch (picketbox-r359-LdapExtLoginModule.patch) adds the attribute-based role search functionality to LdapExtLoginModule.java instead of creating a new login module (also fixes some @SuppressWarnings)
> LdapExtAdLoginModule proposal for inclusion
> -------------------------------------------
>
> Key: SECURITY-711
> URL: https://issues.jboss.org/browse/SECURITY-711
> Project: PicketBox
> Issue Type: Patch
> Security Level: Public(Everyone can see)
> Components: PicketBox, Security SPI
> Affects Versions: PicketBox_4_0_14.Final
> Environment: jboss7, active directory authentication
> Reporter: Péter Radics
> Assignee: Anil Saldhana
> Priority: Minor
> Labels: LdapExtLoginModule, active-directory, security
> Attachments: picketbox-r359-LdapExtLoginModule.patch, picketbox-r362-LdapExtAdLoginModule.patch, picketbox-r363-LdapExtAdLoginModule-with-history.patch
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> Please consider including the attached LdapExtAdLoginModule into the official release. This login module is based on r362 of LdapExtLoginModule, but it's better suited for deeply nested Active Directory domains: it only uses one search for the userDN then it's resolving the roles recursively by querying attributes on DNs only. (as a side-effect, it doesn't trigger AS7-5737)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
[JBoss JIRA] (AS7-6154) Inconsistent expression support
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/AS7-6154?page=com.atlassian.jira.plugin.s... ]
Stefano Maestri updated AS7-6154:
---------------------------------
Assignee: Brian Stansberry (was: Stefano Maestri)
> Inconsistent expression support
> -------------------------------
>
> Key: AS7-6154
> URL: https://issues.jboss.org/browse/AS7-6154
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: Brian Stansberry
> Fix For: 7.2.0.CR1
>
>
> Although some subsystem declare support for expression on certain attributes, they actually don't support it.
> As en example see datasources > pool > max-pool-size.
> The DMR description says it supports expressions on this attribute:
> {noformat}
> "max-pool-size" => {
> "type" => INT,
> "description" => "The max-pool-size element specifies the maximum number of connections for a pool. No more connections will be created in each sub-pool",
> "expressions-allowed" => true,
> "nillable" => true,
> "default" => 20,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> },
> {noformat}
> But then writing an expression value yields an exception
> {noformat}
> Request
> [ERROR] {
> [ERROR] "operation" => "composite",
> [ERROR] "address" => [],
> [ERROR] "steps" => [{
> [ERROR] "address" => [
> [ERROR] ("profile" => "full"),
> [ERROR] ("subsystem" => "datasources"),
> [ERROR] ("data-source" => "ExampleDS")
> [ERROR] ],
> [ERROR] "operation" => "write-attribute",
> [ERROR] "name" => "max-pool-size",
> [ERROR] "value" => expression "${pool:15}"
> [ERROR] }]
> [ERROR] }
> {noformat}
> {noformat}
> 08:48:23,965 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 5) JBAS014616: Operation ("write-attribute") failed - address: ([
> ("subsystem" => "datasources"),
> ("data-source" => "ExampleDS")
> ]) - failure description: "JBAS014688: Wrong type for value. Expected [INT] but was EXPRESSION"
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
[JBoss JIRA] (AS7-6154) Inconsistent expression support
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/AS7-6154?page=com.atlassian.jira.plugin.s... ]
Stefano Maestri commented on AS7-6154:
--------------------------------------
PR resolve pool parameter problem. Reassigning to Brian for general issue
> Inconsistent expression support
> -------------------------------
>
> Key: AS7-6154
> URL: https://issues.jboss.org/browse/AS7-6154
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: Stefano Maestri
> Fix For: 7.2.0.CR1
>
>
> Although some subsystem declare support for expression on certain attributes, they actually don't support it.
> As en example see datasources > pool > max-pool-size.
> The DMR description says it supports expressions on this attribute:
> {noformat}
> "max-pool-size" => {
> "type" => INT,
> "description" => "The max-pool-size element specifies the maximum number of connections for a pool. No more connections will be created in each sub-pool",
> "expressions-allowed" => true,
> "nillable" => true,
> "default" => 20,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> },
> {noformat}
> But then writing an expression value yields an exception
> {noformat}
> Request
> [ERROR] {
> [ERROR] "operation" => "composite",
> [ERROR] "address" => [],
> [ERROR] "steps" => [{
> [ERROR] "address" => [
> [ERROR] ("profile" => "full"),
> [ERROR] ("subsystem" => "datasources"),
> [ERROR] ("data-source" => "ExampleDS")
> [ERROR] ],
> [ERROR] "operation" => "write-attribute",
> [ERROR] "name" => "max-pool-size",
> [ERROR] "value" => expression "${pool:15}"
> [ERROR] }]
> [ERROR] }
> {noformat}
> {noformat}
> 08:48:23,965 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 5) JBAS014616: Operation ("write-attribute") failed - address: ([
> ("subsystem" => "datasources"),
> ("data-source" => "ExampleDS")
> ]) - failure description: "JBAS014688: Wrong type for value. Expected [INT] but was EXPRESSION"
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
[JBoss JIRA] (AS7-5737) LdapExtLoginModule fails with follow referral
by Tom Fonteyne (JIRA)
[ https://issues.jboss.org/browse/AS7-5737?page=com.atlassian.jira.plugin.s... ]
Tom Fonteyne commented on AS7-5737:
-----------------------------------
> does too many searches, the users have to manually control the max recursion depth and even with a smallish recursion depth it gets very slow
I actually hit this, and fixed it. I need to log a JIRA for it and then check my code in. It got delayed due to the upcoming holiday season.
I also got feedback to try something out concerning this JIRA.
More later.
> LdapExtLoginModule fails with follow referral
> ---------------------------------------------
>
> Key: AS7-5737
> URL: https://issues.jboss.org/browse/AS7-5737
> Project: Application Server 7
> Issue Type: Bug
> Components: Security
> Affects Versions: 7.1.1.Final, 7.1.2.Final (EAP), 7.1.3.Final (EAP)
> Environment: Probably not relevant, but Win 7 64, tried on jdk 6 and 7 64-bit.
> Reporter: Alexander Torstling
> Assignee: Stefan Guilhen
> Labels: activedirectory, authentication, authorization, ldap, objectfactory, references
>
> We connect to AD with LdapExtLoginModule. It so happens that AD keeps references to some external trees (such as "DomainDnsZones" and "ForestDnsZones") in the root of the LDAP tree. So when you configure LdapExtLoginModule to search any root, it will hit these referrals.
> This normally fails with a standard
> {code}
> javax.security.auth.login.FailedLoginException: Password Incorrect/Password Required
> {code}
> . This is not the whole story, though. If you enable the module option
> {code}<module-option name="throwValidateError" value="true"/>{code}
> , you get a more complete stack trace:
> {code}
> 09:18:14,724 ERROR [org.jboss.security.authentication.JBossCachedAuthenticationManager] (http--127.0.0.1-8080-2) Login failure: javax.security.auth.login.FailedLoginException: Password Incorrect/Password Required
> at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:270) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0]
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0]
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784) [rt.jar:1.7.0]
> at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0]
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) [rt.jar:1.7.0]
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) [rt.jar:1.7.0]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0]
> at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) [rt.jar:1.7.0]
> at javax.security.auth.login.LoginContext.login(LoginContext.java:594) [rt.jar:1.7.0]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
> at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:214) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:381) [jbossweb-7.0.13.Final.jar:]
> at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
> at com.company.product.web.fix.ContextClassLoaderValve.invoke(ContextClassLoaderValve.java:19) [classes:]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.13.Final.jar:]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.13.Final.jar:]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0]
> Caused by: javax.naming.PartialResultException [Root exception is javax.naming.NotContextException: Cannot create context for: ldap://DomainDnsZones.global.scd.company.com/DC=DomainDnsZones,DC=global,...; remaining name 'dc=global,dc=scd,dc=company,dc=com']
> at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:242) [rt.jar:1.7.0]
> at com.sun.jndi.ldap.LdapNamingEnumeration.hasMore(LdapNamingEnumeration.java:189) [rt.jar:1.7.0]
> at org.jboss.security.auth.spi.LdapExtLoginModule.rolesSearch(LdapExtLoginModule.java:534) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> at org.jboss.security.auth.spi.LdapExtLoginModule.createLdapInitContext(LdapExtLoginModule.java:445) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:312) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:267) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> ... 29 more
> Caused by: javax.naming.NotContextException: Cannot create context for: ldap://DomainDnsZones.global.scd.company.com/DC=DomainDnsZones,DC=global,...; remaining name 'dc=global,dc=scd,dc=company,dc=com'
> at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:141) [rt.jar:1.7.0]
> at com.sun.jndi.ldap.LdapReferralException.getReferralContext(LdapReferralException.java:150) [rt.jar:1.7.0]
> at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreReferrals(LdapNamingEnumeration.java:357) [rt.jar:1.7.0]
> at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:226) [rt.jar:1.7.0]
> ... 34 more
> {code}
> When debugging this error, I concluded that the culprit is that ObjectFactoryBuilder doesn't resolve the reference correctly. getObjectInstance returns the reference instead of resolving it at the following location:
> {code}
> at org.jboss.as.naming.context.ObjectFactoryBuilder.getObjectInstance(ObjectFactoryBuilder.java:87)
> at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:300)
> at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:111)
> at com.sun.jndi.ldap.LdapReferralException.getReferralContext(LdapReferralException.java:150)
> at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreReferrals(LdapNamingEnumeration.java:357)
> at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:226)
> at com.sun.jndi.ldap.LdapNamingEnumeration.hasMore(LdapNamingEnumeration.java:189)
> at org.jboss.security.auth.spi.LdapExtLoginModule.rolesSearch(LdapExtLoginModule.java:534)
> at org.jboss.security.auth.spi.LdapExtLoginModule.createLdapInitContext(LdapExtLoginModule.java:445)
> at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:312)
> at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:267)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784)
> at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696)
> at java.security.AccessController.doPrivileged(AccessController.java:-1)
> at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:594)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160)
> at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:214)
> at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280)
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:381)
> at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
> at com.company.product.web.fix.ContextClassLoaderValve.invoke(ContextClassLoaderValve.java:19)
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671)
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930)
> at java.lang.Thread.run(Thread.java:722)
> {code}
> The relevant bit of code is:
> {code}
> public Object getObjectInstance(final Object ref, final Name name, final Context nameCtx, final Hashtable<?, ?> environment) throws Exception {
> final ClassLoader classLoader = SecurityActions.getContextClassLoader();
> if(classLoader == null) {
> return ref;
> }
> {code}
> So this bit of code doesn't resolve the ref it the context classloader is null. Instead of aborting, it returns the ref unresolved. LdapReferralContext gets very confused when NamingManager doesn't resolve the reference, and throws the aforementioned NotContextException.
> When debugging where the context classloader is set to null I found the following location:
> {code}
> http--127.0.0.1-8080-2@12911 daemon, prio=5, in group 'main', status: 'RUNNING'
> at java.lang.Thread.setContextClassLoader(Thread.java:1480)
> at org.jboss.security.auth.spi.SecurityActions$2.run(SecurityActions.java:59)
> at org.jboss.security.auth.spi.SecurityActions$2.run(SecurityActions.java:56)
> at java.security.AccessController.doPrivileged(AccessController.java:-1)
> at org.jboss.security.auth.spi.SecurityActions.setContextClassLoader(SecurityActions.java:55)
> at org.jboss.security.auth.spi.LdapExtLoginModule.createLdapInitContext(LdapExtLoginModule.java:435)
> at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:312)
> at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:267)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784)
> at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696)
> at java.security.AccessController.doPrivileged(AccessController.java:-1)
> at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:594)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160)
> at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:214)
> at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280)
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:381)
> at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
> at com.company.product.web.fix.ContextClassLoaderValve.invoke(ContextClassLoaderValve.java:19)
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671)
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930)
> at java.lang.Thread.run(Thread.java:722)
> {code}
> Unfortunately I haven't been able to find the source code for this location. But it is clear that LdapExtLoginModule does set the context classloader to null in validatePassword. I haven't come up with any way of avoiding this.
> While trying to circumvent this bug I tried to avoid following the AD referral. This doesn't seem to be possible, though. When setting "java.naming.referral" to "ignore", you would expect that the login would succeed. But as documented at http://docs.oracle.com/javase/jndi/tutorial/ldap/referral/jndi.html , some LDAP implementations might still throw a PartialResultException. This is indeed what I get:
> {code}
> Caused by: javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name 'dc=global,dc=scd,dc=company,dc=com'
> {code}
> Spring points this out at http://static.springsource.org/spring-ldap/site/apidocs/org/springframewo... and has a way of supressing these exceptions: "ignorePartialResultException".
> With JBoss lacking this, I am stuck between a rock and a hard place. I cannot enable referrals due to the null context class loader bug, and I cannot disable them due to the PartialResultException bug.
> So I would call this one a blocker. Any suggestions are greatly appreciated, as we are stuck upgrading to AS 7. This is a regression, by the way, since "follow" used to work on AS 5.1.0.GA which we are upgrading from.
> The only way of avoiding this problem that I've found is to narrow the tree which you search through in AD in such a way that you avoid hitting the referrals at all. There are a couple of related bugs and forum posts (see for instance https://issues.jboss.org/browse/AS7-2085), but I don't think any of them really nailed the problem down. It's pretty tricky since you don't even get a relevant stacktrace unless you enable "throwValidateError".
> Thanks
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
[JBoss JIRA] (AS7-6169) CLI does not work on windows
by Ståle Pedersen (JIRA)
[ https://issues.jboss.org/browse/AS7-6169?page=com.atlassian.jira.plugin.s... ]
Ståle Pedersen commented on AS7-6169:
-------------------------------------
this is fixed in æsh-0.27 and should be fixed in this pull request; https://github.com/jbossas/jboss-as/pull/3667
> CLI does not work on windows
> ----------------------------
>
> Key: AS7-6169
> URL: https://issues.jboss.org/browse/AS7-6169
> Project: Application Server 7
> Issue Type: Bug
> Components: CLI
> Affects Versions: 7.2.0.Alpha1
> Environment: Windows 7, Windows 8, Windows Server 2008r2
> Reporter: Tomaz Cerar
> Assignee: Alexey Loubyansky
> Priority: Blocker
> Labels: cli, windows
> Fix For: 7.2.0.Alpha1
>
>
> Typing in CLI crashes with error below after any character is entered
> {noformat}
> [standalone@localhost:9999 /] ajava.lang.ArithmeticException: / by zero
> at org.jboss.aesh.console.Console.writeChar(Console.java:752)
> at org.jboss.aesh.console.Console.writeChars(Console.java:735)
> at org.jboss.aesh.console.Console.parseOperation(Console.java:432)
> at org.jboss.aesh.console.Console.read(Console.java:377)
> at org.jboss.aesh.console.Console.read(Console.java:331)
> at org.jboss.as.cli.impl.Console$Factory$1.readLine(Console.java:171)
> at org.jboss.as.cli.impl.CommandContextImpl.interact(CommandContextImpl.java:1167)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:259)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.modules.Module.run(Module.java:270)
> at org.jboss.modules.Main.main(Main.java:294)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
[JBoss JIRA] (AS7-5737) LdapExtLoginModule fails with follow referral
by Péter Radics (JIRA)
[ https://issues.jboss.org/browse/AS7-5737?page=com.atlassian.jira.plugin.s... ]
Péter Radics commented on AS7-5737:
-----------------------------------
Well, the current LdapExtLoginModule does too many searches, the users have to manually control the max recursion depth and even with a smallish recursion depth it gets very slow (due to the many role searches).
What would probably work is to use my attribute-based version in the LdapExtLoginModule in case the roleAttributeIsDN property is true (in this case the rolesCtxDN and roleFilter parameters would be ignored).
I'm willing to create such a patch agains LdapExtLoginModule if the above idea is acceptable.
> LdapExtLoginModule fails with follow referral
> ---------------------------------------------
>
> Key: AS7-5737
> URL: https://issues.jboss.org/browse/AS7-5737
> Project: Application Server 7
> Issue Type: Bug
> Components: Security
> Affects Versions: 7.1.1.Final, 7.1.2.Final (EAP), 7.1.3.Final (EAP)
> Environment: Probably not relevant, but Win 7 64, tried on jdk 6 and 7 64-bit.
> Reporter: Alexander Torstling
> Assignee: Stefan Guilhen
> Labels: activedirectory, authentication, authorization, ldap, objectfactory, references
>
> We connect to AD with LdapExtLoginModule. It so happens that AD keeps references to some external trees (such as "DomainDnsZones" and "ForestDnsZones") in the root of the LDAP tree. So when you configure LdapExtLoginModule to search any root, it will hit these referrals.
> This normally fails with a standard
> {code}
> javax.security.auth.login.FailedLoginException: Password Incorrect/Password Required
> {code}
> . This is not the whole story, though. If you enable the module option
> {code}<module-option name="throwValidateError" value="true"/>{code}
> , you get a more complete stack trace:
> {code}
> 09:18:14,724 ERROR [org.jboss.security.authentication.JBossCachedAuthenticationManager] (http--127.0.0.1-8080-2) Login failure: javax.security.auth.login.FailedLoginException: Password Incorrect/Password Required
> at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:270) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0]
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0]
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784) [rt.jar:1.7.0]
> at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0]
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) [rt.jar:1.7.0]
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) [rt.jar:1.7.0]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0]
> at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) [rt.jar:1.7.0]
> at javax.security.auth.login.LoginContext.login(LoginContext.java:594) [rt.jar:1.7.0]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
> at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:214) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:381) [jbossweb-7.0.13.Final.jar:]
> at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
> at com.company.product.web.fix.ContextClassLoaderValve.invoke(ContextClassLoaderValve.java:19) [classes:]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.13.Final.jar:]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.13.Final.jar:]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0]
> Caused by: javax.naming.PartialResultException [Root exception is javax.naming.NotContextException: Cannot create context for: ldap://DomainDnsZones.global.scd.company.com/DC=DomainDnsZones,DC=global,...; remaining name 'dc=global,dc=scd,dc=company,dc=com']
> at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:242) [rt.jar:1.7.0]
> at com.sun.jndi.ldap.LdapNamingEnumeration.hasMore(LdapNamingEnumeration.java:189) [rt.jar:1.7.0]
> at org.jboss.security.auth.spi.LdapExtLoginModule.rolesSearch(LdapExtLoginModule.java:534) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> at org.jboss.security.auth.spi.LdapExtLoginModule.createLdapInitContext(LdapExtLoginModule.java:445) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:312) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:267) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> ... 29 more
> Caused by: javax.naming.NotContextException: Cannot create context for: ldap://DomainDnsZones.global.scd.company.com/DC=DomainDnsZones,DC=global,...; remaining name 'dc=global,dc=scd,dc=company,dc=com'
> at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:141) [rt.jar:1.7.0]
> at com.sun.jndi.ldap.LdapReferralException.getReferralContext(LdapReferralException.java:150) [rt.jar:1.7.0]
> at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreReferrals(LdapNamingEnumeration.java:357) [rt.jar:1.7.0]
> at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:226) [rt.jar:1.7.0]
> ... 34 more
> {code}
> When debugging this error, I concluded that the culprit is that ObjectFactoryBuilder doesn't resolve the reference correctly. getObjectInstance returns the reference instead of resolving it at the following location:
> {code}
> at org.jboss.as.naming.context.ObjectFactoryBuilder.getObjectInstance(ObjectFactoryBuilder.java:87)
> at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:300)
> at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:111)
> at com.sun.jndi.ldap.LdapReferralException.getReferralContext(LdapReferralException.java:150)
> at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreReferrals(LdapNamingEnumeration.java:357)
> at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:226)
> at com.sun.jndi.ldap.LdapNamingEnumeration.hasMore(LdapNamingEnumeration.java:189)
> at org.jboss.security.auth.spi.LdapExtLoginModule.rolesSearch(LdapExtLoginModule.java:534)
> at org.jboss.security.auth.spi.LdapExtLoginModule.createLdapInitContext(LdapExtLoginModule.java:445)
> at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:312)
> at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:267)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784)
> at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696)
> at java.security.AccessController.doPrivileged(AccessController.java:-1)
> at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:594)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160)
> at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:214)
> at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280)
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:381)
> at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
> at com.company.product.web.fix.ContextClassLoaderValve.invoke(ContextClassLoaderValve.java:19)
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671)
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930)
> at java.lang.Thread.run(Thread.java:722)
> {code}
> The relevant bit of code is:
> {code}
> public Object getObjectInstance(final Object ref, final Name name, final Context nameCtx, final Hashtable<?, ?> environment) throws Exception {
> final ClassLoader classLoader = SecurityActions.getContextClassLoader();
> if(classLoader == null) {
> return ref;
> }
> {code}
> So this bit of code doesn't resolve the ref it the context classloader is null. Instead of aborting, it returns the ref unresolved. LdapReferralContext gets very confused when NamingManager doesn't resolve the reference, and throws the aforementioned NotContextException.
> When debugging where the context classloader is set to null I found the following location:
> {code}
> http--127.0.0.1-8080-2@12911 daemon, prio=5, in group 'main', status: 'RUNNING'
> at java.lang.Thread.setContextClassLoader(Thread.java:1480)
> at org.jboss.security.auth.spi.SecurityActions$2.run(SecurityActions.java:59)
> at org.jboss.security.auth.spi.SecurityActions$2.run(SecurityActions.java:56)
> at java.security.AccessController.doPrivileged(AccessController.java:-1)
> at org.jboss.security.auth.spi.SecurityActions.setContextClassLoader(SecurityActions.java:55)
> at org.jboss.security.auth.spi.LdapExtLoginModule.createLdapInitContext(LdapExtLoginModule.java:435)
> at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:312)
> at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:267)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784)
> at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696)
> at java.security.AccessController.doPrivileged(AccessController.java:-1)
> at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:594)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160)
> at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:214)
> at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280)
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:381)
> at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
> at com.company.product.web.fix.ContextClassLoaderValve.invoke(ContextClassLoaderValve.java:19)
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671)
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930)
> at java.lang.Thread.run(Thread.java:722)
> {code}
> Unfortunately I haven't been able to find the source code for this location. But it is clear that LdapExtLoginModule does set the context classloader to null in validatePassword. I haven't come up with any way of avoiding this.
> While trying to circumvent this bug I tried to avoid following the AD referral. This doesn't seem to be possible, though. When setting "java.naming.referral" to "ignore", you would expect that the login would succeed. But as documented at http://docs.oracle.com/javase/jndi/tutorial/ldap/referral/jndi.html , some LDAP implementations might still throw a PartialResultException. This is indeed what I get:
> {code}
> Caused by: javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name 'dc=global,dc=scd,dc=company,dc=com'
> {code}
> Spring points this out at http://static.springsource.org/spring-ldap/site/apidocs/org/springframewo... and has a way of supressing these exceptions: "ignorePartialResultException".
> With JBoss lacking this, I am stuck between a rock and a hard place. I cannot enable referrals due to the null context class loader bug, and I cannot disable them due to the PartialResultException bug.
> So I would call this one a blocker. Any suggestions are greatly appreciated, as we are stuck upgrading to AS 7. This is a regression, by the way, since "follow" used to work on AS 5.1.0.GA which we are upgrading from.
> The only way of avoiding this problem that I've found is to narrow the tree which you search through in AD in such a way that you avoid hitting the referrals at all. There are a couple of related bugs and forum posts (see for instance https://issues.jboss.org/browse/AS7-2085), but I don't think any of them really nailed the problem down. It's pretty tricky since you don't even get a relevant stacktrace unless you enable "throwValidateError".
> Thanks
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
[JBoss JIRA] (JASSIST-162) Correction introduced in JASSIST-127 raises AbstractMethodError on call site
by Donnchadh Ó Donnabháin (JIRA)
[ https://issues.jboss.org/browse/JASSIST-162?page=com.atlassian.jira.plugi... ]
Donnchadh Ó Donnabháin commented on JASSIST-162:
------------------------------------------------
Any thoughts on this patch? What can be done to get this into 3.18.0 ?
I've just run into issues with Hibernate 4.1.9 and javassist 3.17.1 . The problem arises when a bridge getter method is overridden in the proxy class rather than the desired non-bridge method. I haven't racked down the exact cause of the problem but full support for bridge methods would seem to be important. The problem only occurs for javassist versions after 3.15.0 and doesn't seem to have been directly introduced by the update of the hibernate version we use.
> Correction introduced in JASSIST-127 raises AbstractMethodError on call site
> ----------------------------------------------------------------------------
>
> Key: JASSIST-162
> URL: https://issues.jboss.org/browse/JASSIST-162
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.16.1-GA
> Environment: OSX, JDK 1.6.0_29
> Reporter: Brice Dutheil
> Assignee: Shigeru Chiba
> Attachments: JASSIST-162___correct_patch_for_bridge_methods_and_covariant_return_types.patch
>
>
> The proposed solution in JASSIST-127 doesn't work, the JVM raises an {{AbstractMethodError}} on the call site.
> What happen is that in {{getMethods}} the code now discard method with same name / same arguments as the return type is not taken into account when generating the key.
> Reverting this patch will raises a {{DuplicateMemberException}}, the reason is that {{ClassFile.isDuplicated}} don't see either of the possible duplicate method as bridge.
> I've created a patch that detect methods with covariant type and mark forwarding methods as bridge if relevant.
> Note that the effect is only for method calls that have the very same arguments, as Javassist don't see duplicate methods if the arguments differ, e.g. proxying ({{StringList extends List<String>}}) will see {{add(Object)}} and {{add(String)}}, though the first one is not marked as bridge in the generated bytecode.
> Also, I'm not sure of that one, but the patch also adds a boolean to enable the {{MethodHandler}} to intercept bridge methods.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months