[JBoss JIRA] (WFCORE-1083) Login Module is messed up when one of the module-option is empty
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1083?page=com.atlassian.jira.plugi... ]
Alexey Loubyansky commented on WFCORE-1083:
-------------------------------------------
It appears to be fixed in the current master which is WildFly 10.0.0.CR5 (wildfly-core 2.0.0.CR9). principalDNSPrefix will be stored as "undefined" in the XML.
> Login Module is messed up when one of the module-option is empty
> ----------------------------------------------------------------
>
> Key: WFCORE-1083
> URL: https://issues.jboss.org/browse/WFCORE-1083
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Environment: CentOS Linux release 7.1.1503 (Core)
> /usr/java/jdk1.8.0_45/
> WildFly 8.2.0
> Reporter: J Prasanna Venkatesan
> Assignee: Alexey Loubyansky
> Priority: Critical
>
> When one of the module-option is given as empty the whole login-module is messed up. But in real time there will be cases where the module-option can be empty. For Eg. while configuring org.jboss.security.auth.spi.LdapLoginModule, the principalDNPrefix can be empty
> *+Command with principalDNPrefix empty+*
> /subsystem=security/security-domain=SourceForge/authentication=classic/login-module=org.jboss.security.auth.spi.LdapLoginModule33:add(code=org.jboss.security.auth.spi.LdapLoginModule, flag=sufficient, module-options=[ "java.naming.provider.url" => "ldap://ldaphost.jboss.org:1", "java.naming.security.authentication" => "simple", *"principalDNPrefix" => ""*, "principalDNSuffix" => ",ou=People,o=jboss.org", "allowEmptyPasswords" => "false", "java.naming.factory.initial" => "com.sun.jndi.ldap.LdapCtxFactory", "throwValidateError" => "true" ]){allow-resource-service-restart=true}
> +Output in standalone-full.xml+
> Wrong value is stored as principalDNPrefix
> <login-module name="org.jboss.security.auth.spi.LdapLoginModule33" code="org.jboss.security.auth.spi.LdapLoginModule" flag="sufficient">
> <module-option name="java.naming.provider.url" value="ldap://ldaphost.jboss.org:1"/>
> <module-option name="java.naming.security.authentication" value="simple"/>
> *<module-option name="principalDNPrefix" value="principalDNSuffix"/>*
> <module-option name="allowEmptyPasswords" value="false"/>
> <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
> <module-option name="throwValidateError" value="true"/>
> </login-module>
> *+Command with principalDNPrefix with some value+*
> /subsystem=security/security-domain=SourceForge/authentication=classic/login-module=org.jboss.security.auth.spi.LdapLoginModule44:add(code=org.jboss.security.auth.spi.LdapLoginModule, flag=sufficient, module-options=[ "java.naming.provider.url" => "ldap://ldaphost.jboss.org:1", "java.naming.security.authentication" => "simple", *"principalDNPrefix" => "test"*, "principalDNSuffix" => ",ou=People,o=jboss.org", "allowEmptyPasswords" => "false", "java.naming.factory.initial" => "com.sun.jndi.ldap.LdapCtxFactory", "throwValidateError" => "true" ]){allow-resource-service-restart=true}
> +Output in standalone-full.xml+
> Values are stored correctly.
> <login-module name="org.jboss.security.auth.spi.LdapLoginModule44" code="org.jboss.security.auth.spi.LdapLoginModule" flag="sufficient">
> <module-option name="java.naming.provider.url" value="ldap://ldaphost.jboss.org:1"/>
> <module-option name="java.naming.security.authentication" value="simple"/>
> *<module-option name="principalDNPrefix" value="test"/>*
> <module-option name="principalDNSuffix" value=",ou=People,o=jboss.org"/>
> <module-option name="allowEmptyPasswords" value="false"/>
> <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
> <module-option name="throwValidateError" value="true"/>
> </login-module>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (DROOLS-618) Thread deadlock on org.drools.util.CompositeClassLoader
by Satish Narayan (JIRA)
[ https://issues.jboss.org/browse/DROOLS-618?page=com.atlassian.jira.plugin... ]
Satish Narayan commented on DROOLS-618:
---------------------------------------
We ran into this as well. Is this truly a bug? Is there a safe work around?
> Thread deadlock on org.drools.util.CompositeClassLoader
> -------------------------------------------------------
>
> Key: DROOLS-618
> URL: https://issues.jboss.org/browse/DROOLS-618
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.6.0.Final
> Environment: drools expert
> Reporter: Shashank Agarwal
> Assignee: Mark Proctor
> Attachments: http-54350-Processor15.txt, http-54350-Processor18.txt, http-54350-Processor20.txt
>
>
> Sometimes we are facing issues of thread deadlock due to which our application goes unresponsive. Drools version 5.6.0
> Below is the deadlock statements detected by jconsole, also attached full tread dumps. There three threads are deadlocked triangularly.
> Name: http-54350-Processor15
> State: BLOCKED on org.drools.rule.JavaDialectRuntimeData$PackageClassLoader@1d5787a owned by: http-54350-Processor18
> Name: http-54350-Processor18
> State: WAITING on java.util.concurrent.locks.ReentrantLock$NonfairSync@3cda324d owned by: http-54350-Processor15
> Name: http-54350-Processor20
> State: BLOCKED on org.drools.util.CompositeClassLoader@61269654 owned by: http-54350-Processor15
> We do not have definite threads to re-produce the issue.
> But deadlocks are happening repeatedly on our production.
> Regarding out environment details:
> 1. We have windows box on which application runs.
> 2. The rules used are kept in .drl and .xls formats
> 3. Call StatefulKnowledgeSession session = base.newStatefulKnowledgeSession();
> 4. Setup a few session globals as well.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-5614) org.hibernate:4.3 should not be alias for 5.0
by Scott Marlow (JIRA)
Scott Marlow created WFLY-5614:
----------------------------------
Summary: org.hibernate:4.3 should not be alias for 5.0
Key: WFLY-5614
URL: https://issues.jboss.org/browse/WFLY-5614
Project: WildFly
Issue Type: Feature Request
Components: JPA / Hibernate
Affects Versions: 10.0.0.CR4
Reporter: Scott Marlow
Assignee: Scott Marlow
modules/system/layers/base/org/hibernate/4.3/module.xml contains:
{quote}
<module-alias xmlns="urn:jboss:module:1.3" name="org.hibernate" slot="4.3" target-name="org.hibernate"/>
{quote}
org.hibernate:4.3 should be a real module (not alias) like org.hibernate:4.1 is.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFCORE-1090) Modules are missing jboss.api=private setting in module.xml
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1090:
----------------------------------------
Summary: Modules are missing jboss.api=private setting in module.xml
Key: WFCORE-1090
URL: https://issues.jboss.org/browse/WFCORE-1090
Project: WildFly Core
Issue Type: Bug
Affects Versions: 2.0.0.CR9
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 2.0.0.Final
Following modules need to have the jboss.api=private property added to their module.xml:
org.jboss.sasl
org.jboss.as.self-contained
sun.scripting
org.wildfly.extension.io
org.wildfly.extension.request-controller
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFCORE-1089) IgnoredResourcesProfileCloneTestCase does not wait for domain stabilization following reload
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1089?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1089:
-------------------------------------
Summary: IgnoredResourcesProfileCloneTestCase does not wait for domain stabilization following reload (was: IgnoredResourcesProfileCloneTestCase does not well for domain stabilization following reload)
> IgnoredResourcesProfileCloneTestCase does not wait for domain stabilization following reload
> --------------------------------------------------------------------------------------------
>
> Key: WFCORE-1089
> URL: https://issues.jboss.org/browse/WFCORE-1089
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Test Suite
> Affects Versions: 2.0.0.CR9
> Reporter: Brian Stansberry
>
> IgnoredResourcesProfileCloneTestCase several times reloads the slave HC without restarting its servers. But it then does not wait for those servers to reconnect before continuing on. This means the servers may not be reattached to the domain when further modifications are made.
> I'm quite certain this is the cause of the failure at http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=76866&tab=buil... and the other time that test failed.
> IgnoredResourcesProfileCloneTestCase reloads the slave and then exits. CompositeOperationTestCase follows and immediately adds system-property=composite-op in its @Before method. The other-two server doesn't get this op as it's not reconnected. The test then later fails because the other-two server's state is not as expected.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-4866) messaging-activemq: NPE when http-acceptor and https-acceptor configured
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-4866?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil edited comment on WFLY-4866 at 10/30/15 10:24 AM:
--------------------------------------------------------------
ARTEMIS-151 introduces a behaviour changes and no longer allows to have identical acceptor configurations (with different names). This means that in WildFly case, the https-acceptor is discarded because it defines the same configuration that the http-acceptor one.
was (Author: jmesnil):
ARTEMIS-151 introduce a behaviour changes and no longer allows to have identical acceptor configurations (with different names). This means that in WildFly case, the https-acceptor is discarded because it defines the same configuration that the http-acceptor one.
> messaging-activemq: NPE when http-acceptor and https-acceptor configured
> ------------------------------------------------------------------------
>
> Key: WFLY-4866
> URL: https://issues.jboss.org/browse/WFLY-4866
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.1.0.Final, 10.0.0.CR2
> Environment: Windows 7 Pro, Java 7u55
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Labels: JMS, Messaging
> Fix For: 10.0.0.CR3
>
> Attachments: server-logs.zip
>
>
> With both an http-acceptor and an https-acceptor configured in the message subsystem, when an external Java app attempts to connect, it times out and the exception below appears in the server log.
> I tracked it down to the TransportConfigOperationHandlers.processAcceptors() method. At the end of the method, it creates a HashSet of the TransportConfiguration objects representing the acceptors. But, the TransportConfiguration equals() method reports that the https and http acceptors are equal, and as it is building a Set of unique values, the https-acceptor gets dropped.
> Later, when the http-upgrade handshake runs, the code is unable to find the https-acceptor, resulting in the NullPointerException.
> I think the fix might be to either not use a Set, or to look at the TransportConfiguration.equals() method.
> The workaround in the ticket works because the redundant <param> causes the equals() method to see the two acceptors as unequal.
> The exception was:
> [exec] 10:07:57,502 ERROR [org.xnio.listener] (default I/O-10) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
> [exec] at org.jboss.as.messaging.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:161)
> [exec] at org.jboss.as.messaging.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:153)
> [exec] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> [exec] at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:149)
> [exec] at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:271)
> [exec] at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:221)
> [exec] at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1131)
> [exec] at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1351)
> [exec] at io.undertow.server.Connectors.terminateResponse(Connectors.java:78)
> [exec] at io.undertow.server.protocol.http.ServerFixedLengthStreamSinkConduit.channelFinished(ServerFixedLengthStreamSinkConduit.java:33)
> [exec] at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.exitFlush(AbstractFixedLengthStreamSinkConduit.java:273)
> [exec] at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(AbstractFixedLengthStreamSinkConduit.java:207)
> [exec] at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> [exec] at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100)
> [exec] at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1489)
> [exec] at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1470)
> [exec] at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:152)
> [exec] at io.undertow.server.handlers.ProxyPeerAddressHandler.handleRequest(ProxyPeerAddressHandler.java:45)
> [exec] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
> [exec] at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:156)
> [exec] at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:91)
> [exec] at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:45)
> [exec] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> [exec] at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> [exec] at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> [exec] at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-4866) messaging-activemq: NPE when http-acceptor and https-acceptor configured
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-4866?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil reopened WFLY-4866:
-------------------------------
ARTEMIS-151 introduce a behaviour changes and no longer allows to have identical acceptor configurations (with different names). This means that in WildFly case, the https-acceptor is discarded because it defines the same configuration that the http-acceptor one.
> messaging-activemq: NPE when http-acceptor and https-acceptor configured
> ------------------------------------------------------------------------
>
> Key: WFLY-4866
> URL: https://issues.jboss.org/browse/WFLY-4866
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.1.0.Final, 10.0.0.CR2
> Environment: Windows 7 Pro, Java 7u55
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Labels: JMS, Messaging
> Fix For: 10.0.0.CR3
>
> Attachments: server-logs.zip
>
>
> With both an http-acceptor and an https-acceptor configured in the message subsystem, when an external Java app attempts to connect, it times out and the exception below appears in the server log.
> I tracked it down to the TransportConfigOperationHandlers.processAcceptors() method. At the end of the method, it creates a HashSet of the TransportConfiguration objects representing the acceptors. But, the TransportConfiguration equals() method reports that the https and http acceptors are equal, and as it is building a Set of unique values, the https-acceptor gets dropped.
> Later, when the http-upgrade handshake runs, the code is unable to find the https-acceptor, resulting in the NullPointerException.
> I think the fix might be to either not use a Set, or to look at the TransportConfiguration.equals() method.
> The workaround in the ticket works because the redundant <param> causes the equals() method to see the two acceptors as unequal.
> The exception was:
> [exec] 10:07:57,502 ERROR [org.xnio.listener] (default I/O-10) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
> [exec] at org.jboss.as.messaging.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:161)
> [exec] at org.jboss.as.messaging.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:153)
> [exec] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> [exec] at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:149)
> [exec] at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:271)
> [exec] at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:221)
> [exec] at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1131)
> [exec] at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1351)
> [exec] at io.undertow.server.Connectors.terminateResponse(Connectors.java:78)
> [exec] at io.undertow.server.protocol.http.ServerFixedLengthStreamSinkConduit.channelFinished(ServerFixedLengthStreamSinkConduit.java:33)
> [exec] at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.exitFlush(AbstractFixedLengthStreamSinkConduit.java:273)
> [exec] at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(AbstractFixedLengthStreamSinkConduit.java:207)
> [exec] at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> [exec] at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100)
> [exec] at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1489)
> [exec] at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1470)
> [exec] at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:152)
> [exec] at io.undertow.server.handlers.ProxyPeerAddressHandler.handleRequest(ProxyPeerAddressHandler.java:45)
> [exec] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
> [exec] at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:156)
> [exec] at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:91)
> [exec] at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:45)
> [exec] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> [exec] at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> [exec] at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> [exec] at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-3674) In non-transactional entity manager invocation, add extension to defer entity detach until persistence context is closed
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-3674?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-3674:
------------------------------------
The fix is currently in WF9/WF10 and will be in EAP 7. It has not yet been back ported to EAP 6. Thanks for the compliment on the JPA container/subsystem/deployer doc! :-)
> In non-transactional entity manager invocation, add extension to defer entity detach until persistence context is closed
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3674
> URL: https://issues.jboss.org/browse/WFLY-3674
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Fix For: 9.0.0.Alpha1
>
>
> For compatibility with earlier JBoss application server versions (5.0/6.0), add an extension that allows the persistence context to last until the referencing persistence context is closed.
> For example, in a session method that has no active JTA transaction, entities returned, will not cleared from the persistence context, until the session method completes. This extension is only introduced to allow compatibility with older application server versions.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months