Given that one of the main benefits of Spring Data and the related REST repositories is that most of the time the developer doesn't have to worry about the underlying implementations, is there an out-of-the-box way to leverage the Spring Cloud Netflix libraries, specifically the Hystrix annotations in this case, without extending every call in the provided Repository interfaces or creating my own implementation?
Currently you need to wrap calls in another service whose methods are annotated with #HystrixCommand. Because of the way both Spring Data and the Hystrix Aspect work (they both create proxies), there would need to be specific integration in Spring Data for #HystrixCommand. #ccit-spence is right, you really want to put #HystrixCommand on the services calling into a Spring Data REST repository.
Related
I have to integrate spring rest docs in a legacy project were they use a bunch of custom annotation (such as for example the user roles).
Is there a way in spring rest docs to document this annotation?
Spring REST Docs works at the level of HTTP requests and responses. By design, it doesn't know anything about annotations or how those requests are handled and the responses created. This ensures that what you're documenting is at the same level as a client interacting with your service over HTTP.
If you want to include information about #PreAuthorize or an annotation that is similar to it, you will have to write something yourself to do that. If you want to fit into the REST Docs way of doing things, you could implement a custom Snippet that's configured with a class or method from which it extracts the annotation using reflection and generates some documentation from it.
I have an application which is using Spring data JPA and hibernate envers for db auditing.
Since R2DBC doesn't support auditing yet, is it possible to use combination of both in a single application?
If yes, Plan is to use Spring Data JPA for insert, update and delete operations, so that all DB auditing will be handled by hibernate envers. And use R2DBC for reactive non-blocking API's to read data.
If no, Is there any suggestions on how to achieve both reactive API's and auditing?
Spring provided simple Auditing via #EnableR2dbcAuditing, check my example.
Mix JPA in a reactive application is also possible, I have an example to demo run JPA in a reactive application, but not added r2dbc in it.
For your plan, a better solution is applying the cqrs pattern on the database topology, use database cluster for your application.
JPA for applying changes, use the main/master database to accept the modification, and sync changes to the secondary/slave database.
r2dbc for queries as you expected, use the secondary/slave database to query.
use a gateway at the front for the query and command service.
Update: I have created a sample to demo JPA and R2dbc coexistence in a single webflux application. But I do not suggest using it in real-world applications. Consider the 3rd solution above if you really need it.
Yes it is possible however you will probably face two issues, one is that multiple repos modules handling needs to be explicited (e.g specify the paths of the respective modules).
Secondly, the JDBC/JPA Spring Boot autoconfiguration will be disabled and you need to import it back.
Those issues have been reported in Reactive and Non Reactive repository in a Spring Boot application with H2 database
And a solution to them and the thought process can be found in this issue:
https://github.com/spring-projects/spring-boot/issues/28025
We started to use Hystrix-wrapped #FeignClient with Spring Cloud Camden. It is easy to provide fallbacks using the fallback and fallbackFactory properties of the annotation, but we have some special needs.
We want to provide fallbacks only for specific methods of the Feign client. And we want to be able to provide different fallback implementations for the same Feign client method, depending on the use-case that is invoking.
But we don't want to give up on having Hystrix by default. It would be better to not have to annotate every method with #HystrixCommand.
Using #HystrixCommand provides a lot of flexibility, but I've observed that combining #HystrixCommand and wrapped clients results in Hystrix creating 2 thread pools: one for the class that defines the #HystrixCommand annotated methods and another for the Feign wrapped client.
The pool defined by the #HystrixCommand delegates the calls to the thread pool that wraps the Feign client. That is not optimal. A direct consequence is that we have duplicated circuit breakers, we might have to configure the timeouts twice, etc. And I don't know if that can work fine or it can cause troubles in production.
I have been looking for some days for what would be the best way to implement that but I don't think I found a good solution. Is there a better way to do this?
Thanks in advance
I have a very simple service project (SpringBootApplication) that exposes a REST endpoint via a Spring Boot controller class. The controller maps an /events endpoint that converts a simple incoming event DTO into a slightly different event entity object that is then persisted in a database via a org.springframework.data.repository.CrudRepository instance.
In my controller, I am only mapping the POST operator because I don't want my clients to be able to GET, PUT or DELETE data from the service.
During a security scan today, I discovered that the service is exposing a /eventsEntities endpoint, which appears to be mapping all of the CrudRepository verbs into the REST endpoint.
Any idea how I managed to enable this automatic endpoint and more importantly, how to disable it? I'm using Spring Boot 1.2.2.
After some additional digging, I realized that I had inadvertently included org.springframework.boot:spring-boot-starter-data-rest in my compile dependencies. That starter includes spring-data-rest-webmvc, which exposes JPA data over REST. Removing that dependency resolved the issue.
Hope my realization helps someone else in the future.
A common requirement is to access a JPA DataSource via REST. I want the opposite, i.e. a JPA provider that works by sending HTTP requests to a RESTful persistence service. The benefit of this is that any application written against the JPA API could easily switch between a traditional JPA provider (e.g. Hibernate) and the REST-based JPA provider, with no code changes required.
So my question is whether there is an existing REST-based JPA provider, and if not, would such a thing even be feasible?
Datanucleaus has a JPA implementation over a RESTful json API. However, your REST API must adhere to their conventions: http://www.datanucleus.org/products/accessplatform_3_0/json/support.html
Their S3 and GoogleStorage extend the json API.
EDIT: Put link to wrong product in my original answer.
First of all, JPA is really designed for relational databases...
Second, there is no standard for RESTful persistence so a JPA-REST provider would be specific to that REST persistence application.
You could implement something using EclipseLink-EIS. You'd just have to create the JCA_RestAdapter implementation.
If you mean one of the NoSQL databases when you say "RESTful persistence service" then maybe. Some of these NoSQL DBs provide a REST based interface and some JPA providers are starting to support NoSQL DBs. See http://wiki.eclipse.org/EclipseLink/FAQ/NoSQL.
Honestly you'd be better off just implementing the DAO pattern and abstracting your CRUD(L) operations. This is exactly what DAOs are for.
There are several alternatives out there. For example, take a look at "JEST":
https://www.ibm.com/developerworks/mydeveloperworks/blogs/pinaki/entry/rest_and_jpa_working_together71?lang=en
REST is not an API (Application Programming Interface). It is an
architectural style that prescribes not to have an API to access the
facilities of a service.
...
On the opposite end of the stateless spectrum lies the principle of
JEE Application Servers -- where the server maintains state of
everything and there exists one (or multiple) API for everything. Such
server-centric, stateful, API-oriented principles of JEE led to
several roadblocks.
...
I found REST principles concise and elegant. I also find Java
Persistence API (JPA) providers have done a great job in standardizing
and rationalizing the classic object-relational impedance mismatch.
JPA is often misconstrued as a mere replacement of JDBC -- but it is
much more than JDBC and even more than Object-Relational Mapping
(ORM). JPA is be a robust way to view and update relational data as an
object graph. Also core JPA notions such as detached transaction or
customizable closure or persistent identity are seemed to neatly
aligned with REST principles.
Further links:
http://openjpa.apache.org/jest.html
http://www.ibm.com/developerworks/java/library/j-jest/index.html?ca=drs-