WIP: Plugin Extensions are not detected with ClassLoadingStrategy.APD #453
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
solves #449
TODO: fix Bug
The possible solutions I currently see:
PluginClassLoader.getResource would have to be aware of the
extensions.idx
file and always use the plugin way to load the file. Downside: PluginClassLoader would have to be aware of the internals of the storage as adding a new filename would require to change the pluginClassLoader(e.g. adding aNewExtensionStorage
which reads fromMETA-INF/new.idx
would require thatMETA-INF/new.idx
be added to the PluginClassLoader whitelistLegacyExtensionFinder.readPluginsStorages would need to be changed from
getResourceAsStream
togetResources
. This way, the extensionFinder would receive all possible URLs and if more than one url is returned it could decide which url to use(e.g. by comparing with plugin.getPluginPath() to get the correct url). This would partially duplicate the logic of the PluginClassLoader but would keep the classes independent.@decebals What do you think?