spring-projects / spring-boot-data-geode Goto Github PK

View Code? Open in Web Editor NEW

44.0 16.0 47.0 41.07 MB

Spring Boot support for Apache Geode and VMware GemFire

Home Page: https://projects.spring.io/spring-boot

License: Apache License 2.0

Java 97.07% Shell 0.14% HTML 0.22% Groovy 2.57%

java framework spring spring-boot apache-geode

spring-boot-data-geode's People

Contributors

Stargazers

Watchers

spring-boot-data-geode's Issues

Consider adding an 'org.eclipse.jetty:jetty-server' exclusion to the starters

The org.eclipse.jetty:jetty-server dependency (transitively) pulls in the javax.servlet:javax.servlet-api dependency on the application classpath, which causes Spring Boot to think the user's application is always a Web application, and as such, Spring Boot will bootstrap an embedded Servlet Container (e.g. Tomcat, Jetty).

This prevents the user from creating simply non-Web application Spring Boot applications.

Add documentation for when multiple competing providers (e.g. caching providers) are on the application classpath and what is the expected behavior, how to customize it, etc.

Use `spring.application.name` to name the GemFire/Geode node.

Implement auto-configuration support when Spring Session for Apache Geode or Pivotal GemFire are on the CLASSPATH.

Workaround Pivotal Spring Cloud Services bug consuming and discarding EnumerablePropertySources from the Environment

When the org.springframework.cloud:spring-cloud-services-starter-service-registry dependency is added to the CLASSPATH of a Spring Boot application (and specifically, a Spring Boot for Pivotal GemFire (SBDG) application, i.e. org.springframework.geode:spring-gemfire-starter), Pivotal Spring Cloud Services will create a "bootstrap" ApplicationContext with a "bootstrap" Environment.

During the creation of this "bootstrap" ApplicationContext and Environment, specific property sets (aka PropertySources) are copied from the "main" ApplicationContext, Environment object to the "bootstrap" Environment. And, in this particular case, the boot.data.gemfire.cloudcache configuration ProperySource is copied from "main" to "bootstrap". This custom SBDG specific PropertySource contains essential information from the environment/context in which the SBDG app is deploy (e.g. PCF when using PCC). 1 such piece of pertinent information is Authentication credentials extracted from the VCAP environment variables to allow a Spring Boot, Pivotal GemFire cache client application to authenticate with the bound PCC cluster when deployed to PCF.

However, Pivotal Spring Cloud Services is very specific about which PropertySources it collects from the "main" Environment to include in the "bootstrap" Environment. It specifically collects EnumerablePropertySources and later discards them, which then prevents the Spring Boot, Pivotal GemFire cache client application from successfully authenticating with the bound PCC cluster when deployed to PCF.

This enhancement works around this Pivotal Spring Cloud Services behavior (bug?).

HTTP client does not authenticate when pushing cluster config from client to server using @EnableClusterConfiguration with PCC 1.5.

Currently, when a Spring Boot, Apache Geode/Pivotal GemFire ClientCache application is annotated with @EnableClusterConfiguration(useHttp=true) and deployed to PCF, connecting to PCC (1.5), an Exception is thrown:

2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT [error 2018/11/15 18:17:50.069 UTC <main> tid=0x1] Application run failed
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT org.springframework.context.ApplicationContextException: Failed to start bean 'gemfireClusterSchemaObjectInitializer'; nested exception is org.springframework.web.client.HttpClientErrorException: 401 Unauthorized
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:185)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:53)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:360)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifecycleProcessor.java:158)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at org.springframework.context.support.DefaultLifecycleProcessor.onRefresh(DefaultLifecycleProcessor.java:122)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:883)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.finishRefresh(ServletWebServerApplicationContext.java:161)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:551)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.refresh(ServletWebServerApplicationContext.java:140)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:754)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:386)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at org.springframework.boot.SpringApplication.run(SpringApplication.java:307)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at org.springframework.boot.SpringApplication.run(SpringApplication.java:1242)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at org.springframework.boot.SpringApplication.run(SpringApplication.java:1230)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at io.pivotal.cloudcache.app.CloudcachePizzaStoreApplication.main(CloudcachePizzaStoreApplication.java:37)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at java.lang.reflect.Method.invoke(Method.java:498)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:48)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at org.springframework.boot.loader.Launcher.launch(Launcher.java:87)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at org.springframework.boot.loader.Launcher.launch(Launcher.java:50)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:51)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT Caused by: org.springframework.web.client.HttpClientErrorException: 401 Unauthorized
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:94)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:79)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at org.springframework.web.client.ResponseErrorHandler.handleError(ResponseErrorHandler.java:63)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at org.springframework.web.client.RestTemplate.handleResponse(RestTemplate.java:730)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:688)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at org.springframework.web.client.RestTemplate.exchange(RestTemplate.java:622)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at org.springframework.data.gemfire.config.admin.remote.RestHttpGemfireAdminTemplate.createRegion(RestHttpGemfireAdminTemplate.java:189)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at org.springframework.data.gemfire.config.schema.definitions.RegionDefinition.create(RegionDefinition.java:124)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at org.springframework.data.gemfire.config.annotation.ClusterConfigurationConfiguration$ClusterSchemaObjectInitializer.lambda$null$0(ClusterConfigurationConfiguration.java:275)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at java.util.Optional.ifPresent(Optional.java:159)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at org.springframework.data.gemfire.config.annotation.ClusterConfigurationConfiguration$ClusterSchemaObjectInitializer.lambda$start$1(ClusterConfigurationConfiguration.java:275)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at java.util.stream.SortedOps$SizedRefSortingSink.end(SortedOps.java:352)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at java.util.stream.Sink$ChainedReference.end(Sink.java:258)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at org.springframework.data.gemfire.config.annotation.ClusterConfigurationConfiguration$ClusterSchemaObjectInitializer.start(ClusterConfigurationConfiguration.java:274)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	at org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:182)
   2018-11-15T13:17:50.07-0500 [APP/PROC/WEB/0] OUT 	... 22 more
   2018-11-15T13:17:50.13-0500 [APP/PROC/WEB/0] OUT Exit status 1

