[JBoss JIRA] (ELY-1423) Elytron/Remoting/EJB - Exception from failed authentication differs depending on previous calls
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1423?page=com.atlassian.jira.plugin.s... ]
Jan Kalina closed ELY-1423.
---------------------------
Resolution: Rejected
No change in elytron needed.
> Elytron/Remoting/EJB - Exception from failed authentication differs depending on previous calls
> -----------------------------------------------------------------------------------------------
>
> Key: ELY-1423
> URL: https://issues.jboss.org/browse/ELY-1423
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Client
> Affects Versions: 1.2.0.Beta8
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Critical
>
> Exception presented to a client when EJB authentication fails should be the same for first authentication and subsequent authentications.
> I have following scenario:
> {noformat}
> EJB Client -> EntryBean (server1) -> WhoAmIBean (server2)
> {noformat}
> the Client provides correct credentials to server 1 and EntryBean makes reauthentication to server2.
> When I use wrong credentials for server2 in EntryBean, the call fails with:
> {noformat}
> org.jboss.ejb.client.RequestSendFailedException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> {noformat}
> When I run the scenario twice and use a correct credentials in EntryBean first and wrong in the second run, then the Exception is different:
> {noformat}
> org.jboss.ejb.client.RequestSendFailedException: org.wildfly.security.auth.AuthenticationException: JBREM000308: Authentication failed (no mechanisms left)
> {noformat}
> From a client POV the exception should be the same in every call:
> * to allow safer exception handling in client code
> * to avoid disclosure shared connection details
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3539) Flunky controller tests on Windows: Address already in use
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3539?page=com.atlassian.jira.plugi... ]
Jan Kalina updated WFCORE-3539:
-------------------------------
Comment: was deleted
(was: By debug output port is closed correctly by application - it looks windows just does not release it for new use fast enough.
Will resolve by using different ports by different tests.)
> Flunky controller tests on Windows: Address already in use
> ----------------------------------------------------------
>
> Key: WFCORE-3539
> URL: https://issues.jboss.org/browse/WFCORE-3539
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 4.0.0.Alpha6
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> Following combination of tests will fail *sometimes* on "Address already in use: bind" on windows:
> {code}
> mvn test -Dtest=org.jboss.as.controller.test.RemoteChannelProxyControllerTestCase,org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> {code}
> {code}
> [Step 2/3] org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testSequentialGroup
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testCancelBeforePrepared
> [21:41:55][testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> [21:41:55]
> [testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> at sun.nio.ch.Net.bind0(Native Method)
> at sun.nio.ch.Net.bind(Net.java:433)
> at sun.nio.ch.Net.bind(Net.java:425)
> at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
> at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:181)
> at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310)
> at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:372)
> at org.jboss.as.controller.support.ChannelServer.create(ChannelServer.java:93)
> at org.jboss.as.controller.test.TransactionalProtocolClientTestCase.startChannelServer(TransactionalProtocolClientTestCase.java:108)
> {code}
> This happens pretty often on windows CI:
> https://ci.wildfly.org/project.html?projectId=WildFlyCore_PullRequest&tes...
> But it is sufficient to run combination of tests above on Windows to reproduce.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3539) Flunky controller tests on Windows: Address already in use
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3539?page=com.atlassian.jira.plugi... ]
Jan Kalina commented on WFCORE-3539:
------------------------------------
[~brian.stansberry] ok, would not be using different ports by different tests better solution? (it would remove extra time needed for waiting for port releasing)
> Flunky controller tests on Windows: Address already in use
> ----------------------------------------------------------
>
> Key: WFCORE-3539
> URL: https://issues.jboss.org/browse/WFCORE-3539
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 4.0.0.Alpha6
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> Following combination of tests will fail *sometimes* on "Address already in use: bind" on windows:
> {code}
> mvn test -Dtest=org.jboss.as.controller.test.RemoteChannelProxyControllerTestCase,org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> {code}
> {code}
> [Step 2/3] org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testSequentialGroup
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testCancelBeforePrepared
> [21:41:55][testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> [21:41:55]
> [testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> at sun.nio.ch.Net.bind0(Native Method)
> at sun.nio.ch.Net.bind(Net.java:433)
> at sun.nio.ch.Net.bind(Net.java:425)
> at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
> at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:181)
> at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310)
> at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:372)
> at org.jboss.as.controller.support.ChannelServer.create(ChannelServer.java:93)
> at org.jboss.as.controller.test.TransactionalProtocolClientTestCase.startChannelServer(TransactionalProtocolClientTestCase.java:108)
> {code}
> This happens pretty often on windows CI:
> https://ci.wildfly.org/project.html?projectId=WildFlyCore_PullRequest&tes...
> But it is sufficient to run combination of tests above on Windows to reproduce.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3539) Flunky controller tests on Windows: Address already in use
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3539?page=com.atlassian.jira.plugi... ]
Jan Kalina commented on WFCORE-3539:
------------------------------------
By debug output port is closed correctly by application - it looks windows just does not release it for new use fast enough.
Will resolve by using different ports by different tests.
> Flunky controller tests on Windows: Address already in use
> ----------------------------------------------------------
>
> Key: WFCORE-3539
> URL: https://issues.jboss.org/browse/WFCORE-3539
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 4.0.0.Alpha6
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> Following combination of tests will fail *sometimes* on "Address already in use: bind" on windows:
> {code}
> mvn test -Dtest=org.jboss.as.controller.test.RemoteChannelProxyControllerTestCase,org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> {code}
> {code}
> [Step 2/3] org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testSequentialGroup
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testCancelBeforePrepared
> [21:41:55][testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> [21:41:55]
> [testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> at sun.nio.ch.Net.bind0(Native Method)
> at sun.nio.ch.Net.bind(Net.java:433)
> at sun.nio.ch.Net.bind(Net.java:425)
> at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
> at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:181)
> at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310)
> at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:372)
> at org.jboss.as.controller.support.ChannelServer.create(ChannelServer.java:93)
> at org.jboss.as.controller.test.TransactionalProtocolClientTestCase.startChannelServer(TransactionalProtocolClientTestCase.java:108)
> {code}
> This happens pretty often on windows CI:
> https://ci.wildfly.org/project.html?projectId=WildFlyCore_PullRequest&tes...
> But it is sufficient to run combination of tests above on Windows to reproduce.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3531) EnumValidator.validateParameter should check toStringMap first to reduce the times of IllegalArgumentException creation
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3531?page=com.atlassian.jira.plugi... ]
Brad Maxwell updated WFCORE-3531:
---------------------------------
Labels: downstream_dependency performace performance (was: downstream_dependency performace)
> EnumValidator.validateParameter should check toStringMap first to reduce the times of IllegalArgumentException creation
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3531
> URL: https://issues.jboss.org/browse/WFCORE-3531
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management, JMX
> Environment: JBoss EAP 6.4.16,6.4.18
> Reporter: Lin Gao
> Assignee: Lin Gao
> Labels: downstream_dependency, performace, performance
> Fix For: 4.0.0.Alpha7
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> {panel:title=Description of downstream issue}
> Enum is misspelled causing java.lang.IllegalArgumentException
> What is the nature and description of the request?
> Enum is misspelled causing java.lang.IllegalArgumentException
> How would the customer like to achieve this? (List the functional requirements here)
> In such way, it should not throw Exception and spelled correctly.
> ENUM : "ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS"
> Location Where Enum is Used :
> jboss-as-jmx module:
> ./jmx/src/main/java/org/jboss/as/jmx/model/ResourceAccessControlUtil.java
> Code : op.get(ACCESS_CONTROL).set(ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS.toModelNode());
> it's a general internal jboss issue for all queries that somehow involve the JMX related ResourceAccessControlUtil.
> Stacktrace Attached.
> {panel}
> ----
> {panel:title=Description}
> +EnumValidator.validateParameter+ is now trying to call +Enum.valueOf()+ first and fall back to +toStringMap.get(tuString)+ on +IllegalArgumentException+.
> However, +toStringMap+ contains necessary Enum values in most cases, so switch the way to get the +enumValue+ can reduce the times of IllegalArgumentException creation. And Exception creation may affect performance.
> {panel}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3531) EnumValidator.validateParameter should check toStringMap first to reduce the times of IllegalArgumentException creation
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3531?page=com.atlassian.jira.plugi... ]
Brad Maxwell updated WFCORE-3531:
---------------------------------
Description:
{panel:title=Description of downstream issue}
Enum is misspelled causing java.lang.IllegalArgumentException
What is the nature and description of the request?
Enum is misspelled causing java.lang.IllegalArgumentException
How would the customer like to achieve this? (List the functional requirements here)
In such way, it should not throw Exception and spelled correctly.
ENUM : "ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS"
Location Where Enum is Used :
jboss-as-jmx module:
./jmx/src/main/java/org/jboss/as/jmx/model/ResourceAccessControlUtil.java
Code : op.get(ACCESS_CONTROL).set(ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS.toModelNode());
it's a general internal jboss issue for all queries that somehow involve the JMX related ResourceAccessControlUtil.
Stacktrace Attached.
{panel}
----
{panel:title=Description}
+EnumValidator.validateParameter+ is now trying to call +Enum.valueOf()+ first and fall back to +toStringMap.get(tuString)+ on +IllegalArgumentException+.
However, +toStringMap+ contains necessary Enum values in most cases, so switch the way to get the +enumValue+ can reduce the times of IllegalArgumentException creation. And Exception creation may affect performance.
{panel}
was:
{panel:title=Description of downstream issue}
1. Proposed title of this feature request
Enum is misspelled causing java.lang.IllegalArgumentException
2. Who is the customer behind the request?
Account: Hamburg Südamerikanische Dampfschifffahrts-Ge, 5651756
3. What is the nature and description of the request?
Enum is misspelled causing java.lang.IllegalArgumentException
5. How would the customer like to achieve this? (List the functional requirements here)
In such way, it should not throw Exception and spelled correctly.
ENUM : "ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS"
Location Where Enum is Used :
jboss-as-jmx module:
./jmx/src/main/java/org/jboss/as/jmx/model/ResourceAccessControlUtil.java
Code : op.get(ACCESS_CONTROL).set(ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS.toModelNode());
it's a general internal jboss issue for all queries that somehow involve the JMX related ResourceAccessControlUtil.
Stacktrace Attached.
{panel}
----
{panel:title=Description}
+EnumValidator.validateParameter+ is now trying to call +Enum.valueOf()+ first and fall back to +toStringMap.get(tuString)+ on +IllegalArgumentException+.
However, +toStringMap+ contains necessary Enum values in most cases, so switch the way to get the +enumValue+ can reduce the times of IllegalArgumentException creation. And Exception creation may affect performance.
{panel}
> EnumValidator.validateParameter should check toStringMap first to reduce the times of IllegalArgumentException creation
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3531
> URL: https://issues.jboss.org/browse/WFCORE-3531
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management, JMX
> Environment: JBoss EAP 6.4.16,6.4.18
> Reporter: Lin Gao
> Assignee: Lin Gao
> Labels: downstream_dependency, performace
> Fix For: 4.0.0.Alpha7
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> {panel:title=Description of downstream issue}
> Enum is misspelled causing java.lang.IllegalArgumentException
> What is the nature and description of the request?
> Enum is misspelled causing java.lang.IllegalArgumentException
> How would the customer like to achieve this? (List the functional requirements here)
> In such way, it should not throw Exception and spelled correctly.
> ENUM : "ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS"
> Location Where Enum is Used :
> jboss-as-jmx module:
> ./jmx/src/main/java/org/jboss/as/jmx/model/ResourceAccessControlUtil.java
> Code : op.get(ACCESS_CONTROL).set(ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS.toModelNode());
> it's a general internal jboss issue for all queries that somehow involve the JMX related ResourceAccessControlUtil.
> Stacktrace Attached.
> {panel}
> ----
> {panel:title=Description}
> +EnumValidator.validateParameter+ is now trying to call +Enum.valueOf()+ first and fall back to +toStringMap.get(tuString)+ on +IllegalArgumentException+.
> However, +toStringMap+ contains necessary Enum values in most cases, so switch the way to get the +enumValue+ can reduce the times of IllegalArgumentException creation. And Exception creation may affect performance.
> {panel}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (DROOLS-2265) An option to enable strict conformance mode
by Edson Tirelli (JIRA)
Edson Tirelli created DROOLS-2265:
-------------------------------------
Summary: An option to enable strict conformance mode
Key: DROOLS-2265
URL: https://issues.jboss.org/browse/DROOLS-2265
Project: Drools
Issue Type: Enhancement
Components: dmn engine
Affects Versions: 7.5.0.Final
Reporter: Fedor Gavrilov
Assignee: Fedor Gavrilov
Fix For: 7.6.0.Final
Strict conformance mode should be enabled by default for tck profile or by using org.kie.dmn.strictConformance system property or kmodule property.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months