I just upgraded to Boot 1.4.1 which itself upgrades to SDR 2.5.3. This introduces JacksonMappingAwareSortTranslator which kicks in when e.g. a Pageable is used in a RequestMapping-method in a #RepositoryRestController.
This tries to find out the used Repository from the request path and do then some translations.
My problem is, that I have a #RepositoryRestController which is not bound to a particular repository but finds it repo based on the request path like /{collection}/query.
This now failes because SDR cannot find the repository.
So my question is: How can I solve this?
I have to use #RepositoryRestController because I need a PersistentEntityResourceAssembler injected as method param. So Using just #Controller does not work.
Do I have to implement my own version of Pageable and translate it into the SD-Pageable?
Can I disable JacksonMappingAwareSortTranslator?
Thank you
jackson-annotations-2.3.5.jar,
jackson-core-2.3.5.jar,
jackson-databind-2.3.5.jar
<!-- Configure bean to convert JSON to POJO and vice versa -->
<beans:bean id="jsonMessageConverter"
class="org.springframework.http.converter.json.MappingJackson2HttpMessageConverter">
</beans:bean>
<beans:bean id="formHttpMessageConverter"
class="org.springframework.http.converter.FormHttpMessageConverter">
</beans:bean>
Related
We are upgrading from Spring 3.2.4 to Spring 4.3.8 in which singleton="false" is no longer supported. What is the way to set singleton 'false' in Spring 4.3.8?
If singeton="false" then does it means that spring bean scope has become "Prototype"?
You can use #Scope for specifying prototype bean.
Example:
#Bean #Scope("prototype")
public Person personPrototype() {
return new Person();
}
for further reading follow link
As far as I remember, singleton=false was kept for some compatibility reasons, also indicated in some older docs, eg 3.0.0.M3:
<bean id="accountService" class="com.foo.DefaultAccountService"/>
the following is equivalent, though redundant (singleton scope is the default); using spring-beans-2.0.dtd
<bean id="accountService"> class="com.foo.DefaultAccountService" scope="singleton"/>
the following is equivalent and preserved for backward compatibility in spring-beans.dtd
<bean id="accountService"> class="com.foo.DefaultAccountService" singleton="true"/>
Anyway, the default spring scope is singleton, so even when unspecified, but can be changed to prototype (or whatever you need) with:
XML: scope="prototype"
Java DSL: #Scope("prototype") or #Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
Correct, scope="prototype" is the direct equivalent of singleton="false".
The equivalent of singleton="false" is scope="prototype".
another alternative is to use the annotation #Scope("prototype")
The equivalent of singleton="true" would be to eliminate this attribute in the spring config, since scope="singleton" would be the default.
I have modified my original question slightly to better reflect my question. I have a non-Spring Boot application that I would like to have working with the Spring Cloud Config Server. I have searched around online and tried many things but it seems like the crux of my issue is that the server only works within a Spring Boot context. Although ActiveMQ is a Spring application already, it seems non-trivial to convert it to be a Spring Boot one.
I would like to have an ActiveMQ Broker that is configured from the Spring Cloud Config. My local settings within the application.properties should be replaced by those that come from the server. This works in other servers I work on, now I need it to work for my Broker Filter plugins.
I added the following to activemq.xml:
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
<list>
<value>classpath:application.properties</value>
<value>file:${activemq.conf}/credentials.properties</value>
</list>
</property>
</bean>
NOTE: Several base packages omitted here but are similar to:
<context:component-scan base-package="org.springframework.cloud.bootstrap"/>
<!-- enables annotation based configuration -->
<context:annotation-config />
After doing so I was able to get various #Value annotations to work with settings coming from my application.properties but the whole Spring Cloud Config Server thing seems to not replace my local application.properties file settings. Other Spring Boot application I work on do so I know the server is fine.
I have added the following jars to the apache-activemq-5.12.0\lib\extra directory:
spring-aop-4.1.8.RELEASE.jar
spring-beans-4.1.8.RELEASE.jar
spring-boot-1.2.7.RELEASE.jar
spring-boot-actuator-1.2.7.RELEASE.jar
spring-boot-autoconfigure-1.2.7.RELEASE.jar
spring-boot-starter-1.2.7.RELEASE.jar
spring-boot-starter-actuator-1.2.7.RELEASE.jar
spring-boot-starter-data-mongodb-1.2.7.RELEASE.jar
spring-boot-starter-logging-1.2.7.RELEASE.jar
spring-cloud-commons-1.0.1.RELEASE.jar
spring-cloud-config-client-1.0.1.RELEASE.jar
spring-cloud-context-1.0.1.RELEASE.jar
spring-cloud-starter-1.0.1.RELEASE.jar
spring-cloud-starter-config-1.0.1.RELEASE.jar
spring-context-4.1.8.RELEASE.jar
spring-context-support-4.1.8.RELEASE.jar
spring-core-4.1.8.RELEASE.jar
spring-data-commons-1.11.0.RELEASE.jar
spring-data-mongodb-1.8.0.RELEASE.jar
spring-expression-4.1.8.RELEASE.jar
spring-jms-4.1.8.RELEASE.jar
spring-security-crypto-3.2.8.RELEASE.jar
spring-test-4.1.8.RELEASE.jar
spring-tx-4.1.8.RELEASE.jar
spring-web-4.1.8.RELEASE.jar
refreshendpoint is not necessarily initialized when the constructor is called. You need to add a method annotation with #PostConstruct (or implement InitializingBean and implement afterPropertiesSet method) in which you'll perform refreshendpoint.refresh(); , e.g:
#PostConstruct
void init() {
refreshendpoint.refresh();
}
I have got Spring RestController classes to handle rest services using JSON. For JSON I am using Jackson. There are fields of java.util.Optional type
private Optional<Long> start = Optional.empty();
To enable the handling of Optional type, I am configuring the Spring as follows
<bean id="objectMapper" class="org.springframework.http.converter.json.Jackson2ObjectMapperFactoryBean">
<property name="modulesToInstall" value="com.fasterxml.jackson.datatype.jdk8.Jdk8Module" />
</bean>
However when I call the webservice, it fails in deserializing the Optional types with following message
org.springframework.http.converter.HttpMessageNotReadableException:
Could not read JSON: Can not instantiate value of type
[simple type, class java.util.Optional<java.lang.Long>]
from Long integral number (3424323423432); no
single-long-arg constructor/factory method
Doing serialization/deserialization from stand alone code works fine. There I register the module directly using the following code
ObjectMapper m = new ObjectMapper();
m.registerModule(new Jdk8Module());
Versions I am using:
Spring : 4.1.5.RELEASE
Jackson: 2.5.1
Thanks in advance
I could figure out this. The solution is to register the object mapper to Message converter as follows
<mvc:annotation-driven>
<mvc:message-converters>
<bean
class="org.springframework.http.converter.json.MappingJackson2HttpMessageConverter">
<property name="objectMapper" ref="objectMapper" />
</bean>
</mvc:message-converters>
</mvc:annotation-driven>
<bean id="objectMapper" class="org.springframework.http.converter.json.Jackson2ObjectMapperFactoryBean">
<property name="modulesToInstall"
value="com.fasterxml.jackson.datatype.jdk8.Jdk8Module" />
</bean>
If you are using latest version of Spring-boot then you could achieve this by adding the following dependency in the pom file
<dependency>
<groupId>com.fasterxml.jackson.datatype</groupId>
<artifactId>jackson-datatype-jdk8</artifactId>
</dependency>
Spring blog says :
Some well known Jackson modules are automatically registered if they are detected on the classpath:
jackson-datatype-jdk7: Java 7 types like java.nio.file.Path (as of 4.2.1 release)
jackson-datatype-joda: Joda-Time types
jackson-datatype-jsr310: Java 8 Date & Time API data types
jackson-datatype-jdk8: other Java 8 types like Optional (as of 4.2.0 release)
And if you want to use the mapper in your code, auto wire the JacksonObjectMapper.
#Autowired
private ObjectMapper jacksonObjectMapper;
Then use the above Spring container's mapper instance to convert Object to String
jacksonObjectMapper.writeValueAsString(user);
The answer above works for Spring 4.
Just make sure you're using the latest xsd's in your xml configuration.
In my situation it was somehow referencing 'spring-mvc-3.0.xsd' and this version does not know the 'mvc:message-converters' tag yet. Changing it to 'spring-mvc.xsd' solved this issue.
I been trying to find a example of how to do multiple file upload in Spring MVC without using XML only Java Config. So far have found nothing and a lot of people that just either want hits to sites or don't know what java configuration v xml configuration is.
I don't use Spring Boot and don't want to as I want to learn this framework no matter how difficult.
Even advice on how to convert the following line to java config would be appreciated:
<bean id="multipartResolver" class="org.springframework.web.multipart.commons.CommonsMultipartResolver">
<property name="maxUploadSize" value="1000000" />
</bean>
Please do advise also what JARs i would need for the above multipartResolver.
Thanks a bunch gang
That line translates to
#Bean
public MultipartResolver multipartResolver() {
org.springframework.web.multipart.commons.CommonsMultipartResolver multipartResolver = new org.springframework.web.multipart.commons.CommonsMultipartResolver();
multipartResolver.setMaxUploadSize(1000000);
return multipartResolver;
}
Within a #Configuration class which you'd load in your Servlet context.
You need commons-fileupload library for this to work.
I'm configuring my Spring MVC 3.1.1 app as summarized below. Logging shows that 'MyArgumentResolver.resolveArgument' is invoked before 'MyInterceptor.preHandle'. When using both in an old fashion configuration (with exclicitly defined AnnotationMethodHandlerAdapter bean etc.) they are invoked vice versa. I read that <mvc:annotation-driven> is somehow critical, since its configuration does not complement other settings of mvc: namespace. Am I facing the same problem?
<mvc:annotation-driven>
<mvc:message-converters>
...
</mvc:message-converters>
<mvc:argument-resolvers>
<bean class="[...].MyArgumentResolver"/>
</mvc:argument-resolvers>
</mvc:annotation-driven>
<mvc:interceptors>
<mvc:interceptor>
<mvc:mapping path="/home/**" />
<bean class="[...].MyInterceptor" />
</mvc:interceptor>
</mvc:interceptors>
Many Thanks!
Spring 3.1 with <mvc:annotation-driven> uses a different set of classes for handling requests - e.g., AnnotationMethodHandlerAdapter is replaced with RequestMappingHandlerAdapter. You can read more about that here: http://static.springsource.org/spring/docs/3.1.x/spring-framework-reference/html/mvc.html#mvc-ann-requestmapping-31-vs-30
In order to work properly with those classes, they've added a new HandlerMethodArgumentResolver that supersedes the old WebArgumentResolver interface. However, I believe that Spring will automatically try to "upgrade" old WebArgumentResolvers by wrapping them in an AbstractWebArgumentResolverHandlerAdapter, which is the behavior that I was seeing during the process of upgrading. The JavaDoc for AbstractWebArgumentResolverHandlerAdapter says:
Note: This class is provided for backwards compatibility. However it is recommended to re-write a WebArgumentResolver as HandlerMethodArgumentResolver. Since supportsParameter(org.springframework.core.MethodParameter) can only be implemented by actually resolving the value and then checking the result is not WebArgumentResolver#UNRESOLVED ...
After stepping through the code, I think what may be happening in your case is that it the new classes call the supportsParameter function before executing preHandle in the interceptors, but the implementation of AbstractWebArgumentResolverHandlerAdapter actually calls the resolveArgument method and checks for 'UNRESOLVED' as the return type in order to determine if the argument resolver supports the given argument, which would give the appearance of them being called out of order.
I suspect if you rewrite your argument resolver to implement the new HandlerMethodArgumentResolver interface, it will solve your problem.