Include additional support in @EnableClusterAware to connect to Auth and SSL enabled clusters during the test

[OPTIONAL] Add support to log warnings about the use of certain Annotations (e.g. @Indexed) in the absence of the enabling Annotation (e.g. @EnableIndexing).

While this is rather difficult to achieve in practice, it may be worth exploring the possibilities.

One of the challenges in properly detecting the use of certain annotations (e.g. @Indexed) on application domain objects without the associated "enabling" annotation (e.g. @EnableIndexing) is that, by way of example, the application domain model objects containing @Indexed annotations are not even picked up unless the @EnableIndexing annotation is present since that triggers a "scan", which is necessary to 1) limit the scope of the application object types introspected as well as 2) detect whether any @Indexed annotations have been declared. Without the scan, the objects containing the annotations are not even inspected in the first place, so how would the infrastructure know the @Indexed annotation was used without @EnableIndexing, for instance. The "enabling" annotation is needed to begin the scan for the object-level annotations, like @Indexed.

Change 'org.springframework.data:spring-data-geode-test' dependency in test starters from testCompile to compile

Currently, the org.springframework.data:spring-data-geode-test dependency in the spring-geode-starter-test module and the org.springframework.data:spring-data-gemfire-test dependency in the spring-gemfire-starter-test module are test-compile dependencies.

This prevents the Spring Test for Apache Geode & Pivotal GemFire (STDG) test framework and library from being used as a test-compile dependency in users' application development projects using Apache Geode, or Pivotal GemFire, to write Unit and Integration Tests.

The STDG dependencies declared in the test starters need to be made into compile-time dependencies.

Geode Core overrides the Log format

Hi,

http://gemfire.docs.pivotal.io/96/geode/managing/logging/configuring_log4j2.html As per this article geode jar is overriding the custom logger jar. We have our micro-service deployed in the Pivotal Cloud Foundry, and we are not sure if how we can set -Dlog4j.configurationFile=file-path

We tried below configuration in the boostrap-cloud.yml of our micro-service and it didn't help:

logging:
config: file-path

Much Thanks!

Refactor Boolean.getBoolean(..) obtained auto-configuration enabling/disabling properties to use the Spring Environment.

404 issue with PCC

Hello,

I am trying to test {{@EnableClusterConfiguration}} with PCC and I am getting the following exception:

Caused by: org.springframework.web.client.HttpClientErrorException: 404 Not Found
	at org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:94)
	at org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:79)
	at org.springframework.web.client.ResponseErrorHandler.handleError(ResponseErrorHandler.java:63)
	at org.springframework.web.client.RestTemplate.handleResponse(RestTemplate.java:730)
	at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:688)

Include support for using Micrometer and Spring Boot Actuator to provide runtime metrics for Apache Geode and VMware Tanzu GemFire.

Spring Boot for Apache Geode (SBDG) already includes Spring Boot Actuator support with extensive metrics and runtime configuration metadata for the Apache Geode cache instance, whether a client or a peer node in the cluster.

However, the Spring Boot Actuator integration needs to be refactored from the old model to the new HealthIndicators.

Additionally, now that Observability is a major theme for the Spring Framework 6 generation, Micrometer 2.0 integration should be evaluated.

Please rename the project to make it clear that it's not part of Spring Boot

