You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Udo Kohlmeyer <ud...@vmware.com> on 2020/09/14 10:42:28 UTC
[Discussion] - ClassLoaderService RFC proposal
Hi there Apache Geode Devs, (try 2)
Please find attached a proposal for a ClassLoaderService. Please review and ponder on it.
https://cwiki.apache.org/confluence/display/GEODE/Introduction+of+ClassLoaderService+into+Geode
All comments are please to be made in this mail thread.
—Udo
Re: [Discussion] - ClassLoaderService RFC proposal
Posted by Udo Kohlmeyer <ud...@vmware.com>.
Hi there Alberto,
The ClassLoader Isolation work is currently still in development. Nothing is in the main code-branch yet.
But you are correct. 2 versions. DefaultClassLoaderService will be the standard Java ClassLoader functionality as we are currently used to. The other, JBoss Modules based. Until the ClassLoader Isolation work is completed, the DefaultClassLoaderService will make sure the system works as-is. No changes required.
The JBoss modules based ClassLoaderService will initially opt-in under the flag, until we find it to be stable enough to make it the default. But we really want this swapping of ClassLoaders to be simple and seamless.
The reason for this RFC is to lay the ground work into the main code base, that would allow us to plug-in a different ClassLoaderService into the main code base. At this stage, from a prototype we’ve done, this “simple” change will touch in excess of 200 classes. Mostly only tests. But you can imagine if this work would be in the same PR as the ClassLoader Isolation work, the PR review would be the worst. Not only would you have to understand the changes suggested / implemented, but also all the classes that have simple, single changes in them.
But that does not say that the PR for this RFC would be simple to review either.. As we’d still have the 200+ classes that are touched.
—Udo
On Sep 15, 2020, 10:33 PM +1000, Alberto Gomez <al...@est.tech>, wrote:
Nice proposal, Udo.
Here come some questions:
Is the ClassLoader isolation RFC implemented? I have not seen any references to it in the doc or code. To me this RFC seems like a part of the ClassLoader isolation RFC as, without it, the original one would not work completely. Is this right?
If I understand correctly, to start with there will be two implementations of the ClassLoaderService, the DefaultClassLoaderService (with the current ClassLoader functionality) and another one with the modular ClassLoader functionality as provided by JBoss modules. The latter one will be used when the --experimental-classloader flag is used in GFSH. Is this right?
Thanks,
-Alberto G.
________________________________
From: Udo Kohlmeyer <ud...@vmware.com>
Sent: Monday, September 14, 2020 12:42 PM
To: geode <de...@geode.apache.org>
Subject: [Discussion] - ClassLoaderService RFC proposal
Hi there Apache Geode Devs, (try 2)
Please find attached a proposal for a ClassLoaderService. Please review and ponder on it.
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FIntroduction%2Bof%2BClassLoaderService%2Binto%2BGeode&data=02%7C01%7Cudo%40vmware.com%7C0f20f50e1cb14ae271d308d859738aec%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637357700083700083&sdata=lFqZF71ZAVNvEo4FytSqZzpwKAcHuYzj7uuBRiCQ10U%3D&reserved=0
All comments are please to be made in this mail thread.
—Udo
Re: [Discussion] - ClassLoaderService RFC proposal
Posted by Alberto Gomez <al...@est.tech>.
Nice proposal, Udo.
Here come some questions:
Is the ClassLoader isolation RFC implemented? I have not seen any references to it in the doc or code. To me this RFC seems like a part of the ClassLoader isolation RFC as, without it, the original one would not work completely. Is this right?
If I understand correctly, to start with there will be two implementations of the ClassLoaderService, the DefaultClassLoaderService (with the current ClassLoader functionality) and another one with the modular ClassLoader functionality as provided by JBoss modules. The latter one will be used when the --experimental-classloader flag is used in GFSH. Is this right?
Thanks,
-Alberto G.
________________________________
From: Udo Kohlmeyer <ud...@vmware.com>
Sent: Monday, September 14, 2020 12:42 PM
To: geode <de...@geode.apache.org>
Subject: [Discussion] - ClassLoaderService RFC proposal
Hi there Apache Geode Devs, (try 2)
Please find attached a proposal for a ClassLoaderService. Please review and ponder on it.
https://cwiki.apache.org/confluence/display/GEODE/Introduction+of+ClassLoaderService+into+Geode
All comments are please to be made in this mail thread.
—Udo
Re: [Discussion] - ClassLoaderService RFC proposal
Posted by Udo Kohlmeyer <ud...@vmware.com>.
Jens, yes and no.
The ClassPathLoader will still be relevant for the ClassLoader mechanisms we require for the non-ClassLoader-Isolated starting of the server.
But all the functionality that ClassPathLoader exposes will eventually be replaced with the ClassLoader Isolated capability.
I’ll add some code snippets to the RFC to further explain the proposal. Thank you for raising this.
—Udo
On Sep 18, 2020, 2:22 AM +1000, Jens Deppe <jd...@vmware.com>, wrote:
Thanks for this work Udo!
Does this ClassLoaderService effectively replace the current ClassPathLoader mechanism then?
How will one access the service; is there some static reference? Some code examples would be helpful to properly understand how one might work with this.
--Jens
On 9/14/20, 3:42 AM, "Udo Kohlmeyer" <ud...@vmware.com> wrote:
Hi there Apache Geode Devs, (try 2)
Please find attached a proposal for a ClassLoaderService. Please review and ponder on it.
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FIntroduction%2Bof%2BClassLoaderService%2Binto%2BGeode&data=02%7C01%7Cudo%40vmware.com%7C6390afa1ddb342a93e1808d85b25d703%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637359565380628408&sdata=TgEkaSRzde3EkhejssRwhRF8IbiNY0D4J4V3XaY3V2E%3D&reserved=0
All comments are please to be made in this mail thread.
—Udo
Re: [Discussion] - ClassLoaderService RFC proposal
Posted by Udo Kohlmeyer <ud...@vmware.com>.
Sorry...
Also, the new implementation will not be statically available and for now the instance is passed into the locations that require it.
—Udo
On Sep 18, 2020, 2:22 AM +1000, Jens Deppe <jd...@vmware.com>, wrote:
Thanks for this work Udo!
Does this ClassLoaderService effectively replace the current ClassPathLoader mechanism then?
How will one access the service; is there some static reference? Some code examples would be helpful to properly understand how one might work with this.
--Jens
On 9/14/20, 3:42 AM, "Udo Kohlmeyer" <ud...@vmware.com> wrote:
Hi there Apache Geode Devs, (try 2)
Please find attached a proposal for a ClassLoaderService. Please review and ponder on it.
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FIntroduction%2Bof%2BClassLoaderService%2Binto%2BGeode&data=02%7C01%7Cudo%40vmware.com%7C6390afa1ddb342a93e1808d85b25d703%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637359565380628408&sdata=TgEkaSRzde3EkhejssRwhRF8IbiNY0D4J4V3XaY3V2E%3D&reserved=0
All comments are please to be made in this mail thread.
—Udo
Re: [Discussion] - ClassLoaderService RFC proposal
Posted by Jens Deppe <jd...@vmware.com>.
Thanks for this work Udo!
Does this ClassLoaderService effectively replace the current ClassPathLoader mechanism then?
How will one access the service; is there some static reference? Some code examples would be helpful to properly understand how one might work with this.
--Jens
On 9/14/20, 3:42 AM, "Udo Kohlmeyer" <ud...@vmware.com> wrote:
Hi there Apache Geode Devs, (try 2)
Please find attached a proposal for a ClassLoaderService. Please review and ponder on it.
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FIntroduction%2Bof%2BClassLoaderService%2Binto%2BGeode&data=02%7C01%7Cjdeppe%40vmware.com%7Cde083e2172634f2bf11b08d8589ae7dc%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637356769623047129&sdata=VkXprwOM%2FzGXO%2FYMOoBMC60kiREyagn%2B6%2F%2FSvajv9Tg%3D&reserved=0
All comments are please to be made in this mail thread.
—Udo
Re: [Discussion] - ClassLoaderService RFC proposal
Posted by "Ju@N" <ju...@gmail.com>.
Looks good to me Udo, thanks for putting it together!.
On Mon, 14 Sep 2020 at 11:42, Udo Kohlmeyer <ud...@vmware.com> wrote:
> Hi there Apache Geode Devs, (try 2)
>
> Please find attached a proposal for a ClassLoaderService. Please review
> and ponder on it.
>
>
> https://cwiki.apache.org/confluence/display/GEODE/Introduction+of+ClassLoaderService+into+Geode
>
> All comments are please to be made in this mail thread.
>
> —Udo
>
--
Ju@N
Re: [Discussion] - ClassLoaderService RFC proposal
Posted by Udo Kohlmeyer <ud...@vmware.com>.
Hi there Donal,
Good question. No, the ClassLoaderService does not need to be persisted. The type of Service (Modular or Default) is determined at start up and passed in. This way we can run the Geode code ClassLoaderIsolated or “normal” depending on what ClassLoaderService we decide to pass in.
—Udo
On Sep 15, 2020, 3:42 AM +1000, Donal Evans <do...@vmware.com>, wrote:
Sounds good to me. One question though: is it likely that the ClassLoaderService configuration will need to be persisted at all? For example, would it be reasonable to provide a user with the ability to specify a new ClassLoaderService implementation to be used upon cluster restart (via GFSH or REST), which would require some sort of persisted configuration? If this is likely, will the currently proposed implementation provide this functionality, or will that be left for future work? I only ask because I'm not sure how easy it is to convert something into a persistent service vs creating it as one in the first place. If it's trivial, then no worries.
________________________________
From: Udo Kohlmeyer <ud...@vmware.com>
Sent: Monday, September 14, 2020 3:42 AM
To: geode <de...@geode.apache.org>
Subject: [Discussion] - ClassLoaderService RFC proposal
Hi there Apache Geode Devs, (try 2)
Please find attached a proposal for a ClassLoaderService. Please review and ponder on it.
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FIntroduction%2Bof%2BClassLoaderService%2Binto%2BGeode&data=02%7C01%7Cudo%40vmware.com%7C7fa63fb521b7420dda7608d858d58b5d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637357021472112142&sdata=Hr3c2OPVJypxFiL%2BIlX6tpjdQYo%2BPHIrG68JjZNfHqc%3D&reserved=0
All comments are please to be made in this mail thread.
—Udo
Re: [Discussion] - ClassLoaderService RFC proposal
Posted by Donal Evans <do...@vmware.com>.
Sounds good to me. One question though: is it likely that the ClassLoaderService configuration will need to be persisted at all? For example, would it be reasonable to provide a user with the ability to specify a new ClassLoaderService implementation to be used upon cluster restart (via GFSH or REST), which would require some sort of persisted configuration? If this is likely, will the currently proposed implementation provide this functionality, or will that be left for future work? I only ask because I'm not sure how easy it is to convert something into a persistent service vs creating it as one in the first place. If it's trivial, then no worries.
________________________________
From: Udo Kohlmeyer <ud...@vmware.com>
Sent: Monday, September 14, 2020 3:42 AM
To: geode <de...@geode.apache.org>
Subject: [Discussion] - ClassLoaderService RFC proposal
Hi there Apache Geode Devs, (try 2)
Please find attached a proposal for a ClassLoaderService. Please review and ponder on it.
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FIntroduction%2Bof%2BClassLoaderService%2Binto%2BGeode&data=02%7C01%7Cdoevans%40vmware.com%7C7cf5b252f85a4deb173f08d8589ae792%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637356769617910090&sdata=lDloqR55FH9dkUD9cyboujDkf8GjUdrAqdCzSpB8QCA%3D&reserved=0
All comments are please to be made in this mail thread.
—Udo