-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
ReflectionUtils use Class.forName in order to properly discover classes in Functions Runtime while using "DefaultImplementation" #10827
ReflectionUtils use Class.forName in order to properly discover classes in Functions Runtime while using "DefaultImplementation" #10827
Conversation
…es in Functions Runtime while using DefaultImplementation Using Class.forName allows Java classes loaded in the Functions Runtime to fully use the Implementation classes loaded from the Pulsar API using DefaultImplementation
@codelipenghui it happens that without this patch some connectors that worked on Pulsar 2.7.x do not work anymore on 2.8.0. |
@@ -51,12 +51,12 @@ | |||
try { | |||
try { | |||
// when the API is loaded in the same classloader as the impl | |||
return (Class<T>) DefaultImplementation.class.getClassLoader().loadClass(className); | |||
return (Class<T>) Class.forName(className, true, DefaultImplementation.class.getClassLoader()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why set initialize
to true
here? Will it change the behaviour here since .loadClass(className)
will not do the initialization.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@freeznet in my experience I saw that it is better to fully initialise the classes in environments where there are dynamic classloaders, because you may see weird errors when you shutdown the classloader and you still try to use the class: if the class is not fully loaded you can see NoClassDefFound errors or other link related errors.
I can try to use 'false' and test again my code if you feel strong
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest using Class.forName
as a backup solution when loadClass
thrown exceptions, since you mentioned that the problem only happened sometimes
.
Is it still true in the current master? There shouldn't be anymore any client impl dependency in the function/io class path. |
@merlimat This is the jar that is in classpath for every Function/Source/Sink. it makes sense to have it in the classpath, but I do not know why, without this change some API functions (like the ones I cited in the description) do not work |
@merlimat @codelipenghui I sincerely believe that this may be a show stopper for 2.8.0 release |
I'm not sure if there are some changes related to the classloader of the Pulsar Functions, seems the class loader of the |
@codelipenghui probably you are right. Writing an integration test that demonstrate the failure is pretty time consuming. Another error I see in a Source that uses RecordSchemaBuilder |
@eolivelli SGTM, @merlimat @freeznet Please help check again. |
…es in Functions Runtime while using DefaultImplementation (apache#10827) Using Class.forName allows Java classes loaded in the Functions Runtime to fully use the Implementation classes loaded from the Pulsar API using DefaultImplementation Co-authored-by: Enrico Olivelli <eolivelli@apache.org>
…es in Functions Runtime while using DefaultImplementation (apache#10827) Using Class.forName allows Java classes loaded in the Functions Runtime to fully use the Implementation classes loaded from the Pulsar API using DefaultImplementation Co-authored-by: Enrico Olivelli <eolivelli@apache.org>
Motivation
With recent changes in Pulsar IO we are bundling the Pulsar Client Implementation in the classpath of the Functions/Pulsar IO connectors.
Sometimes it happens that calls to DefaultImplementation fail, like this call to
SchemaBuilder.record()
:Modifications
Using Class.forName allows Java classes loaded in the Functions Runtime to fully use the Implementation classes loaded from the Pulsar API using DefaultImplementation
Verifying this change
This change is a trivial rework / code cleanup without any test coverage.