As described in Spring Boot's documentation we prefer to keep the spring-boot-* naming for modules that are part of Spring Boot. As this project will be an add-on, something like data-gemfire-spring-boot would be a more appropriate, and less confusing, name.

Improve caching provider auto-configuration to respect 'spring.cache.type'.

Add Auto-configured Templates for all Region definitions.

This new feature will add support automatically creating SDG org.springframework.data.gemfire.GemfireTemplate objects for each Region bean declared in the Spring ApplicationContext whether explicitly defining/declaring Region beans or using SDG's @EnableEntityDefinedRegions / @EnableCachingDefinedRegions.

Clarify in documentation which Spring Boot auto-configuration classes will be applied when explicit configuration is used (e.g. SDG's @ClientCacheApplication).

Improve @EnableClusterAware to also be Environment aware (e.g. PCF vs. Non-PCF)

Autowiring a GemfireTemplate into the application is not working in all cases

Autowiring the {{o.s.d.g.GemfireTemplate}} as per the documentation does not work as documented.

Seems it has to do with the lazy initialization of the Region. If the Repository is annotated wit DependsOn("Customers"), then the problem is resolved.

@Repository
public class DemoRepository {

	@Autowired
	@Qualifier("customersTemplate")
	private GemfireTemplate customersTemplate;

	public void putData(String key, String value) {
		customersTemplate.put(key, value);
	}
}

Fails with:

Description:

Field customersTemplate in com.example.demo.client.repo.DemoRepository required a bean of type 'org.springframework.data.gemfire.GemfireTemplate' that could not be found.


Action:

Consider defining a bean of type 'org.springframework.data.gemfire.GemfireTemplate' in your configuration.

Logging should reuse existing logging format rather that overwriting it

Adding this starter in an empty Spring Boot application alters the standard logging format, e.g. using 1.1.0.M3:


  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::        (v2.1.6.RELEASE)

[info 2019/07/15 14:21:55.653 CEST <main> tid=0x1] Starting DemoApplication on gemini.lan with PID 24874 (/Users/snicoll/Downloads/test-geode/target/classes started by snicoll in /Users/snicoll/Downloads/test-geode)

[info 2019/07/15 14:21:55.656 CEST <main> tid=0x1] No active profile set, falling back to default profiles: default

2019-07-15 14:21:56.171  INFO 24874 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Bootstrapping Spring Data repositories in DEFAULT mode.
2019-07-15 14:21:56.184  INFO 24874 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Finished Spring Data repository scanning in 6ms. Found 0 repository interfaces.
[info 2019/07/15 14:21:56.309 CEST <main> tid=0x1] @Bean method PdxConfiguration.pdxDiskStoreAwareBeanFactoryPostProcessor is non-static and returns an object assignable to Spring's BeanFactoryPostProcessor interface. This will result in a failure to process annotations such as @Autowired, @Resource and @PostConstruct within the method's declaring @Configuration class. Add the 'static' modifier to this method to avoid these container lifecycle issues; see @Bean javadoc for complete details.

[info 2019/07/15 14:21:56.405 CEST <main> tid=0x1] Bean 'org.springframework.data.gemfire.config.annotation.ContinuousQueryConfiguration' of type [org.springframework.data.gemfire.config.annotation.ContinuousQueryConfiguration$$EnhancerBySpringCGLIB$$935c745d] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)

[info 2019/07/15 14:21:56.410 CEST <main> tid=0x1] Bean 'org.springframework.geode.boot.autoconfigure.RegionTemplateAutoConfiguration' of type [org.springframework.geode.boot.autoconfigure.RegionTemplateAutoConfiguration$$EnhancerBySpringCGLIB$$73f3c190] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)

[info 2019/07/15 14:21:57.259 CEST <main> tid=0x1] 
---------------------------------------------------------------------------
  
  Licensed to the Apache Software Foundation (ASF) under one or more
  contributor license agreements.  See the NOTICE file distributed with this
  work for additional information regarding copyright ownership.

...

I guess the logging infrastructure is configured on startup at some point. In the example above we can see two log entries with the "Spring Boot format" mangled with another one.

Add dedicated support for in-line caching.

Currently, Apache Geode/Pivotal GemFire offers the JDBC Connector. However, this proves to be too limited in practice to be useful. Therefore, SBDG will offer dedicated support for inline caching that achieves 2 primary goals:

Support for any backend data store (e.g. RDBMS, Document, Graph, Key/Value, other) by integrating the Spring Data Repositories infrastructure.
Support for complex mapping. E.g. when using an RDBMS to back the cache for in-line caching, enable users to use Hibernate, or any other ORM tool (e.g. EclipseLink) to handle complex object hierarchies and relationships.

