The problem is always tricky when you are working with dependencies and class loading. It is a two part problem.
1. First, you must acquire and deploy the dependencies an application will need at runtime. This can be achieved many different ways, such as by "copying" files to a designated, well-known location, adding them to the classpath on startup, or perhaps, you provide a meta-data file with dependency declarations like Maven/Gradle the resolves the dependencies and adds to the classpath at startup. 2. Then, you need to apply those dependencies, possible without bringing down the server. This is much more difficult to achieve, particularly since deploying and possibly "updating" dependencies will possibly (and most likely) disrupt the lifecycle of the (previously) deployed code. I have said Geode/GemFire is not an application container, and it's not. This extends well beyond classpath isolation too. There is a sharp contrast between deploying Functions (equivalent to Stored Procedures/Functions in a RDBMS), or other types of callbacks (CacheListeners, Loader, Writers) and deploying and running, say, *Spring* code in Geode/GemFire. While the former can be done without bringing down Geode/GemFire, the later is much more difficult since the *Spring* ApplicationContext (aka a "container") must be, in effect, restarted. This in-turn can have adverse affects on other the application components/beans that may be defined within that (nested) context, which have nothing to do with Geode/GemFire. These components, may in turn acquire and potentially use other system resources; think DataSources, Files, Message Queues, etc. Managing these sort of interactions is much more complex and cannot happen effectively without proper lifecycle events/messaging and scopes (e.g. singleton, prototype, session, request/thread, etc) provided by the container. The closet Geode/GemFire comes to messaging for the application components is the ResourceEventsListener <https://github.com/apache/geode/blob/rel/v1.0.0-incubating/geode-core/src/main/java/org/apache/geode/distributed/internal/ResourceEventsListener.java> [1] and the corresponding ResourceEvent <https://github.com/apache/geode/blob/rel/v1.0.0-incubating/geode-core/src/main/java/org/apache/geode/distributed/internal/ResourceEvent.java> [2] (which has "interesting" to application components type events), neither which is part of the public API. Still, this is not enough as application components would need an event hierarchy (for example <http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/context/ApplicationEvent.html> [3]) where it could fire it's own type of events as well. It's not uncommon for some system/environments to be "scriptable", but that is much different than application code that is managed by a container. For these reasons, as well as others, I generally do not recommend users use Geode/GemFire to bootstrap other application code, rather the inverse is more sensible and more flexible as you migrate to other "managed" environments, like PCF. 1 thing is for certain though, users are going to want the ability to "manage" their application dependencies (i.e. upgrade, provide their own, etc), which may also be required by the services (e.g. Geode/GemFire) their applications consume in that managed environment. -John [1] https://github.com/apache/geode/blob/rel/v1.0.0-incubating/geode-core/src/main/java/org/apache/geode/distributed/internal/ResourceEventsListener.java [2] https://github.com/apache/geode/blob/rel/v1.0.0-incubating/geode-core/src/main/java/org/apache/geode/distributed/internal/ResourceEvent.java [3] http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/context/ApplicationEvent.html On Fri, Jan 6, 2017 at 10:03 AM, Kirk Lund <kl...@pivotal.io> wrote: > Even though Apache Geode is accepting jars containing Geode callback > implementations (Functions, CacheListener, etc), it's NOT a container or > application server. You can WANT it to be a container or EXPECT it to be a > container but it's not ;) This would require Apache Geode becoming an > application server. To become an application server would require extensive > rearchitecting to introduce a complex classloading hierarchy for > application isolation. Whether you want this functionality or not, the > unfortunate truth is it cannot be done in a few weeks by a few developers. > If it's important then it becomes one of the few new features that can be > added to something like Geode in a given year. It would be better to find > other open-source containers such as Apache Felix and install Apache Geode > in it and then use Felix as the container. We could theoretically turn > Apache Geode into a project that depends on Apache Felix (or another > container project) such that starting an Apache Geode Locator or Server > actually starts up an Apache Felix process with Geode running inside it and > available for applications that are then deployed into Felix. > > > On Fri, Jan 6, 2017 at 9:44 AM, Real Wes <thereal...@outlook.com> wrote: > > > Here’s a use-case I’m dealing with right now: A single cluster > supporting > > multiple applications (i.e. a multi-tenant cluster). One new application > > wants to do Spring http session replication. This requires placing 3 > Spring > > jars onto the start server —classpath=$SPRING_JARS:… It requires a > cluster > > bounce. > > > > Would be really nice to do this without bouncing the entire cluster. May > > need to do so anyway since this is a Java restriction, but at least you > > see a real use-case. > > > > Wes > > > > > On Jan 6, 2017, at 12:11 PM, Jens Deppe <jde...@pivotal.io> wrote: > > > > > > Got to chime in here and +1 on what Anthony's and Jake's sentiments > are. > > > > > > Let's be *very* careful and try to understand what users are trying to > > > achieve. > > > > > > If we're providing a 'gfsh cp' option that then requires further > > > intervention to actually achieve what the user wants (i.e. server > restart > > > or whatever is required to now use the new files) then we're nowhere > > better > > > off than we are now. 'gfsh cp' seems like a targeted solution. > > > > > > I'd prefer to see us do a better job of classloading and have that be > > > clearly specified. Someone mentioned that Geode isn't a container but I > > > would argue that as soon as we can accept and run somebody else's code > > > we're a container and should provide facilities to dynamically manage > the > > > lifecycle of that code. > > > > > > --Jens > > > > > > On Fri, Jan 6, 2017 at 8:31 AM, Udo Kohlmeyer <ukohlme...@pivotal.io> > > wrote: > > > > > >> I think I can see the benefit of this feature. > > >> > > >> If you have Geode running in the cloud, it is easier to have a single > > >> management tool that can copy resource files to all the servers within > > the > > >> cluster. > > >> > > >> Although I would not see this a feature I'd promote, as it could > really > > be > > >> abused, I believe it would work well for cloud environments. > > >> > > >> --Udo > > >> > > >> > > >> > > >> On 1/6/17 02:38, Swapnil Bawaskar wrote: > > >> > > >>> Some application may need to copy files to all the servers. These > files > > >>> could either be data files or they could be configuration files > needed > > by > > >>> the application or they could be jar files (that don't have functions > > but > > >>> have say, spring data geode jar files) that need to be on the > server's > > >>> classpath. > > >>> We could accomplish this by enhancing the current gfsh "deploy" > > command to > > >>> accept any kind of file and write it to the servers file system OR > > create > > >>> a > > >>> new gfsh "copy" command to copy any arbitrary file to the servers. > > >>> I would personally like to repurpose the deploy command but would > like > > to > > >>> hear the community's opinion. > > >>> > > >>> Thanks! > > >>> > > >>> > > >> > > > > > -- -John john.blum10101 (skype)
