[JBoss JIRA] (AS7-6821) Installed library not available to an EAR deployment
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/AS7-6821?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas resolved AS7-6821.
---------------------------------
Resolution: Done
> Installed library not available to an EAR deployment
> ----------------------------------------------------
>
> Key: AS7-6821
> URL: https://issues.jboss.org/browse/AS7-6821
> Project: Application Server 7
> Issue Type: Bug
> Components: EE
> Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final)
> Reporter: Jozef Hartinger
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Alpha1
>
>
> {quote}The referenced libraries must be made available to all components contained within the referencing file, including any components contained within other JAR format files within the referencing file. For example, if a .ear file references an installed library, the library must be made available to all components in all .war files, EJB .jar files, application .jar files, and resource adapter .rar files within the .ear file.{quote}
> A referenced installed library seems to only be made available to some (not all) components in an EAR.
--
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, 3 months
[JBoss JIRA] (AS7-6450) Missing <recovery> element. XA recovery disabled for: java:/JmsXA
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6450?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration updated AS7-6450:
-----------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=907901, https://bugzilla.redhat.com/show_bug.cgi?id=953298 (was: https://bugzilla.redhat.com/show_bug.cgi?id=907901)
> Missing <recovery> element. XA recovery disabled for: java:/JmsXA
> -----------------------------------------------------------------
>
> Key: AS7-6450
> URL: https://issues.jboss.org/browse/AS7-6450
> Project: Application Server 7
> Issue Type: Bug
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> With latest version of HornetQ and IronJacamar, when AS7 is started with the standalone-full.xml, it logs a WARN message:
> {noformat}
> 11:23:11,152 INFO [org.hornetq.core.server] (MSC service thread 1-5) HQ221001: live server is starting with configuration HornetQ Configuration (clustered=false,backup=false,sharedStore=true,journalDirectory=/Users/jmesnil/Developer/jboss-as/build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/standalone/data/messagingjournal,bindingsDirectory=/Users/jmesnil/Developer/jboss-as/build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/standalone/data/messagingbindings,largeMessagesDirectory=/Users/jmesnil/Developer/jboss-as/build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/standalone/data/messaginglargemessages,pagingDirectory=/Users/jmesnil/Developer/jboss-as/build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/standalone/data/messagingpaging)
> 11:23:11,154 INFO [org.hornetq.core.server] (MSC service thread 1-5) HQ221008: Waiting to obtain live lock
> 11:23:11,175 INFO [org.hornetq.core.server] (MSC service thread 1-5) HQ221017: Using NIO Journal
> 11:23:11,235 INFO [org.hornetq.core.server] (MSC service thread 1-5) HQ221039: Waiting to obtain live lock
> 11:23:11,235 INFO [org.hornetq.core.server] (MSC service thread 1-5) HQ221040: Live Server Obtained live lock
> 11:23:11,489 INFO [org.hornetq.core.server] (MSC service thread 1-5) HQ221024: Started Netty Acceptor version 3.6.2.Final-c0d783c 127.0.0.1:5455 for CORE protocol
> 11:23:11,490 INFO [org.hornetq.core.server] (MSC service thread 1-5) HQ221024: Started Netty Acceptor version 3.6.2.Final-c0d783c 127.0.0.1:5445 for CORE protocol
> 11:23:11,492 INFO [org.hornetq.core.server] (MSC service thread 1-5) HQ221009: Server is now live
> 11:23:11,492 INFO [org.hornetq.core.server] (MSC service thread 1-5) HQ221003: HornetQ Server version 2.3.0.CR1 (buzzzzz!, 122) [0ac0dcd4-6f7e-11e2-9c21-f566250843f7]
> 11:23:11,507 INFO [org.jboss.as.messaging] (ServerService Thread Pool -- 60) JBAS011601: Bound messaging object to jndi name java:/ConnectionFactory
> 11:23:11,508 INFO [org.jboss.as.messaging] (ServerService Thread Pool -- 61) JBAS011601: Bound messaging object to jndi name java:jboss/exported/jms/RemoteConnectionFactory
> 11:23:11,543 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-10) JBAS010406: Registered connection factory java:/JmsXA
> 11:23:11,545 WARN [org.jboss.as.connector.services.resourceadapters.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-10) IJ020016: Missing <recovery> element. XA recovery disabled for: java:/JmsXA
> 11:23:11,568 INFO [org.hornetq.ra] (MSC service thread 1-10) HornetQ resource adaptor started
> 11:23:11,569 INFO [org.jboss.as.connector.services.resourceadapters.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-10) IJ020002: Deployed: file://RaActivatorhornetq-ra
> 11:23:11,570 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-3) JBAS010401: Bound JCA ConnectionFactory [java:/JmsXA]
> {noformat}
> This WARN was not present in AS7 7.1.2.Final
--
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, 3 months
[JBoss JIRA] (AS7-6935) Deploying dynamic VDB with invalid XML will cause incomprehensible error
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6935?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on AS7-6935:
---------------------------------------
The scanner tries to guard against deploying partially copied files by doing a trivial parse to confirm well-formed xml [1]. It's unlikely there would be any Teiid related logs, as the deployment scanner doesn't even try to execute a management operation to deploy the file if it doesn't pass this check.
If you enable DEBUG logging of log category org.jboss.as.server.deployment.scanner you may get some more details.
[1] https://github.com/jbossas/jboss-as/blob/master/deployment-scanner/src/ma...
> Deploying dynamic VDB with invalid XML will cause incomprehensible error
> ------------------------------------------------------------------------
>
> Key: AS7-6935
> URL: https://issues.jboss.org/browse/AS7-6935
> Project: Application Server 7
> Issue Type: Bug
> Affects Versions: 7.1.1.Final
> Reporter: Filip Nguyen
> Priority: Trivial
> Attachments: loop-vdb.xml
>
>
> Deploying VDB with invalid XML (closed translator tag). Causes following error:
> [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015009: Scan found incompletely copied file content for deployment standalone/deployments/loop-vdb.xml. Deployment changes will not be processed until all content is complete.
--
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, 3 months
[JBoss JIRA] (AS7-6840) Backup can't start after fallback and another failover
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6840?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6840:
----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 948247|https://bugzilla.redhat.com/show_bug.cgi?id=948247] from MODIFIED to ON_QA
> Backup can't start after fallback and another failover
> ------------------------------------------------------
>
> Key: AS7-6840
> URL: https://issues.jboss.org/browse/AS7-6840
> Project: Application Server 7
> Issue Type: Bug
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Critical
> Fix For: 8.0.0.Alpha1
>
>
> 1. start AS7 + HornetQ configured as backup + allow-tailback
> 2. start AS7 + HornetQ configured as live
> 3. Shutdown AS7 + HornetQ live
> => AS7 + HornetQ backup becomes active
> 4. Restart AS7 + HornetQ live
> => AS7 + HornetQ backup fails back
> => AS7 + HornetQ live becomes active
> 3. Shutdown AS7 + HornetQ live again
> => AS7 + HornetQ backup does not failover properly:
> {noformat}
> 18:15:03,296 ERROR [org.hornetq.core.server] (HQ119000: Activation for server
> HornetQServerImpl::serverUUID=7c2c4c70-9c79-11e2-abd5-538a3c182844) HQ224000: Failure in initialisation: java.lang.IllegalStateEx
> ception: ServiceBuilder is already installed
> at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:302)
> at org.jboss.as.messaging.jms.JMSService$1.activated(JMSService.java:89) [jboss-as-messaging-7.2.0.Final-redhat-4.jar:7.2.0.Final-redhat-4]
> at org.hornetq.core.server.impl.HornetQServerImpl.callActivateCallbacks(HornetQServerImpl.java:1358) [hornetq-server-2.3.0.CR2-redhat-1.jar:2.3.0.CR2-redhat-1]
> at org.hornetq.core.server.impl.HornetQServerImpl.initialisePart2(HornetQServerImpl.java:1581) [hornetq-server-2.3.0.CR2-redhat-1.jar:2.3.0.CR2-redhat-1]
> at org.hornetq.core.server.impl.HornetQServerImpl.access$1300(HornetQServerImpl.java:169) [hornetq-server-2.3.0.CR2-redhat-1.jar:2.3.0.CR2-redhat-1]
> at org.hornetq.core.server.impl.HornetQServerImpl$SharedStoreBackupActivation.run(HornetQServerImpl.java:2117) [hornetq-server-2.3.0.CR2-redhat-1.jar:2.3.0.CR2-redhat-1]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15]
> {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, 3 months
[JBoss JIRA] (AS7-5737) LdapExtLoginModule fails with follow referral
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-5737?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-5737:
----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 901138|https://bugzilla.redhat.com/show_bug.cgi?id=901138] from MODIFIED to ON_QA
> 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: Peter Skopek
> Labels: activedirectory, authentication, authorization, ldap, objectfactory, references
> Attachments: ldap-referral-test.zip, secured-webapp.war
>
>
> 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, 3 months
[JBoss JIRA] (AS7-6727) Modular build not in sync with modules directory structure
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6727?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6727:
----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 947145|https://bugzilla.redhat.com/show_bug.cgi?id=947145] from MODIFIED to ON_QA
> Modular build not in sync with modules directory structure
> ----------------------------------------------------------
>
> Key: AS7-6727
> URL: https://issues.jboss.org/browse/AS7-6727
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Labels: Karaf
>
> {code}
> [echo] Static modules: [org.jboss.as.standalone,org.jboss.as.domain-http-error-context,,, org.jboss.logging, org.jboss.vfs, org.slf4j, org.jboss.logging.jul-to-slf4j-stub]
> [java] Exception in thread "main" java.io.FileNotFoundException: /Users/tdiesler/git/jboss-as/build-modular/../build/src/main/resources/modules/org/jboss/as/logging/main/module.xml (No such file or directory)
> [java] at java.io.FileInputStream.open(Native Method)
> [java] at java.io.FileInputStream.<init>(FileInputStream.java:138)
> [java] at org.jboss.as.config.assembly.ModuleParser.parse(ModuleParser.java:61)
> [java] at org.jboss.as.config.assembly.GenerateModulesDefinition.processModuleDependency(GenerateModulesDefinition.java:193)
> [java] at org.jboss.as.config.assembly.GenerateModulesDefinition.process(GenerateModulesDefinition.java:130)
> [java] at org.jboss.as.config.assembly.GenerateModulesDefinition.main(GenerateModulesDefinition.java:104)
> [java] Java Result: 1
> {code}
--
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, 3 months
[JBoss JIRA] (AS7-6779) AS7.1 jars run against as7.2/eap6.1 cause test case (eclipse) to hang
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6779?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6779:
----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 927318|https://bugzilla.redhat.com/show_bug.cgi?id=927318] from MODIFIED to ON_QA
> AS7.1 jars run against as7.2/eap6.1 cause test case (eclipse) to hang
> ---------------------------------------------------------------------
>
> Key: AS7-6779
> URL: https://issues.jboss.org/browse/AS7-6779
> Project: Application Server 7
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Rob Stryker
> Assignee: Emanuel Muckenhuber
> Priority: Blocker
> Fix For: 8.0.0.Alpha1
>
> Attachments: AS7-6779.out2.txt, AS7-6779.stack.txt, out.zip
>
>
> Somewhere along the line recently, EAP6.1 / AS 7.2 has a regression in remoting or xnio somehow, and this is causing blocking problems for tools.
> Recall:
> 1) JBossTools bundles a set of jars capable of communicating with a running application server
> 2) This single set of jars must be capable of communicating with all servers in the 7.x stream
> 3) Bundling a second set of jars is not easily accomplished, but could be possible
> And:
> 4) Using the as7.1.0 jars against eap6.1 in a specific unit test causes eclipse to hang
> The basic code of our test case (once we get rid of the jbt stuff wrapped around it) is basically as follows:
> {code}
> this.client = ModelControllerClient.Factory.create(details.getHost(), details.getManagementPort(),
> getCallbackHandler());
> this.manager = ServerDeploymentManager.Factory.create(client);
> DeploymentPlanBuilder builder = manager.newDeploymentPlan().replace(name, file);
> try {
> DeploymentAction action = builder.getLastAction();
> Future<ServerDeploymentPlanResult> planResult = manager.execute(builder.build());
> // FREEZE HERE
> // This is "DeploymentOperationResult.getStatus() in the stack trace
> ServerDeploymentActionResult actionResult = planResult.get().getDeploymentActionResult(action.getId());
> IStatus status = createStatus(action.getDeploymentUnitUniqueName(), action.getType().name(), actionResult);
> } catch (Exception e) {
> throw new JBoss7ManangerException(e);
> }
> {code}
> The actual stack trace is:
> {code}
> Thread [main] (Suspended)
> owns: RunnableLock (id=461)
> waiting for: ActiveOperationSupport$ActiveOperationImpl<T,A> (id=462)
> Object.wait(long) line: not available [native method]
> ActiveOperationSupport$ActiveOperationImpl<T,A>(Object).wait() line: 503
> ActiveOperationSupport$ActiveOperationImpl<T,A>(AsyncFutureTask<T>).await() line: 192
> ActiveOperationSupport$ActiveOperationImpl<T,A>(AsyncFutureTask<T>).get() line: 266
> AbstractModelControllerClient$DelegatingCancellableAsyncFuture.get() line: 363
> AbstractModelControllerClient$DelegatingCancellableAsyncFuture.get() line: 317
> ServerDeploymentPlanResultFuture.get() line: 76
> ServerDeploymentPlanResultFuture.get() line: 42
> DeploymentOperationResult.getStatus() line: 52
> AS7ManagerTestUtils.waitUntilFinished(IJBoss7DeploymentResult) line: 93
> AS7ManagerIntegrationTest.canReplaceWar() line: 129
> {code}
> The list of jars we are using to communicate with the server are:
> {code}
> jboss-as-controller-client-7.1.0.Final.jar
> jboss-as-protocol-7.1.0.Final.jar
> jboss-dmr-1.1.1.Final.jar
> jboss-logging-3.1.0.GA.jar
> jboss-marshalling-1.3.9.GA.jar
> jboss-remoting-3.2.7.GA.jar
> jboss-sasl-1.0.0.Final.jar
> jboss-threads-2.0.0.GA.jar
> xnio-api-3.0.3.GA.jar
> xnio-nio-3.0.3.GA.jar
> {code}
> It was suggested in irc by ctomc that we simply replace the following jars with new jars from jboss-as 7.2 / eap6.1:
> {code}
> jboss-remoting-3.2.7.GA.jar -> 3.2.15.GA
> xnio-api-3.0.3.GA.jar -> 3.0.7
> xnio-nio-3.0.3.GA.jar -> 3.0.7
> {code}
> This approach also failed, with the following stack trace:
> {code}
> java.lang.NoClassDefFoundError: org/xnio/Cancellable
> (sic)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.<init>(RemotingModelControllerClient.java:59)
> at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:211)
> at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:173)
> {code}
> So it is obvious that jboss-as-controller jar from as-7.1 requires classes that are no longer present in xnio. If this is the case, it would indicate that xnio has REMOVED classes from its jar during an incremental version from 3.0.3 to 3.0.7, which would constitute an API breakage.
> So clearly for us, updating only remoting and xnio does not work. The next possible solution would be to update ALL jars, however, this led to a similar situation when using AS7.2 / Eap 6.1 jars to communicate with an AS 7.0.0 server. Again, similar to what was mentioned above, all tests passed EXCEPT the test above. The test above failed with an almost identical stack trace:
> {code}
> Thread [main] (Suspended)
> owns: RunnableLock (id=160)
> waiting for: ActiveOperationSupport$ActiveOperationImpl<T,A> (id=161)
> Object.wait(long) line: not available [native method]
> ActiveOperationSupport$ActiveOperationImpl<T,A>(Object).wait() line: 503
> ActiveOperationSupport$ActiveOperationImpl<T,A>(AsyncFutureTask<T>).await() line: 192
> ActiveOperationSupport$ActiveOperationImpl<T,A>(AsyncFutureTask<T>).get() line: 266
> AbstractModelControllerClient$DelegatingCancellableAsyncFuture(AbstractDelegatingAsyncFuture<T>).get() line: 100
> ServerDeploymentPlanResultFuture.get() line: 76
> ServerDeploymentPlanResultFuture.get() line: 42
> DeploymentOperationResult.getStatus() line: 52
> AS7ManagerTestUtils.waitUntilFinished(IJBoss7DeploymentResult) line: 93
> AS7ManagerTestUtils.quietlyUndeploy(String, AS71Manager) line: 76
> AS7ManagerIntegrationTest.canReplaceWar() line: 135
> {code}
> No matter how you look at it, the contract has been broken. JBossTools now is looking for a specific set of jars which care capable of communicating with AS7.0, 7.1, 7.2, eap6.0, 6.1, jpp6.0, etc. Without a set of jars that can communicate with all of these servers, our tools will need to implement drastic workarounds or bundle several versions of the app server's jars within it.
> It's interesting to me that the as7.1 jars work against everything except eap6.1, and yet, the eap6.1 jars work against everything except as7.0.0.
--
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, 3 months