On top of these primary goals, this change will also include dedicated support configure in-line caching regardless of the context (e.g. Standalone vs. Cloud).

Add auto-configuration for logging.

@ClientCacheApplication - Overrides log

@ClientCacheApplication overrides my logger settings. None of my log4j information is carried since I have declared this.

In my application, I don't need client cache either. Is there a way to avoid using this? Kindly advise?

If I comment on this line I get below error -

Consider defining a bean named 'gemfireCache' in your configuration

Changes made:

@Configuration
// @ClientCacheApplication(name = "GemFireClientCacheApplication", durableClientId = "store", keepAlive = true, readyForEvents = true, subscriptionEnabled = true)**
@EnableGemfireCaching
@EnableSecurity
@EnablePdx
public class GemfireConfiguration {

}

Log shows the override. Please let me know if how I can avoid it.

Log4J 2 Configuration:
2018-12-06T20:11:26.807-05:00 [APP/PROC/WEB/0] [OUT] jar:file:/home/vcap/app/BOOT-INF/lib/geode-core-9.1.1.jar!/log4j2.xml

Generated POMs refer to Spring Security

Generated poms of this project have wrong metadata:

The SCM url refers to the Spring Security project
The list of developers contains Rob and Joe (which I believe is an oversight as well).
The project URL refers to Spring Security

Add Starters for Spring Test for Apache Geode/Pivotal GemFire (STDG).

This improvement will add the following Starter modules that will include test dependencies used when testing Apache Geode or Pivotal GemFire in a Spring context:

spring-geode-starter-test
spring-gemfire-starter-test

Add documentation to document each SBDG provided Spring Boot auto-configuration class and how to disable or override it.

Update copyright in source file headers to 2019.

GemFireSecurityException: Error: Anonymous User on running application on PCF

We received an exception on a running application (i.e. no deployment or restart in between). It seems like somehow the PCC binding got messed up or dropped. After restarting the server it got fixed. Can someone please check what could possibly the issue so that we can avoid this in future on production? Below is stack trace from the log:

2018-11-28T16:28:53.424-05:00 [APP/PROC/WEB/0] [OUT] at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:478) [tomcat-embed-core-8.5.23.jar!/:8.5.23]
2018-11-28T16:28:53.424-05:00 [APP/PROC/WEB/0] [OUT] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140) [tomcat-embed-core-8.5.23.jar!/:8.5.23]
2018-11-28T16:28:53.424-05:00 [APP/PROC/WEB/0] [OUT] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81) [tomcat-embed-core-8.5.23.jar!/:8.5.23]
2018-11-28T16:28:53.424-05:00 [APP/PROC/WEB/0] [OUT] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87) [tomcat-embed-core-8.5.23.jar!/:8.5.23]
2018-11-28T16:28:53.424-05:00 [APP/PROC/WEB/0] [OUT] at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:677) [tomcat-embed-core-8.5.23.jar!/:8.5.23]
2018-11-28T16:28:53.424-05:00 [APP/PROC/WEB/0] [OUT] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342) [tomcat-embed-core-8.5.23.jar!/:8.5.23]
2018-11-28T16:28:53.424-05:00 [APP/PROC/WEB/0] [OUT] at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:803) [tomcat-embed-core-8.5.23.jar!/:8.5.23]
2018-11-28T16:28:53.424-05:00 [APP/PROC/WEB/0] [OUT] at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) [tomcat-embed-core-8.5.23.jar!/:8.5.23]
2018-11-28T16:28:53.424-05:00 [APP/PROC/WEB/0] [OUT] at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868) [tomcat-embed-core-8.5.23.jar!/:8.5.23]
2018-11-28T16:28:53.424-05:00 [APP/PROC/WEB/0] [OUT] at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1459) [tomcat-embed-core-8.5.23.jar!/:8.5.23]
2018-11-28T16:28:53.424-05:00 [APP/PROC/WEB/0] [OUT] at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) [tomcat-embed-core-8.5.23.jar!/:8.5.23]
2018-11-28T16:28:53.424-05:00 [APP/PROC/WEB/0] [OUT] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [na:1.8.0_192]
2018-11-28T16:28:53.424-05:00 [APP/PROC/WEB/0] [OUT] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_192]
2018-11-28T16:28:53.424-05:00 [APP/PROC/WEB/0] [OUT] at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) [tomcat-embed-core-8.5.23.jar!/:8.5.23]
2018-11-28T16:28:53.424-05:00 [APP/PROC/WEB/0] [OUT] at java.lang.Thread.run(Thread.java:748) [na:1.8.0_192]
2018-11-28T16:28:53.424-05:00 [APP/PROC/WEB/0] [OUT] Caused by: org.apache.geode.security.GemFireSecurityException: Error: Anonymous User
2018-11-28T16:28:53.424-05:00 [APP/PROC/WEB/0] [OUT] at org.apache.geode.internal.security.IntegratedSecurityService.getSubject(IntegratedSecurityService.java:117) ~[geode-core-1.0.0-incubating.jar!/:na]
2018-11-28T16:28:53.424-05:00 [APP/PROC/WEB/0] [OUT] at org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:231) ~[geode-core-1.0.0-incubating.jar!/:na]
2018-11-28T16:28:53.424-05:00 [APP/PROC/WEB/0] [OUT] at org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:219) ~[geode-core-1.0.0-incubating.jar!/:na]
2018-11-28T16:28:53.424-05:00 [APP/PROC/WEB/0] [OUT] at org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:209) ~[geode-core-1.0.0-incubating.jar!/:na]
2018-11-28T16:28:53.424-05:00 [APP/PROC/WEB/0] [OUT] at org.apache.geode.internal.cache.tier.sockets.command.KeySet.cmdExecute(KeySet.java:99) ~[geode-core-1.0.0-incubating.jar!/:na]
2018-11-28T16:28:53.424-05:00 [APP/PROC/WEB/0] [OUT] at org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:162) ~[geode-core-1.0.0-incubating.jar!/:na]
2018-11-28T16:28:53.424-05:00 [APP/PROC/WEB/0] [OUT] at org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:785) ~[geode-core-1.0.0-incubating.jar!/:na]
2018-11-28T16:28:53.424-05:00 [APP/PROC/WEB/0] [OUT] at org.apache.geode.internal.cache.tier.sockets.LegacyServerConnection.doOneMessage(LegacyServerConnection.java:85) ~[na:na]
2018-11-28T16:28:53.424-05:00 [APP/PROC/WEB/0] [OUT] at org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1166) ~[geode-core-1.0.0-incubating.jar!/:na]
2018-11-28T16:28:53.424-05:00 [APP/PROC/WEB/0] [OUT] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_192]
2018-11-28T16:28:53.424-05:00 [APP/PROC/WEB/0] [OUT] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_192]
2018-11-28T16:28:53.424-05:00 [APP/PROC/WEB/0] [OUT] at org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:557) ~[geode-core-1.0.0-incubating.jar!/:na]
2018-11-28T16:28:53.424-05:00 [APP/PROC/WEB/0] [OUT] at java.lang.Thread.run(Thread.java:745) [na:1.8.0_192]

