I can't seem to find anything that talks about using the #WebFilter annotation, and having Spring 3.2 AbstractAnnotationConfigDispatcherServletInitializer correctly handle the params used.
Does Spring 3.2 support that annotation?
EDIT: based upon nicohlas answer
If I use the #WebFilter annontation, and set params inside of that...it looks like AbstractAnnotationConfigDispatcherServletInitializer registerServletFilter does not look at those annontations and setup things properly from those params: e.g url-mappings
Knowing that Spring 3.2 supports Servlet 3.0, shouldn't it support #WebFilter?
or am i missing the whole point of the WebFilter annontation?
EDIT 2:
When I deploy my war, and have #WebFilters defined inside that war, the container looks to "register" those...but, for some reason, even with the proper urlPatterns set, when the request comes into the DispatchServlet...it's like the filter doesn't get called.
#WebFilter is a JEE6 component, and is new to Servlet 3.0.
It is not something that Spring would support, but rather your application container (Tomcat, WebSphere, Glassfish, JBoss,...)
The idea here is to move configuration of your application container to Java, rather than utilizing the web.xml deployment descriptor.
EDIT:
It would seem to me that using the #WebFilter annotation would be for discovering Filter's via classpath scanning. The AbstractAnnotationConfigDispatcherServletInitializer#registerServletFilter method that you are asking about is taking in a Filter and does not look at the annotations on it.
Related
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.
This question already has answers here:
Why is my Spring #Autowired field null?
(21 answers)
Closed 7 years ago.
In order to provide POJOs in my legacy web app (Tomcat 8.0.26) with the ability to send ActiveMQ messages I've taken the recommendation to introduce Camel (2.15.2) / Spring (4.2.1) into the app to purely for the purpose of managing pooled MQ connections. I'm hoping there isn't an easier way.
Doing things the Spring way I'm thinking everything would need to be based around an MVC architecture with HTTP servlet aware controllers having access to the servlet context and therefore the Spring context in order to inject beanFactory beans into classes annotated with #Controller and #Service (and in fact there must be a Spring #Controller class that enables Spring to inject the #Service class.
However, as I've stated this is legacy code that will not be using the spring web framework.
After much pain it seems that the only way I can get beanFactory beans injected into my POJOs is to go the AspectJ and Weaving route. Before I go down this road can someone tell me that this is currently the best approach (what I've read describing this solution is from 2011 Can't get Spring to inject my dependencies - Spring Newbie) ? Can you point me to documentation and a working example?
Many thanks.
1) aspectj with #Configurable
In your #Configuration annotated class/es
you can add some more annotations
#Configuration
#EnableLoadTimeWeaving(aspectjWeaving = EnableLoadTimeWeaving.AspectJWeaving.ENABLED)
#EnableSpringConfigured
#EnableAspectJAutoProxy
to enable aspectj and the #Configurable annotation,
you need to import the aspectj lib to your project and add the spring tomcat instrumentable java agent in your tomcat lib folder (give a look here, it exaplains how to configure tomcat) http://docs.spring.io/spring-framework/docs/2.5.6/api/org/springframework/instrument/classloading/tomcat/TomcatInstrumentableClassLoader.html
this is not going to help you if you are going to create your pojos using "new"
MyPojo p = new MyPojo(); // no black magic for this, you will need to satisfies the dependencies yourself) but that would be helpful for example when you load some entities through a framework like hibernate and you want to inject something into them.. #Configurable it's an option that can be evaluated in those cases, for what you describe I would rather not use it.
2) You can have some static methods that uses some static set spring-beans and use them from your pojos, something like
class Util{
private static SprintBeanWithJmsSupport x;
public static setSpringBeanToHandleJmsMessages(SprintBeanWithJmsSupport x){
Util.x = x;
}
public static sendJmsMessage(JmsMessage m){
x.sendMessage(m)
}
}
and you can go with Util.sendJmsMessage(...)
this is a bit shitty but it does the work, I don't personally like this approach
3) set your spring beans in your pojo when they need to use them (maybe behind some nice interfaces that suit your domain)
if you go with spring mvc you will likely end up having some controllers that will use some services (generally they handle security / db access and are the entry point to start the "use cases"), as everything wthin these layers is handled by spring it will be very simple to pass the spring-bean to handle jms messaging to your pojos, this seems to me quite a nice way to handle the problem
I went mostly based on memory and something may not be completely accurate, plus my english is .. what it is, so hope this can be helpful anyway.
Can someone help me with a minimal project setup with Spring Boot and Struts2?
I have already create a Spring Boot application with a H2-database. I also added a h2Configuration class, so that I'm able to access the database with localhost:8080/console.
But how can I add Struts2 to my Application without web.xml?
Without web.xml you can only write a Struts2 filter using servlet 3.0 or higher
#WebFilter("/*")
public class Struts2Filter extends Struts2PrepareAndExecuteFilter {
}
The content could be empty, it's enough to add annotated filter without any inclusion in the web.xml file.
If you want to integrate Struts2 with Spring, then you should use a plugin.
Struts 2 provides a plugin that enables Spring to inject into the ActionSupport classes any dependent objects you've specified in the Spring configuration file. Consult Spring Plugin documentation for more information about how the plugin works.
I have a huge set of really old Portlets code I am being required to "refactor" due to a bug that was found in Prod. The refactor is requiring me to update to a new library, and as a result move from a custom DAO structure using "Query" classes to one that uses Springs JdbcTemplate and annotations to wire everything together.
BUT, there are a LOT of portlets. Is there a way to use Spring with Annotations for DI that does NOT require me to completely re-write the Portlet to use DispatcherPortlet and the #RequestMappings? I just want to mark all the Portlets, and the handful of Servlets as well, with #Component just to have Spring inject the classes I need. Where I am struggling is in how to bootstrap the ApplicationContext without using the Spring-provided dispatcher portlet/servlet to initiate the context. I would like to not have to use the ApplicationContext directly to pull the necessary beans out by hand, if possible. I do have contextConfigLocation and the ContextLoaderListener defined in my web.xml already.
Definitely need some expert help with this! I think this is mainly a Spring Security question, but as I don't know for sure, so I am also tagging with the general Spring tag!
When the Application Context is loaded (mine is all via Java Config, though I don't believe that matters), the "DefaultListableBeanFactory" is processed and eventually (via the ProxyFactory) Spring Security Advisors are added. This is great when I have Spring Beans as I have Permissions that need authorization.
My question is: how do I get the same effect when I no longer require those classes to be Spring Beans? Said differently, if I have an object instance created as a singleton bean via Java Config and the authorization is working correctly, is it possible to maintain that with the object instance being a POJO? Again, for the experts, I want the interception chain returned in the JdkDynamicAopProxy to contain the Spring Security interceptors.
And "no", I am not really expecting an answer to this, maybe just hoping!!!
To add security interceptors to beans not instantiated by spring container
switch global-security tag to mode aspectj and weave the provided AnnotationSecurityAspect in the aspecj module.
For your second question I suppose that you want to do one of the following:
Use a ProxyFactoryBean to secure a bean.
Create security proxies programmatically: Use ProxyFactory.addAdvice() method.
Add the security interceptor to all proxies created by an AutoProxyCreator: This usually don't needed, but you can use the AbstractAutoProxyCreator.interceptorNames property to add common interceptors. The global-security tag parser uses a generated name for the MethodSecurityInterceptor, so you need to configure the interceptor manually and set a consistent SecurityMetadataSource.