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

Allow to override the strategy used in ReflectUtils.defineClass #22310

Closed
j3rem1e opened this issue Jan 26, 2019 · 2 comments
Closed

Allow to override the strategy used in ReflectUtils.defineClass #22310

j3rem1e opened this issue Jan 26, 2019 · 2 comments
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement

Comments

@j3rem1e
Copy link

j3rem1e commented Jan 26, 2019

Affects: Spring 5.1

Since #20414, Spring uses MethodHandler.Lookup.defineClass to define proxy classes. However, this method forces the proxy to be defined in the same classloader as the initial class, and this classloader should have a visibility for all the classes used by the proxy (spring-aop, cglib & co).

This is not necessary the case in a restricted environment, or in osgi applications.

In my case, I used to build a custom classloader which provide visibility for such proxies - but I can't use this classloader anymore, although I have control of the defineClass on my classloader.

I'd like t have a way to override the spring-cglib ReflectUtils.defineClass() strategy.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Jan 26, 2019
@jhoeller jhoeller self-assigned this Jan 26, 2019
@jhoeller jhoeller added this to the 5.1.5 milestone Jan 26, 2019
@jhoeller jhoeller added type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Jan 27, 2019
@jhoeller jhoeller modified the milestones: 5.1.5, 5.2 M2 Jan 30, 2019
@jhoeller
Copy link
Contributor

As per #22416 (to be shipped in 5.1.6), we only prefer the JDK 9+ Lookup.defineClass API if the ClassLoader matches the context class now. This should cover OSGi scenarios and similar custom class loader architectures out of the box now. Please give it a try, possibly against a 5.1.6.BUILD-SNAPSHOT ahead of the release, and let me know whether you still see a need for a custom defineClass strategy.

@jhoeller
Copy link
Contributor

I'm closing this issue for the time being, assuming that the resolution for #22416 covers this case as well.

@jhoeller jhoeller removed this from the 5.2 M2 milestone Mar 27, 2019
@jhoeller jhoeller added the in: core Issues in core modules (aop, beans, core, context, expression) label Mar 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

3 participants