ClientCache Region default is PROXY; unclear section 4 prose implies default is LOCAL

In this version of the SBDG docs, https://docs.spring.io/autorepo/docs/spring-boot-data-geode-build/1.0.1.RELEASE, I became confused. Section 4 (Building ClientCache Applications) has 2 sentences that gave me the impression that the default for any region in the ClientCache would be LOCAL. (It isn't. The default is PROXY.)

Here are the 2 problematic sentences:

However, the ClientCache instance does not require a GemFire/Geode sever (i.e. CacheServer) to be running in order to use the ClientCache instance. It is perfectly valid to create a cache client and perform local data access operations on LOCAL Regions.

Later on, when needed, you can expand your Spring Boot, ClientCache application into a fully functional client/server architecture by changing the client Region’s data policy from LOCAL to PROXY or CACHING_PROXY, and send/receive data to/from 1 or more servers, respectively.

I believe that these sentences were written with the unstated assumption that a developer would know to set the client cache first as a near cache, by setting
@EnableCachingDefinedRegions(clientRegionShortcut = ClientRegionShortcut.LOCAL)

The @EnableCachingDefinedRegions is discussed in section 6. People like me tend to read sections in order when first attempting to learn about something new. So, I read that second problematic sentence (the one that starts with "Later on") as implying that the default client cache would have regions of type LOCAL. And, I read that sentence before reading section 6.

To make this more clear, I think I would change that first sentence to something more like:

However, the ClientCache instance does not require a GemFire/Geode sever (i.e. CacheServer) to be running in order to use the ClientCache instance. It is perfectly valid to create a cache client, specify any regions to be of type LOCAL, and perform local data access operations on those LOCAL Regions.

It might be helpful to also include a link to an example or section that defines how to use the @EnableCachingDefinedRegions annotation.

Improve the intelligence around enabling Auto-configuration for CQs

By default, SBDG will auto-configure CQs for any Spring Boot, ClientCache application without regard to whether a server or cluster exists in the first place.

When the client runs in local-only mode, or in a local topology (i.e. client LOCAL Regions), then as of Apache Geode 1.9, Geode will throw benign Exceptions in the log output of the application while it attempts to satisfy the minimum pre-fill connection count of the Pool (e.g. "DEFAULT" Pool) used to register CQs, if any.

