WildFlyCore

Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Fix for WFCORE-3567, domain specific options not proposed

Fix for WFCORE-3564, completion issue with --server-groups option

Fix WFCORE-3565: Check task queue for more tasks

Updates the runQueuedTask() method to always check whether there are any

tasks in the task queue. This prevents tasks from getting stuck in the

task queue forever if they were placed in there while the container was

at the max request limit.

Additionally, the changes to the runQueuedTask() method in this commit

ensure that forced tasks do not get lost anymore if the container is

paused and has reached the request limit.

Fix for WFCORE-3447 CLI SSL security commands

    • -0
    • +139
    /cli/src/main/java/org/jboss/as/cli/Util.java
  1. … 18 more files in changeset.
Next is 4.0.0.Beta1

  1. … 48 more files in changeset.
Prepare for WildFly Core 4.0.0.Alpha8 release

  1. … 48 more files in changeset.
Merge pull request #2946 from jfdenise/4.0-aesh1.0-final

CLI, aesh1.0,patching,help,deployment,operators

Next is 4.0.0.Beta1

  1. … 48 more files in changeset.
Prepare for 4.0.0.Alpha7 release

  1. … 48 more files in changeset.
Merge pull request #3072 from dmlloyd/threadpool

[WFCORE-3397] Introduce new thread pool implementation

Merge pull request #3069 from jamezp/WFCORE-3549

[WFCORE-3549] Downgrade jboss-logmanager to a final version, 2.0.9.Final

upgrade to aesh and aesh-extensions 1.0

Merge pull request #3035 from darranl/WFCORE-3457

[WFCORE-3457] Make 'TrivialResourceDefinition' final and use a Builder instead of extending each time.

Adjusted WFCORE-3221 tests

Merge pull request #3068 from jfdenise/WFCORE-3548

Fix for WFCORE-3548, CLI, Command executor should create daemon thread

Tests for WFCORE-3221 Support for | and >> operators

Merge pull request #3065 from darranl/WFCORE-3543

[WFCORE-3543] / [WFCORE-3544] WildFly Elytron Component Upgrades

Merge pull request #3067 from dudaerich/WFCORE-3546

WFCORE-3546 Update MoreTestCase to hide failures caused by WFCORE-3545

Merge pull request #3024 from jfdenise/WFCORE-3494

Fix for WFCORE-3494, CLI, infinite loop when accepting temporarily SSL certificate

[WFCORE-3550] Minimize creation of attribute descriptions in support off JMX read/setAttribute

[WFCORE-3549] Downgrade jboss-logmanager to a final version, 2.0.9.Final.

Fix for WFCORE-3548, CLI, Command executor should create daemon thread

Fix for WFCORE-3547, ExceptionInInitializerError during create of CLI object on client app

WFCORE-3546 Update MoreTestCase to hide failures caused by WFCORE-3545

[WFCORE-3541] ScramDigestPassword into set-password operation

Merge pull request #3061 from dudaerich/WFCORE-3538

WFCORE-3537 Add support for testing of CLI multi page output

[WFCORE-3544] Upgrade Elytron Web to 1.1.0.Beta1

[WFCORE-3543] Upgrade WildFly Elytron to 1.2.0.Beta12

Upgrade to aesh-1.0-Alpha5, added unit test to cover >> operator behavior change

[WFCORE-2235] Fixing race condition that appears when the following scenario happens:

Module A depends on module B (optional dependency).

Both modules are dynamic (they're not present on the file system

but dynamically deployed at runtime). The following scenario exposes

race condition for this kind of dynamic modules:

1] Module A is starting and module B is not available yet

2] Module A during its initialization phase calls

ModuleLoader.loadModuleLocal() to resolve its optional module B dependency

3] Module A initialization thread registers "newFuture" with "moduleMap"

4] Module A initialization thread fails to find ModuleSpec of module B

5] ModuleLoadService representing Module B appears and is starting

(such service knows all its preconditions are met - its ModuleSpec is available)

6] MSC thread executing ModuleLoadService.start() (of module B)

is calling moduleLoader.loadModule(moduleB_Id)

7] MSC thread executing ModuleLoadService.start() (of module B)

enters ModuleLoader.loadModuleLocal() to find the module

8] MSC thread requests "moduleMap" and receives "newFuture" created in step [3]

9] MSC thread enters "newFuture" wait set and blocks (waiting for Module A

initialization thread to complete)

10] Module A initialization thread wakes up and identifies that (moduleSpec == null)

MOduleLoader.loadModuleLocal() will return null

11] Before method return "finally" sections is executed, where:

a) newFuture.setModule(null) is called

b) "newFuture" is removed from "moduleMap"

12] MSC thread wakes up and throws ModuleNotFoundException

This fix ensures proper ordering of resolution process for dynamic modules

and fixes aforementioned race condition.