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

Remove ClassLoader from Settings #12868

Merged
merged 1 commit into from Aug 14, 2015

Conversation

@rjernst
Copy link
Member

commented Aug 14, 2015

Settings currently has a classloader member, which any user (plugin
or core ES code) can access to load classes/resources. This is extremely
error prone as setting the classloder on the Settings instance is a
public method. Furthermore, it is not really necessary. Classes that
need resources should load resources using normal means
(getClass().getResourceAsStream). Those that need classes
should use Class.forName, which will load the class with the
same classloader as the calling class. This means, in the few
places where classes are loaded by string name, they will use
the appropriate loader: either the default classloader which loads
core ES code, or a child classloader for each plugin.

This change removes the classloader member from Settings, as
well as other classloader related uses (except for a handful
of cases which must use a classloader, at least for now).

Settings currently has a classloader member, which any user (plugin
or core ES code) can access to load classes/resources. This is extremely
error prone as setting the classloder on the Settings instance is a
public method. Furthermore, it is not really necessary. Classes that
need resources should load resources using normal means
(getClass().getResourceAsStream). Those that need classes
should use Class.forName, which will load the class with the
same classloader as the calling class. This means, in the few
places where classes are loaded by string name, they will use
the appropriate loader: either the default classloader which loads
core ES code, or a child classloader for each plugin.

This change removes the classloader member from Settings, as
well as other classloader related uses (except for a handful
of cases which must use a classloader, at least for now).
assertTrue(e instanceof SettingsException);
assertThat(e.getMessage(), equalTo("Failed to load settings from [" + invalidResourceName + "]"));
}
}

This comment has been minimized.

Copy link
@jpountz

jpountz Aug 14, 2015

Contributor

did you remove it on purpose?

This comment has been minimized.

Copy link
@rjernst

rjernst Aug 14, 2015

Author Member

Yes, this was intentional. This was just checking loadFromClasspath's behavior for a non-existent resource, but loadFromClasspath is gone now.

This comment has been minimized.

Copy link
@jpountz

jpountz Aug 14, 2015

Contributor

ok, sorry I got confused because this test was just added yesterday :)

@jpountz

This comment has been minimized.

Copy link
Contributor

commented Aug 14, 2015

There is one test which I don't understand why it got removed, but otherwise LGTM

@jpountz

This comment has been minimized.

Copy link
Contributor

commented Aug 14, 2015

LGTM

1 similar comment
@s1monw

This comment has been minimized.

Copy link
Contributor

commented Aug 14, 2015

LGTM

rjernst added a commit that referenced this pull request Aug 14, 2015
@rjernst rjernst merged commit 470f537 into elastic:master Aug 14, 2015
1 check passed
1 check passed
CLA Commit author is a member of Elasticsearch
Details
@rjernst rjernst deleted the rjernst:bye_bye_classloaders branch Aug 14, 2015
rjernst added a commit that referenced this pull request Aug 19, 2015
Settings currently has a classloader member, which any user (plugin
or core ES code) can access to load classes/resources. This is extremely
error prone as setting the classloder on the Settings instance is a
public method. Furthermore, it is not really necessary. Classes that
need resources should load resources using normal means
(getClass().getResourceAsStream). Those that need classes
should use Class.forName, which will load the class with the
same classloader as the calling class. This means, in the few
places where classes are loaded by string name, they will use
the appropriate loader: either the default classloader which loads
core ES code, or a child classloader for each plugin.

This change removes the classloader member from Settings, as
well as other classloader related uses (except for a handful
of cases which must use a classloader, at least for now).

Backport of #12868
@rjernst rjernst added v2.0.0-beta1 and removed v2.0.0 labels Aug 19, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.