Comments (9)
@snicoll - Will think on this. Thanks for the feedback.
from spring-boot-data-geode.
Correction to:
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.
To my knowledge, SBDG, through transitive dependencies, only brought in the javax.servlet-api
, not spring-webmvc
. I never saw spring-webmvc
in the dependency graph with the SBDG spring-geode-starter
was on the classpath of a Spring Boot application.
It is true that SBDG has a direct dependency on SDG, which in turn has a dependency on the spring-web
, but spring-web
was not enough for Spring Boot to decide that the application should be a "Web application" with an embedded Servlet Container (e.g. Tomcat, Jetty) bootstrapped by Spring Boot on startup.
Never-the-less, I feel that having smoke tests to catch/prevent these type of situations going forward are important, even if it is largely due some transitive dependency (e.g. Apache Geode 1.6
, which caused logging issues in SBDG 1.1
, and again, Apache Geode 1.9
, which forced the application to be a Web application by Spring Boot in SBDG 1.2
).
I take full responsibility.
from spring-boot-data-geode.
I meant to write spring-web
and I wrote spring-mvc
, that's all.
from spring-boot-data-geode.
I have added 2 Smoke Tests to the SBDG project.
-
The first smoke test tests and asserts that a
Spring for Apache Geode
project generated and created with Spring Initializer at start.spring.io works as expected. That is, it creates a standard, non-Webapp, Spring Boot application and that it can interact with Apache Geode using basic functions, aput(key, value)
followed by aget(key)
. I generated a project using the Initializer then copied the contents of the generated Gradle build file into the smoke test module's Gradle build file. Essentially, thespring-initializer
smoke test module resolves theorg.springframework.geode:spring-geode-starter
dependency in the same way as aSpring for Apache Geode
project would when created/generated from Spring Initializer. -
The second smoke test tests and asserts that a Spring Data multi-store project works as expected when using the
Spring for Apache Geode
as resolved from a project generated from Spring Initializer. This smoke test module includes both thespring-geode-starter
as well as thespring-boot-starter-data-jpa
module in Spring Boot core.spring-boot-starter-data-jpa
pulls in several other Spring Boot core modules as well (e.g.spring-boot-starter-logging
,spring-boot-starter-jdbc
, etc). The test goes on to assert the proper behavior of SD multi-store support, ensuring that SD JPA can properly persist data to a backend HSQLDB database while using Apache Geode as a caching provider in Spring's Cache Abstraction, without interference to any of Spring [Boot] module on the application classpath.
While this effort is not an exhaustive list, it does cover the 2 scenarios highlighted above to a degree.
Also, as any new problems or scenarios come to our attention, we will continue to add additional smoke tests to cover as many UCs as possible and ensure SBDG is behaving correctly in all contexts, playing nicely with other Spring Boot modules, working for the intended UCs, and so on and so forth.
Therefore, please do not take the closure of this Issues as final. It is just the beginning of much more.
from spring-boot-data-geode.
Thanks for this @jxblum, I had a quick look at this so I might be missing something. Can you please share how that zip file in etc
is going to be updated?
In the current form and, as far as I understood, I can see that it uses 1.2.0.M3
so it isn't building against the current code. I am afraid that it's not guarding from a release to be shipped with a broken use case as the smoke tests run against an (older) fixed version.
Have you considering having a project with the starter (in the latest snapshot form) and run tests against that. The smoke tests in Spring Boot work that way and since they inherit from the current build, they can use whatever dependency that is managed in the project, i.e. these dependencies bring the code that was just built. In your case, just providing the starter is all that would be required. Another smoke test project that brings the web starter could validate the integration with the rest of the ecosystem (though secondary).
from spring-boot-data-geode.
Hi @snicoll - Thanks for the feedback.
Can you please share how that zip file in etc is going to be updated?
Good question! It will be manually updated for now.
Presently, I simply wanted to put together any kind of test, which was better than having no tests. So, I went to start.spring.io, generated a "Spring for Apache Geode" Spring Boot 2.2
, Gradle project and then used the contents of the generated Gradle file as a basis for the spring-initializer
Smoke Tests Gradle build file. This isn't ideal, but it essentially mimicked the product that a user would get as generated by Spring Initializer when creating a "Spring for Apache Geode" project.
This is accomplished by 1) declaring the repos from which the artifact (e.g. spring-geode-starter
) would be resolved (copied from the Gradle file produced by Initializer) and 2) declaring a dependency on the fully qualified artifact (i.e. org.springframework.geode:spring-geode-starter
, as produced by Initializer, minus the version) rather than pulling in, for example, compile project('spring-geode-starter')
.
Of course, now that I think about it, not sure if that quite does the same thing?? I then set the "version" to match whatever version the SBDG project is currently building at (e.g. 1.2.0.BUILD-SNAPSHOT
). However, there is a problem with my versioning scheme.
The version (e.g. 1.3.0.BUILD-SNAPSHOT
) may not currently be available in the targeted repos before the Smoke Tests run since the build would need to initially run and upload the artifacts (e.g. 1.3.0.BUILD-SNAPSHOT
when the version changes) to snapshot repo before the Smoke Test runs (just after the version change). Otherwise, the artifacts would not yet be available and the build would fail thereby never uploading the new version (e.g. 1.3.0.BUILD-SNAPSHOT
). I have created a chicken and egg problem. Damn, didn't think of that.
Also, if the contents of the generated Spring Initializer product ever changes, then it won't quite be testing what Initializer is doing when a user generates a "Spring for Apache Geode" project, :(
Let me digest your additional comments more and then figure out next steps. For now, I just wanted to share what my original (flawed) thinking was.
from spring-boot-data-geode.
I verified and the spring-initializer
Smoke Test is pulling in the project version, in the same manner as Spring Boot Smoke Tests do. That is, if the project version
is set to 1.2.0.BUILD-SNAPSHOT
, then the spring-geode-starter
declared in the spring-initializer
Smoke Test would resolve to 1.2.0.BUILD-SNAPSHOT
. It would not just be the latest version of the spring-geode-starter
on Spring Initializer, which at the time of this comment is 1.2.0.M3
.
I also tested what would happen if I superfically changed the "version
" (again, here) to, for example, 1.3.0.BUILD-SNAPSHOT
, and sure enough...
$ gradlew --no-daemon :spring-geode-smoke-tests-initializer:build
> Task :spring-geode-smoke-tests-initializer:compileJava FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':spring-geode-smoke-tests-initializer:compileJava'.
> Could not resolve all files for configuration ':spring-geode-smoke-tests-initializer:compileClasspath'.
> Could not find org.springframework.geode:spring-geode-starter:1.3.0.BUILD-SNAPSHOT.
Required by:
project :spring-geode-smoke-tests-initializer
This also happens when I run the entire project build. Everything builds fine up to the Smoke Tests (the last thing to run), which then fail.
$ gradlew --no-daemon clean build install
...
..
.
> Task :spring-geode-smoke-tests-initializer:compileJava FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':spring-geode-smoke-tests-initializer:compileJava'.
> Could not resolve all files for configuration ':spring-geode-smoke-tests-initializer:compileClasspath'.
> Could not find org.springframework.geode:spring-geode-starter:1.3.0.BUILD-SNAPSHOT.
Required by:
project :spring-geode-smoke-tests-initializer
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
I am an idiot.
However, what this does mean is, the build is properly trying to resolve the org.springframework.geode:spring-geode-starter:1.3.0.BUILD-SNAPSHOT
from the declared repos in the Gradle build file from the spring-initializer
Smoke Tests, the same as a "Spring for Apache Geode" project generated with Spring Initializer at start.spring.io would do, as opposed to pulling the dependency from the project, or locally.
I clearly need to rethink this, though.
from spring-boot-data-geode.
If you don't have a particular opinion, I'd align to what we've done for our smoke tests in Spring Boot (link above).
The setup from start.spring.io is not what we should be testing here IMO (it's our problem making sure that if we generated a build.gradle
, Gradle will be able to download the bits based on the repo we've defined.
Rather we should have a simple @SpringBootApplication
class and some test repository perhaps with as less code as possible (i.e. I would move those assertions in the test itself). And the simplest gradle build possible (just declaring the starter. If you need more dependencies to cover another smoke test such as actuator, I'd recommend to create another smoke test as you did to cover the fact the integration works with only the core starter). Then the tests can start the context and exercise the app. @SpringBootTest
should cover most cases IMO. Maybe another smoke test with the web starter to validate it works fine in a web application?
If dependency management is configured as it should in your gradle build, you could just refer to your starter without a version and it will use whatever bits were built locally. That way, if a regression occurs in the code, the smoke test can break and prevent the bits to be deployed on a repo. I don't know enough gradle to help you investigate that part though, sorry.
from spring-boot-data-geode.
Thanks for the feedback and ideas/thoughts, @snicoll. I will think on this more and follow-up with comments later.
from spring-boot-data-geode.
Related Issues (20)
- Create a spring-cloud-bindings BindingsPropertiesProcessor for Apache Geode HOT 2
- State project goals in documentation
- Include chapter on Testing in the SBDG reference documentation
- Compatability matrix is not up to date. HOT 1
- Remove link to SDG Version Compatibility Matrix in SBDG Wiki
- Missing geode-pulse Dependency in Documentation
- Compatibility question HOT 3
- Using a sealed class as a data object fails HOT 1
- Inheriting from entity types causes failure when using entity-defined Regions HOT 1
- Exception thrown when parsing spring.session.timeout property with java.time.Duration styling HOT 1
- Improve documentation around overriding dependency versions
- Clarify the use of SDG's @EnableExpiration annotation in docs
- Integrate Apache Geode and Jetty 11 HOT 1
- Improve Logging configuration in the Starter
- @LocatorApplication does not work with @EnableSecurity HOT 5
- PARTITION_PERSISTENT_OVERFLOW index slow HOT 6
- SBDG Fails in Docker HOT 10
- Gemfire Fails in AWS ECS HOT 8
- Add new BeanPostProcessor to register RegionConfigurers for explicitly declared Region beans
- Improve logging output for @EnableClusterAware functionality re:connection type HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from spring-boot-data-geode.