java.net.ConnectException: Connection refused (Connection refused)
	at java.net.PlainSocketImpl.socketConnect(Native Method) ~[na:1.8.0_192]
	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) ~[na:1.8.0_192]
	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) ~[na:1.8.0_192]
	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) ~[na:1.8.0_192]
	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) ~[na:1.8.0_192]
	at java.net.Socket.connect(Socket.java:589) ~[na:1.8.0_192]
	at org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:946) ~[geode-core-1.9.0.jar:na]
	at org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:887) ~[geode-core-1.9.0.jar:na]
	at org.apache.geode.internal.net.SocketCreator.connectForClient(SocketCreator.java:859) ~[geode-core-1.9.0.jar:na]
	at org.apache.geode.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:106) ~[geode-core-1.9.0.jar:na]
	at org.apache.geode.cache.client.internal.ConnectionConnector.connectClientToServer(ConnectionConnector.java:75) ~[geode-core-1.9.0.jar:na]
	at org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:111) ~[geode-core-1.9.0.jar:na]
	at org.apache.geode.cache.client.internal.QueueManagerImpl.initializeConnections(QueueManagerImpl.java:452) [geode-core-1.9.0.jar:na]
	at org.apache.geode.cache.client.internal.QueueManagerImpl.start(QueueManagerImpl.java:290) [geode-core-1.9.0.jar:na]
	at org.apache.geode.cache.client.internal.PoolImpl.start(PoolImpl.java:337) [geode-core-1.9.0.jar:na]
	at org.apache.geode.cache.client.internal.PoolImpl.finishCreate(PoolImpl.java:176) [geode-core-1.9.0.jar:na]
	at org.apache.geode.cache.client.internal.PoolImpl.create(PoolImpl.java:162) [geode-core-1.9.0.jar:na]
	at org.apache.geode.internal.cache.PoolFactoryImpl.create(PoolFactoryImpl.java:372) [geode-core-1.9.0.jar:na]
	at org.apache.geode.internal.cache.GemFireCacheImpl.determineDefaultPool(GemFireCacheImpl.java:2902) [geode-core-1.9.0.jar:na]
	at org.apache.geode.internal.cache.GemFireCacheImpl.getDefaultPool(GemFireCacheImpl.java:1151) [geode-core-1.9.0.jar:na]
	at org.apache.geode.internal.cache.GemFireCacheImpl.getQueryService(GemFireCacheImpl.java:4161) [geode-core-1.9.0.jar:na]
	at org.apache.geode.internal.cache.GemFireCacheImpl.getQueryService(GemFireCacheImpl.java:255) [geode-core-1.9.0.jar:na]
	at org.springframework.data.gemfire.listener.ContinuousQueryListenerContainer.setCache(ContinuousQueryListenerContainer.java:421) [spring-data-geode-2.2.0.RC3.jar:2.2.0.RC3]
	at org.springframework.data.gemfire.config.annotation.ContinuousQueryConfiguration.continuousQueryListenerContainer(ContinuousQueryConfiguration.java:202) [spring-data-geode-2.2.0.RC3.jar:2.2.0.RC3]
	at org.springframework.data.gemfire.config.annotation.ContinuousQueryConfiguration$$EnhancerBySpringCGLIB$$d4ae8c50.CGLIB$continuousQueryListenerContainer$6(<generated>) [spring-data-geode-2.2.0.RC3.jar:2.2.0.RC3]
	at org.springframework.data.gemfire.config.annotation.ContinuousQueryConfiguration$$EnhancerBySpringCGLIB$$d4ae8c50$$FastClassBySpringCGLIB$$b90f023d.invoke(<generated>) [spring-data-geode-2.2.0.RC3.jar:2.2.0.RC3]
	at org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:244) [spring-core-5.2.0.RC2.jar:5.2.0.RC2]
	at org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:363) [spring-context-5.2.0.RC2.jar:5.2.0.RC2]
	at org.springframework.data.gemfire.config.annotation.ContinuousQueryConfiguration$$EnhancerBySpringCGLIB$$d4ae8c50.continuousQueryListenerContainer(<generated>) [spring-data-geode-2.2.0.RC3.jar:2.2.0.RC3]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_192]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_192]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_192]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_192]
	at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:154) [spring-beans-5.2.0.RC2.jar:5.2.0.RC2]
	at org.springframework.beans.factory.support.ConstructorResolver.instantiate(ConstructorResolver.java:640) [spring-beans-5.2.0.RC2.jar:5.2.0.RC2]
	at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:625) [spring-beans-5.2.0.RC2.jar:5.2.0.RC2]
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1339) [spring-beans-5.2.0.RC2.jar:5.2.0.RC2]
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1178) [spring-beans-5.2.0.RC2.jar:5.2.0.RC2]
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:557) [spring-beans-5.2.0.RC2.jar:5.2.0.RC2]
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:517) [spring-beans-5.2.0.RC2.jar:5.2.0.RC2]
	at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:323) [spring-beans-5.2.0.RC2.jar:5.2.0.RC2]
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222) ~[spring-beans-5.2.0.RC2.jar:5.2.0.RC2]
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:321) [spring-beans-5.2.0.RC2.jar:5.2.0.RC2]
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202) [spring-beans-5.2.0.RC2.jar:5.2.0.RC2]
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:878) ~[spring-beans-5.2.0.RC2.jar:5.2.0.RC2]
	at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:877) ~[spring-context-5.2.0.RC2.jar:5.2.0.RC2]
	at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:549) ~[spring-context-5.2.0.RC2.jar:5.2.0.RC2]
	at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.refresh(ServletWebServerApplicationContext.java:141) ~[spring-boot-2.2.0.BUILD-SNAPSHOT.jar:2.2.0.BUILD-SNAPSHOT]
	at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:747) ~[spring-boot-2.2.0.BUILD-SNAPSHOT.jar:2.2.0.BUILD-SNAPSHOT]
	at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:397) ~[spring-boot-2.2.0.BUILD-SNAPSHOT.jar:2.2.0.BUILD-SNAPSHOT]
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:315) ~[spring-boot-2.2.0.BUILD-SNAPSHOT.jar:2.2.0.BUILD-SNAPSHOT]
	at example.app.caching.lookaside.BootGeodeLookAsideCachingApplication.main(BootGeodeLookAsideCachingApplication.java:40) ~[classes/:na]

