[JBoss JIRA] (WFLY-8993) Incorrect path separator added to the end of the ENC_FILE_DIR property when defining a vault in Windows
by Matthew Casperson (JIRA)
Matthew Casperson created WFLY-8993:
---------------------------------------
Summary: Incorrect path separator added to the end of the ENC_FILE_DIR property when defining a vault in Windows
Key: WFLY-8993
URL: https://issues.jboss.org/browse/WFLY-8993
Project: WildFly
Issue Type: Bug
Affects Versions: 11.0.0.Alpha1
Reporter: Matthew Casperson
Assignee: Jason Greene
Priority: Minor
Executing this command:
{code:java}
/host=master/core-service=vault:add(vault-options={"KEYSTORE_URL" => "C:\wildfly_slave\wildfly-11.0.0.Alpha1\domain\configuration\keystore.vault", "KEYSTORE_PASSWORD" => "Password01", "KEYSTORE_ALIAS" => "vault", "SALT" => "12345678", "ITERATION_COUNT" => "50", "ENC_FILE_DIR" => "C:\wildfly_slave\wildfly-11.0.0.Alpha1\domain\configuration\vault"})
{code}
Will result in this element in the XML:
{code:xml}
</extensions>
<vault>
<vault-option name="KEYSTORE_URL" value="C:\wildfly_slave\wildfly-11.0.0.Alpha1\domain\configuration\keystore.vault"/>
<vault-option name="KEYSTORE_PASSWORD" value="MASK-223/wEo1GLELe8EuQa5u20"/>
<vault-option name="KEYSTORE_ALIAS" value="vault"/>
<vault-option name="SALT" value="12345678"/>
<vault-option name="ITERATION_COUNT" value="50"/>
<vault-option name="ENC_FILE_DIR" value="C:\wildfly_slave\wildfly-11.0.0.Alpha1\domain\configuration\vault/"/>
</vault>
{code}
Note the incorrect slash on the end of the ENC_FILE_DIR option. I assume this value is being normalised to include a trailing slash, but the wrong character is being selected on a Windows system.
WildFly seems quite happy with this incorrect character, but external tools reading this path have to account for the unexpected value.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 months
[JBoss JIRA] (WFCORE-3003) Elytron subsystem fails to boot if SecurityProvider cannot be loaded.
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3003?page=com.atlassian.jira.plugi... ]
Tomaz Cerar commented on WFCORE-3003:
-------------------------------------
Digging a bit into code, it looks like that it could also be caused by non intentionally availability/visibility of JDK providers that ServiceLoader can see.
Maybe fix could would be as simple as changing what classes are exported / imported by deps.
> Elytron subsystem fails to boot if SecurityProvider cannot be loaded.
> ---------------------------------------------------------------------
>
> Key: WFCORE-3003
> URL: https://issues.jboss.org/browse/WFCORE-3003
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Tomaz Cerar
> Assignee: Darran Lofthouse
>
> Trying to run secmgr testsuite under JDK9 results in
> {noformat}
> Caused by: java.util.ServiceConfigurationError: java.security.Provider: Provider com.sun.deploy.security.MozillaJSSProvider could not be instantiated
> at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:581)
> at java.base/java.util.ServiceLoader.access$100(ServiceLoader.java:390)
> at java.base/java.util.ServiceLoader$ProviderImpl.newInstance(ServiceLoader.java:799)
> at java.base/java.util.ServiceLoader$ProviderImpl.get(ServiceLoader.java:721)
> at java.base/java.util.ServiceLoader$3.next(ServiceLoader.java:1389)
> at java.base/java.lang.Iterable.forEach(Iterable.java:74)
> at org.wildfly.extension.elytron//org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:201)
> at org.wildfly.extension.elytron//org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:158)
> at org.wildfly.extension.elytron//org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc//org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> {noformat}
> and server doesn't start.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 months
[JBoss JIRA] (WFCORE-3003) Elytron subsystem fails to boot if SecurityProvider cannot be loaded.
by Tomaz Cerar (JIRA)
Tomaz Cerar created WFCORE-3003:
-----------------------------------
Summary: Elytron subsystem fails to boot if SecurityProvider cannot be loaded.
Key: WFCORE-3003
URL: https://issues.jboss.org/browse/WFCORE-3003
Project: WildFly Core
Issue Type: Bug
Components: Security
Reporter: Tomaz Cerar
Assignee: Darran Lofthouse
Trying to run secmgr testsuite under JDK9 results in
{noformat}
Caused by: java.util.ServiceConfigurationError: java.security.Provider: Provider com.sun.deploy.security.MozillaJSSProvider could not be instantiated
at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:581)
at java.base/java.util.ServiceLoader.access$100(ServiceLoader.java:390)
at java.base/java.util.ServiceLoader$ProviderImpl.newInstance(ServiceLoader.java:799)
at java.base/java.util.ServiceLoader$ProviderImpl.get(ServiceLoader.java:721)
at java.base/java.util.ServiceLoader$3.next(ServiceLoader.java:1389)
at java.base/java.lang.Iterable.forEach(Iterable.java:74)
at org.wildfly.extension.elytron//org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:201)
at org.wildfly.extension.elytron//org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:158)
at org.wildfly.extension.elytron//org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
at org.jboss.msc//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
at org.jboss.msc//org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
{noformat}
and server doesn't start.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 months
[JBoss JIRA] (WFCORE-3002) (Elytron) ModelControllerClient connecting to management native-interface is not able to force SSL/TLS
by Josef Cacek (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3002?page=com.atlassian.jira.plugi... ]
Josef Cacek moved WFLY-8992 to WFCORE-3002:
-------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-3002 (was: WFLY-8992)
Component/s: Domain Management
Security
(was: Domain Management)
(was: Security)
> (Elytron) ModelControllerClient connecting to management native-interface is not able to force SSL/TLS
> ------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3002
> URL: https://issues.jboss.org/browse/WFCORE-3002
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Reporter: Josef Cacek
> Assignee: Brian Stansberry
> Priority: Blocker
>
> The ModelControllerClient is not able to force using SSL/TLS connection with management native interface.
> *Usecase:* As an administrator I want to be sure that a ModelControllerClient connection to management native-interface goes through a secure connection. (I.e. Client connection is only established when the server uses SSL/TLS).
> Setting a blocker priority, as this can lead to security leaks, when a client assumes the secure management connection is used and the opposite is true and such a connection can be easily eavesdropped.
> My first try was to use ModelControllerClient configuration to set SSL context:
> {code:java}
> new ModelControllerClientConfiguration.Builder().setSslContext(sslFactory.create())
> .setProtocol("remote");
> {code}
> Nevertheless such a configuration doesn't force using SSL and if the server doesn't have SSL context configured, then the created connection is a plain remoting one.
> Next try was to configure the SSL context in Elytron's {{AuthenticationContext}}:
> {code:java}
> AuthenticationContext.withSsl(MatchRule.ALL, sslContext)
> {code}
> The result was the same (i.e. plain connection was used). [~dlofthouse] commented on this on Hipchat:
> {quote}
> In terms of Elytron configuration generally the config provided is there so it can be used if it is needed rather than it forming some form of mandatory policy. So in this case I would expect you would drive that more with the protocol you specify e.g. remote+tls or remote+https
> {quote}
> Based on the comment I've used "remote+tls" protocol on the client:
> {code:java}
> ModelControllerClientConfiguration.Builder().setProtocol("remote+tls")
> {code}
> but in this case the connection fails even if the server has the sslContext configured:
> {code:xml}
> <management-interfaces>
> <native-interface sasl-authentication-factory="test-sasl-authn-factory" ssl-context="elytron-ssl-context">
> <socket-binding native="testbinding"/>
> </native-interface>
> ...
> </management-interfaces>
> {code}
> The failure:
> {noformat}
> java.io.IOException: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+tls://127.0.0.1:10567. The connection failed
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:149) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at ... [cropped]
> Caused by: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+tls://127.0.0.1:10567. The connection failed
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:126) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:259) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.getChannel(ManagementClientChannelStrategy.java:162) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:146) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:60) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> ... 144 more
> Caused by: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
> at sun.security.ssl.EngineInputRecord.bytesInCompletePacket(EngineInputRecord.java:156) [jsse.jar:1.8.0_131]
> at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:868) [jsse.jar:1.8.0_131]
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781) [jsse.jar:1.8.0_131]
> at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624) [rt.jar:1.8.0_131]
> at org.wildfly.security.ssl.AbstractDelegatingSSLEngine.unwrap(AbstractDelegatingSSLEngine.java:56) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.ssl.JsseSslConduitEngine.engineUnwrap(JsseSslConduitEngine.java:688) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.ssl.JsseSslConduitEngine.unwrap(JsseSslConduitEngine.java:620) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.ssl.JsseSslStreamSourceConduit.read(JsseSslStreamSourceConduit.java:126) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:123) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.remoting3.remote.MessageReader.getMessage(MessageReader.java:131) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Greeting.handleEvent(ClientConnectionOpenListener.java:172) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Greeting.handleEvent(ClientConnectionOpenListener.java:167) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.nio.NioHandle$1.run(NioHandle.java:50) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:592) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:472) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:545) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:509) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:497) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:194) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:118) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> {noformat}
> Am I missing some piece of configuration here?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 months
[JBoss JIRA] (WFLY-8992) (Elytron) ModelControllerClient connecting to management native-interface is not able to force SSL/TLS
by Josef Cacek (JIRA)
Josef Cacek created WFLY-8992:
---------------------------------
Summary: (Elytron) ModelControllerClient connecting to management native-interface is not able to force SSL/TLS
Key: WFLY-8992
URL: https://issues.jboss.org/browse/WFLY-8992
Project: WildFly
Issue Type: Bug
Components: Domain Management, Security
Reporter: Josef Cacek
Assignee: Brian Stansberry
Priority: Blocker
The ModelControllerClient is not able to force using SSL/TLS connection with management native interface.
*Usecase:* As an administrator I want to be sure that a ModelControllerClient connection to management native-interface goes through a secure connection. (I.e. Client connection is only established when the server uses SSL/TLS).
Setting a blocker priority, as this can lead to security leaks, when a client assumes the secure management connection is used and the opposite is true and such a connection can be easily eavesdropped.
My first try was to use ModelControllerClient configuration to set SSL context:
{code:java}
new ModelControllerClientConfiguration.Builder().setSslContext(sslFactory.create())
.setProtocol("remote");
{code}
Nevertheless such a configuration doesn't force using SSL and if the server doesn't have SSL context configured, then the created connection is a plain remoting one.
Next try was to configure the SSL context in Elytron's {{AuthenticationContext}}:
{code:java}
AuthenticationContext.withSsl(MatchRule.ALL, sslContext)
{code}
The result was the same (i.e. plain connection was used). [~dlofthouse] commented on this on Hipchat:
{quote}
In terms of Elytron configuration generally the config provided is there so it can be used if it is needed rather than it forming some form of mandatory policy. So in this case I would expect you would drive that more with the protocol you specify e.g. remote+tls or remote+https
{quote}
Based on the comment I've used "remote+tls" protocol on the client:
{code:java}
ModelControllerClientConfiguration.Builder().setProtocol("remote+tls")
{code}
but in this case the connection fails even if the server has the sslContext configured:
{code:xml}
<management-interfaces>
<native-interface sasl-authentication-factory="test-sasl-authn-factory" ssl-context="elytron-ssl-context">
<socket-binding native="testbinding"/>
</native-interface>
...
</management-interfaces>
{code}
The failure:
{noformat}
java.io.IOException: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+tls://127.0.0.1:10567. The connection failed
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:149) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
at ... [cropped]
Caused by: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+tls://127.0.0.1:10567. The connection failed
at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:126) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:259) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.getChannel(ManagementClientChannelStrategy.java:162) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:146) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:60) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
... 144 more
Caused by: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
at sun.security.ssl.EngineInputRecord.bytesInCompletePacket(EngineInputRecord.java:156) [jsse.jar:1.8.0_131]
at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:868) [jsse.jar:1.8.0_131]
at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781) [jsse.jar:1.8.0_131]
at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624) [rt.jar:1.8.0_131]
at org.wildfly.security.ssl.AbstractDelegatingSSLEngine.unwrap(AbstractDelegatingSSLEngine.java:56) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
at org.xnio.ssl.JsseSslConduitEngine.engineUnwrap(JsseSslConduitEngine.java:688) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
at org.xnio.ssl.JsseSslConduitEngine.unwrap(JsseSslConduitEngine.java:620) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
at org.xnio.ssl.JsseSslStreamSourceConduit.read(JsseSslStreamSourceConduit.java:126) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:123) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
at org.jboss.remoting3.remote.MessageReader.getMessage(MessageReader.java:131) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Greeting.handleEvent(ClientConnectionOpenListener.java:172) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Greeting.handleEvent(ClientConnectionOpenListener.java:167) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
at org.xnio.nio.NioHandle$1.run(NioHandle.java:50) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:592) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
at org.xnio.nio.WorkerThread.run(WorkerThread.java:472) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:545) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:509) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:497) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:194) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:118) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
{noformat}
Am I missing some piece of configuration here?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 months
[JBoss JIRA] (WFLY-5727) After day or two Wildfly hangs and consumes 100% CPU
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5727?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-5727:
------------------------------
Fix Version/s: 10.1.0.Final
> After day or two Wildfly hangs and consumes 100% CPU
> ----------------------------------------------------
>
> Key: WFLY-5727
> URL: https://issues.jboss.org/browse/WFLY-5727
> Project: WildFly
> Issue Type: Bug
> Components: IO, Web (Undertow)
> Affects Versions: 8.2.0.Final, 9.0.1.Final
> Environment: Wildfly 9.01 Final, Wildfly 8.2
> CentOS Linux release 7.1.1503 (Core)
> java version "1.8.0_66"
> Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)
> Reporter: Petri Tuomaala
> Assignee: Stuart Douglas
> Priority: Blocker
> Labels: Linux, io, ssl, undertow, wildfly, xnio
> Fix For: 9.x.x TBD, 10.1.0.Final
>
> Attachments: jstack.22263.102919.280420771, jstack.22263.102925.032513958, jstack.22263.102930.660792783, jstack.22263.102936.697001192, jstack.22263.102942.535009068, jstack.22263.102948.169314576, jstack.22263.102954.185475598, jstack.22263.102959.848031929, jstack.22263.103005.599986837, jstack.22263.103011.261542540, monitor.png, pid.png
>
>
> First disclaimer, this looks pointing to undertow/xnio but I am not sure for the root cause so I'm filing this for Wildfly.
> After a day or two Wildfly just hangs and consumes the cpu. We have noticed that the site traffic itself has no impact on this: it has happened during peak traffic and also almost in idle situations.
> We are handling SSL in Wildfly and example this https://issues.jboss.org/browse/UNDERTOW-282 looks similar to this but it has been resolved over year ago so it should be in Wildfly 9.01.
> Our SSL conf in standalone.xml:
> <https-listener name="https" socket-binding="https" security-realm="UndertowRealm" enabled-cipher-suites="TLS_DHE_DSS_WITH_AES_128_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA" max-parameters="5000"/>
> I have narrowed down the thread that hangs. Or at least tried, my first time to study thread dumps. PID for thread that is jammed is 22599 => 0x5847 as hex and it points to the thread end of this description. I attach the actual thread dumps to this ticket. Any workaround for this is preciated, we currently need to reboot the servers when the Wildfly hangs (almost every nigth).
> "default task-20" #285 prio=5 os_prio=0 tid=0x00007f862c328800 nid=0x5847 runnable [0x00007f85f5ad6000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
> at sun.nio.ch.IOUtil.read(IOUtil.java:192)
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
> - locked <0x00000006f6065210> (a java.lang.Object)
> at org.xnio.nio.NioSocketConduit.read(NioSocketConduit.java:282)
> at org.xnio.ssl.JsseSslConduitEngine.handleUnwrapResult(JsseSslConduitEngine.java:737)
> - locked <0x00000006f606b708> (a org.xnio.ByteBufferSlicePool$PooledByteBuffer)
> at org.xnio.ssl.JsseSslConduitEngine.unwrap(JsseSslConduitEngine.java:620)
> - locked <0x00000006f606b708> (a org.xnio.ByteBufferSlicePool$PooledByteBuffer)
> at org.xnio.ssl.JsseSslConduitEngine.unwrap(JsseSslConduitEngine.java:574)
> at org.xnio.ssl.JsseSslStreamSourceConduit.read(JsseSslStreamSourceConduit.java:89)
> at org.xnio.conduits.AbstractStreamSourceConduit.read(AbstractStreamSourceConduit.java:51)
> at io.undertow.conduits.ReadDataStreamSourceConduit.read(ReadDataStreamSourceConduit.java:67)
> at io.undertow.conduits.FixedLengthStreamSourceConduit.read(FixedLengthStreamSourceConduit.java:249)
> at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127)
> at io.undertow.channels.DetachableStreamSourceChannel.read(DetachableStreamSourceChannel.java:209)
> at io.undertow.server.HttpServerExchange$ReadDispatchChannel.read(HttpServerExchange.java:2136)
> at io.undertow.server.handlers.form.FormEncodedDataDefinition$FormEncodedDataParser.doParse(FormEncodedDataDefinition.java:133)
> at io.undertow.server.handlers.form.FormEncodedDataDefinition$FormEncodedDataParser.parseBlocking(FormEncodedDataDefinition.java:251)
> at io.undertow.servlet.spec.HttpServletRequestImpl.parseFormData(HttpServletRequestImpl.java:753)
> at io.undertow.servlet.spec.HttpServletRequestImpl.getParameter(HttpServletRequestImpl.java:627)
> at org.apache.myfaces.context.servlet.RequestParameterMap.getAttribute(RequestParameterMap.java:45)
> at org.apache.myfaces.context.servlet.RequestParameterMap.getAttribute(RequestParameterMap.java:33)
> at org.apache.myfaces.util.AbstractAttributeMap.containsKey(AbstractAttributeMap.java:62)
> at org.apache.myfaces.renderkit.html.HtmlResponseStateManager.isPostback(HtmlResponseStateManager.java:303)
> at org.apache.myfaces.lifecycle.DefaultRestoreViewSupport.isPostback(DefaultRestoreViewSupport.java:242)
> at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:120)
> at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:170)
> at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:197)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
> at fi.elbit.skills.loginview.DefaultsFilter.doFilter(DefaultsFilter.java:117)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:357)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> 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:51)
> 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:56)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> 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 io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> 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)
> Locked ownable synchronizers:
> - <0x00000006f20bb6c8> (a java.util.concurrent.ThreadPoolExecutor$Worker)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 months
[JBoss JIRA] (WFLY-5727) After day or two Wildfly hangs and consumes 100% CPU
by Samuel Ferreira (JIRA)
[ https://issues.jboss.org/browse/WFLY-5727?page=com.atlassian.jira.plugin.... ]
Samuel Ferreira commented on WFLY-5727:
---------------------------------------
I'm seeing something like described here and XNIO-244 in Wildfly 8.2.1. I'll also test with the {{read-timeout}} in the {{https-listener}} and see if it helps.
[~swd847] Can you update the fixVersion? Tks.
> After day or two Wildfly hangs and consumes 100% CPU
> ----------------------------------------------------
>
> Key: WFLY-5727
> URL: https://issues.jboss.org/browse/WFLY-5727
> Project: WildFly
> Issue Type: Bug
> Components: IO, Web (Undertow)
> Affects Versions: 8.2.0.Final, 9.0.1.Final
> Environment: Wildfly 9.01 Final, Wildfly 8.2
> CentOS Linux release 7.1.1503 (Core)
> java version "1.8.0_66"
> Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)
> Reporter: Petri Tuomaala
> Assignee: Stuart Douglas
> Priority: Blocker
> Labels: Linux, io, ssl, undertow, wildfly, xnio
> Fix For: 9.x.x TBD
>
> Attachments: jstack.22263.102919.280420771, jstack.22263.102925.032513958, jstack.22263.102930.660792783, jstack.22263.102936.697001192, jstack.22263.102942.535009068, jstack.22263.102948.169314576, jstack.22263.102954.185475598, jstack.22263.102959.848031929, jstack.22263.103005.599986837, jstack.22263.103011.261542540, monitor.png, pid.png
>
>
> First disclaimer, this looks pointing to undertow/xnio but I am not sure for the root cause so I'm filing this for Wildfly.
> After a day or two Wildfly just hangs and consumes the cpu. We have noticed that the site traffic itself has no impact on this: it has happened during peak traffic and also almost in idle situations.
> We are handling SSL in Wildfly and example this https://issues.jboss.org/browse/UNDERTOW-282 looks similar to this but it has been resolved over year ago so it should be in Wildfly 9.01.
> Our SSL conf in standalone.xml:
> <https-listener name="https" socket-binding="https" security-realm="UndertowRealm" enabled-cipher-suites="TLS_DHE_DSS_WITH_AES_128_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA" max-parameters="5000"/>
> I have narrowed down the thread that hangs. Or at least tried, my first time to study thread dumps. PID for thread that is jammed is 22599 => 0x5847 as hex and it points to the thread end of this description. I attach the actual thread dumps to this ticket. Any workaround for this is preciated, we currently need to reboot the servers when the Wildfly hangs (almost every nigth).
> "default task-20" #285 prio=5 os_prio=0 tid=0x00007f862c328800 nid=0x5847 runnable [0x00007f85f5ad6000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
> at sun.nio.ch.IOUtil.read(IOUtil.java:192)
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
> - locked <0x00000006f6065210> (a java.lang.Object)
> at org.xnio.nio.NioSocketConduit.read(NioSocketConduit.java:282)
> at org.xnio.ssl.JsseSslConduitEngine.handleUnwrapResult(JsseSslConduitEngine.java:737)
> - locked <0x00000006f606b708> (a org.xnio.ByteBufferSlicePool$PooledByteBuffer)
> at org.xnio.ssl.JsseSslConduitEngine.unwrap(JsseSslConduitEngine.java:620)
> - locked <0x00000006f606b708> (a org.xnio.ByteBufferSlicePool$PooledByteBuffer)
> at org.xnio.ssl.JsseSslConduitEngine.unwrap(JsseSslConduitEngine.java:574)
> at org.xnio.ssl.JsseSslStreamSourceConduit.read(JsseSslStreamSourceConduit.java:89)
> at org.xnio.conduits.AbstractStreamSourceConduit.read(AbstractStreamSourceConduit.java:51)
> at io.undertow.conduits.ReadDataStreamSourceConduit.read(ReadDataStreamSourceConduit.java:67)
> at io.undertow.conduits.FixedLengthStreamSourceConduit.read(FixedLengthStreamSourceConduit.java:249)
> at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127)
> at io.undertow.channels.DetachableStreamSourceChannel.read(DetachableStreamSourceChannel.java:209)
> at io.undertow.server.HttpServerExchange$ReadDispatchChannel.read(HttpServerExchange.java:2136)
> at io.undertow.server.handlers.form.FormEncodedDataDefinition$FormEncodedDataParser.doParse(FormEncodedDataDefinition.java:133)
> at io.undertow.server.handlers.form.FormEncodedDataDefinition$FormEncodedDataParser.parseBlocking(FormEncodedDataDefinition.java:251)
> at io.undertow.servlet.spec.HttpServletRequestImpl.parseFormData(HttpServletRequestImpl.java:753)
> at io.undertow.servlet.spec.HttpServletRequestImpl.getParameter(HttpServletRequestImpl.java:627)
> at org.apache.myfaces.context.servlet.RequestParameterMap.getAttribute(RequestParameterMap.java:45)
> at org.apache.myfaces.context.servlet.RequestParameterMap.getAttribute(RequestParameterMap.java:33)
> at org.apache.myfaces.util.AbstractAttributeMap.containsKey(AbstractAttributeMap.java:62)
> at org.apache.myfaces.renderkit.html.HtmlResponseStateManager.isPostback(HtmlResponseStateManager.java:303)
> at org.apache.myfaces.lifecycle.DefaultRestoreViewSupport.isPostback(DefaultRestoreViewSupport.java:242)
> at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:120)
> at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:170)
> at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:197)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
> at fi.elbit.skills.loginview.DefaultsFilter.doFilter(DefaultsFilter.java:117)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:357)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> 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:51)
> 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:56)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> 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 io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> 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)
> Locked ownable synchronizers:
> - <0x00000006f20bb6c8> (a java.util.concurrent.ThreadPoolExecutor$Worker)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 months
[JBoss JIRA] (DROOLS-1632) Warning "Getter overloaded" is sometimes inaccurate
by Geoffrey De Smet (JIRA)
Geoffrey De Smet created DROOLS-1632:
----------------------------------------
Summary: Warning "Getter overloaded" is sometimes inaccurate
Key: DROOLS-1632
URL: https://issues.jboss.org/browse/DROOLS-1632
Project: Drools
Issue Type: Enhancement
Components: core engine
Reporter: Geoffrey De Smet
Assignee: Mario Fusco
Priority: Minor
A user got this warning:
{code}
Getter overloading detected in class mypackage.MyClass : getId (class java.lang.Object) vs getId (class java.lang.Long)
{code}
The warning happened for a case with 2 methods that are NOT overloaded:
* Object getId() {...}
* Long getId() {...}
Methods are only overloaded if they have the same name and a different parameter list.
In this case they might be overwritten (if the first one is from a parent class). Or the user somehow managed to circumvent the JLS (unlikely).
1) The error message should be accurate. Don't use "overloaded " when "overwritten".
2) The error message should mention the declaring class for every method, so it's easier to recognize class hierachy's involvement. So "MyClass.getId()" or "Parent.getId()" instead of just "getId".
3) The error message should not put the return type between braces after the method name as that makes it look like a paremeter. Use "getId() returns java.lang.object" instead of "getId (class java.lang.Object)"
Full user's case:
https://stackoverflow.com/questions/44723889/drools-claims-that-method-wa...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 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 6/24/17 12:36 PM:
-----------------------------------------------------------------------
Just one further note.
The stack traces above for wildfly were taken using Wildfly 10.0.0.Final.
I am not using 10.1.0.Final for this.
The reason being that using 10.1.0.Final implies more time investiment in verifying application compatibility with the newest release.
So for now, unless some must have features exist on 10.1.0.Final, or unless 10.1.0.Final is pure bug fix release, the intention would ideally be to keep using 10.0.0.Final for a while.
Or would you say that 10.1.0.Final should be just as stable as 10.0.0.Final?
E.g. additional bugfixes and no breaking changes on previosuly existing APIs?
Kindest regards.
was (Author: nuno.godinhomatos):
The stack traces on wildfly were taken using wildfly 10.0.0.Final.
I am not using 10.1.0.Final, because right now because to be using 10.1.0.Final requires more time investiment in verify application compatibility with the newest released. So for now, unless some must have features exist on 10.1.0.Final, the intention is to keep using 10.0.0.Final for a while.
Or would you say that 10.1.0.Final should be as stable as 10.0.0.Final? E.g. more bugfixes in there and no breaking changes?
Kindest regards.
> 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, 12 months