search

rbeckman-nextgen / test-mc6

0 stars 0 forks source link

Allow Resources to have child-first ClassLoader semantics #4051

Open rbeckman-nextgen opened 4 years ago

rbeckman-nextgen commented 4 years ago

Having a child-first ClassLoader for resources allows a channel, etc. to use library versions that are different from those provided by Mirth server or one of the extensions.

As it stands, Mirth's provided libraries will take precedence over anything in any resource loader, so if Mirth bundles library X version 1 and the channel requires library X version 2, the channel will (likely) fail.

Mirth should provide such child-first ClassLoaders to allow channels that require such semantics. This makes it much easier to deploy on Mirth without having to take the risky step of upgrading Mirth's provided libraries when a conflict exists.

Imported Issue. Original Details: Jira Issue Key: MIRTH-4198 Reporter: cschultz@chadis.com Created: 2017-07-19T14:04:34.000-0700

rbeckman-nextgen commented 4 years ago

http://www.mirthcorp.com/community/issues/browse/MIRTH-3835 seems related. If I can get the isolated classloader does that imply that I can also easily set that classloader or set that classloader as the parent?

Imported Comment. Original Details: Author: jbartels Created: 2017-10-05T12:54:19.000-0700

rbeckman-nextgen commented 4 years ago

I was just bitten by this again. Because Mirth internally uses lots of popular libraries (e.g. Apache commons-lang3 in my case), it's not possible to require a higher-level version of a library without upgrading the version Mirth ships with, or there will be odd conflicts.

Imported Comment. Original Details: Author: cschultz@chadis.com Created: 2017-11-30T09:10:01.000-0800

rbeckman-nextgen commented 4 years ago

MC extensions can also contribute to this issue. I have a customer using a home grown library which depends on Apaches WSS4J which has a transitive dependency on OpenSAML 3.1.1. The commercial NextGen extension for XDS tools uses OpenSAML 2.6.4.

If both the library and that NextGen extension are loaded, the library cannot run because of classpath conflicts. The workaround is to use the isolated classloader (see MIRTH-3835) to load the library and its dependencies. The isolated classloader works to solve this problem but it is a little challenging for channel engineers who are not also Java engineers to use.

Is it possible or practical to define a channel that uses the isolated classloader by default and have that set as a checkbox option instead of having to do it manually in code? Does such an option to use the isolated classloader cover most of the use cases and reduce the need for a child-first loader?

Imported Comment. Original Details: Author: jbartels Created: 2018-09-05T12:35:27.000-0700

rbeckman-nextgen commented 4 years ago

The isolated ClassLoader IMO is a step backward from a "parent-last" ClassLoader because it is more awkward to use.

MC should use parent-last semantics by default for every channel (or, really, every resource-set) and that would solve 99% of these kinds of issues. The "isolated" ClassLoader should basically never be necessary. MC should isolate anything that the server needs to run itself from the resources required by various channels, unless MC is declaring that it provides specific libraries. Unfortunately, declaring that a library is provided (e.g. http-client) runs the risk that the server and the channel/resource-set disagree over which version is appropriate.

It would therefore be best to isolate the server and let channels use whatever they want.

Imported Comment. Original Details: Author: cschultz@chadis.com Created: 2018-09-05T13:37:03.000-0700