Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
[WFCORE-4621] Create wildflyee.api static module to serve the Jakarta EE api dependencies to the external modules

  1. … 3 more files in changeset.
[WFCORE-4626] Expose ExternalModuleService as WidlFly capability

    • -0
    • +81
    ./ExternalModule.java
  1. … 5 more files in changeset.
Fixing NPE

[WFCORE-4375] Implement a different comparator loading the jar files

  1. … 1 more file in changeset.
[WFCORE-4375] Implement a different comparator loading the jar files

    • -19
    • +29
    ./ExternalModuleSpecService.java
  1. … 1 more file in changeset.
[WFCORE-4597] Use PhaseContext target to start external module spec services being tracked by the stability monitor

  1. … 1 more file in changeset.
[WFCORE-4612] ExternalModuleDependencySpecService should make dependencies on 'javaee.api' optional. Instead of adding an optional dep on javaee.api, add deps on the individual APIs, to allow flexible use of whatever is provisioned.

[WFCORE-4375] Provide ability to easily apply certain JBoss module libraries to all deployments running in a server

[WFCORE-4375] Added some logs when the files are added as resource roots

- Use resource name for created module

[WFCORE-4375] Add posibility to scan subfolders for jar files

[WFCORE-4375] Do not process class path entries if they are directory

[WFCORE-4375] Add control tolimit number of files processed in a global directory

[WFCORE-4375] Fix checkstyle

[WFCORE-4375] More work in progress

[WFCORE-4375] Increase the logs of ExternalModuleSpecService when jar files are processed

[WFCORE-4375] Improve error messages

[WFCORE-4375] Do not initialize the jars TreeSet if there is no available paths poiting to a jar file

[WFCORE-4375] Add paths sorted by full path name, change error message including exception trace

    • -17
    • +71
    ./ExternalModuleSpecService.java
  1. … 2 more files in changeset.
[WFCORE-4327] Use correct order of method arguments in ModuleLoadService

[WFCORE-4327] Use correct order of method arguments in ModuleLoadService

[WFCORE-4251] Provide ability to list module dependencies for a deployment and subdeployment

  1. … 8 more files in changeset.
[WFCORE-4251] Provide ability to list module dependencies for a deployment and subdeployment

  1. … 8 more files in changeset.
[WFCORE-4201] Refactoring - eliminating ServiceBuilder.addDependency(ServiceName) method usages.

  1. … 26 more files in changeset.
[WFCORE-4201] Refactoring - eliminating ServiceBuilder.addDependency(ServiceName) method usages.

  1. … 26 more files in changeset.
WFCORE-3918 Services created by extension index service is not part of stability monitor

[WFCORE-3816] ExtensionIndexService throws NPE while reading extensions on the IBM jdk

[WFCORE-3817] Eliminating usages of deprecated ServiceListeners.

  1. … 6 more files in changeset.
[WFCORE-3623] Remove ModuleIndexService

  1. … 2 more files in changeset.
[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.

  1. … 1 more file in changeset.
[WFCORE-2589] There are two ways how users can specify explicit optional module dependencies to a deployment: [1] via META-INF/MANIFEST.MF 'Dependencies' header [2] via jboss-deployment-structure/dependencies/module elements

Definition of 'optional' attribute of jboss-deployment-structure/dependencies/module element

(which is by the way the only available description for user of how 'optional' deployment

dependencies are handled at runtime regardless if they have been specified via [1] or [2])

states that:

<xsd:attribute name="optional" type="xsd:boolean" use="optional" default="false">

<documentation>

Specifies whether this dependency is optional (defaults to false).

An optional dependency will not cause the module to fail to load

if not found; however if the module is added later, it will not be

retroactively linked into this module's dependency list.

</documentation>

</xsd:attribute>

This fix eliminates these dynamic module dependencies mapping to MSC optional dependencies

for three reasons:

* to make it consistent with documented 'optional module dependency' behaviour description above

(since upgrade to JBoss MSC 1.2.8.Final optional dependencies are behaving properly

and once such optional MSC dependency would appear it would cause complete reloading

to take appeared optional dependencies into account)

* we would like to get rid of all MSC optional dependencies usages

(MSC optional dependencies are causing performance defects)

* JBoss modules based classloading layer is capable of handling optional module dependencies on its own

(there is not need to emulate optionality in MSC layer too)

[WFCORE-2589] Removing useless code.

Dependency on 'module resolved service' already guarantees these dependencies

are up see comment in the diff just one line above the useless code removal.

Removing useless latch. We never call latch.await() on it

Removing dead code

[WFCORE-2758] Upgrading to JBoss Modules 1.6.0.Beta8

  1. … 1 more file in changeset.
[WFCORE-525] Ability to mark a module as deprecated

  1. … 1 more file in changeset.
[WFLY-3276] Misc fix: exception is constructed but not thrown

was: d7a02b8348f1c8fd209c7e6d295b4c2d6cf4fe80

  1. … 9 more files in changeset.
[WFLY-2864] WildFly Server

was: a1c734436e77d45f9dd6fe2c372ac02a908e5eac

  1. … 75 more files in changeset.
WFLY-920 Module Service Dependencies do not take transitive dependencies into account

Add multi-stage resolution process to make sure that all dependent module spec

services are up before starting the module service.

was: 26fff319b411b8baf0b02cef5a5dc70f154e47e6

    • -0
    • +40
    ./ModuleDefinition.java
    • -0
    • +131
    ./ModuleResolvePhaseService.java
  1. … 1 more file in changeset.
[AS7-6781] Make non-final constants final; reduce visibility in some cases

was: a823dea8c3c239e406ff7bad619f4fa19ba5d771

  1. … 35 more files in changeset.
Fix code to comply with more strict UnusedImport rules

* don't introduce compile import dependency in case javadoc is only user of imporated class

was: 2e5e616b02fd767b1e5b820c57c5a5b35d1f4767

  1. … 82 more files in changeset.