I'm replacing the service tier in an existing older Struts2 project with Spring service beans developed for another project.
I'd like to just #Inject these service beans into my Action classes.
Is it required to use Struts' Spring Plugin? Or can I add Spring into my Struts web application like I would any other (ContextLoaderListener, applicationContext.xml, context:component-scan)?
Am I missing some reason why the Struts Spring plugin helps me in another way?
Many thanks!
Well you can do the most of the things what you have described in your question as Services layer is completely out of view for the S2 and Struts2 do not care how you are creating your Service layer instances and other things.
Benefits i am seeing of using Struts2-Spring plugin is to delegate creation of Struts2 related things to Spring like Action classes creation,Interceptors,Results etc.
My Suggestion is to use the plugin as you are going to use the Spring in your application so its very good and flexible as well powerful to use the power of Spring DI to create required objects needed by S2 else S2 will use its own data creation factory to create framework component.
Why wouldn't you use the Spring plugin?
It's essentially invisible, uses Spring to create your actions (including injecting other Spring beans), etc.
Guice's #Inject doesn't know anything about Spring beans, AFAIK, so you'd be naming classes manually, they'd be instantiated via normal Java/Guice mechanisms, wouldn't be injected with their own Spring dependencies (unless you did it manually, or via AOP, or whatever).
You'd also need to use non-Spring mechanisms for doing injection in testing, which is fine, but unless you provide more details regarding your usecase, I don't really see a reason to bypass the functionality the Spring plugin provides out-of-the-box.
Related
My question is not only if action classes can be scoped to singleton, but I also want to know which are the best practices. Both in context of Struts2 and Spring. Best scope of VIEW (say request or session), for controller and model.
Struts2 Actions are managed by the Struts Container. They are ThreadLocal, hence every request has its own thread-safe copy of the Action.
If you use Spring to handle them through the Struts2-Spring-plugin, there are multiple levels of usage:
you can let the Struts container instantiate them, and handle them through Spring for the Dependency Injection, or
you can let Spring take over control and be fully responsible for the whole lifecycle of every Action. In this second case:
if you declare an action as a bean in a Spring XML configuration file, the action will get the default Spring scope, that is Singleton (scope="singleton"). THIS IS DANGEROUS, USELESS, and 99.99% of the times NOT WHAT YOU WANT, because you will lose a fundamental part of the framework capability, actions will be turned into kind-of servlets, thread-UNsafe, and many problems will arise;
to prevent that, you can put the scope="prototype" in the bean declaration, that will let Spring instantiate the action without affecting its nature.
If you are inside a container Java EE 6+ compliant (for example, Jboss 7, Wildfly 8, TomEE 1.7, Glassfish 3+, ecc...), the Contexts and the Dependency Injections are handled through CDI. If you want, you can use the Struts2-CDI-plugin to allow CDI to handle your actions and inject dependencies through the #Inject annotation (instead of the #Autowired one)
I've used Spring a lot in the past, then after discovering CDI and the CDI plugin, I've switched and never looked back, so I vote for the n.3
Is it possible to use the Grails Cache plugin's annotations (ie: #Cacheable) on methods in normal Groovy classes? The plugin's documentation doesn't mention anything about normal Groovy classes and based on my own tests the annotations have no effect when used in a normal class. So I'm just wondering if there's a way to get the annotations to work in a normal Groovy class.
The current alternative is to simply directly access the cache in the method via the Cache Manager bean, but it would be nice to use the annotations instead.
No, the annotation only works on services and controllers. The plugin detects the annotation and creates a proxy for the service which intercepts all method calls and does the cache-related work first. So if there is a value in the cache for that method, it won't bother calling your real method but return the cached value instead. But if it's not cached, it will call your method and use its return value, but cache that for later.
This works because you have to retrieve the service from the Spring ApplicationContext (or have Grails do that for you) and this gives Spring a chance to give you the proxy instead of the real implementation instance, but there's no way for Spring to know about access to regular Groovy classes without AOP or some other more invasive solution.
Having said that, the plugin is probably being overly strict in limiting to only controllers and services. It handles controllers specially because those involve caching web requests instead of method return values, but there shouldn't be much difference between a Grails service and any other annotated Spring bean as far as caching goes. You can add your own Spring beans, either manually in grails-app/conf/spring/resources.groovy or by adding them to the grails.spring.bean.packages list in Config.groovy, so the plugin should be updated to look for all annotated classes. You can request this in the plugin's JIRA at https://jira.grails.org/browse/GPCACHE
My problem:
I would love to use the Spring Security plugin's access control/authorization mechanism with my Grails application without having to use the plugin's authentication mechanism. The various Grails Spring Security plugin examples (like this one) I've found combine these two functions. Is there an easy way to just do access control?
Background:
I would like to add roles-based access control to my existing app. I would love to either just annotate my controllers or use the Config.groovy map approach for setting up the access control.
My app already has a user domain class.
The user domain class already handles encrypting passwords using BCrypt.
The app does not have a "role" domain class.
I already have controller actions, views and business logic for handling logging in and logging out. I have no interest in replacing this with the plugin's implementation.
On the right track, but not quite helpful:
I know this is possible to do, as explained in this other question: BUT, that questions and its answers explains how to do it in a Java app using the raw Spring Security framework. I would love for someone to lay out how to do this in a way that is compatible with the latest version (1.2.7.3 as of this writing) of the Grails Spring Security plugin. I don't want to reinvent wheels that have already been taken care of by the plugin.
In addition, this example explains how to do some of this, but it appears to be outdated because it is based on an older version of the plugin that uses Spring Security 2.x. It also only uses custom authentication for one piece of the app, while it looks like it still uses the Spring Security plugin's domain classes elsewhere.
How to do it?
Can someone lay out an approach for me?
I assume I need to create my Role domain class.
After that I assume it will involve custom Authentication objects and the like. But how do I hook them into use the plugin's existing code?
You could go with a custom authentication provider and I have an updated version that I did as part of a recent talk. See this blog post which has a sample app and link to a video of the talk: http://burtbeckwith.com/blog/?p=1090
It would be simple to use a custom UserDetailsService - this is the most common customization done for the plugin and it so has its own chapter in the docs: http://grails-plugins.github.com/grails-spring-security-core/docs/manual/guide/11%20Custom%20UserDetailsService.html
Basically you need to create a Spring Security User instance and Spring Security (and the plugin) doesn't care how you get the data. So your custom UserDetailsService just needs to be a bridge between your current auth scheme and Spring Security.
I ended up creating my own access control/authorization mechanism rather than using the Spring Security plugin. I never could figure out how to separate the plugin's authentication mechanism from the authorization mechanism. Doing the work myself was very easy.
I did the following:
Created a new Role domain class.
Added a Set property and hasMany relationship to my User domain class.
Created a new AuthorizationFilters filter. This is where I put in my authorization rules. In this filter I can check to see if a user has the role necessary to access the given URL and redirect to a login page, redirect to a "not authorized page" or allow them to pass.
This doesn't have the nice syntactic sugar of the plugin and isn't quite as concise either, but it was very easy to implement and understand.
I added cronjobs to spring app using quartz.
inside these jobs, I would like to access spring-security secured bean methods from another app.
This is my application structure.
| - core
| - webapp
| - jobs-app
both the webapp and jobsapp use core services. jobsapp is not a web application. It just has quartz jobs in it.
Inside a job if I try to access a bean that is secured using SpringSecurity global-method-security I get an exception {org.springframework.security.AuthenticationCredentialsNotFoundException}"org.springframework.security.AuthenticationCredentialsNotFoundException: An Authentication object was not found in the SecurityContext"
If I set the context using SecurityContextHolder.getContext().setAuthentication to a power user, it works.
But, I have to do this for all the jobs.
Is there a way I can make all the jobs runas a particular user? may be some configuration somewhere?
You have two choices:
move #Secured annotation up, from service to web layer. If I understand correctly your Quartz jobs access service beans directly (bypassing the web layer) so you'll bypass the security as well
implement Run-As functionality, just like you described. It doesn't have to be that manual. Try template method pattern or some AOP + annotations. It'll turn out to be rather clean.
We tried both approaches and moving security to web layer worked slightly better. This was possible because service layer was mapping nicely to Spring MVC controller methods.
Where should I put the logic of my app when i'm using JSF framework? As I understand managed beans are used only for getting/setting the properties of the form and also have controllers methods. I don't think that implementing the logic in controllers method is a good way. Of course I can use ejb to implement the logic and inject it to managed beans, but how it will work on servers that don't have an ejb container(e.g. Tomcat).
I don't think that implementing the logic in controllers method is a good way.
Indeed. Use business services like EJBs.
Of course I can use ejb to implement the logic and inject it to managed beans, but how it will work on servers that don't have an ejb container(e.g. Tomcat).
You could use OpenEJB to enrich it with (limited) EJB 3.x capabilities. An alternative is Spring, that's what they used during the EJB 2.x era when EJBs were hated.