Dynamically update classloader after adding a library with the add-library command

[OndroMih]

Dynamically updates the common classloader if a common library is added. It means that restart is not needed to add the library to the classpath.

[dmatej]

Is it possible also to remove the library? I see there is the asadmin remove-library command too, however I have no idea how it works if the application is already running and using the library.

[avpinchuk]

Is it possible also to remove the library? I see there is the asadmin remove-library command too, however I have no idea how it works if the application is already running and using the library.

Perhaps, on Linux (and Unix generally) library file will be removed, but library will be accessible until server stop/restart. On Windows remove-library command should be failed due to file locking.

[OndroMih]

The remove-library command just deletes the JAR on the file system. It could remove the url in the classloader but it’s not necessary. The CL will just ignore the url if the file doesn’t exist. So no need to remove the url from the CL. Classes loaded from the removed JAR will keep being loaded even after the JAR is removed.

[avpinchuk]

The CL will just ignore the url if the file doesn’t exist

If JAR was already opened by CL, CL will not ignore this JAR. Application will load classes and resources from this JAR.

[dmatej]

We already have this command, so it should probably do more, ie. refuse to remove the file if it is used by any classloader and report that classloader to the user. We can try to do that in another PR, but for this reason I always pushed libraries inside ear/war files, because they have lifecycle while this is quite fragile.

Could it be enough to disable the application and then remove the library? Maybe we can move this to discussions.

[avpinchuk]

Maybe we can move this to discussions

Good idea ;)

[OndroMih]

I used a wrong phase for the assembly plugin. It's supposed to copy test classes before classloader tests are executed. Before the fix, it was executed before test classes were compiled, it tried to move non-existent classes and failed.

[OndroMih]

OK, the fastest profile disabled test compilation, so I needed to disable the assembly plugin in the fastest profile too.

[dmatej]

If we want to hurry to merge it to 7.0.18, those two comments can be resolved in another PR (or I can add it to mine as I am messing with classloaders too)