Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

238: Remove recursive classloader check in loadSpi #239

Merged
merged 1 commit into from
Dec 13, 2019

Conversation

andymc12
Copy link
Contributor

@andymc12 andymc12 commented Dec 9, 2019

Resolves issue #238 - using the same pattern as MP Config.

@andymc12 andymc12 added this to the V.Next milestone Dec 9, 2019
@andymc12 andymc12 self-assigned this Dec 9, 2019
@@ -23,5 +23,5 @@
* provide additional functionality for MP Rest Clients.
*
*/
@org.osgi.annotation.versioning.Version("1.1")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any reason why a patch over minor?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking about removing the setInstance method per issue #103 - which would force the package version to be 2.0, but then I realized that we hadn't actually come to a consensus on that. Since this change isn't changing any method signatures, it shouldn't require a minor update. I'm not an expert in semantic versioning, but I think in this case, a micro version update is correct.

I'd also like to separate the "spi" package into it's own artifact - that might require a version change too, but I'm not positive about that.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Took a quick look at semVer and it probably does align with a patch version

@michalszynkiewicz
Copy link
Contributor

michalszynkiewicz commented Dec 9, 2019

@andymc12 do you know what might have been the reason for the previous approach?

@andymc12
Copy link
Contributor Author

andymc12 commented Dec 9, 2019

@michalszynkiewicz I'm not sure. The previous approach was copied almost 100% from MP Config (and then changed to use RestClientResolver instead of ConfigResolver). This change is staying in sync with the changes to MP Config (and other specs) - and it looks right to me.

The older approach was probably only useful in environments like Liberty which uses OSGi and isolates implementation classes from the application classloaders. I know that Liberty doesn't need this old functionality, so it should be safe there - it might be worth checking with other app servers to see if it works there - I suspect it is fine for Wildfly/Thorntail/Quarkus/etc. and GlassFish.

I think TomEE uses OSGi, so it might be an issue there... @cesarhernandezgt is this something you could try out?

@struberg
Copy link

FYI: TomEE does not use OSGi!

@andymc12
Copy link
Contributor Author

@struberg thanks for the clarification. Given that, I think we are good to merge this change. Thanks all!

@andymc12 andymc12 merged commit 45ac083 into eclipse:master Dec 13, 2019
@andymc12 andymc12 modified the milestones: 2.0, 1.4 Jan 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants