Different module or different repo is same thing I'm suggesting. Make it separate and independent such that a Client can be compiled only with geode-client-ai.jar.
On Wed, Apr 26, 2017 at 4:52 PM, Bruce Schuchardt <bschucha...@pivotal.io> wrote: > I don't think we should mix the old client code with a new API. We should > keep the new client code separate from the server. Maybe even in a > different repo, as I think Fred suggested. > > Le 4/26/2017 à 3:12 PM, Kirk Lund a écrit : > >> If we want to add a new API then I suggest we create new API packages and >> leave the "cache" package as the old deprecated API for backwards >> compatibility. >> >> The new APIs and implementation could be separated into different geode >> modules and packages (something like what follows): >> >> org.apache.geode.api -- the main rich API (geode-api module and jar) >> org.apache.geode.api.client -- the new thin client API (geode-api-client >> module and jar) >> org.apache.geode.core -- the main implementation of api (geode-core module >> and jar which also currently contains the old API) >> >> On Wed, Apr 26, 2017 at 9:41 AM, William Markito Oliveira < >> william.mark...@gmail.com> wrote: >> >> This is an awesome discussion and Jake's hitting all the right notes about >>> why JCache is a good idea! I've fought that fight in the past and lost it >>> but I'm happy to see it coming back... >>> >>> What's really nice about Geode is that the functionalities and >>> capabilities >>> are all there, they're just not that well exposed, known by others or >>> obscured by some decisions that doesn't apply anymore. >>> >>> It's the same conversation about monitoring and statistics... All the >>> capability is there with JMX and Stats, but using an unknown custom >>> format >>> or tool to display that data makes it not very appealing for OSS and >>> enterprise users that need workarounds and hacks to integrate with common >>> monitoring tools. >>> >>> Refactoring API Client APIs, documentation and implementation of a new >>> Protocol, Reactive APIs, better integration with standard monitoring >>> tools >>> - Sounds like good points for a 2.0 roadmap IMHO. >>> >>> >>> On Wed, Apr 26, 2017 at 10:28 AM, Jacob Barrett <jbarr...@pivotal.io> >>> wrote: >>> >>> Wes, >>>> >>>> Those are almost all administrative commands and have no place on the >>>> client API. They belong on an administrative API or as I'm arguing a >>>> >>> series >>> >>>> of MBeans/JMX as it is already an established standard. >>>> >>>> -Jake >>>> >>>> On Wed, Apr 26, 2017 at 8:09 AM Wes Williams <wwilli...@pivotal.io> >>>> >>> wrote: >>> >>>> Now we're getting some precision. Let's talk about the "raw" Geode >>>>> proprietary bad ass API! Would that "raw" Geode proprietary bad ass >>>>> >>>> API >>> >>>> "raw" >>>>> Geode proprietary bad ass API that we're talking about be centered >>>>> >>>> around >>> >>>> the commands found here: >>>>> >>>>> https://github.com/apache/geode/tree/rel/v1.1.1/geode- >>>>> >>>> core/src/main/java/org/apache/geode/management/internal/cli/commands >>>> >>>>> Or somewhere else? >>>>> >>>>> *Wes Williams | Pivotal Advisory **Data Engineer* >>>>> 781.606.0325 >>>>> http://pivotal.io/big-data/pivotal-gemfire >>>>> >>>>> On Tue, Apr 25, 2017 at 11:41 PM, Jacob Barrett <jbarr...@pivotal.io> >>>>> wrote: >>>>> >>>>> Java and its community have standards for all of these issue so why >>>>>> re-invent the wheel. The market doesn't want proprietary anymore, >>>>>> >>>>> they >>> >>>> want >>>>> >>>>>> standards and mobility. >>>>>> >>>>>> Configuration of the server should happen through MBeans. You can >>>>>> >>>>> wrap >>> >>>> that >>>>> >>>>>> in gfsh for command line, REST for remote web based admin, use >>>>>> >>>>> JConsole >>> >>>> or >>>>> >>>>>> any other number of JMX based enterprise management tools. By using >>>>>> >>>>> MBeans >>>>> >>>>>> the server can easily expose new discovered services without the need >>>>>> >>>>> to >>>> >>>>> code specific gfsh commands, REST interfaces or APIs. There is no >>>>>> >>>>> reason >>>> >>>>> my >>>>> >>>>>> SDG can't be retooled to "discover" the configuration from these >>>>>> >>>>> MBeans >>> >>>> as >>>>> >>>>>> well rather than having to be touched every time we add or change >>>>>> something. There are tools and books already written that >>>>>> >>>>> implementors >>> >>>> can >>>>> >>>>>> consult on MBeans. There isn't anything out there on gfsh commands. >>>>>> >>>>>> If we want to play in the Java community, especially J2EE (the other >>>>>> >>>>> 50% >>>> >>>>> of >>>>> >>>>>> Java that isn't Spring), then we had better have a JSR-107 answer no >>>>>> >>>>> matter >>>>> >>>>>> what the pain is to provide it. I can pull dozens of books of the >>>>>> >>>>> shelf >>> >>>> that teach me how to effectively use a JCache, how many can I pull >>>>>> >>>>> off >>> >>>> the >>>>> >>>>>> shelf that teach me Geode's API? How many engineers can I get >>>>>> >>>>> applications >>>>> >>>>>> form by saying "must have Geode API knowledge"? I can find people >>>>>> >>>>> with >>> >>>> JCache knowledge though. So from in implementor's perspective having >>>>>> standards is a must. Now I don't think the JSR-107 interface should >>>>>> >>>>> be >>> >>>> the >>>>> >>>>>> root interface but rather a facade on the "raw" Geode proprietary bad >>>>>> >>>>> ass >>>> >>>>> API. That API should be 100% asynchronous (reactive, SEDA, whatever >>>>>> >>>>> the >>> >>>> current buzzword for asynchronous is today). Around that API we can >>>>>> >>>>> provide >>>>> >>>>>> facades for JSR 107, ConcurrentMap (our current yet not so well >>>>>> >>>>> behaving >>>> >>>>> API), List, Queue, etc. Maybe even JPA, JCA, etc. The thought of >>>>>> >>>>> putting >>>> >>>>> all those features into a single API makes my head exploded and they >>>>>> >>>>> don't >>>>> >>>>>> need to be like they are today. >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Apr 25, 2017 at 8:25 PM Wes Williams <wwilli...@pivotal.io> >>>>>> >>>>> wrote: >>>>> >>>>>> A couple of points to interact with John's points. >>>>>>> >>>>>>> GFSH as API >>>>>>> >>>>>>> We agree that GFSH is a DSL, and a really good and useful one. We >>>>>>> >>>>>> agree >>>> >>>>> that we don't want our API tied to GFSH syntax. I view the valuable >>>>>>> >>>>>> part >>>>> >>>>>> of >>>>>> >>>>>>> GemFire admin as the Java code underneath GFSH, or the "Commands." >>>>>>> >>>>>>> For example, to create a JAVA API to "Create Region", why not >>>>>>> >>>>>> create a >>>> >>>>> Java API around CreateAlterDestroyRegionCommands? In this way, >>>>>>> >>>>>> GFSH >>> >>>> and >>>> >>>>> the >>>>>> >>>>>>> JAVA API share the same code. It seems too obvious yet I don't see >>>>>>> >>>>>> it >>> >>>> being >>>>>> >>>>>>> recommended. Why not? (Note: the hard-coded formatting would need >>>>>>> >>>>>> to >>>> >>>>> be >>>>> >>>>>> removed). >>>>>>> >>>>>>> Once you have the Java/GFSH/REST API as common code, you then >>>>>>> >>>>>> refactor >>>> >>>>> it. >>>>>> >>>>>>> What's the objection to this approach? Once you open Java API's to >>>>>>> >>>>>> do >>> >>>> everything that GFSH does, then you have now unshackled the power >>>>>>> >>>>>> of >>> >>>> the >>>>> >>>>>> developer (the JAVA API) and the admin (GFSH API). >>>>>>> >>>>>>> >>>>>>> REST API >>>>>>> >>>>>>> I've found that most don't want to use the Dev REST API because >>>>>>> >>>>>> it's >>> >>>> attached to a server rather than the cluster. HA? >>>>>>> >>>>>>> >>>>>>> *Wes Williams | Pivotal Advisory **Data Engineer* >>>>>>> 781.606.0325 <(781)%20606-0325> >>>>>>> http://pivotal.io/big-data/pivotal-gemfire >>>>>>> >>>>>>> On Tue, Apr 25, 2017 at 7:01 PM, Fred Krone <fkr...@pivotal.io> >>>>>>> >>>>>> wrote: >>>> >>>>> Good feedback. >>>>>>>> >>>>>>>> This would use the new protocol. I should have mentioned that. >>>>>>>> >>>>>>>> The original driver for this was the Region API needs either an >>>>>>>> >>>>>>> update >>>>> >>>>>> or >>>>>> >>>>>>> an alternative. Updating has a few drawbacks: Region wasn't >>>>>>>> >>>>>>> designed >>>> >>>>> with >>>>>>> >>>>>>>> open source in-mind and as Swap mentioned it is naturally tightly >>>>>>>> >>>>>>> coupled. >>>>>>> >>>>>>>> Members of the community are already working to update Region but >>>>>>>> >>>>>>> something >>>>>>> >>>>>>>> gets fixed and it breaks something for someone else. I think >>>>>>>> >>>>>>> it's >>> >>>> much >>>>> >>>>>> better to provide a new interface that implements the first part >>>>>>>> >>>>>>> of >>> >>>> JSR >>>>> >>>>>> 107 >>>>>>> >>>>>>>> (javax.cache) and get the ball rolling for the community and, >>>>>>>> >>>>>>> perhaps, >>>>> >>>>>> over >>>>>>> >>>>>>>> time deprecate Region (although that's not a primary objective). >>>>>>>> >>>>>>>> A Java driver will probably get built regardless just to give the >>>>>>>> >>>>>>> new >>>> >>>>> protocol some legs. That driver also needs a decent caching >>>>>>>> >>>>>>> interface. >>>>> >>>>>> JSR >>>>>>> >>>>>>>> 107 has already solved that part. So let's get started on it. >>>>>>>> >>>>>>> If >>> >>>> the >>>>> >>>>>> community wants to go the whole way and continue JSR 107 >>>>>>>> >>>>>>> implementation >>>>> >>>>>> after that that's awesome. Functions can also be added, etc. >>>>>>>> >>>>>>>> I intentionally did not mention anything about PCF as this >>>>>>>> >>>>>>> pertains >>> >>>> to >>>>> >>>>>> Geode itself as an open source offering and developer experience. >>>>>>>> >>>>>>> I'm >>>>> >>>>>> writing as a member of the community. Ie: I'm a developer who >>>>>>>> >>>>>>> would >>> >>>> like >>>>>> >>>>>>> to >>>>>>> >>>>>>>> add some caching to my application -- I can download either Geode >>>>>>>> >>>>>>> or >>>> >>>>> Hazelcast for free and right now it's a no brainer. Not that we >>>>>>>> >>>>>>> wouldn't >>>>>> >>>>>>> keep PCF in-mind but it's out of scope for this thread. I do >>>>>>>> >>>>>>> believe >>>> >>>>> getting started on a Java driver for the protocol and a >>>>>>>> >>>>>>> standardized >>>> >>>>> caching API are easily leveraged wins across the board. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Apr 25, 2017 at 3:20 PM, Swapnil Bawaskar < >>>>>>>> >>>>>>> sbawas...@pivotal.io> >>>>>> >>>>>>> wrote: >>>>>>>> >>>>>>>> I had looked at the JCache in the past and here are some of the >>>>>>>>> >>>>>>>> things >>>>>> >>>>>>> I >>>>>>> >>>>>>>> noted: >>>>>>>>> >>>>>>>>> Naming convention: Geode's region is a Cache in JSR-107, and >>>>>>>>> >>>>>>>> Geode's >>>>> >>>>>> Cache >>>>>>>> >>>>>>>>> is a CacheManager. I think it would be too confusing to change >>>>>>>>> >>>>>>>> the >>>> >>>>> meaning >>>>>>>> >>>>>>>>> of cache. Also, how do you document this given that Cache means >>>>>>>>> >>>>>>>> different >>>>>>> >>>>>>>> things if you are talking JCache vs Geode. >>>>>>>>> >>>>>>>>> The way to create a Cache in JSR-107 is: >>>>>>>>> Cache<Integer, Date> cache = manager.createCache(cacheName, >>>>>>>>> >>>>>>>> Configuration >>>>>>> >>>>>>>> c); >>>>>>>>> Where it is upto the implementation to extend Configuration. >>>>>>>>> >>>>>>>> Given >>>> >>>>> this, >>>>>>> >>>>>>>> users will not be able to switch from an existing >>>>>>>>> >>>>>>>> implementation >>> >>>> to >>>> >>>>> ours; >>>>>>> >>>>>>>> will have to write new code specially Configuration, making >>>>>>>>> >>>>>>>> callbacks >>>>> >>>>>> serializable etc. >>>>>>>>> >>>>>>>>> JSR-107 will not be limited to the client. Server side >>>>>>>>> >>>>>>>> callbacks >>> >>>> like >>>>> >>>>>> CacheLoader, CacheListener etc. will need handle on jsr-107 >>>>>>>>> >>>>>>>> “cache”. >>>>> >>>>>> JSR-107 supports features like an EntryProcessor, which is a >>>>>>>>> >>>>>>>> function >>>>> >>>>>> invoked atomically on an entry operation. We will have to make >>>>>>>>> >>>>>>>> invasive >>>>>> >>>>>>> changes to Geode to support this. >>>>>>>>> >>>>>>>>> Given these, I don't think supporting JSR-107 is trivial. >>>>>>>>> >>>>>>>>> On Tue, Apr 25, 2017 at 2:55 PM Dan Smith <dsm...@pivotal.io> >>>>>>>>> >>>>>>>> wrote: >>>>> >>>>>> What transport are you planning on using? REST, or the >>>>>>>>>> >>>>>>>>> current >>> >>>> binary >>>>>> >>>>>>> protocol? Or is this just a wrapper around the existing java >>>>>>>>>> >>>>>>>>> client >>>>> >>>>>> APIs? >>>>>>>> >>>>>>>>> If this about creating a new API, I agree with what John is >>>>>>>>>> >>>>>>>>> saying >>>>> >>>>>> that >>>>>>> >>>>>>>> we >>>>>>>>> >>>>>>>>>> need reduce the number of APIs we have to do the same thing >>>>>>>>>> >>>>>>>>> in >>> >>>> java. >>>>>> >>>>>>> It >>>>>>> >>>>>>>> seems especially confusing if we end up with different APIs >>>>>>>>>> >>>>>>>>> that >>>> >>>>> support >>>>>>>> >>>>>>>>> distinct features - like being able to create a region on the >>>>>>>>>> >>>>>>>>> server >>>>>> >>>>>>> with >>>>>>>> >>>>>>>>> this new API but only being able to invoke a function with >>>>>>>>>> >>>>>>>>> the >>> >>>> old >>>>> >>>>>> API. >>>>>>> >>>>>>>> The other thing I think we need to avoid is being able to do >>>>>>>>>> >>>>>>>>> things >>>>> >>>>>> from >>>>>>>> >>>>>>>>> the client (or gfsh, or xml, ...) that don't have a java API >>>>>>>>>> >>>>>>>>> on >>> >>>> the >>>>> >>>>>> server. >>>>>>>>> >>>>>>>>>> I'm assuming your getOrCreateRegion region is supposed behave >>>>>>>>>> >>>>>>>>> like >>>>> >>>>>> the >>>>>>> >>>>>>>> gfsh >>>>>>>>> >>>>>>>>>> command and update the cluster configuration? +++1 to Wes's >>>>>>>>>> >>>>>>>>> suggestion >>>>>>> >>>>>>>> have >>>>>>>>> >>>>>>>>>> a public API for executing these gfsh operations. >>>>>>>>>> >>>>>>>>>> I really think we need to work on having *one* authoritative >>>>>>>>>> >>>>>>>>> public >>>>> >>>>>> API >>>>>>> >>>>>>>> that contains everything that we support on the server. The >>>>>>>>>> >>>>>>>>> protocols >>>>>> >>>>>>> we >>>>>>>> >>>>>>>>> support (REST, binary, ...) and the client drivers that use >>>>>>>>>> >>>>>>>>> those >>>> >>>>> protocols >>>>>>>>> >>>>>>>>>> should just be ways of accessing that API. The Java API on >>>>>>>>>> >>>>>>>>> the >>> >>>> server >>>>>> >>>>>>> right >>>>>>>>> >>>>>>>>>> now the closest thing we have to this, but there are things >>>>>>>>>> >>>>>>>>> you >>> >>>> can >>>>> >>>>>> do >>>>>>> >>>>>>>> with >>>>>>>>> >>>>>>>>>> gfsh and things you can do with the current client that have >>>>>>>>>> >>>>>>>>> no >>> >>>> java >>>>>> >>>>>>> API >>>>>>>> >>>>>>>>> equivalent. I think we really need to fix that! >>>>>>>>>> >>>>>>>>>> Also, preferably we won't have to hand code a bunch of stuff >>>>>>>>>> >>>>>>>>> in >>> >>>> every >>>>>> >>>>>>> client driver and protocol whenever we add a new feature. For >>>>>>>>>> >>>>>>>>> example >>>>>> >>>>>>> if >>>>>>>> >>>>>>>>> were to add a geode function to invoke each new API we add, >>>>>>>>>> >>>>>>>>> that >>>> >>>>> new >>>>>> >>>>>>> API >>>>>>>> >>>>>>>>> would be accessible from REST, gfsh, the java client etc. >>>>>>>>>> >>>>>>>>> Later >>> >>>> we >>>>> >>>>>> could >>>>>>>> >>>>>>>>> add syntatic sugar to make the new API prettier, but if we >>>>>>>>>> >>>>>>>>> had >>> >>>> a >>>> >>>>> low >>>>>> >>>>>>> level >>>>>>>>> >>>>>>>>>> API that automatically exposed all new features that would >>>>>>>>>> >>>>>>>>> make >>> >>>> adding >>>>>>> >>>>>>>> new >>>>>>>>> >>>>>>>>>> features much less painful. >>>>>>>>>> >>>>>>>>>> I do like the idea of adding a reactive API. >>>>>>>>>> >>>>>>>>>> Supporting JSR-107 might be nice - but that could probably >>>>>>>>>> >>>>>>>>> be >>> >>>> written >>>>>>> >>>>>>>> just >>>>>>>>> >>>>>>>>>> as a wrapper around the current API without too much work. I >>>>>>>>>> >>>>>>>>> don't >>>>> >>>>>> think >>>>>>>> >>>>>>>>> we >>>>>>>>> >>>>>>>>>> should do anything for JSR-107 other than provide a JSR-107 >>>>>>>>>> >>>>>>>>> compatible >>>>>>> >>>>>>>> wrapper - if someone wants additional geode specific features >>>>>>>>>> >>>>>>>>> they >>>>> >>>>>> should >>>>>>>> >>>>>>>>> drop into the existing API. >>>>>>>>>> >>>>>>>>>> I also like the idea of a smaller client jar and >>>>>>>>>> >>>>>>>>> dependencies, >>> >>>> but >>>>> >>>>>> I >>>>>> >>>>>>> think >>>>>>>>> >>>>>>>>>> there is a huge amount of room for improvement in our >>>>>>>>>> >>>>>>>>> existing >>> >>>> client >>>>>> >>>>>>> just >>>>>>>>> >>>>>>>>>> by refactoring the code a bit more and shinking geode-core >>>>>>>>>> >>>>>>>>> into a >>>> >>>>> bare >>>>>>> >>>>>>>> minimum. >>>>>>>>>> >>>>>>>>>> -Dan >>>>>>>>>> >>>>>>>>>> On Mon, Apr 24, 2017 at 8:20 PM, Fred Krone < >>>>>>>>>> >>>>>>>>> fkr...@pivotal.io >>> >>>> wrote: >>>>>>> >>>>>>>> That's great, Wes. I will take a look. Thanks. >>>>>>>>>>> >>>>>>>>>>> John -- good feedback to consider and I was hoping this >>>>>>>>>>> >>>>>>>>>> would >>> >>>> come >>>>>> >>>>>>> up. >>>>>>>> >>>>>>>>> "In my mind, there really are only 2 approaches... *Spring* >>>>>>>>>>> >>>>>>>>>> and >>>> >>>>> non-*Spring*, >>>>>>>>>>> or rather PCF and non-PCF, and since PCF is primarily based >>>>>>>>>>> >>>>>>>>>> on >>>> >>>>> Boot >>>>>> >>>>>>> (given >>>>>>>>>> >>>>>>>>>>> Microservices/applications are the new concurrency), then I >>>>>>>>>>> >>>>>>>>>> am >>>> >>>>> really >>>>>>> >>>>>>>> saying the same thing." >>>>>>>>>>> >>>>>>>>>>> This would be cover non spring and attempt to give the >>>>>>>>>>> >>>>>>>>>> community >>>>> >>>>>> something >>>>>>>>>> >>>>>>>>>>> that had the same standardized experience as JSR 107 -- >>>>>>>>>>> >>>>>>>>>> starting >>>>> >>>>>> with >>>>>>> >>>>>>>> the >>>>>>>>> >>>>>>>>>> Cache interface itself. Although we don't necessarily have >>>>>>>>>>> >>>>>>>>>> to >>>> >>>>> implement >>>>>>>>> >>>>>>>>>> Cache, it's method signatures are essentially a (non >>>>>>>>>>> >>>>>>>>>> spring) >>> >>>> caching >>>>>>> >>>>>>>> standard for Java developers at this point. We considered >>>>>>>>>>> >>>>>>>>>> full >>>>> >>>>>> blown >>>>>>>> >>>>>>>>> JSR >>>>>>>>>> >>>>>>>>>>> 107 implementation but thought it was too robust for the >>>>>>>>>>> >>>>>>>>>> needs >>>> >>>>> mentioned >>>>>>>>> >>>>>>>>>> (that's not to say we couldn't get there incrementally). I >>>>>>>>>>> >>>>>>>>>> think >>>>> >>>>>> those >>>>>>>> >>>>>>>>> needs still exist open-source outside of PCF and don't >>>>>>>>>>> >>>>>>>>>> cannibalize. >>>>>> >>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Mon, Apr 24, 2017 at 7:44 PM, Real Wes < >>>>>>>>>>> >>>>>>>>>> thereal...@outlook.com> >>>>>> >>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Here is a simple Java client _for enterprise use_ that I >>>>>>>>>>>> >>>>>>>>>>> developed >>>>>>> >>>>>>>> for >>>>>>>>> >>>>>>>>>> Geode and distributed to several enterprises. It has >>>>>>>>>>>> >>>>>>>>>>> similarities >>>>>> >>>>>>> and >>>>>>>> >>>>>>>>> differences for your goal. This project creates both >>>>>>>>>>>> >>>>>>>>>>> server >>> >>>> and >>>>> >>>>>> client >>>>>>>>> >>>>>>>>>> regions dynamically. It lists regions, alters regions… >>>>>>>>>>>> >>>>>>>>>>> really >>>>> >>>>>> anything >>>>>>>>> >>>>>>>>>> that GFSH can do. It differs in that it calls GFSH to do >>>>>>>>>>>> >>>>>>>>>>> its >>>> >>>>> work >>>>>> >>>>>>> rather >>>>>>>>>> >>>>>>>>>>> than a Java interface. You can think of this as a Java >>>>>>>>>>>> >>>>>>>>>>> API >>> >>>> on >>>> >>>>> top >>>>>> >>>>>>> of >>>>>>>> >>>>>>>>> GFSH. >>>>>>>>>>> >>>>>>>>>>>> You can use this model and keep the similarities while >>>>>>>>>>>> >>>>>>>>>>> adjusting >>>>>> >>>>>>> for >>>>>>>> >>>>>>>>> the >>>>>>>>>> >>>>>>>>>>> Java interface. >>>>>>>>>>>> >>>>>>>>>>>> Similarities >>>>>>>>>>>> - Client uses SDG and complies with JSR-107 >>>>>>>>>>>> [the Cache Manager is here: >>>>>>>>>>>> >>>>>>>>>>> https://github.com/Pivotal- >>>> >>>>> Data-Engineering/ClusterManagement/tree/master/ >>>>>>>>>>>> >>>>>>>>>>>> cluster-management-client/src/main/java/com/geode/cache/manager >>>>> >>>>>> ] >>>>>> >>>>>>> - After the server creates its region, client creates its >>>>>>>>>>>> >>>>>>>>>>> region >>>>>> >>>>>>> [ see createRegions at: https://github.com/Pivotal- >>>>>>>>>>>> >>>>>>>>>>> Data-Engineering/ >>>>>>>>>>> >>>>>>>>>>>> ClusterManagement/blob/master/cluster-management- >>>>>>>>>>>> >>>>>>>>>>>> client/src/main/java/com/geode/cache/manager/ >>>>>>>>>> >>>>>>>>> RegionCreator.java<https:// >>>>>>>> >>>>>>>>> github.com/Pivotal-Data-Engineering/ClusterManagement/ >>>>>>>>>>>> >>>>>>>>>>> blob/master/cluster- >>>>>>>>>>> >>>>>>>>>>>> management-client/src/main/java/com/geode/cache/manager/ >>>>>>>>>>>> >>>>>>>>>>> RegionCreator.java> >>>>>>>>>>> >>>>>>>>>>>> ] >>>>>>>>>>>> >>>>>>>>>>>> Differences >>>>>>>>>>>> Server dynamically calls GFSH to execute commands >>>>>>>>>>>> >>>>>>>>>>>> How it works >>>>>>>>>>>> - Whenever the client calls a region that does not exist, >>>>>>>>>>>> >>>>>>>>>>> the >>>> >>>>> client >>>>>>>> >>>>>>>>> looks >>>>>>>>>>> >>>>>>>>>>>> for a <region name>.properties file. If the properties >>>>>>>>>>>> >>>>>>>>>>> file >>> >>>> exists, >>>>>>> >>>>>>>> the >>>>>>>>> >>>>>>>>>> region is created with the dynamic properties. >>>>>>>>>>>> - If <region name>.properties does not exist, default >>>>>>>>>>>> >>>>>>>>>>> region >>>> >>>>> properties >>>>>>>>> >>>>>>>>>> are loaded and used to create the region. >>>>>>>>>>>> - properties are formed into a GFSH string and passed to >>>>>>>>>>>> >>>>>>>>>>> a >>> >>>> server >>>>>> >>>>>>> function >>>>>>>>>>> >>>>>>>>>>>> - The server function calls GFSH using internal calls. It >>>>>>>>>>>> >>>>>>>>>>> calls >>>>> >>>>>> the >>>>>>> >>>>>>>> GfshParser, executes the command, and then returns the >>>>>>>>>>>> >>>>>>>>>>> parsed >>>> >>>>> results. >>>>>>>>> >>>>>>>>>> [see https://github.com/Pivotal-Data-Engineering/ >>>>>>>>>>>> ClusterManagement/blob/master/ >>>>>>>>>>>> >>>>>>>>>>> cluster-management-server/src/ >>>> >>>>> main/java/com/geode/gfsh/GfshCommand.java] >>>>>>>>>>>> >>>>>>>>>>>> Limitations >>>>>>>>>>>> It uses internal calls to call GFSH. I have made requests >>>>>>>>>>>> >>>>>>>>>>> to >>>> >>>>> make >>>>>> >>>>>>> this >>>>>>>>> >>>>>>>>>> a >>>>>>>>>> >>>>>>>>>>> stable public interface. Andrew Baker had a good idea to >>>>>>>>>>>> >>>>>>>>>>> return >>>>> >>>>>> gfsh >>>>>>>> >>>>>>>>> results in JSON format with a new —results=json property >>>>>>>>>>>> >>>>>>>>>>> to >>> >>>> pass >>>>>> >>>>>>> to >>>>>>> >>>>>>>> GFSH. >>>>>>>>>> >>>>>>>>>>> Strengths >>>>>>>>>>>> That is uses GFSH can be viewed as a strength to keep a >>>>>>>>>>>> >>>>>>>>>>> consistent >>>>>>> >>>>>>>> API, >>>>>>>>> >>>>>>>>>> whether Java or GFSH >>>>>>>>>>>> >>>>>>>>>>>> TESTS >>>>>>>>>>>> You can start by running server tests at: >>>>>>>>>>>> >>>>>>>>>>> https://github.com/Pivotal- >>>>>>>>> >>>>>>>>>> Data-Engineering/ClusterManagement/tree/master/ >>>>>>>>>>>> cluster-management-server/src/test/java/com/geode/gfsh >>>>>>>>>>>> >>>>>>>>>>>> Client tests are at: >>>>>>>>>>>> >>>>>>>>>>> https://github.com/Pivotal-Data-Engineering/ >>>>>>> >>>>>>>> ClusterManagement/tree/master/ >>>>>>>>>>>> >>>>>>>>>>> cluster-management-client/src/ >>>> >>>>> test/java/com/geode/management/client >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Wes Williams >>>>>>>>>>>> >>>>>>>>>>>> On Apr 24, 2017, at 6:51 PM, Kirk Lund <kl...@apache.org >>>>>>>>>>>> >>>>>>>>>>> <mailto: >>>>>> >>>>>>> klund >>>>>>>>> >>>>>>>>>> @apache.org>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> A couple things I'd like to see: >>>>>>>>>>>> >>>>>>>>>>>> 1) completely new API that doesn't reuse the old API >>>>>>>>>>>> >>>>>>>>>>> classes >>>> >>>>> (or >>>>>> >>>>>>> at >>>>>>> >>>>>>>> least >>>>>>>>>> >>>>>>>>>>> not the giant classes such as Cache and Region >>>>>>>>>>>> >>>>>>>>>>> interfaces) >>> >>>> 2) separation of API and Impl so that users can compile >>>>>>>>>>>> >>>>>>>>>>> their >>>> >>>>> code >>>>>>> >>>>>>>> against >>>>>>>>>>> >>>>>>>>>>>> a dedicated client API jar >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Apr 24, 2017 at 3:03 PM, Fred Krone < >>>>>>>>>>>> >>>>>>>>>>> fkr...@pivotal.io >>>>> >>>>>> <mailto: >>>>>>>>> >>>>>>>>>> fkro >>>>>>>>>> >>>>>>>>>>
