Passing a List of Enum to Spring REST using Get method #QueryParam - spring

I am using Spring and I need to pass a list consisting of enum values using the GET METHOD. Is it possible to use #QueryParam for a List ? If yes, then how and how do we send it through the url.
I used #QueryParam List enumValues and sent data through the url as enumValues=value1&enumVales=value2.
But I get the following error:
org.springframework.beans.BeanInstantiationException: Failed to instantiate [java.util.List]: Specified class is an interface
Please help!

You are facing this issue because you are using JAX-RS annotation #QueryParam with spring. Spring is not compliant to JAX-RS framework, they are completely two different MVC frameworks. If you rather use Spring annotation #RequestParam, the configuration is simple and it will create list of Enum for you:
Your query parameters will look like this: enumValues=value1&enumVales=value2
Your spring RequestMapping will look like: #RequestParam(value="enumValues")List<EnumValues> enumValues

Related

Spring Boot / MVC - How to customize handling of return types for controller methods?

Spring Boot 2.3
I would like to return Kotlin's Result type from a Spring Boot controller method. This type can either be an exception or a success. If it is an exception, I would like to extract this and allow it to flow to the normal ExceptionHandler. If it is a success, then I want to extract this and allow it to flow out as if it had been returned from the controller method.
I am having trouble finding information on how to add additional controller result type handlers in Spring Boot. Any help that can be provided toward this would be much appreciated.

Jackson Custom Deserializer/Serializer with Spring MongoTemplates

I am having trouble accessing and writing data from/to mongoDB using spring mongoTemplate.
For starters I have a data-model that represents the object that I am trying to retrieve from mongo. I have it annotated with #JsonSerialize and #JsonDeserialize for specifying custom converters.
However when I invoke mongoTemplate.findById(), and try to get this object, I find that my custom deserializer is not invoked at all and I get HttpMessageNotWriteableException.
Is there any other configuration that must be put in place to let mongo know that it needs to use my custom Jackson deserializer?
You can use this for reference: https://gist.github.com/letalvoj/978e6c975398693fc6843c5fe648416d

Using #ConfigurationProperties statically - such as on #RequestMapping

Let's ignore for a moment whether doing this is a great idea, but I'm creating Spring Boot AutoConfiguration for an internal library and as part of this I want to auto-register a Controller that accepts GET/POST/DELETE requests (it is responsible for setting/clearing a cookie value for application testing purposes)
The issue is that I would like the request mapping path to be configurable by the end user. I have a #ConfigurationProperties(prefix = "my.configs") class that contains all the configuration values with their defaults for example: private String path = "default-path"
Ideally i'd be able to reference this in my controller like so: #RequestMapping(path=${my.configs.path}) but this does not work, Spring reports that it is unable to find that configuration parameter, if I place it into a properties file instead of into a the type-safe #ConfigurationProperties it works as expected.
I know I could get around this by putting a default value into the Request mapping, but I'd like to understand just what is happening here, and why I cannot statically refer environment variables read / defaulted into #ConfigurationProperties in the way that I can those defined in files.
#RequestMapping is a Spring MVC annotation and it gets processed by Spring MVC - no matter if it is all wrapped in Spring Boot app or not.
#ConfiguationProperties is on the other hand 100% Spring Boot code and to my knowledge both types of properties are processed at different moments during Spring Context startup lifecycle.

When to use #RestController vs #RepositoryRestResource

I have been looking at various examples of how to use Spring with REST. Our end target is a Spring HATEOAS/HAL setup
I have seen two distinct methods for rendering REST within Spring
Via #RestController within a Controller
Via #RepositoryRestResource within a Repository
The thing I am struggling to find is why would you use one over the other. When trying to implement HAL which is best?
Our database backend is Neo4j.
Ok, so the short story is that you want to use the #RepositoryRestResource since this creates a HATEOAS service with Spring JPA.
As you can see here adding this annotation and linking it to your Pojo you have a fully functional HATEOAS service without having to implement the repository method or the REST service methods
If you add the #RestController then you have to implement each method that you want to expose on your own and also it does not export this to a HATEOAS format.
There is a third (and fourth) option that you have not outlined, which is to use either #BasePathAwareController or #RepositoryRestController, depending on whether you are performing entity-specific actions or not.
#RepositoryRestResource is used to set options on the public Repository interface - it will automatically create endpoints as appropriate based on the type of Repository that is being extended (i.e. CrudRepository/PagingAndSortingRepository/etc).
#BasePathAwareController and #RepositoryRestController are used when you want to manually create endpoints, but want to use the Spring Data REST configurations that you have set up.
If you use #RestController, you will create a parallel set of endpoints with different configuration options - i.e. a different message converter, different error handlers, etc - but they will happily coexist (and probably cause confusion).
Specific documentation can be found here.
Well, above answers are correct in their context still I am giving you practical example.
In many scenarios as a part of API we need to provide endpoints for searching an entity based on certain criteria. Now using JPA you don't have to even write queries, just make an interface and methods with specific nomenclature of Spring-JPA. To expose such APIs you will make Service layer which would simply call these repository methods and finally Controllers which will expose endpoints by calling Service layer.
What Spring did here, allow you to expose these endpoints from such interfaces (repositories) which are generally GET calls to search entity and in background generates necessary files to create final endpoints. So if you are using #RepositoryRestResource then there is no need to make Service/Controller layer.
On the other hand #RestController is a controller that specifically deals with json data and rest work as a controller. In short #Controller + #ResponseBody = #RestController.
Hope this helps.
See my working example and blog for the same:
http://sv-technical.blogspot.com/2015/11/spring-boot-and-repositoryrestresource.html
https://github.com/svermaji/Spring-boot-with-hibernate-no-controller
#RepositoryRestController override default generated Spring Data REST controllers from exposed repository.
To take advantage of Spring Data REST’s settings, message converters, exception handling, and more, use the #RepositoryRestController annotation instead of a standard Spring MVC #Controller or #RestController
E.g this controllers use spring.data.rest.basePath Spring Boot setting as base path for routing.
See Overriding Spring Data REST Response Handlers.
Be aware of adding #ResponseBody as it is missed in #RepositoryRestController
If you not exposed repository (marked as #RepositoryRestResource(exported = false)), use #BasePathAwareController annotation instead
Also be aware of bags
ControllerLinkBuilder does not take Spring Data REST's base path into account and #RequestMapping shouldn't be used on class/type level
and
Base path doesn't show up in HAL
Workaround to fix link: https://stackoverflow.com/a/51736503/548473
UPDATE: at last I prefer not to use #RepositoryRestController due to lot of workarounds.

integrating spring 2.5.6 and Struts 1.3.8

I want to clear some moments about integrating spring and struts. I have only one action class per application extended from MappingDispatchAction. So, actually my app when doing something uses not Action objects, but methods from my action. All I want from spring is to initialize this action and all for now. Just simply set DAO object. I looked through documentation, but I don't understand following:
We use action path from struts-config.xml as a name of bean in action-servlet.xml. Okay, but am I supposed to write beans in action-servlet.xml for every path name and set this poor DAO ref or what ?
The Struts 1 config file will use the DelegatingActionProxy class as the type attribute for all action configurations.
The Spring config file will contain the bean definitions of each action implementation. I don't know what DAO you're talking about, but actions that require DAO or service injection need to have them listed, yes--that's what Spring configuration is.
You may also be able to use annotations if you're not interested in using XML configuration, or use bean inheritance if many beans share the same DAO/service/etc. property values.

Resources