[JBoss JIRA] (WFLY-2641) ARQ upgrade likely to cause test failures
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-2641?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-2641:
-------------------------------
Fix Version/s: 9.0.0.CR1
(was: 8.0.0.Final)
> ARQ upgrade likely to cause test failures
> ------------------------------------------
>
> Key: WFLY-2641
> URL: https://issues.jboss.org/browse/WFLY-2641
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Thomas Diesler
> Assignee: Aslak Knutsen
> Priority: Blocker
> Fix For: 9.0.0.CR1
>
>
> {code}
> testSimpleBundleWithWabExtension(org.jboss.test.osgi.example.webapp.WebAppTestCase) Time elapsed: 0.028 sec <<< ERROR!
> java.lang.NullPointerException: null
> at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:290)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (WFLY-2854) '**' role incorrectly returns false from isUserInRole when user is authenticated
by arjan tijms (JIRA)
[ https://issues.jboss.org/browse/WFLY-2854?page=com.atlassian.jira.plugin.... ]
arjan tijms updated WFLY-2854:
------------------------------
Description:
When authentication has taken place in a web application such that {{HttpServletRequest#getUserPrincipal}} does not return null, testing for role '**' using {{HttpServletRequest#isUserInRole}} returns false.
This is not correct. According to Servlet 13.3:
{quote}
{noformat}
If the role-name of the security-role to be tested is “**”,
and the application has NOT declared an application security-role with
role-name “**”, isUserInRole must only return true if the user has been
authenticated;
{noformat}
{quote}
This is demonstrated by the following test:
https://github.com/arjantijms/javaee7-samples/blob/master/jacc/contexts/s...
was:
When authentication has taken place in a web application such that {{HttpServletRequest#getUserprincipap}} does not return null, testing for role '**' using {{HttpServletRequest#isUserInRole}} returns false.
This is not correct. According to Servlet 13.3:
{quote}
{noformat}
If the role-name of the security-role to be tested is “**”,
and the application has NOT declared an application security-role with
role-name “**”, isUserInRole must only return true if the user has been
authenticated;
{noformat}
{quote}
This is demonstrated by the following test:
https://github.com/arjantijms/javaee7-samples/blob/master/jacc/contexts/s...
> '**' role incorrectly returns false from isUserInRole when user is authenticated
> --------------------------------------------------------------------------------
>
> Key: WFLY-2854
> URL: https://issues.jboss.org/browse/WFLY-2854
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Security
> Affects Versions: 8.0.0.CR1
> Reporter: arjan tijms
> Assignee: Darran Lofthouse
> Labels: role, roles, security, servlet
>
> When authentication has taken place in a web application such that {{HttpServletRequest#getUserPrincipal}} does not return null, testing for role '**' using {{HttpServletRequest#isUserInRole}} returns false.
> This is not correct. According to Servlet 13.3:
> {quote}
> {noformat}
> If the role-name of the security-role to be tested is “**”,
> and the application has NOT declared an application security-role with
> role-name “**”, isUserInRole must only return true if the user has been
> authenticated;
> {noformat}
> {quote}
> This is demonstrated by the following test:
> https://github.com/arjantijms/javaee7-samples/blob/master/jacc/contexts/s...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (WFLY-2854) '**' role incorrectly returns false from isUserInRole when user is authenticated
by arjan tijms (JIRA)
arjan tijms created WFLY-2854:
---------------------------------
Summary: '**' role incorrectly returns false from isUserInRole when user is authenticated
Key: WFLY-2854
URL: https://issues.jboss.org/browse/WFLY-2854
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: 8.0.0.CR1
Reporter: arjan tijms
Assignee: Darran Lofthouse
When authentication has taken place in a web application such that {{HttpServletRequest#getUserprincipap}} does not return null, testing for role '**' using {{HttpServletRequest#isUserInRole}} returns false.
This is not correct. According to Servlet 13.3:
{quote}
{noformat}
If the role-name of the security-role to be tested is “**”,
and the application has NOT declared an application security-role with
role-name “**”, isUserInRole must only return true if the user has been
authenticated;
{noformat}
{quote}
This is demonstrated by the following test:
https://github.com/arjantijms/javaee7-samples/blob/master/jacc/contexts/s...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (JGRP-1789) Fix host binding of tests involving GossipRouter
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1789?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1789:
-------------------------------------------
It also would not hurt to print out the actual bind address and port used to start the GossipRouter in the test. Aids debugging.
> Fix host binding of tests involving GossipRouter
> ------------------------------------------------
>
> Key: JGRP-1789
> URL: https://issues.jboss.org/browse/JGRP-1789
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: Windows
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
>
> Tests like TUNNEL_Test, TUNNELDeadlockTest, and GossipRouterTest make use of the following:
> - a GosspiRouter which binds to a certain host address and port
> - a GossipRouter client whose TUNNEL protocol binds to a certain host address and port
> - a property gossip_router_hosts which specifies the gossip router hosts the client can connect to
> If these bind addresses are not specified, we often get test failures involving an inability of the client to communicate with the GossipRouter, due to each not having the other's correct address, or one being on local host and the other on a non-localhost interface:
> {noformat}
> ------------- startRouter -----------
> -- starting GossipRouter on 127.0.0.1[23003]
> ------------- testConnectThree -----------
> -------------------------------------------------------------------
> GMS: address=B, cluster=TUNNEL_Test, physical address=192.168.5.141:61373
> -------------------------------------------------------------------
> 605382 [WARN] TUNNEL: - Failed connecting to GossipRouter at /127.0.0.1:23003
> 605383 [WARN] TUNNEL: - failed reconnecting stub to GR at /127.0.0.1:23003: java.lang.Exception: Could not connect to /127.0.0.1:23003
> 605383 [ERROR] TUNNEL: - failed sending message to cluster (94 bytes): java.lang.Exception: None of the available stubs [RouterStub[localsocket=/192.168.5.141:51802,router_host=127.0.0.1::23003,connected=false]] accepted a multicast message, cause: null
> {noformat}
> TUNNEL_Test and GossipRouterTest are failing on Windows, for example, due to this sort of issue.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (WFLY-2838) Revisit default mod_cluster metric for WildFly 8
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-2838?page=com.atlassian.jira.plugin.... ]
Jason Greene commented on WFLY-2838:
------------------------------------
I think its hard to determine based on number of requests because it all depends on how heavy the user code is in the context of a request.
CPU time is a pretty good value to use IMO. We could still have a watermark that the user could override. Alternatively it could get fancier and calculate the amount of CPU time used by the I/O threads and the worker pool saturation. That would require deeper OS integration and more work than we have time left.
> Revisit default mod_cluster metric for WildFly 8
> ------------------------------------------------
>
> Key: WFLY-2838
> URL: https://issues.jboss.org/browse/WFLY-2838
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.CR1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Blocker
> Fix For: 8.0.0.Final
>
>
> Since the threading aspects of Undertow in WildFly are completely different from JBoss Web's in the previous versions of AS, we should reconsider the default metric for WildFly.
> Currently, busyness requires explicit capacity to be useful which would require further tweaking by users.
> Metric "cpu" is also a good candidate since it doesn't need explicit capacity..
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (JGRP-1789) Fix host binding of tests involving GossipRouter
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1789?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz updated JGRP-1789:
--------------------------------------
Description:
Tests like TUNNEL_Test, TUNNELDeadlockTest, and GossipRouterTest make use of the following:
- a GosspiRouter which binds to a certain host address and port
- a GossipRouter client whose TUNNEL protocol binds to a certain host address and port
- a property gossip_router_hosts which specifies the gossip router hosts the client can connect to
If these bind addresses are not specified, we often get test failures involving an inability of the client to communicate with the GossipRouter, due to each not having the other's correct address, or one being on local host and the other on a non-localhost interface:
{noformat}
------------- startRouter -----------
-- starting GossipRouter on 127.0.0.1[23003]
------------- testConnectThree -----------
-------------------------------------------------------------------
GMS: address=B, cluster=TUNNEL_Test, physical address=192.168.5.141:61373
-------------------------------------------------------------------
605382 [WARN] TUNNEL: - Failed connecting to GossipRouter at /127.0.0.1:23003
605383 [WARN] TUNNEL: - failed reconnecting stub to GR at /127.0.0.1:23003: java.lang.Exception: Could not connect to /127.0.0.1:23003
605383 [ERROR] TUNNEL: - failed sending message to cluster (94 bytes): java.lang.Exception: None of the available stubs [RouterStub[localsocket=/192.168.5.141:51802,router_host=127.0.0.1::23003,connected=false]] accepted a multicast message, cause: null
{noformat}
TUNNEL_Test and GossipRouterTest are failing on Windows, for example, due to this sort of issue.
was:
Tests like TUNNEL_Test, TUNNELDeadlockTest, and GossipRouterTest make use of the following:
- a GosspiRouter which binds to a certain host address and port
- a GossipRouter client whose TUNNEL protocol binds to a certain host address and port
If these bind addresses are not specified, we often get test failures involving an inability of the client to communicate with the GossipRouter, due to each not having the other's correct address, or one being on local host and the other on a non-localhost interface:
{noformat}
------------- startRouter -----------
-- starting GossipRouter on 127.0.0.1[23003]
------------- testConnectThree -----------
-------------------------------------------------------------------
GMS: address=B, cluster=TUNNEL_Test, physical address=192.168.5.141:61373
-------------------------------------------------------------------
605382 [WARN] TUNNEL: - Failed connecting to GossipRouter at /127.0.0.1:23003
605383 [WARN] TUNNEL: - failed reconnecting stub to GR at /127.0.0.1:23003: java.lang.Exception: Could not connect to /127.0.0.1:23003
605383 [ERROR] TUNNEL: - failed sending message to cluster (94 bytes): java.lang.Exception: None of the available stubs [RouterStub[localsocket=/192.168.5.141:51802,router_host=127.0.0.1::23003,connected=false]] accepted a multicast message, cause: null
{noformat}
TUNNEL_Test and GossipRouterTest are failing on Windows, for example, due to this sort of issue.
> Fix host binding of tests involving GossipRouter
> ------------------------------------------------
>
> Key: JGRP-1789
> URL: https://issues.jboss.org/browse/JGRP-1789
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: Windows
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
>
> Tests like TUNNEL_Test, TUNNELDeadlockTest, and GossipRouterTest make use of the following:
> - a GosspiRouter which binds to a certain host address and port
> - a GossipRouter client whose TUNNEL protocol binds to a certain host address and port
> - a property gossip_router_hosts which specifies the gossip router hosts the client can connect to
> If these bind addresses are not specified, we often get test failures involving an inability of the client to communicate with the GossipRouter, due to each not having the other's correct address, or one being on local host and the other on a non-localhost interface:
> {noformat}
> ------------- startRouter -----------
> -- starting GossipRouter on 127.0.0.1[23003]
> ------------- testConnectThree -----------
> -------------------------------------------------------------------
> GMS: address=B, cluster=TUNNEL_Test, physical address=192.168.5.141:61373
> -------------------------------------------------------------------
> 605382 [WARN] TUNNEL: - Failed connecting to GossipRouter at /127.0.0.1:23003
> 605383 [WARN] TUNNEL: - failed reconnecting stub to GR at /127.0.0.1:23003: java.lang.Exception: Could not connect to /127.0.0.1:23003
> 605383 [ERROR] TUNNEL: - failed sending message to cluster (94 bytes): java.lang.Exception: None of the available stubs [RouterStub[localsocket=/192.168.5.141:51802,router_host=127.0.0.1::23003,connected=false]] accepted a multicast message, cause: null
> {noformat}
> TUNNEL_Test and GossipRouterTest are failing on Windows, for example, due to this sort of issue.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (JGRP-1789) Fix host binding of tests involving GossipRouter
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1789?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz updated JGRP-1789:
--------------------------------------
Description:
Tests like TUNNEL_Test, TUNNELDeadlockTest, and GossipRouterTest make use of the following:
- a GosspiRouter which binds to a certain host address and port
- a GossipRouter client whose TUNNEL protocol binds to a certain host address and port
If these bind addresses are not specified, we often get test failures involving an inability of the client to communicate with the GossipRouter, due to each not having the other's correct address, or one being on local host and the other on a non-localhost interface:
{noformat}
------------- startRouter -----------
-- starting GossipRouter on 127.0.0.1[23003]
------------- testConnectThree -----------
-------------------------------------------------------------------
GMS: address=B, cluster=TUNNEL_Test, physical address=192.168.5.141:61373
-------------------------------------------------------------------
605382 [WARN] TUNNEL: - Failed connecting to GossipRouter at /127.0.0.1:23003
605383 [WARN] TUNNEL: - failed reconnecting stub to GR at /127.0.0.1:23003: java.lang.Exception: Could not connect to /127.0.0.1:23003
605383 [ERROR] TUNNEL: - failed sending message to cluster (94 bytes): java.lang.Exception: None of the available stubs [RouterStub[localsocket=/192.168.5.141:51802,router_host=127.0.0.1::23003,connected=false]] accepted a multicast message, cause: null
{noformat}
TUNNEL_Test and GossipRouterTest are failing on Windows, for example, due to this sort of issue.
was:
Tests like TUNNEL_Test and GossipRouterTest make use of the following:
- a GosspiRouter which binds to a certain host address and port
- a GossipRouter client whose TUNNEL protocol binds to a certain host address and port
If these bind addresses are not specified, we often get test failures involving an inability of the client to communicate with the GossipRouter, due to each not having the other's correct address, or one being on local host and the other on a non-localhost interface:
{noformat}
------------- startRouter -----------
-- starting GossipRouter on 127.0.0.1[23003]
------------- testConnectThree -----------
-------------------------------------------------------------------
GMS: address=B, cluster=TUNNEL_Test, physical address=192.168.5.141:61373
-------------------------------------------------------------------
605382 [WARN] TUNNEL: - Failed connecting to GossipRouter at /127.0.0.1:23003
605383 [WARN] TUNNEL: - failed reconnecting stub to GR at /127.0.0.1:23003: java.lang.Exception: Could not connect to /127.0.0.1:23003
605383 [ERROR] TUNNEL: - failed sending message to cluster (94 bytes): java.lang.Exception: None of the available stubs [RouterStub[localsocket=/192.168.5.141:51802,router_host=127.0.0.1::23003,connected=false]] accepted a multicast message, cause: null
{noformat}
TUNNEL_Test and GossipRouterTest are failing on Windows, for example, due to this sort of issue.
> Fix host binding of tests involving GossipRouter
> ------------------------------------------------
>
> Key: JGRP-1789
> URL: https://issues.jboss.org/browse/JGRP-1789
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: Windows
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
>
> Tests like TUNNEL_Test, TUNNELDeadlockTest, and GossipRouterTest make use of the following:
> - a GosspiRouter which binds to a certain host address and port
> - a GossipRouter client whose TUNNEL protocol binds to a certain host address and port
> If these bind addresses are not specified, we often get test failures involving an inability of the client to communicate with the GossipRouter, due to each not having the other's correct address, or one being on local host and the other on a non-localhost interface:
> {noformat}
> ------------- startRouter -----------
> -- starting GossipRouter on 127.0.0.1[23003]
> ------------- testConnectThree -----------
> -------------------------------------------------------------------
> GMS: address=B, cluster=TUNNEL_Test, physical address=192.168.5.141:61373
> -------------------------------------------------------------------
> 605382 [WARN] TUNNEL: - Failed connecting to GossipRouter at /127.0.0.1:23003
> 605383 [WARN] TUNNEL: - failed reconnecting stub to GR at /127.0.0.1:23003: java.lang.Exception: Could not connect to /127.0.0.1:23003
> 605383 [ERROR] TUNNEL: - failed sending message to cluster (94 bytes): java.lang.Exception: None of the available stubs [RouterStub[localsocket=/192.168.5.141:51802,router_host=127.0.0.1::23003,connected=false]] accepted a multicast message, cause: null
> {noformat}
> TUNNEL_Test and GossipRouterTest are failing on Windows, for example, due to this sort of issue.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months