This Exceptions continue to clutter up (add noise to) the log output of the running application without adding any real value. It is, for all intents and purpose, a useless, unhelpful Exception that user's applications cannot do anything about anyway.

Furthermore, a local-only application does not care whether a server or cluster of servers is available or not, as it is not critical to the proper function of the application.

If, however, the application was a legitimate client/server application in the Apache Geode client/server topology with CQs listeners (i.e. POJO methods annotated with @ContinuousQuery), then the application would fail-fast if a server or cluster was not available since SBDG would go onto register the application CQs (as expressed in the @ContinousQuery annotations on POJO handler methods) on startup.

Still, more care should be taken to avoid this ugly situation triggered and exposed by SBDG in the first place. Therefore, this ticket serves to improve on the intelligent registration of CQ Auto-configuration.

Add support to allow SBDG PCF deployed apps to connect to standalone, external (non-PCF/PCC) Pivotal GemFire clusters.

[OPTIONAL] Enable configuration of Apache Geode/PCC using both spring.data.gemfire.* and spring.data.geode.* properties.

This new feature would add support for both spring.data.gemfire.* as well as spring.data.geode.* properties.

Of course, some sort of precedence is required if duplicate, but equivalent properties are configured, for example:

spring.data.gemfire.cache.log.level=INFO
...

spring-data-geode.cache.log.level=WARN

For instance, should the log-level of the cache be WARN or INFO? 1 strategy could be that the last property definition wins. However, this can get quite confusing when the definitions are spread across multiple locations and property files, in addition to the use of Spring profiles.

Improve CQ auto-configuration support to only enable client subscriptions if the user annotated POJO method message handlers (@EventListener) with @ContinuousQuery.

Remove unnecessary, explicit exclusion on 'org.apache.logging.log4j:log4j-core'

The explicit exclusion on org.apache.logging.log4j:log4j-core in SBDG will be unnecessary once SD[G] Moore/2.2 is rebased on Apache Geode 1.9.1, which will include a fix for GEODE-7058.

At this point, SBDG can then be rebased on SDG Moore-X (where X is in [Moore-RC3, Moore-RELEASE, Moore-SR1, ... ], i.e. which ever version of SDG Moore is rebased on Apache Geode 1.9.1) thereby making the exclude no longer necessary.

Remove unnecessary, explicit exclusion on 'javax.sevlet:javax.servlet-api'

The explicit exclusion on javax.servlet:javax.servlet-api in SBDG will be unnecessary once SD[G] Moore/2.2 is rebased on the Apache Geode version that includes a fix for GEODE-7107.

At this point, SBDG can then be rebased on SDG Moore-X (where X is in [Moore-RC3, Moore-RELEASE, Moore-SR1, ... ], i.e. which ever version of SDG Moore is rebased on the Apache Geode version including the fix for GEODE-7107) thereby making the exclude no longer necessary.

Add Starters for Spring Session.

Implement a Spring Boot custom HealthIndicator to assess the health and state of a Pivotal GemFire or Apache Geode cache instance.

Update project coordinates to make the relationship with Spring Boot clear

