[JBoss JIRA] (ELY-1802) LDAPS referrals broken
by Maria Vassileva (Jira)
Maria Vassileva created ELY-1802:
------------------------------------
Summary: LDAPS referrals broken
Key: ELY-1802
URL: https://issues.jboss.org/browse/ELY-1802
Project: WildFly Elytron
Issue Type: Bug
Reporter: Maria Vassileva
Assignee: Darran Lofthouse
Fix For: 1.7.0.CR1
We are having trouble getting LDAPS referrals working with an Elytron LDAP realm. The issue is the following stack trace.
{code}
javax.security.sasl.SaslException: ELY05012: Authentication mechanism server-side authentication failed [Caused by org.wildfly.security.auth.server.RealmUnavailableException: ELY01153: Direct LDAP verification failed with DN [redacted] and absolute DN [null]]
at org.wildfly.security.sasl.plain.PlainSaslServer.evaluateResponse(PlainSaslServer.java:121)
at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1.evaluateResponse(AuthenticationCompleteCallbackSaslServerFactory.java:58)
at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer.evaluateResponse(AuthenticationTimeoutSaslServerFactory.java:106)
at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1.evaluateResponse(SecurityIdentitySaslServerFactory.java:59)
at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:245)
at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:217)
at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:486)
at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.wildfly.security.auth.server.RealmUnavailableException: ELY01153: Direct LDAP verification failed with DN [redacted] and absolute DN [null]
at org.wildfly.security.auth.realm.ldap.DirectEvidenceVerifier$1.verifyEvidence(DirectEvidenceVerifier.java:104)
at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:609)
at org.wildfly.security.auth.realm.AggregateSecurityRealm$Identity.verifyEvidence(AggregateSecurityRealm.java:155)
at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1977)
at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:759)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:992)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:902)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:839)
at org.wildfly.security.sasl.util.SSLQueryCallbackHandler.handle(SSLQueryCallbackHandler.java:60)
at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.lambda$createSaslServer$0(TrustManagerSaslServerFactory.java:96)
at org.wildfly.security.sasl.plain.PlainSaslServer.evaluateResponse(PlainSaslServer.java:117)
... 12 more
Caused by: javax.naming.CommunicationException: ldap.acme.com:636 [Root exception is java.lang.ClassNotFoundException: org.wildfly.security.auth.realm.ldap.ThreadLocalSSLSocketFactory from [Module "org.wildfly.extension.io" version 5.0.0.Final from local module loader @7586beff (finder: local module finder @3b69e7d1 (roots: redacted))]]
at com.sun.jndi.ldap.Connection.<init>(Connection.java:226)
at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1615)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2749)
at com.sun.jndi.ldap.LdapCtx.ensureOpen(LdapCtx.java:2699)
at com.sun.jndi.ldap.LdapCtx.ensureOpen(LdapCtx.java:2673)
at com.sun.jndi.ldap.LdapCtx.reconnect(LdapCtx.java:2669)
at org.wildfly.security.auth.realm.ldap.DelegatingLdapContext.reconnect(DelegatingLdapContext.java:181)
at org.wildfly.security.auth.realm.ldap.DirectEvidenceVerifier$1.verifyEvidence(DirectEvidenceVerifier.java:97)
... 22 more
Caused by: java.lang.ClassNotFoundException: org.wildfly.security.auth.realm.ldap.ThreadLocalSSLSocketFactory from [Module "org.wildfly.extension.io" version 5.0.0.Final from local module loader @7586beff (finder: local module finder @3b69e7d1 (roots: redacted))]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:255)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at com.sun.jndi.ldap.VersionHelper12.loadClass(VersionHelper12.java:72)
at com.sun.jndi.ldap.Connection.createSocket(Connection.java:281)
at com.sun.jndi.ldap.Connection.<init>(Connection.java:203)
... 30 more
{code}
As you can see the Sun/Oracle LDAP classes try to load the class {{org.wildfly.security.auth.realm.ldap.ThreadLocalSSLSocketFactory}} using the TCCL which is the {{org.wildfly.extension.io}} module loader. This will not work as ThreadLocalSSLSocketFactor is in the module {{org.wildfy.security.elytron-private}}.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years
[JBoss JIRA] (DROOLS-3953) DMN UX - error highlight in boxed expression.
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3953?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton updated DROOLS-3953:
--------------------------------------
Sprint: 2019 Week 17-19
> DMN UX - error highlight in boxed expression.
> ---------------------------------------------
>
> Key: DROOLS-3953
> URL: https://issues.jboss.org/browse/DROOLS-3953
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Elizabeth Clayton
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: UX, UXTeam, drools-tools
> Attachments: Error reporting after test run-different kinds.png, Error reporting after test run-different kinds2.png, Error reporting after test run-popup.png, Error reporting after test run-popup.png, Error reporting after test run.png
>
>
> As user after a test run, I want see not only the cell that are not correct (red background) but also the reason.
> For instance have the possibility to see the actual value that is different from the expected or the error message.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years
[JBoss JIRA] (WFLY-8217) ActiveMQ leaks connections if a JMS message is sent from an MDB
by Scott Van Wart (Jira)
[ https://issues.jboss.org/browse/WFLY-8217?page=com.atlassian.jira.plugin.... ]
Scott Van Wart commented on WFLY-8217:
--------------------------------------
For anyone continuing to have issues with this, it appears to be corrected in 15.x but not 14.x or 13.x. I experienced it again with the following scenario:
- Thread spawned by 3rd party library calls a method on an @ApplicationScoped CDI bean.
- This in turn calls a @Transactional method on another @ApplicationScoped CDI bean.
- ... calls a @Transactional method on a @Dependent CDI bean.
- ... calls a method on an @ApplicationScoped bean.
- ... calls a method on an @Inject'ed @Stateless EJB.
- The EJB uses its @Inject'ed JMSContext and calls createBytesMessage():
{noformat}
2019-05-01 14:12:06,906 INFO [org.jboss.jca.core.api.connectionmanager.ccm.CachedConnectionManager] (hz._hzInstance_1_dev.cached.thread-5) IJ000100: Closing a connection for you. Please close them yourself: org.apache.activemq.artemis.ra.ActiveMQRASession@4dc6784e: java.lang.Throwable: STACKTRACE
at org.jboss.ironjacamar.impl@1.4.11.Final//org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl.registerConnection(CachedConnectionManagerImpl.java:308)
at org.jboss.ironjacamar.impl@1.4.11.Final//org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:819)
at org.apache.activemq.artemis.ra@2.6.3.jbossorg-001//org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.allocateConnection(ActiveMQRASessionFactoryImpl.java:872)
at org.apache.activemq.artemis.ra@2.6.3.jbossorg-001//org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:531)
at org.apache.activemq.artemis.ra@2.6.3.jbossorg-001//org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:746)
at org.apache.activemq.artemis@2.6.3.jbossorg-001//org.apache.activemq.artemis.jms.client.ActiveMQJMSContext.checkSession(ActiveMQJMSContext.java:140)
at org.apache.activemq.artemis@2.6.3.jbossorg-001//org.apache.activemq.artemis.jms.client.ActiveMQJMSContext.createBytesMessage(ActiveMQJMSContext.java:242)
at org.wildfly.extension.messaging-activemq//org.wildfly.extension.messaging.activemq.deployment.injection.JMSContextWrapper.createBytesMessage(JMSContextWrapper.java:122)
{noformat}
This was reported 3 times in a single transaction so it looks like the original problem might be related to improperly or neglecting to attach the JMS session to the current transaction.
I don't see this behaviour in 15.x but I'm including all this for anyone searching for solutions to a similar problem; the marked Fixed Version says 13.x but this doesn't seem to be the case.
> ActiveMQ leaks connections if a JMS message is sent from an MDB
> ---------------------------------------------------------------
>
> Key: WFLY-8217
> URL: https://issues.jboss.org/browse/WFLY-8217
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Transactions
> Affects Versions: 10.1.0.Final
> Environment: Running on Windows 10. Java(TM) SE Runtime Environment (build 1.8.0_92-b14)
> Reporter: Scott Van Wart
> Assignee: Emmanuel Hugonnet
> Priority: Minor
> Fix For: 13.0.0.Final
>
> Attachments: leak.zip, leak.zip, log.txt, log.txt, server.log
>
>
> If an MDB causes a JMS message to be sent during the call to onMessage(), ActiveMQ won't close its connection. I'm using JMS2 through an @Inject'ed JMSContext. My sample project is an EAR with an EJB JAR (containing a service and an MDB) and a JAX-RS endpoint (entry point for the test).
> 1) Build the EAR
> 2) Run wildfly with the standalone-full.xml configuration:
> {{standalone.bat --server-config=standalone-full.xml}}
> 3) Enable debug and error reporting for leaked connections with ActiveMQ/CCM:
> {{jboss-cli.bat -c}}
> {{/subsystem=jca/cached-connection-manager=cached-connection-manager:write-attribute(name=debug,value=true)}}
> {{/subsystem=jca/cached-connection-manager=cached-connection-manager:write-attribute(name=error,value=true)}}
> 4) Deploy the EAR.
> 5) Access http://localhost:8080/leak-web/rest/test?message=Hi
> The REST endpoint will send a message to the test topic (Defined in leak-ejb/src/main/java/test/mdb/TestTopic.java). TestTopicListener (in the same package as TestTopic) will receive the message and send a second message to the topic. Upon returning from TestTopicListener.onMessage(), the message is sent, but this shows up in the logs
> (see attached log.txt)
> I have no idea why JIRA attached each file twice.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years
[JBoss JIRA] (WFLY-9529) Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry
by Scott Van Wart (Jira)
[ https://issues.jboss.org/browse/WFLY-9529?page=com.atlassian.jira.plugin.... ]
Scott Van Wart commented on WFLY-9529:
--------------------------------------
That's good to hear; thanks for the update. My connection leak issue I mentioned off-hand is much more likely to be [WFLY-8217] which seems to still be present in 13.x and 14.x but fixed in 15.x so it's not an issue. We're continuing to use an EJB wrapper for our other JMS scenarios. I do wish there could be a grand unification of of EJB/CDI/JSF in the EE spec complete with mass deprecation that would eliminate a good deal of confusion. Our explicit use of EJB is very limited though required implicitly once MDBs and executor threads are involved, even though most of our dependencies are strictly CDI. It just looks like it creates unnecessary complexity. Thanks again.
> Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9529
> URL: https://issues.jboss.org/browse/WFLY-9529
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, JMS, Naming
> Affects Versions: 14.0.1.Final, 10.1.0.Final, 11.0.0.Final, 12.0.0.Final, 13.0.0.Final
> Environment: Running on Windows 10, Java 64-bit 1.8.0_131
> Reporter: Scott Van Wart
> Assignee: Eduardo Martins
> Priority: Major
> Labels: ActiveMQ, jms, transaction
> Attachments: injected-jms.zip, injected-jms2.zip, wildfly-11-injected-jms.txt
>
>
> If I try to use an @Injected JMSContext while executing within a background task (ManagedExecutorService) or thread (ManagedThreadFactory), I get the attached stacktrace. I've experienced this a number of times with Wildfly 10.1.0, including messages sent in Infinispan's expiry task thread.
> My original workaround was to submit an additional task on a separate thread to send the message, then wait for it to complete. That seemed unreliable (sometimes it would still produce NameNotFoundException). I've resorted to creating my own JMSContext by using @Resource( lookup="java:/ConnectionFactory" ) and sending messages that way. Both workarounds prevent the message sending logic from participating in any ongoing transactions.
> I'm also attaching a sample EAR project. It can be built with Maven. It creates a background task that waits 3 seconds and then tries to send a JMS message in a new transaction using an injected JMS context. I use the standalone-full.xml profile to run it.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years