While fixing all the deprecated api's when upgrading to Spring 4.3.3, I'm facing an issue with the MultiActionController class which is used in multiple locations.
Are there any alternative classes in spring which have the same functionality as MultiActionController?
As per the spring docs:
as of 4.3, in favor of annotation-driven handler methods ,we need to
follow annotation .
Are annotations the only solution or are there any other classes or workarounds?
As far as I'm aware, annotations are the only way now, unless you're willing to use the deprecated MultiActionController class.
In the javadoc for the MultiActionController class, they state that it's deprecated in favor of annotations, so logically there should be an annotation to replace (or at least mimic) the majority on methods within the class. They don't list any other alternatives or workarounds so I doubt there are any. The methods don't specify anything either.
Here is the Spring 4.3.3 framework reference which could aid you in tracking down the annotations you're looking for. Section 30.6 - Annotation-driven listener endpoints would be a good place to start.
Here is a page on Migrating to spring framework 4.x, and finally, a page on Converting a Spring Controller into a #Controller. These links should point you in the right direction.
Related
Thanks to this question, I think I understand how validation is working.
As for JPA, here we have a specification called JSR-303 explaining how Bean Validation should work and then we are using implementations like the commonly used Hibernate Validator or Apache BVal also.
I am struggling about using #Validin some part of my code. I am not using #Validated because I do not need group validation.
You can find an example of a demo project here
In PropertyExample class, you can see I marked my class for bean validation to happen.
When using #Validated, everything work as expected since I am violating a constraint in my application.yml file.
When using #Valid over #Validated, it seems nothing happens. I do not understand why.
I saw too that those annotations could be used on ElementType.PARAMETER but when I am using using them during constructor initialisation, validation doesn't seem to trigger either.
Explanations on how to used those annotations (especially the #Valid) would be greatly appreciated.
It works when using Validated and doesn't when using Valid simply because Spring Boot requires properties classes to be annotated with Validated if you want them to be validated. See the documentation:
Spring Boot attempts to validate #ConfigurationProperties classes whenever they are annotated with Spring’s #Validated annotation
[...]
You can also trigger validation by annotating the #Bean method that creates the configuration properties with #Validated.
Note that they can't possibly allow the use of Valid on properties classes, since the Valid annotation isn't applicable to classes.
I am use Spring in my app, when we have some class that doesn't implements any interface, Spring will use "cglib" to proxy.
Can I change the cglib to other lib in Spring? If yes, How can I do it?
Thanks!
[EDIT]
Hi, I was wanting because I have problems with PermGen when I use CGLIB, the proxys instance are not cleaning when I do hotdeploy.
Yes, I can change for other stretegy, Aspect etc...
Spring only supports JDK (interface only) and CGLIB based (for classes) proxying, and while it's not explicitly mentioned, it also uses Objenesis with CGLIB for proxying classes with no default constructor. Also see their issues regarding this at https://jira.spring.io/browse/SPR-8190 and https://jira.spring.io/browse/SPR-5654 for further reference. That means there's no drop-in replacement or configuration options in Spring to switch to some other proxy creation method.
If you're still willing to explore uncharted territories, the DefaultAopProxyFactory might be a good place to start as it seems it's a central piece of the proxy creation code in Spring, the proxy creator classes use it as a factory through their common superclass ProxyCreatorSupport.
This is a follow up to a prior SO post.
Spring 3.2 has deprecated AnnotationMethodHandlerAdapter in lieu of RequestMappingHandlerAdapter. Prior to Spring 3.2, I was able to use AnnotationMethodHandlerConfigurer to configure the PathMatcher, but I cannot seem to find the equivalent in Spring 3.2.
There is a RequestMappingHandlerMapping class to customize the RequestMappingHandlerAdapter, however I do not see how I can specify a custom PathMatcher. To be frank, I cannot find where a PathMatcher is used in Spring 3.2.
Can anyone point me in the right direction?
As an FYI for someone who comes across this in the future, I also found this reference link that has some information as to how to do it via XML, however I have not tested it yet.
The method setPathMatcher is defined in the abstract base class AbstractHandlerMapping. So you can configure the RequestMappingHandlerMapping to use another PathMatcher.
According to the Spring docs, to enable autodetection of annotated controllers, you add component scanning to your configuration:
<context:component-scan base-package="org.springframework.samples.petclinic.web"/>
My question is, why is this necessary?
If a Controller has an annotation to already indicate what it is, shouldn't that be enough for Spring without component scanning?
How else would Spring find the classes? If you haven't told Spring to look in a certain class or package, those classes aren't going to get loaded, and Spring is never going to find them.
This is more a limitation of the java classloading model (if you can call it a limitation), then it is a limitation of Spring.
You only have to put the following in your configuration:
<context:annotation-config/>
If you only put the annotation on your class, the framework had to load all the classes to check if the annotation is present.
To minimize this overhead, you have to put the annotation-config tag in your configuration. That way the framework knows it has to check the classes from that configuration.
You can help the framework by specifying the package where your annotated classes are with the "base-package" attribute.
//EDIT//
This also explains the note in the documentation:
Note
<context:annotation-config/> only
looks for annotations on beans in the
same application context in which it
is defined. This means that, if you
put in a
WebApplicationContext for a
DispatcherServlet, it only checks for
#Autowired beans in your controllers,
and not your services.
Simply annotating a class with #Controller doesn't necessarily mean you want it to be part of your Spring context. Imagine if the class is part of another application, or part of a third party library, or a deprecated component of your system, etc. Just because it is on the classpath doesn't necessarily mean that you want it automatically instantiated as a bean in your Spring context.
I have noticed from several web pages that apparently Spring 3.0 supports #Inject from JSR-330. As we would really like to use JSR-299 syntax for dependency injection in our libraries for both web apps and stand-alone applications, and have alternatives to Weld, it would be nice if Spring could do this.
Being a novice to Spring, I tried downloading the Spring Framework distribution and put all jars on the Eclipse build path. No Inject annotation so my existing test project using Weld did not compile.
Can this be done with Spring? What do I need to do to get it running?
(I am aware that Guice eventually will support this too. It is only in SVN for now, and if there is an official Spring release which can, that would be better.)
It can be done. The JSR-330 jar must be downloaded seperately, and cglib to parse the manually written #Configuration classes, plus a commons logging implementation.
The largest difference from Weld seems to be that the wiring needs to be manually written instead of magically found (a bit more cumbersome, but may make more robust applications), plus the startup time is much less. I am still new to Spring - is there a way to have #Configuration classes autodiscovered?
From the Spring 3.0.x Reference documentation:
JSR 330's #Inject annotation can be used in place of Spring's #Autowired in the examples below. #Inject does not have a required property unlike Spring's #Autowire annotation which has a required property to indicate if the value being injected is optional. This behavior is enabled automatically if you have the JSR 330 JAR on the classpath.
So you can make your code agnostic of the DI framework by using #Inject, but you still need to include a jar with the javax.inject classes in your project because Spring does not ship them itself. You can find the relevant jar in the downloads section at JSR-330's Google Code site.
The javax.inject package is not included as part of Spring 3, but it does support it if it's present.
If you look at the source for AutowiredAnnotationBeanPostProcessor, you'll see the constructor uses reflection to locate javax.inject.Inject, and logs a message if it finds it. There's no compile-time dependency on it.
You'll need to locate the JSR-330 JARs from some other source (e.g. the JavaEE 6 SDK).