I don't understand the difference between this proposal: > gfsh> deploy resource --name=myApplicationDependencies.jar > gfsh> deploy cache-writer --name=x.y.z.MyApplicationCacheWriter --members=serverX
And this example, which you can already do today: gfsh> depoy --jar=myApplicationStuff.jar gfsh> alter region --cache-writer=x.y.z.MyApplicationCacheWriter As far as the hot swapping classes goes, I agree that that is a really tricky problem. I also agree with Udo that a fine grained approach probably won't work. Since classes tend to be interconnected and refer to each other, you really need swap out everything at once. Application servers do this with war files by serializing all of the session data and creating a new classloader with the war file. This is turning gemfire into a container as everyone is pointing out. -Dan On Fri, Jan 6, 2017 at 12:00 PM, John Blum <jb...@pivotal.io> wrote: > @Luke- > > *> if my CacheWriter had depenancies of its own, would the expectation be > I bundle them as a fat jar and use the explict deploy cachewriter command?* > > Yes, I would envisions something like this... > > gfsh> deploy resource --name=myApplicationDependencies.jar > > gfsh> deploy cache-writer --name=x.y.z.MyApplicationCacheWriter > --members=serverX > > The myApplicationDependencies.jar file would contain the > x.y.z.MyApplicationCacheWriter.class and all the dependencies it needs. > > @Udo- > > *> Do we expect them to have fine grained jars?* > > I think we should assume that we can expect, and we should be ready for > anything our users throw at us. Either we handle it correctly and very > explicitly, or we give them a very detailed message of what went wrong > along and possible ways to fix it. > > I was not thinking a user would be expected to package *Functions*, > *Listeners*, *Loaders*, *Writers*, etc individually, in separate JAR files, > although nothing should prevent them from doing so if they so choose to > organize things that way. Rather, they could deploy a single application > JAR file in 1 fair swoop that contains all the artifacts their application > will potentially need at runtime. As such, `deploy resource` would no > longer be responsible for construction/initializing and registering these > components. It's sole responsibility would be to "upload" the artifact(s) > where they are needed by the application. > > Therefore, the other individual `deploy` commands would then determine what > gets used/put-into-service (e.g. `deploy function` to construct/initialize > and register a Function; `deploy cache-loader` to construct/initialize and > register a CacheLoader callback for read-through on cache miss; etc). > > It would be expected that all these application components would have been > previously deployed first using `deploy resource`, before invoking the > other `deploy' commands. This seems reasonable to me. > > Perhaps to avoid confusion, `deploy resource` could even be called `upload > resource`. > > As to how finely grained components are packaged, i.e. individual JAR > files, a single JAR, or 1 big FAT JAR (a JAR of JARS, classes, and other > resource files... XML, properties, etc) that is a problem for the > ClassLoader to work out. > > -j > > > On Fri, Jan 6, 2017 at 11:37 AM, Udo Kohlmeyer <ukohlme...@pivotal.io> > wrote: > > > In some ways that is a great idea.... but sometimes too explicit... Do we > > expect them to have fine grained jars? > > Also how do we handle dependencies.... as a single util class might be > > used by both a cache-listener and a partition listener... is the > > expectation that we update the dependent util class for one but not the > > other.... > > > > It's a very grey area.... > > > > > > On 1/6/17 11:19, John Blum wrote: > > > >> How about... > >> > >> * deploy function > >> * deploy cache-listener > >> * deploy cache-loader > >> * deploy cache-loader > >> * deploy resource (jar, xml, properties, etc) > >> * etc. > >> > >> Might as was make it explicit. For instance, I may have a JAR file I > just > >> deployed (uploaded) that contains Functions, Listeners, Loaders, > Writers, > >> etc but I only want to deploy functions. > >> > >> Having 1 uber "deploy" command with many options gets cumbersome. > >> > >> It is a simple matter to introduce multiple command but have those > >> commands > >> share similar logic. This would also enable different workflows for > >> different commands in a more non-convoluted, maintainable way. > >> > >> These could be matched with corresponding `undeploy` commands. > >> > >> Food for thought, > >> > >> John > >> > >> > >> > >> On Fri, Jan 6, 2017 at 11:11 AM, Kirk Lund <kl...@apache.org> wrote: > >> > >> With appropriate constraints, a copy file type command could be secure. > >>> > >>> 1) don't use Apache Geode without security AND make the command require > >>> authorization permissions > >>> 2) limit the target directory to a directory under the working > directory > >>> of > >>> the remote server > >>> 3) rename it to "deploy resource" so people don't expect it to copy to > an > >>> arbitrary target directory on the remote machine > >>> > >>> Back to "deploy jar": > >>> > >>> The deploy command is only for deploying Apache Geode callbacks > >>> (Function, > >>> CacheListener, etc). "deploy resource" such Spring jars or Spring xml > >>> files > >>> or anything similar does not overlap with "deploy jar". There is > >>> continued > >>> confusion over what "deploy jar" is or does. I propose we rename it to > >>> "deploy functions" or "deploy callbacks" or something along those lines > >>> to > >>> end the confusion. > >>> > >>> 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 > >>>> > >>>> 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) >
