@Dan- `deploy resource` is like `deploy jar` today, but *without* the additional steps of constructing/initializing and (possibly) registering GemFire objects (which currently only handles Functions today).
The idea is, a user may not want the same objects applied to all servers/nodes in the cluster, especially if all their application artifacts and dependencies are all uploaded in 1 JAR (which is as it should be, but technically, is an application developers design decision, IMO). For instance, a Function does not (and perhaps, should not) necessarily be deployed on every single node in the cluster. And by "deploy" I really mean "applied"; not whether the bits physically exists or not. In fact, the bits should exist on all nodes in case the user wants to deploy/apply the Function, Listener, or whatever, to another existing, or possibly new node in the cluster. The same might be true of a Loader or Writer, though I don't recall whether Geode may think the Region configuration conflicts in this case if all nodes hosting the Region do not have the same Listeners, Loader and Writer configured???. Anyhow... perhaps "deploy" is the wrong terminology as I did not mean that each individual `deploy` command: `deploy function`, `deploy cache-listener`, etc, "uploads" artifacts; NO, yuck! Only `deploy resource`, or rather `upload resource` would. SIDE NOTE: We keep talking about containers as if they just handle class loading or something. That is not all that is required to be a container, much less, a completely "managed" environment (which PCF has covered)!. Class loading is an implementation detail. It would have been easier if containers just forked individual JVM processes, IMO (some do). Spring XD switched from class loading to individual JVM processes in SCDF. This class loading business is highly error prone, and, well, overly complicated to get right in all situations. In addition, you cannot be a proper container without an SPI or extension points to customize lifecycle, scope, events, etc, all the things application components need in a managed environment. On Fri, Jan 6, 2017 at 1:34 PM, Michael Stolz <mst...@pivotal.io> wrote: > Does all this stuff get easier if we actually create a Spring Boot > application that embeds Geode server functionality? > > -- > Mike Stolz > Principal Engineer, GemFire Product Manager > Mobile: 631-835-4771 > > On Fri, Jan 6, 2017 at 4:11 PM, John Blum <jb...@pivotal.io> wrote: > > > *@Anthony-* > > > > *> The server should be smart enough to figure out what's in my bundle > and > > understand how to deploy it including any dependencies* > > > > Agreed on the dependencies part, but... "*smart enough to figure out > what's > > in my bundle*". Hmmm. Beyond recognizing Geode/GemFire > > objects/interfaces, I don't see how this is likely. > > > > For instance, I recently added the ability (SGF-106 > > <https://jira.spring.io/browse/SGF-106> [1]) in SDG to create Indexes > > using > > Annotations on application domain objects/entities properties/fields when > > using the SDG mapping support > > <http://docs.spring.io/spring-data-gemfire/docs/current/ > > reference/html/#mapping> > > [2] > > (and SD *Repositories*). Currently, Geode/GemFire does not even > recognize > > SDG "defined" (annotated) Functions. How is it going to know (or how I > am > > I going tell it) about Index annotations now, or something else. Of > > course, Geode/GemFire could delegate to the *Spring* container in both > > instances, but that does not cover cases where *Spring* is not used. > > > > [1] https://jira.spring.io/browse/SGF-106 > > [2] > > http://docs.spring.io/spring-data-gemfire/docs/current/ > > reference/html/#mapping > > > > > > On Fri, Jan 6, 2017 at 12:49 PM, Jacob Barrett <jbarr...@pivotal.io> > > wrote: > > > > > We need to take a lesson from any modern Java application an embrace > > class > > > loader modularization. The only thing in the system class path should > be > > > very minimal bootstrap jar. The rest of our needs should be addressed > by > > > well organized and isolated class loaders. > > > > > > The deployment of a function, or set of functions, should operate in a > > > fully isolated class loader. The deployment should include all > > dependencies > > > except for the APIs provided by the Geode framework. > > > > > > -Jake > > > > > > On Fri, Jan 6, 2017 at 8:13 AM Michael Stolz <mst...@pivotal.io> > wrote: > > > > > > > So maybe a generic copy command is too insecure, I agree. > > > > What we should do is think about exactly what files we think we are > > > trying > > > > to deploy. > > > > > > > > 1. I believe that there is a need to deploy dependency jars into > the > > > > system classpath. > > > > 2. I believe that there is also a desire to be able to deploy > Spring > > > > Data Geode xml configuration files. > > > > 3. There is also an issue with attempting to deploy Spring Data > > Geode > > > > functions that we should try to work out. > > > > > > > > Anything else that anyone is aware of? > > > > > > > > > > > > > > > > > > > > -- > > > > Mike Stolz > > > > Principal Engineer, GemFire Product Manager > > > > Mobile: 631-835-4771 <(631)%20835-4771> > > > > > > > > On Fri, Jan 6, 2017 at 10:59 AM, Jacob Barrett <jbarr...@pivotal.io> > > > > wrote: > > > > > > > > > Agree with Anthony. A copy command would either duplicate what > deploy > > > > does > > > > > by only putting files within as specific location in the server's > > > > directory > > > > > or creating a security nightmare if allowed to write anywhere on > the > > > > host. > > > > > > > > > > > > > > > On Fri, Jan 6, 2017 at 7:56 AM Anthony Baker <aba...@pivotal.io> > > > wrote: > > > > > > > > > > > I think there are lots of great OS orchestration and automation > > > tools. > > > > > > I’m not sure I understand the need for `gfsh cp`. If I could > > easily > > > > grab > > > > > > the member hostnames from `gfsh list members` and pipe them into > > > mpssh > > > > > (for > > > > > > example) that would do the job. > > > > > > > > > > > > I *do* like the idea of an improved `gfsh deploy` that supports > hot > > > > > deploy > > > > > > and reconfiguration. > > > > > > > > > > > > Anthony > > > > > > > > > > > > > On Jan 6, 2017, at 2:38 AM, Swapnil Bawaskar < > > sbawas...@pivotal.io > > > > > > > > > > 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) > > > -- -John john.blum10101 (skype)
