[JBoss JIRA] (ELY-1939) [GSS][7.2.2] HTTP External Security Not Supported by Elytron
by Ashley Abdel-Sayed (Jira)
Ashley Abdel-Sayed created ELY-1939:
---------------------------------------
Summary: [GSS][7.2.2] HTTP External Security Not Supported by Elytron
Key: ELY-1939
URL: https://issues.redhat.com/browse/ELY-1939
Project: WildFly Elytron
Issue Type: Feature Request
Affects Versions: 1.11.0.Final
Reporter: Ashley Abdel-Sayed
Assignee: Ashley Abdel-Sayed
For legacy security, there's an EXTERNAL HTTP authentication mechanism (io.undertow.security.impl.ExternalAuthenticationMechanism) which performs no verification and simply uses the principal that was passed from the REMOTE_USER attribute by the AJP protocol. There is a "ClientLoginModule" in legacy security used as such: https://access.redhat.com/solutions/3465231. It is a requirement to add an equivalent of this EXTERNAL mechanism available in legacy and Elytron-SASL for Elytron-HTTP in order to migrate away from legacy security.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFWIP-307) MP Fault Tolerance - unexpected behaviour @Fallback method calls with @CircuitBreaker
by Miroslav Novak (Jira)
[ https://issues.redhat.com/browse/WFWIP-307?page=com.atlassian.jira.plugin... ]
Miroslav Novak updated WFWIP-307:
---------------------------------
Description:
MP FT does not behave correctly in case when there is @CircuitBreaker, @Fallback, @Retry and @Asynchronous on service method. @CircuitBreaker does not get opened based on its configuration and @Fallback method is called with incorrect value.
Test scenario:
* Deploy MP FT service with:
{code}
@Asynchronous
@Retry(retryOn = IOException.class)
@CircuitBreaker(failOn = IOException.class, requestVolumeThreshold = 5, successThreshold = 3, delay = 2, delayUnit = ChronoUnit.SECONDS, failureRatio = 0.75)
@Fallback(fallbackMethod = "processFallback")
public CompletionStage<MyConnection> retryCircuitBreaker(int counter) throws IOException {
System.out.println("retryCircuitBreaker - called - " + counter);
if (counter % 4 != 0) { // 3/4 requests trigger IOException
System.out.println("retryCircuitBreaker - called - " + counter + " throwing exception");
throw new IOException("Simulated IOException");
}
System.out.println("retryCircuitBreaker - called - " + counter + " success");
return CompletableFuture.completedFuture(new MyConnection() {
@Override
public String getData() {
return "Hello from @Retry @CircuitBreaker method" + counter;
}
});
}
private CompletionStage<MyConnection> processFallback(int counter) {
System.out.println("processFallback - returned url counter: " + counter);
return CompletableFuture.completedFuture(new MyConnection() {
@Override
public String getData() {
return "Fallback Hello" + counter;
}
});
}
{code}
* Sends 16 parallel requests. Every 4th requests pass (including 0th one as there is modulo 4), and 12 invocations fail on IOException.
* Try on more request and check that @Fallback method was called as circuit is open
Expected result:
Circuit gets opened and @Fallback method is called.
Actual Result:
Circuit is not opened and @Fallback method is called.
was:
MP FT does behave correctly in case when there is @CircuitBreaker, @Fallback, @Retry and @Asynchronous on service method. @CircuitBreaker does not get opened based on its configuration and @Fallback method is called with incorrect value.
Test scenario:
* Deploy MP FT service with:
{code}
@Asynchronous
@Retry(retryOn = IOException.class)
@CircuitBreaker(failOn = IOException.class, requestVolumeThreshold = 5, successThreshold = 3, delay = 2, delayUnit = ChronoUnit.SECONDS, failureRatio = 0.75)
@Fallback(fallbackMethod = "processFallback")
public CompletionStage<MyConnection> retryCircuitBreaker(int counter) throws IOException {
System.out.println("retryCircuitBreaker - called - " + counter);
if (counter % 4 != 0) { // 3/4 requests trigger IOException
System.out.println("retryCircuitBreaker - called - " + counter + " throwing exception");
throw new IOException("Simulated IOException");
}
System.out.println("retryCircuitBreaker - called - " + counter + " success");
return CompletableFuture.completedFuture(new MyConnection() {
@Override
public String getData() {
return "Hello from @Retry @CircuitBreaker method" + counter;
}
});
}
private CompletionStage<MyConnection> processFallback(int counter) {
System.out.println("processFallback - returned url counter: " + counter);
return CompletableFuture.completedFuture(new MyConnection() {
@Override
public String getData() {
return "Fallback Hello" + counter;
}
});
}
{code}
* Sends 16 parallel requests. Every 4th requests pass (including 0th one as there is modulo 4), and 12 invocations fail on IOException.
* Try on more request and check that @Fallback method was called as circuit is open
Expected result:
Circuit gets opened and @Fallback method is called.
Actual Result:
Circuit is not opened and @Fallback method is called.
> MP Fault Tolerance - unexpected behaviour @Fallback method calls with @CircuitBreaker
> -------------------------------------------------------------------------------------
>
> Key: WFWIP-307
> URL: https://issues.redhat.com/browse/WFWIP-307
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Fault Tolerance
> Reporter: Miroslav Novak
> Assignee: Radoslav Husar
> Priority: Blocker
>
> MP FT does not behave correctly in case when there is @CircuitBreaker, @Fallback, @Retry and @Asynchronous on service method. @CircuitBreaker does not get opened based on its configuration and @Fallback method is called with incorrect value.
> Test scenario:
> * Deploy MP FT service with:
> {code}
> @Asynchronous
> @Retry(retryOn = IOException.class)
> @CircuitBreaker(failOn = IOException.class, requestVolumeThreshold = 5, successThreshold = 3, delay = 2, delayUnit = ChronoUnit.SECONDS, failureRatio = 0.75)
> @Fallback(fallbackMethod = "processFallback")
> public CompletionStage<MyConnection> retryCircuitBreaker(int counter) throws IOException {
> System.out.println("retryCircuitBreaker - called - " + counter);
> if (counter % 4 != 0) { // 3/4 requests trigger IOException
> System.out.println("retryCircuitBreaker - called - " + counter + " throwing exception");
> throw new IOException("Simulated IOException");
> }
> System.out.println("retryCircuitBreaker - called - " + counter + " success");
> return CompletableFuture.completedFuture(new MyConnection() {
> @Override
> public String getData() {
> return "Hello from @Retry @CircuitBreaker method" + counter;
> }
> });
> }
> private CompletionStage<MyConnection> processFallback(int counter) {
> System.out.println("processFallback - returned url counter: " + counter);
> return CompletableFuture.completedFuture(new MyConnection() {
> @Override
> public String getData() {
> return "Fallback Hello" + counter;
> }
> });
> }
> {code}
> * Sends 16 parallel requests. Every 4th requests pass (including 0th one as there is modulo 4), and 12 invocations fail on IOException.
> * Try on more request and check that @Fallback method was called as circuit is open
> Expected result:
> Circuit gets opened and @Fallback method is called.
> Actual Result:
> Circuit is not opened and @Fallback method is called.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFWIP-308) MP Fault Tolerance - unexpected behaviour @Fallback method calls with @Bulkhead
by Ondrej Kotek (Jira)
Ondrej Kotek created WFWIP-308:
----------------------------------
Summary: MP Fault Tolerance - unexpected behaviour @Fallback method calls with @Bulkhead
Key: WFWIP-308
URL: https://issues.redhat.com/browse/WFWIP-308
Project: WildFly WIP
Issue Type: Bug
Components: MP Fault Tolerance
Reporter: Ondrej Kotek
Assignee: Radoslav Husar
MP FT does behave correctly in case when there is {{@Bulkhead}}, {{@Timeout}} and {{@Fallback}} and {{@Asynchronous}} on service method. Some of requests do not go to fallback method but end with {{InterruptedException}}.
Test scenario:
- Deploy MP FT service with:
{noformat}
@Asynchronous
@Bulkhead(value = 15, waitingTaskQueue = 15)
@Timeout(value = 1000)
@Fallback(fallbackMethod = "processFallback")
public CompletionStage<MyConnection> bulkheadTimeout(boolean fail) throws InterruptedException {
if (fail) {
Thread.sleep(2000);
}
return CompletableFuture.completedFuture(new MyConnection() {
@Override
public String getData() {
return "Hello from @Bulkhead @Timeout method";
}
});
}
private CompletionStage<MyConnection> processFallback(boolean fail) {
return CompletableFuture.completedFuture(new MyConnection() {
@Override
public String getData() {
return "Fallback Hello";
}
});
}
{noformat}
- Send 10+ parallel requests with fail == true
Expected result:
All requests should go to fallback.
Actual Result:
Random number of requests (close to the number of requests) go to fallback.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFWIP-308) MP Fault Tolerance - unexpected behaviour @Fallback method calls with @Bulkhead
by Ondrej Kotek (Jira)
[ https://issues.redhat.com/browse/WFWIP-308?page=com.atlassian.jira.plugin... ]
Ondrej Kotek commented on WFWIP-308:
------------------------------------
CCing [~lthon]
> MP Fault Tolerance - unexpected behaviour @Fallback method calls with @Bulkhead
> -------------------------------------------------------------------------------
>
> Key: WFWIP-308
> URL: https://issues.redhat.com/browse/WFWIP-308
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Fault Tolerance
> Reporter: Ondrej Kotek
> Assignee: Radoslav Husar
> Priority: Blocker
>
> MP FT does behave correctly in case when there is {{@Bulkhead}}, {{@Timeout}} and {{@Fallback}} and {{@Asynchronous}} on service method. Some of requests do not go to fallback method but end with {{InterruptedException}}.
> Test scenario:
> - Deploy MP FT service with:
> {noformat}
> @Asynchronous
> @Bulkhead(value = 15, waitingTaskQueue = 15)
> @Timeout(value = 1000)
> @Fallback(fallbackMethod = "processFallback")
> public CompletionStage<MyConnection> bulkheadTimeout(boolean fail) throws InterruptedException {
> if (fail) {
> Thread.sleep(2000);
> }
> return CompletableFuture.completedFuture(new MyConnection() {
> @Override
> public String getData() {
> return "Hello from @Bulkhead @Timeout method";
> }
> });
> }
> private CompletionStage<MyConnection> processFallback(boolean fail) {
> return CompletableFuture.completedFuture(new MyConnection() {
> @Override
> public String getData() {
> return "Fallback Hello";
> }
> });
> }
> {noformat}
> - Send 10+ parallel requests with fail == true
> Expected result:
> All requests should go to fallback.
> Actual Result:
> Random number of requests (close to the number of requests) go to fallback.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFWIP-307) MP Fault Tolerance - unexpected behaviour @Fallback method calls with @CircuitBreaker
by Miroslav Novak (Jira)
[ https://issues.redhat.com/browse/WFWIP-307?page=com.atlassian.jira.plugin... ]
Miroslav Novak updated WFWIP-307:
---------------------------------
Description:
MP FT does behave correctly in case when there is @CircuitBreaker, @Fallback, @Retry and @Asynchronous on service method. @CircuitBreaker does not get opened based on its configuration and @Fallback method is called with incorrect value.
Test scenario:
* Deploy MP FT service with:
{code}
@Asynchronous
@Retry(retryOn = IOException.class)
@CircuitBreaker(failOn = IOException.class, requestVolumeThreshold = 5, successThreshold = 3, delay = 2, delayUnit = ChronoUnit.SECONDS, failureRatio = 0.75)
@Fallback(fallbackMethod = "processFallback")
public CompletionStage<MyConnection> retryCircuitBreaker(int counter) throws IOException {
System.out.println("retryCircuitBreaker - called - " + counter);
if (counter % 4 != 0) { // 3/4 requests trigger IOException
System.out.println("retryCircuitBreaker - called - " + counter + " throwing exception");
throw new IOException("Simulated IOException");
}
System.out.println("retryCircuitBreaker - called - " + counter + " success");
return CompletableFuture.completedFuture(new MyConnection() {
@Override
public String getData() {
return "Hello from @Retry @CircuitBreaker method" + counter;
}
});
}
private CompletionStage<MyConnection> processFallback(int counter) {
System.out.println("processFallback - returned url counter: " + counter);
return CompletableFuture.completedFuture(new MyConnection() {
@Override
public String getData() {
return "Fallback Hello" + counter;
}
});
}
{code}
* Sends 16 parallel requests. Every 4th requests pass (including 0th one as there is modulo 4), and 12 invocations fail on IOException.
* Try on more request and check that @Fallback method was called as circuit is open
Expected result:
Circuit gets opened and @Fallback method is called.
Actual Result:
Circuit is not opened and @Fallback method is called.
was:
MP FT does behave correctly in case when there is @CircuitBreaker, @Fallback, @Retry and @Asynchronous on service method. @CircuitBreaker does not get opened based on its configuration and @Fallback method is called with incorrect value.
Test scenario:
* Deploy MP FT service with:
{code}
@Asynchronous
@Retry(retryOn = IOException.class)
@CircuitBreaker(failOn = IOException.class, requestVolumeThreshold = 5, successThreshold = 3, delay = 2, delayUnit = ChronoUnit.SECONDS, failureRatio = 0.75)
@Fallback(fallbackMethod = "processFallback")
public CompletionStage<MyConnection> retryCircuitBreaker(int counter) throws IOException {
System.out.println("retryCircuitBreaker - called - " + counter);
if (counter % 4 != 0) { // 3/4 requests trigger IOException
System.out.println("retryCircuitBreaker - called - " + counter + " throwing exception");
throw new IOException("Simulated IOException");
}
System.out.println("retryCircuitBreaker - called - " + counter + " success");
return CompletableFuture.completedFuture(new MyConnection() {
@Override
public String getData() {
return "Hello from @Retry @CircuitBreaker method" + counter;
}
});
}
private CompletionStage<MyConnection> processFallback(int counter) {
System.out.println("processFallback - returned url counter: " + counter);
return CompletableFuture.completedFuture(new MyConnection() {
@Override
public String getData() {
return "Fallback Hello" + counter;
}
});
}
{code}
* Sends 16 parallel requests. Every 4th requests pass (including 0th one is there modulo 4), and 12 invocations fail on IOException.
* Try on more request and check that @Fallback method was called as circuit is open
Expected result:
Circuit gets opened and @Fallback method is called.
Actual Result:
Circuit is not opened and @Fallback method is called.
> MP Fault Tolerance - unexpected behaviour @Fallback method calls with @CircuitBreaker
> -------------------------------------------------------------------------------------
>
> Key: WFWIP-307
> URL: https://issues.redhat.com/browse/WFWIP-307
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Fault Tolerance
> Reporter: Miroslav Novak
> Assignee: Radoslav Husar
> Priority: Blocker
>
> MP FT does behave correctly in case when there is @CircuitBreaker, @Fallback, @Retry and @Asynchronous on service method. @CircuitBreaker does not get opened based on its configuration and @Fallback method is called with incorrect value.
> Test scenario:
> * Deploy MP FT service with:
> {code}
> @Asynchronous
> @Retry(retryOn = IOException.class)
> @CircuitBreaker(failOn = IOException.class, requestVolumeThreshold = 5, successThreshold = 3, delay = 2, delayUnit = ChronoUnit.SECONDS, failureRatio = 0.75)
> @Fallback(fallbackMethod = "processFallback")
> public CompletionStage<MyConnection> retryCircuitBreaker(int counter) throws IOException {
> System.out.println("retryCircuitBreaker - called - " + counter);
> if (counter % 4 != 0) { // 3/4 requests trigger IOException
> System.out.println("retryCircuitBreaker - called - " + counter + " throwing exception");
> throw new IOException("Simulated IOException");
> }
> System.out.println("retryCircuitBreaker - called - " + counter + " success");
> return CompletableFuture.completedFuture(new MyConnection() {
> @Override
> public String getData() {
> return "Hello from @Retry @CircuitBreaker method" + counter;
> }
> });
> }
> private CompletionStage<MyConnection> processFallback(int counter) {
> System.out.println("processFallback - returned url counter: " + counter);
> return CompletableFuture.completedFuture(new MyConnection() {
> @Override
> public String getData() {
> return "Fallback Hello" + counter;
> }
> });
> }
> {code}
> * Sends 16 parallel requests. Every 4th requests pass (including 0th one as there is modulo 4), and 12 invocations fail on IOException.
> * Try on more request and check that @Fallback method was called as circuit is open
> Expected result:
> Circuit gets opened and @Fallback method is called.
> Actual Result:
> Circuit is not opened and @Fallback method is called.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFWIP-307) MP Fault Tolerance - unexpected behaviour @Fallback method calls with @CircuitBreaker
by Miroslav Novak (Jira)
Miroslav Novak created WFWIP-307:
------------------------------------
Summary: MP Fault Tolerance - unexpected behaviour @Fallback method calls with @CircuitBreaker
Key: WFWIP-307
URL: https://issues.redhat.com/browse/WFWIP-307
Project: WildFly WIP
Issue Type: Bug
Components: MP Fault Tolerance
Reporter: Miroslav Novak
Assignee: Radoslav Husar
MP FT does behave correctly in case when there is @CircuitBreaker, @Fallback, @Retry and @Asynchronous on service method. @CircuitBreaker does not get opened based on its configuration and @Fallback method is called with incorrect value.
Test scenario:
* Deploy MP FT service with:
{code}
@Asynchronous
@Retry(retryOn = IOException.class)
@CircuitBreaker(failOn = IOException.class, requestVolumeThreshold = 5, successThreshold = 3, delay = 2, delayUnit = ChronoUnit.SECONDS, failureRatio = 0.75)
@Fallback(fallbackMethod = "processFallback")
public CompletionStage<MyConnection> retryCircuitBreaker(int counter) throws IOException {
System.out.println("retryCircuitBreaker - called - " + counter);
if (counter % 4 != 0) { // 3/4 requests trigger IOException
System.out.println("retryCircuitBreaker - called - " + counter + " throwing exception");
throw new IOException("Simulated IOException");
}
System.out.println("retryCircuitBreaker - called - " + counter + " success");
return CompletableFuture.completedFuture(new MyConnection() {
@Override
public String getData() {
return "Hello from @Retry @CircuitBreaker method" + counter;
}
});
}
private CompletionStage<MyConnection> processFallback(int counter) {
System.out.println("processFallback - returned url counter: " + counter);
return CompletableFuture.completedFuture(new MyConnection() {
@Override
public String getData() {
return "Fallback Hello" + counter;
}
});
}
{code}
* Sends 16 parallel requests. Every 4th requests pass (including 0th one is there modulo 4), and 12 invocations fail on IOException.
* Try on more request and check that @Fallback method was called as circuit is open
Expected result:
Circuit gets opened and @Fallback method is called.
Actual Result:
Circuit is not opened and @Fallback method is called.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-4959) Package name does not changes on copying of an existing package
by Toni Rikkola (Jira)
[ https://issues.redhat.com/browse/DROOLS-4959?page=com.atlassian.jira.plug... ]
Toni Rikkola commented on DROOLS-4959:
--------------------------------------
Unfortunately I doubt this will get fixed in the near future. The unfortunate workaround would be to git clone the project, change the packages and push changes back.
> Package name does not changes on copying of an existing package
> ---------------------------------------------------------------
>
> Key: DROOLS-4959
> URL: https://issues.redhat.com/browse/DROOLS-4959
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.31.0.Final
> Reporter: Nikos Tsekouras
> Assignee: Toni Rikkola
> Priority: Major
> Attachments: step1.PNG, step2.PNG, step3.PNG, step4.PNG
>
>
> After copying a package to a new one, all copied resources will remain referencing the existing one.
> This becomes a bigger issue once you use guided rules, which their source cannot be edited.
> Due to that, duplication alerts will be raised.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFCORE-4862) NPE starting the server by using incorrect git repository configurations
by Yeray Borges Santana (Jira)
Yeray Borges Santana created WFCORE-4862:
--------------------------------------------
Summary: NPE starting the server by using incorrect git repository configurations
Key: WFCORE-4862
URL: https://issues.redhat.com/browse/WFCORE-4862
Project: WildFly Core
Issue Type: Bug
Reporter: Yeray Borges Santana
Assignee: Yeray Borges Santana
The standalone server can be configured to use a git repository as a persister to backup server configurations.
When the server is started by using any of these configurations with incorrect values, the usage description is shown together with the following NPE trace that should not be there:
{noformat}
java.lang.NullPointerException
at org.jboss.as.server@11.0.0.Beta10-SNAPSHOT//org.jboss.as.server.Main.main(Main.java:99)
at org.jboss.modules.Module.run(Module.java:352)
at org.jboss.modules.Module.run(Module.java:320)
at org.jboss.modules.Main.main(Main.java:593)
{noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months