[JBoss JIRA] (WFLY-9231) Wildfly wildfly-ejb3 - 10.1.0.Final EJBComponentDescription - not useful exception when class for mdb not found
by Nuno Godinho de Matos (JIRA)
Nuno Godinho de Matos created WFLY-9231:
-------------------------------------------
Summary: Wildfly wildfly-ejb3 - 10.1.0.Final EJBComponentDescription - not useful exception when class for mdb not found
Key: WFLY-9231
URL: https://issues.jboss.org/browse/WFLY-9231
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 10.1.0.Final
Environment: windows 7, but it is immaterial
Reporter: Nuno Godinho de Matos
Priority: Minor
While opening a WAR project on eclipse, for some unkown reason, the project / jboss tooling integration was not working properly.
In particular, when deploying a small sample application there was an Mdb class that was not getting copied over to the deploymnet folder.
e.g.
C:\dev\Widlfly10\wildfly-10.1.0.Final\user_projects\domains\standalone-orcl\deployments\wildfly-jta-commit-reproducebug.war\WEB-INF\classes\entrypoint\mdb
The above folder was empty.
The deployment would fail because the Mdb class was not withing that folder.
Now the fix for this problem was to close and re-open the project.
Ater which whatever glitch was going on eclipse got resolved and the deployment process started working properly.
With that said, this issue is about the exception that wildfly was firing during the deployment:
Namely:
{panel}
2017-08-16 14:08:00,203 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."wildfly-jta-commit-reproducebug.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."wildfly-jta-commit-reproducebug.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "wildfly-jta-commit-reproducebug.war"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalArgumentException: WFLYEE0078: componentClassName is null
at org.jboss.as.ee.component.ComponentDescription.<init>(ComponentDescription.java:114)
at org.jboss.as.ejb3.component.EJBComponentDescription.<init>(EJBComponentDescription.java:269)
at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponentDescription.<init>(MessageDrivenComponentDescription.java:96)
at org.jboss.as.ejb3.deployment.processors.MessageDrivenComponentDescriptionFactory.processMessageDrivenBeanMetaData(MessageDrivenComponentDescriptionFactory.java:244)
at org.jboss.as.ejb3.deployment.processors.MessageDrivenComponentDescriptionFactory.processBeanMetaData(MessageDrivenComponentDescriptionFactory.java:88)
at org.jboss.as.ejb3.deployment.processors.AnnotatedEJBComponentDescriptionDeploymentUnitProcessor.processBeanMetaData(AnnotatedEJBComponentDescriptionDeploymentUnitProcessor.java:64)
at org.jboss.as.ejb3.deployment.processors.AbstractDeploymentUnitProcessor.processDeploymentDescriptor(AbstractDeploymentUnitProcessor.java:138)
at org.jboss.as.ejb3.deployment.processors.AbstractDeploymentUnitProcessor.deploy(AbstractDeploymentUnitProcessor.java:79)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
... 5 more
{panel}
The above exception is not very useful, because it does not say what component is the point of origin for the above exception.
Before I could go investigate the folder in the deployment dir, I thought there must be something wrong in the project (there wasn't).
So I had to wonder what component was bugy.
It was necessary to add to the project the following dependency:
{panel}
<dependency>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-ejb3</artifactId>
<version>10.1.0.Final</version>
<scope>provided</scope>
</dependency>
{panel}
Debug the class:
org.jboss.as.ejb3.component.EJBComponentDescription
{panel}
public EJBComponentDescription(final String componentName, final String componentClassName, final EjbJarDescription ejbJarDescription, final ServiceName deploymentUnitServiceName, final EnterpriseBeanMetaData descriptorData) {
super(componentName, componentClassName, ejbJarDescription.getEEModuleDescription(), deploymentUnitServiceName);
{panel}
To figure out the compnent name that was the cause of the issue.
Then I finally added the ejb-class extra metadata to the jboss-ejb3.xml.
{panel}
<message-driven>
<ejb-name>ReproduceBugMdb</ejb-name>
<!-- Sometimes neecessary. -->
<ejb-class>entrypoint.mdb.ReproduceBugMdb</ejb-class>
<resource-ref>
<res-ref-name>JmsXA</res-ref-name>
<res-type>javax.jms.ConnectionFactory</res-type>
<lookup-name>java:/JmsXA</lookup-name>
</resource-ref>
<activation-config>
<activation-config-property>
<activation-config-property-name>maxSession</activation-config-property-name>
<activation-config-property-value>1</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>destinationLookup</activation-config-property-name>
<activation-config-property-value>java:/queue/ReproduceBugQueue</activation-config-property-value>
</activation-config-property>
</activation-config>
</message-driven>
{panel}
And only then could I get the "class not found exception" that lead me to go take a peek at the deployment folder and see that the folder was empty of any classes.
Which lead me to close and open the project.
I believe that the firing up an exception that reports that component class is null does not help anybody.
The exception should give as much context as possible to help the user identify the point of origing of the problem.
In this case, it should at least refer the mdb whose class could not be figured out during deployment.
Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3186) Query MBean names takes forever when having many loggers and many classes
by Steffen Czymmeck (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3186?page=com.atlassian.jira.plugi... ]
Steffen Czymmeck edited comment on WFCORE-3186 at 8/16/17 7:59 AM:
-------------------------------------------------------------------
[~jamezp] I encountered this while migrating a big application from an older JBoss version to WildFly. I guess we could reduce the number of configured loggers, but even with only a few it's still pretty slow compared to JBoss 5, where you could query MBean names nearly instantaneously.
Edit: Even with a reduced number of configured loggers (28 in my case) it is still incredibly slow. In the long run I could also reduce the number of deployments, but the performance hit would still be noticeable.
was (Author: steffencz):
[~jamezp] I encountered this while migrating a big application from an older JBoss version to WildFly. I guess we could reduce the number of configured loggers, but even with only a few it's still pretty slow compared to JBoss 5, where you could query MBean names nearly instantaneously.
> Query MBean names takes forever when having many loggers and many classes
> -------------------------------------------------------------------------
>
> Key: WFCORE-3186
> URL: https://issues.jboss.org/browse/WFCORE-3186
> Project: WildFly Core
> Issue Type: Bug
> Components: JMX, Logging
> Environment: Windows 7 and Windows 10
> Reporter: Steffen Czymmeck
> Attachments: manyClasses.ear, standalone.xml
>
>
> If you configure many loggers (~300) and deploy a rather big ear with many classes, it takes forever to query mbean names with
> javax.management.MBeanServer#queryNames or via. jconsoles MBeans tab.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9226) Elytron dir-context referral mode THROW results to LdapReferralException for MS Active Directory
by Jiri Ondrusek (JIRA)
[ https://issues.jboss.org/browse/WFLY-9226?page=com.atlassian.jira.plugin.... ]
Jiri Ondrusek updated WFLY-9226:
--------------------------------
Git Pull Request: https://github.com/wildfly-security/wildfly-elytron/pull/947 (was: https://github.com/wildfly-security/wildfly-elytron/pull/946)
> Elytron dir-context referral mode THROW results to LdapReferralException for MS Active Directory
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-9226
> URL: https://issues.jboss.org/browse/WFLY-9226
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.CR1
> Reporter: Jiri Ondrusek
> Assignee: Jiri Ondrusek
> Labels: eap72
>
> When Elytron dir-context is configured to use referral mode THROW and MS Active Directory is used and ldap-realm attributes {{identity-mapping.search-base-dn}} or {{identity-mapping.attribute-mapping.filter-base-dn}} is configured to referral domain (i.e. domain which is referred through crossRef of LDAP server configured in related {{dir-context}}) then LdapReferralException is thrown and authentication is failed.
> In correct behavior ldap-realm with THROW referral mode should be able to authenticate user from referral correctly.
> Thrown Exception:
> {code}
> BASIC: org.wildfly.security.http.HttpAuthenticationException: org.wildfly.security.http.HttpAuthenticationException: org.wildfly.security.auth.server.RealmUnavailableException: ELY01108: Ldap-backed realm identity search failed
> at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:176)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:115)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94)
> at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78)
> at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:100)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:211)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.wildfly.security.http.HttpAuthenticationException: org.wildfly.security.auth.server.RealmUnavailableException: ELY01108: Ldap-backed realm identity search failed
> at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:79)
> at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:152)
> ... 37 more
> Caused by: org.wildfly.security.auth.server.RealmUnavailableException: ELY01108: Ldap-backed realm identity search failed
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapSearch.search(LdapSecurityRealm.java:1138)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:689)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:601)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1859)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:665)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:877)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:787)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:928)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:735)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:73)
> ... 38 more
> Caused by: com.sun.jndi.ldap.LdapReferralException: [LDAP: error code 10 - 0000202B: RefErr: DSID-03100781, data 0, 1 access points
> ref 1: 'eap-vm002.mw.lab.eng.bos.redhat.com'
> \00]; remaining name 'ou=SimpleADReferralTestCasea4e11461,OU=secondary,O=eapqe,DC=JBOSS3,DC=test2'
> at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2975)
> at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2888)
> at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1846)
> at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1769)
> at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1786)
> at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:418)
> at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:396)
> at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:297)
> at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:297)
> at org.wildfly.security.auth.realm.ldap.DelegatingLdapContext.search(DelegatingLdapContext.java:330)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapSearch.searchWithPagination(LdapSecurityRealm.java:1158)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapSearch.search(LdapSecurityRealm.java:1052)
> ... 48 more
> {code}
> Similar issue for referral mode THROW is also included in older version of application server, see JBEAP-3027 and JBEAP-3029.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ELY-1226) Elytron dir-context referral mode THROW results to LdapReferralException for MS Active Directory
by Jiri Ondrusek (JIRA)
[ https://issues.jboss.org/browse/ELY-1226?page=com.atlassian.jira.plugin.s... ]
Jiri Ondrusek updated ELY-1226:
-------------------------------
Git Pull Request: https://github.com/wildfly-security/wildfly-elytron/pull/947 (was: https://github.com/wildfly-security/wildfly-elytron/pull/946)
> Elytron dir-context referral mode THROW results to LdapReferralException for MS Active Directory
> ------------------------------------------------------------------------------------------------
>
> Key: ELY-1226
> URL: https://issues.jboss.org/browse/ELY-1226
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta47
> Reporter: Ondrej Lukas
> Assignee: Jiri Ondrusek
>
> When Elytron dir-context is configured to use referral mode THROW and MS Active Directory is used and ldap-realm attributes {{identity-mapping.search-base-dn}} or {{identity-mapping.attribute-mapping.filter-base-dn}} is configured to referral domain (i.e. domain which is referred through crossRef of LDAP server configured in related {{dir-context}}) then LdapReferralException is thrown and authentication is failed.
> In correct behavior ldap-realm with THROW referral mode should be able to authenticate user from referral correctly.
> Thrown Exception:
> {code}
> BASIC: org.wildfly.security.http.HttpAuthenticationException: org.wildfly.security.http.HttpAuthenticationException: org.wildfly.security.auth.server.RealmUnavailableException: ELY01108: Ldap-backed realm identity search failed
> at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:176)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:115)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94)
> at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78)
> at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:100)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:211)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.wildfly.security.http.HttpAuthenticationException: org.wildfly.security.auth.server.RealmUnavailableException: ELY01108: Ldap-backed realm identity search failed
> at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:79)
> at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:152)
> ... 37 more
> Caused by: org.wildfly.security.auth.server.RealmUnavailableException: ELY01108: Ldap-backed realm identity search failed
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapSearch.search(LdapSecurityRealm.java:1138)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:689)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:601)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1859)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:665)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:877)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:787)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:928)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:735)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:73)
> ... 38 more
> Caused by: com.sun.jndi.ldap.LdapReferralException: [LDAP: error code 10 - 0000202B: RefErr: DSID-03100781, data 0, 1 access points
> ref 1: 'eap-vm002.mw.lab.eng.bos.redhat.com'
> \00]; remaining name 'ou=SimpleADReferralTestCasea4e11461,OU=secondary,O=eapqe,DC=JBOSS3,DC=test2'
> at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2975)
> at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2888)
> at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1846)
> at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1769)
> at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1786)
> at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:418)
> at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:396)
> at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:297)
> at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:297)
> at org.wildfly.security.auth.realm.ldap.DelegatingLdapContext.search(DelegatingLdapContext.java:330)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapSearch.searchWithPagination(LdapSecurityRealm.java:1158)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapSearch.search(LdapSecurityRealm.java:1052)
> ... 48 more
> {code}
> Similar issue for referral mode THROW is also included in older version of application server, see JBEAP-3027 and JBEAP-3029.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ]
Nuno Godinho de Matos edited comment on WFLY-8954 at 8/16/17 7:38 AM:
----------------------------------------------------------------------
Two quick notes:
(a) the following set of files can be a problem for people that have an antivirus on their local machine:
deleted: jsf/multi-jsf-installer/src/main/resources/mojarra-undeploy.scr
deleted: jsf/multi-jsf-installer/src/main/resources/myfaces-deploy.scr
deleted: jsf/multi-jsf-installer/src/main/resources/myfaces-undeploy.scr
A person might not be able to checkout these files and they shall be listed as deleted.
It was necessary to disable mcaffee.
(b) To build the project, many of dependencies need to be fetched out of the jboss pulic repository.
It might not be a bad Idea to have a root pom.xml that ensures that libraries like slf4j-api-jboss1.jar can be resolved.
Otherwise the build.bat may fail.
was (Author: nuno.godinhomatos):
Two quick notes:
(a) the following set of files can be a problem for people that have an antivirus on their local machine:
deleted: jsf/multi-jsf-installer/src/main/resources/mojarra-undeploy.scr
deleted: jsf/multi-jsf-installer/src/main/resources/myfaces-deploy.scr
deleted: jsf/multi-jsf-installer/src/main/resources/myfaces-undeploy.scr
A person might not be able to checkout these files and they shall be listed as deleted.
It was necessary to disable mcaffee.
(b) To build the project, many of dependencies need to be fetched out of the jboss pulic repository.
It might not be a bad Idea to have the pom.xml that depend on libraries like slf4j-api-jboss1.jar to refer the public red hat repository..
> Wildfly 10 with eclipselink Onscucess observer gets stale entity
> ----------------------------------------------------------------
>
> Key: WFLY-8954
> URL: https://issues.jboss.org/browse/WFLY-8954
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Scott Marlow
>
> Hi,
> In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink.
> When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success.
> Then the observer will be working with stale entities that do not reflect the modifications done to the entity.
> A sample application for this issue is available in:
> https://github.com/99sono/wildfly10-observe-on-success-stale-entity
> The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation.
> Many thanks for taking a look.
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ]
Nuno Godinho de Matos commented on WFLY-8954:
---------------------------------------------
Two quick notes:
(a) the following set of files can be a problem for people that have an antivirus on their local machine:
deleted: jsf/multi-jsf-installer/src/main/resources/mojarra-undeploy.scr
deleted: jsf/multi-jsf-installer/src/main/resources/myfaces-deploy.scr
deleted: jsf/multi-jsf-installer/src/main/resources/myfaces-undeploy.scr
A person might not be able to checkout these files and they shall be listed as deleted.
It was necessary to disable mcaffee.
(b) To build the project, many of dependencies need to be fetched out of the jboss pulic repository.
It might not be a bad Idea to have the pom.xml that depend on libraries like slf4j-api-jboss1.jar to refer the public red hat repository..
> Wildfly 10 with eclipselink Onscucess observer gets stale entity
> ----------------------------------------------------------------
>
> Key: WFLY-8954
> URL: https://issues.jboss.org/browse/WFLY-8954
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Scott Marlow
>
> Hi,
> In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink.
> When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success.
> Then the observer will be working with stale entities that do not reflect the modifications done to the entity.
> A sample application for this issue is available in:
> https://github.com/99sono/wildfly10-observe-on-success-stale-entity
> The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation.
> Many thanks for taking a look.
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-4572) wildfly-arquillian uses slf4j-api:1.7.7.jbossorg-1 which is not available in maven central repository
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFLY-4572?page=com.atlassian.jira.plugin.... ]
Nuno Godinho de Matos edited comment on WFLY-4572 at 8/16/17 5:22 AM:
----------------------------------------------------------------------
One question, while trying to build wildfly locally using the build bat, I am confronted with unfound dependenicies.
So now trying to do the following on my local machine:
{panel}
SET GROUP_ID=org.slf4j
SET ARTIFACT_ID=slf4j-api
SET ARTIFACT_VERSION=1.7.7.jbossorg-1
mvn org.apache.maven.plugins:maven-dependency-plugin:copy -Dmdep.useBaseVersion=true -DoutputAbsoluteArtifactFilename -DoutputDirectory=%WORKING_DIR% -Dartifact=%GROUP_ID%:%ARTIFACT_ID%:%ARTIFACT_VERSION%
{panel}
I end up getting that this artifact is not to be found in the remote repositories.
I am getting this for multiple artifacts.
Now looking at the mirror file system:
http://uk.maven.org/maven2/org/slf4j/slf4j-api/
We can see that this true the dependencyh is not there.
But looking at maven central page.
https://mvnrepository.com/artifact/org.slf4j/slf4j-api/1.7.7.jbossorg-1
...
Revision to my commment above.
After checking the download link in maven central.
It was trivial to see that the reason is that i needed to enrich my maven settings with:
{panel}
<repository>
<id>central_third_party_releases</id>
<url>https://repository.jboss.org/nexus/content/repositories/thirdparty-releases</url>
<releases>
<enabled>true</enabled>
</releases>
</repository>
{panel}
Kindest regards.
was (Author: nuno.godinhomatos):
One question, while trying to build wildfly locally using the build bat, I am confronted with unfound dependenicies.
So now trying to do the following on my local machine:
{panel}
SET GROUP_ID=org.slf4j
SET ARTIFACT_ID=slf4j-api
SET ARTIFACT_VERSION=1.7.7.jbossorg-1
mvn org.apache.maven.plugins:maven-dependency-plugin:copy -Dmdep.useBaseVersion=true -DoutputAbsoluteArtifactFilename -DoutputDirectory=%WORKING_DIR% -Dartifact=%GROUP_ID%:%ARTIFACT_ID%:%ARTIFACT_VERSION%
{panel}
I end up getting that this artifact is not to be found in the remote repositories.
I am getting this for multiple artifacts.
Now looking at the mirror file system:
http://uk.maven.org/maven2/org/slf4j/slf4j-api/
We can see that this true the dependencyh is not there.
But looking at maven central page.
https://mvnrepository.com/artifact/org.slf4j/slf4j-api/1.7.7.jbossorg-1
The dependency should be found.
What exactly is going on?
Kindest regards.
> wildfly-arquillian uses slf4j-api:1.7.7.jbossorg-1 which is not available in maven central repository
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-4572
> URL: https://issues.jboss.org/browse/WFLY-4572
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 8.2.0.Final, 9.0.0.Beta2
> Reporter: Martin Kouba
> Assignee: James Perkins
> Fix For: 9.0.0.CR1
>
>
> GAV: {{org.slf4j:slf4j-api:1.7.7.jbossorg-1}}
> As a result, it's not possible to build a project which depends on some referencing module, e.g. {{wildfly-arquillian-common}}, and does not define JBoss repository at the same time.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months