Can you please update this project to align with the recommendations in Boot's documentation? Rather than being called spring-boot-data-geode, spring-data-geode-boot or similar would be more appropriate and would be consistent with other projects that are in a similar position. The group ID should also be something other than org.springframework.boot.

Add to the 'Switch from Apache Geode to Pivotal Cloud Cache' section details on how to resolve the PCC or Pivotal GemFire bits

Add to the Appendix, in the section Switch from Apache Geode to Pivotal Cloud Cache (a.k.a. Pivotal GemFire), details on how to acquire the Pivotal GemFire/Pivotal Cloud Cache bits and the appropriate process to follow and commercial repository to use.

Add starters for Pivotal Cloud Cache

This enhancement will include the following Spring Boot starters for Pivotal Cloud Cache (PCC):

spring-cloudcache-starter
spring-cloudcache-starter-actuator
spring-cloudcache-starter-session
spring-cloudcache-starter-test

Add configuration processor to support content-assist / auto-completion of well-known SDG properties.

NOTE: All well-known SDG properties are in the SDG annotations, available here (https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/config/annotation/package-summary.html).

Add `@EnableClusterAware` annotation and support

This new annotation will enable users to seamlessly switch between "local-only" mode and client/server, which will particularly help when switching between various environments (e.g. DEV to TEST), or rather non-managed to managed.

A good example of this would be when the application developers are developing locally and then deploying to PCF on an ad hoc basis, connecting their Spring Boot applications to PCC.

Conversely, if users need to move from PCF back to local (without the presence of a server cluster, perhaps), for example when debugging or writing additional tests for functionality, then SBDG will enable this transition smoothly without additional code or configuration changes.

Create an initial implementation of AuthInitialize interface that can connect to PCC

http://gemfire-82-javadocs.docs.pivotal.io/com/gemstone/gemfire/security/AuthInitialize.html

I think the first hello-world step is an implementation that will pull username/password from a specific environment variable set by the PCC service. The env-var can be hard coded to use a specific name of the PCC service.

Add 'awareness' of the new SDG `@LocatorApplication` annotation even though SBDG is not based on SD[G] Moore yet.

More details to come...

Include `org.springframework.shell:spring-shell` dependency in SBDG dependencies.

Add capability to select a specific user when connecting to Geode

PCC is process of enabling instance sharing on PCF, using which one app could gain access to a shared cluster from another org and space. A new user role readonly is introduced with this new feature so that when instances are shared to APPS of other org only read-only access is granted.

We need a way to let SBDG apps to work with readonly credentials, this means that the APPS cannot push configuration etc.

In the current state the service key will only have readonly user and not other users in the service binding, so rather than asking user to configure which role to pick up it may be as simple as just use existing user from the binding.

Consider removing JSR-107 - JCache API dependency from starters

Adding JCache in the starter looks a bit unusual to me and I'd like to know more about it. A typical Spring Boot application will react based on choices made by the user and it's not obvious to me why using geode means they want to use JCache.

Add Sample with Guide and Example Code for Getting Started

This ticket tracks the work to create a new Sample with a Guide and Example Code on getting started quickly, easily and reliable with Spring Boot for Apache Geode or Pivotal GemFire (SBDG).

This guide will walk users through:

Creating a new SBDG project with Spring Initializer at https://start.spring.io[start.spring.io].
We then show how to create a simple SBDG application that persists data into Apache Geode, locally.
Next, we switch the application to use a client/server topology.
Finally, we show how to push the application to a managed platform (e.g. Pivotal Platform formerly known as Pivotal CloudFoundry (PCF) using Pivotal Cloud Cache (PCC)).

Include Async support for Inline Caching using AEQ + Listener

Add smoke tests to validate use of the starter in a vanilla application

In the recent past, a number of issues were discovered adding the spring-geode-starter to a vanilla Spring Boot application. Given that this project built successfully and a release was made with those issues, I think a number of integration/smoke tests are missing.

The two recent examples I have in mind are:

With the 1.1 line adding the starter alone was working but combining the starter with any other starter would break without an explicit library exclusion (see #42)
With the 1.2 line adding the starter alone would break as both spring-mvc and servlet-api were present in the classpath, triggering an embedded application server bootstrap.

While both theses issues are actually located outside of this project (and workarounds have been swiftly applied), the integration in a Spring Boot application was broken and having an automated way of discovering such issue prior of a release is necessary.

I don't know how easy that's going to be. Perhaps testcontainers can help to make sure a vanilla geode instance is running for such tests.

spring-projects / spring-boot-data-geode Goto Github PK

spring-boot-data-geode's People

Contributors

Stargazers

Watchers

Forkers

spring-boot-data-geode's Issues

Recommend Projects

Recommend Topics

Recommend Org