"geode-client-api.jar" (not ai) On Thu, Apr 27, 2017 at 2:20 PM, Kirk Lund <kl...@pivotal.io> wrote:
> 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/mana >>>>>> ger >>>>>> >>>>>>> ] >>>>>>> >>>>>>>> - 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 >>>>>>>>>>> >>>>>>>>>>> >
