We could have a simple wrapper around geode API for JSR-107, but I still don't see how this is helpful. I can read a book about JSR-107 and try to use geode, but then I wanted to create a PartitionedRegion in Geode, the book didn't tell me anything about that (since it is implementation specific), I then tried to use the EntryProcessor mentioned in the book, but Geode does not support that. Supporting a standard would only become an exercise in getting a checkmark in a feature comparison. BTW, we are stuck with "Region" because of the initial drafts of JSR-107. Geode is much more than a "Cache", a number of users treat it as a system of record. Implementing JSR-107 would be a step backward. I would have been onboard implementing JSR-347 "Data grids for Java <https://jcp.org/en/jsr/detail?id=347>, unfortunately, it was withdrawn. Rather than renaming "Region" to "Cache", if we do have to rename it, we should just call it a Map. Then add other data structures like Lists and Sorted Sets.
On Thu, Apr 27, 2017 at 2:21 PM Kirk Lund <kl...@pivotal.io> wrote: > "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 <(781)%20606-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> <(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 > >>>>>>>>>>> > >>>>>>>>>>> > > >
