I have an interesting problem regarding json web token. The moment I add this dependency to maven pom, my unit tests for Spring Rest Controller throw gibberish, like
ResultActions results = mockMvc.perform(post("/customers/" + customerId + "/orders")
.contentType(MediaType.APPLICATION_JSON).content(new Gson().toJson(order)));
is expected to give 200, but gives 400. What I've noticed upon investigating the issue is that the problem happens only for tests that test POST/PUT (transactional HTTP requests I guess I could call them). I've tried excluding dependency from testing using information in this link, but to no avail. I'm not sure what other information to provide, because I really don't have the faintest idea as to what is causing this issue.
I've solved this issue. The problem was dependency conflict. JJWT depends on Jackson and I've already been using GSON for my Jsons. Those two conflicted in a weird way. I've solved the issue by changing JJWT to another JWT lib.
Related
I have a small issue, in development I created an API that also checks if the POST values are valid with annotation #Valid.
#PostMapping("/news")
#ResponseBody
public News add(#Valid #RequestBody News news){
return repository.save(news);
}
When the fields are invalid, I get a return with the errors included, with the fields and defaultMessage.
I have an entity with annotations like #NotBlank etc.
Once I build my project to a jar file, and I run my project with this file, I do not get those errors anymore included in the response.
I was taking maybe this is because of development mode or something but I couldn't find anything online about it.
I assume that you are using Spring Boot's Devtools. They enable the inclusion of binding errors by default. This is only done at development time to reduce the risk of information leakage in your application's error responses. If you're comfortable with this risk, you can enable the behaviour by adding server.error.include-binding-errors = always to application.properties.
I just stumbled upon the fact that there are two classes that apparently do very similar things and it is not clear to me from the documentation when to use which.
ServletBearerExchangeFilterFunction and
ServerBearerExchangeFilterFunction
both live in the same package of Spring-Boot-Security-oauth2-resource-server and serve the same purpose of transporting a bearer token from the Context into outgoing http requests.
From the names I would have guessed that the Servlet option would be used for non Reactor projects while the Server version would be used with project Reactor. However that doesn't seem to be the case. At least the Servlet version seems to be working with Spring-WebFlux.
Can anyone please explain when to use which implementation?
We apparently had a false observation when using the ServletBearerExchangeFilterFunction. I corrected this in the original Question.
It turns out the ServletBearerExchangeFilterFunction can be used to configure a WebClient for use in a WebMVC (Thread based request processing) context while the ServerBearerExchangeFilterFunction works when using SpringWebFlux.
I'm trying to build a Java service that other services could call.
This service is not a WS, but is calling a RestfulWS.
I'm really just building a wrapper around this call. This would find the correct data it needs, set up the JSON for the call. Get a response and send it back up.
Was told to use Jersey for this. Trying to set up all the pom.xml to use Jersey.
Building code works fine, it is when the deploy to the server happens that things fail.
I get the error -- "JBAS011232: Only one JAX-RS Application Class allowed. "
I don't have a web.xml, which I guess is used to skip some ResetEasy files.
I do have exclusions in pom.xml and jboss-deployment-structure.xml.
I still get the error when deploy happens. Not really sure what else to check.
It looks like you have a problem with JAX-RS dependencies. JBoss already has its own implementation of JAX-RS and probably that’s causing the issue. Some solutions are already suggested here Jboss error: Only one JAX-RS Application Class allowed
Working with Spring Data Rest continues. Moving to 2.4.0 gave me more of the behavior I want, however now I am getting a strange intermittent exception.
About. . . 2/3 of the time when I reload or deploy my application, every SDR endpoint with data throws a 500, and gives the following:
GET /api/departments
--------------------
HTTP Status 500 - Could not write content: org.springframework.data.rest.webmvc.json.PersistentEntityJackson2Module$ProjectionResourceContentSerializer
cannot be cast to com.fasterxml.jackson.databind.ser.impl.UnwrappingBeanSerializer
(through reference chain:
org.springframework.hateoas.PagedResources["_embedded"]
->java.util.UnmodifiableMap["departments"]
->java.util.ArrayList[0]
->org.springframework.data.rest.webmvc.json.ProjectionResource["content"]);
nested exception is com.fasterxml.jackson.databind.JsonMappingException:
org.springframework.data.rest.webmvc.json.PersistentEntityJackson2Module$ProjectionResourceContentSerializer
cannot be cast to com.fasterxml.jackson.databind.ser.impl.UnwrappingBeanSerializer
(through reference chain:
org.springframework.hateoas.PagedResources["_embedded"]
->java.util.UnmodifiableMap["departments"]
->java.util.ArrayList[0]
->org.springframework.data.rest.webmvc.json.ProjectionResource["content"])
(Full error report available: http://pastebin.com/xzzXkFiR )
Like I said, this does not occur every time I reload/deploy the app, but if it is occuring it's completely stuck, and a reload is the only way to fix it. Very odd behavior, wondering if anyone has any insight.
Issue does not occur if I roll back to Spring Data Rest 2.3.2
Thanks for the help, and please let me know what other relevant information I can provide.
SDR: 2.4.1
SFW: 4.2.1
SDJPA: 1.9.0
Some further testing
Issue also occurs with latest (2.5.0 SNAPSHOT).
I can observe the same issue after updating to Spring Data Rest 2.4.0. The issue is not deterministically reproducible. I do not have any statistics so far, but it occurs less frequently after updating Jackson dependencies from 2.4.0 to 2.6.0. Sometimes it still pops up, but then a reload is sufficient in my case. A minimal example would help to dive deeper into it.
Bugs in jackson-databind library. Upgrade to release train Gosling-SR3 once released.
See https://jira.spring.io/browse/DATAREST-716 and https://jira.spring.io/browse/DATAREST-743
I have a simple Spring Integration 2.0.1 aggregator setup, using a SimpleMessageStore along with a regular Spring MessageGroupStoreReaper defined, in order to be able to implement a grouping timeout mechanism (which worked simply as an aggregator 'timeout' parameter in Spring Integration 1.0.4).
I already debugged and verified the messages are aggregated correctly within SimpleMessageStore based on groupId, but upon timeout the MessageGroupStoreReaper fails, with "Unable to access property 'messages' through getter" AccessException. The precise error is located within MessagingMethodInvokerHelper class, which asserts the messages field is not null. It seems somehow the messages aggregated are not available during execution of the Invoker, resulting in the ""Invalid method parameter for messages: was expecting a single payload." IllegalStateException.
What could be the cause of this issue and how to resolve it?
I already tried updating to 2.0.6, but the issue remains.
***EDIT
I updated my SI dependencies to 2.2.5, but this did not resolve my problem. I use Spring 3.0.7.
Only one solution to fix it just to upgrade to latest version of Spring Integration - 2.2.6.
2.0 is now out of support. Sorry
I resolved the issue, it seems that the previous setup that worked for SI 1.0.4 required modification on service activator side - the output channel was expecting List<Message<?>>, while the actual aggregated type was Message<List<Message<?>>>. After modification of activator's method signature to match the latter type, SI was able to match signature candidate properly. This could possibly be also fixed by modification of aggregator add method to operate on specific Message instead of List, with no modifications to the activator.