Re: One class loader vs multiple class loaders for deployed jars

+1 to what Mike Stolz said. On Wed, Apr 12, 2017 at 8:17 PM, Anthony Baker wrote: > Agreed. It’s used by maven but the project itself doesn’t seem very > active. > > Anthony > > > On Apr 12, 2017, at 11:15 AM, Jared Stewart wrote: > > > > Anthony - I was never able to find any substantial docu

Re: One class loader vs multiple class loaders for deployed jars

Agreed. It’s used by maven but the project itself doesn’t seem very active. Anthony > On Apr 12, 2017, at 11:15 AM, Jared Stewart wrote: > > Anthony - I was never able to find any substantial documentation for Plexus > Classworlds. This makes it both hard to evaluate and potentially scary to

Re: One class loader vs multiple class loaders for deployed jars

I have submitted a review board request for this change, comments and feedback are welcome: https://reviews.apache.org/r/58393/ I don’t believe it breaks the current expected behavior, and I don’t think it will pose any additional barriers to classloader

Re: One class loader vs multiple class loaders for deployed jars

+1 for merging the current fix. It at least makes it easier to deploy a jar in the happy day scenario. I'm not sure how much we should be trying to emulate an application server anyway. If people really want to combine the cache with the app server they can embed Geode into an app server. There ma

Re: One class loader vs multiple class loaders for deployed jars

I believe with the current fix, we at least do not have the "eager loading" problem anymore. The classloader isolation was a problem before and would remain as a problem after this for further larger scale changes. +1 for merging the fix. On Tue, Apr 11, 2017 at 4:04 PM, Swapnil Bawaskar wrote:

Re: One class loader vs multiple class loaders for deployed jars

+1 for merging Jared's fix. it gets us closer to fixing classloading in a later release. On Tue, Apr 11, 2017 at 1:41 PM Jacob Barrett wrote: > I can support the idea of taking the small step of fixing the eager class > loading if it doesn't: > 1) break the current expected behavior. > 2) dig is

Re: One class loader vs multiple class loaders for deployed jars

I can support the idea of taking the small step of fixing the eager class loading if it doesn't: 1) break the current expected behavior. 2) dig is deeper into a hole with class loading isolation in the future. If it breaks the current expected behavior, that in itself is ok until you consider that

Re: One class loader vs multiple class loaders for deployed jars

Just adding another spin to this discussion... Today the idea of "application" inside a Geode cluster is really hard to define, there is no real concept of multitenancy and that also makes the problem of deployed jar isolation harder. How would you define the hierarchy of a deployed jar from App

Re: One class loader vs multiple class loaders for deployed jars

I recall that initially there was some discussion around plexus-classworlds. Does that look promising? Anthony > On Apr 11, 2017, at 10:06 AM, Jared Stewart wrote: > > I would like to distinguish between the following two objectives: > 1) Do not eagerly load every class contained in a deploy

Re: One class loader vs multiple class loaders for deployed jars

I think this comes down to two current (realistic) options: 1) accept Jared's changes as are so we can avoid forced loading of all deployed jars up front (GEODE-2290 will be fixed in the next release) 2) reject the changes until someone has time to retrofit Geode with a new CL container (GEODE-229

Re: One class loader vs multiple class loaders for deployed jars

I would like to distinguish between the following two objectives: 1) Do not eagerly load every class contained in a deployed jar 2) Establish robust classloader isolation for deployed jars The aim of my current line of work is to fix 1) (GEODE-2290). This is not to say that 2) is not a valuab

Re: One class loader vs multiple class loaders for deployed jars

There are certainly many projects in the OS community that have solved this same problem. Perhaps we can find a class loader from a project that would suite this need. Quick search of standalone frameworks comes up with a few popular hits: https://github.com/kamranzafar/JCL https://github.com/jbos

Re: One class loader vs multiple class loaders for deployed jars

I think Jared started down this path because we had a custom classloader implementation that he was trying to get rid of -- that impl was pretty limited and forced loading of all classes up-front. Now the code uses fast classpath scanner and that old custom classloader can't be used. The old class

Re: One class loader vs multiple class loaders for deployed jars

I think this would be a viable approach in principle, but it would require us to write a custom classloader implementation for what you have described as the application classloader, rather than simply using an implementation from the jdk. On Apr 10, 2017 10:30 AM, "Anthony Baker" wrote: What ab

Re: One class loader vs multiple class loaders for deployed jars

What about this: 1) Each jar is deployed into it’s own classloader. 2) If the classloader for jar1 is unable to load a class, it delegates to its parent which can load classes from siblings to jar1. The classloader hierarchy would be: bootstrap << system << application << (deploy jar)* where t

One class loader vs multiple class loaders for deployed jars

There is last one implementation decision for GEODE-2290 that I'm torn about, namely having one classloader for all deployed jars vs having separate classloaders for each deployed jar. If we have one class loader, e.g. new UrlClassLoader(jar1, jar2), then: - Jar1 will be able to load classes/re