This is a design level question and i need opinion on what would be a better approach.
The application i am working on uses Struts 2 and Spring (for dependency injection).
Each Action class make a call to Service Layer to perform business functions. All data is saved in Model classes. Every action uses modals to save/edit data. These Modal classes are defined as private members of the class with getter/setters.
Question 1) Should we define the Modal classes as Beans in application context? Currently i have not. On form submit the Struts itself creates the instance. On edit ( when i want to show data on screen ) I have to explicitly create the modal ( using new ). What would be the better approach.
Question 2) Should the beans for Action Classes in aplCntx be defined as scope="prototype" ? Does Struts its self not take care to create new instance of action classes?
Question 1:
As Jigar said you don't need to define your action fields as beans in your application context, because most of the time they just carry data between the page and your application, so most probably you either has created them from you service layers and just want to pass them to page for presentation or their data is submitted from the page in which case struts2 takes care of the instantiation.
Question 2:
There's a object factory in struts2 which by default takes care of action creation. You can change this and specify spring to take care of the action creation. First you have to add spring plugin for struts2 to your classpath then add this line to you struts2 config file:
<constant name="struts.objectFactory" value="org.apache.struts2.spring.StrutsSpringObjectFactory"/>
Then you create beans for your actions like:
<bean id="myActionBean" class="com.my.myAction" scope="prototype">
... required properties ...
</bean>
Remember you have to set the scope to prototype that's how it works for struts2. Then in your struts config file:
<action name="myaAction" class="myActionBean">
... required result mapping ...
</action>
1) Should we define the Modal classes as Beans in application context? Currently i have not. On form submit the Struts itself creates the instance. On edit ( when i want to show data on screen ) I have to explicitly create the modal ( using new ). What would be the better approach.
No. You shouldn't define modal in spring-context , they should be just simple POJOs
Related
I'm currently migrating existing components to use the HST-2 Spring Bean Bridge to integrate better with the Spring IOC container.
I followed the Hippo documentation and everything works as advertised, at least in the running site. I can now define my component beans in my spring configuration and use DI for my component dependencies.
However, I learned that now I cannot modify the parameters on those component's in the Channel Manager's Template Composer. Before migrating those catalog components to use the SpringBridgeHstComponent I could click in the component item area in the Template Composer and get the pop up dialog which let me view and edit all the parameters to that component item
(hst:parameternames, hst:parametervalues).
Now the pop up dialog just shows a message that
"No editable properties found for this component."
I should mention that the component parameter values that were already set on the components are still available during request processing/execution. But those values are now effectively "hard-coded" because the webmaster cannot view/change them in the Template Composer.
Is this a known issue with the SpringBridgeHstComponent? Or is there a workaround configuration or something to make those component parameters available again in the Channel's Template Composer?
The Hippo CMS Channel manager can only scan annotations in the component class configured by the hst:componentclassname property.
SpringBridgeHstComponent class itself, which is used in your component
configuration now, cannot be annotated by a domain-specific parameters
info annotation. As a result, it's not shown in the channel manager
properly.
If you want to enable the parameters setting window for the
SpringBridgeHstComponent-bridged component, then you should extend the
class only for the annotation. e.g, ContactSpringBridgeHstComponent
extends SpringBridgeHstComponent with a specific annotation in that
extending class for contact component for instance. See the docs for detail.
This is needed at the moment because channel manager recognizes the
parameters information only by class annotation, which makes you extend
a new class for each component.
I am using Struts 2 v 2.3.16.3 with tomcat 6.
A user will click on an action which finds an object by id and the page displays it. I have encountered a sporadic bug where the user will all of a sudden get the id of another lookup from another user on another machine. So effectively they are both calling the same action but passing different id to the request, but both end up viewing the same id.
This is obviously disastrous, and the data is totally corrupted as both users think they are editing a different record. Any ideas how make sure session/request activity is kept secure to each session?
I am also using spring and am using the #Transactional annotation in my Service layer, which returns the objects from the DAO. Is there something I need to do with this annotation to make it secure for each session ?
I am using org.springframework.orm.hibernate3.HibernateTransactionManager
Classic Thread-UnSafe problem.
Since you nominated Spring, my first guess is that you have not specified the right scope for your action beans in Spring xml configuration.
Be sure you are using scope="prototype" because otherwise the default scope of Spring is Singleton, and you don't want a single(ton) instance of an Action, that would not be ThreadLocal (and hence ThreadSafe) anymore.
If it is not that, it could be something on an Interceptor (that, differently from an action, is not Thread Safe), or you are using something static (in your Business / DAO layer, or in the Action itself) that should be not.
Usually Struts 2 action instances will get create on the request. I mean per every request new action instance will get create. But if I integrate with Spring then there will be only one action instance will get create (I am not sure correct me if I am wrong).
So in this case what is if I have instance variables in the action class?
First user here will set that instance with some instance variables and second user may set there something. How it will behave at this time?
More clarification: Instance variable means, in Struts 2, action forms won't be there so, your action itself work as a form to get the request parameters. First user enters something and second user enters something and both are setting to one instance action.
If your actions are managed by Struts container, then Struts is creating them in the default scope.
If your actions are managed by Spring container, then you need to define the scope of the action beans, because Spring by default uses singleton scope.
If you don't want to share your action beans between user's requests you should define the corresponding scope.
You can use prototype scope, which means a new instance is returned by the Spring each time Struts is being built an action instance.
I am asking this question because of the following reasons:
Usually struts 2 action instances will get create on the request. I mean per every request new action instance will get create. But if I integrate with spring then there will be only one action instance will get create (I am not sure correct me if i am wrong). So in this case what is if I have instance variables in the action class. First user he will set that instance with some instance variables and second user may set the something.
How it will behave at this time.
More clarification: Instance variable means, in struts 2, action forms wont be there so, your action itself work as a form to get the request parameters. First user enters something and second user enters something and both are setting to one instance action.
By default Spring will create a singleton instance of your action class. In that case, depending on how your action classes are written there might be such a danger.
But you can also specify that a bean be created prototypically (scope="prototype") so that a new instance of the class is created with each request.
First, If you integrated struts2 with spring, normally, the action instances are managed by spring container! this is supported by struts2 spring plugin: https://struts.apache.org/release/2.3.x/docs/spring-plugin.html
Second, as the plugin doc mentioned, by default, the action bean's scope is request, this is up to the struts2, but you can change yuor action scope to other type,i.e. session,application,etc.
I am developing a web project and after much research I have decided to go ahead with JSF+Primefaces, Spring and Hibernate approach. While designing the architecture of my project I have finalized the following approach :
Actor --> JSF+PrimeFaces page --- > Backing Bean -- > Service Bean -- > Dao -- > Hibernate
Service Bean and DAO are spring beans with dependency injection.
My concern now is now with respect to backing bean:
I plan to use multiple backing beans for UI page depending upon the type of Page I need to render.
Now for example: For a new user registration page i have UserProfile.xhtml which uses UserBackingBean. UserBackingBean has UserServiceBean injected by spring. UserServiceBean has UserDao injected by Spring.
Now in UserBackingBean when the user enters the form data from UserProfile.xhtml I will have to populate the User.java domain(ORM) object.
a) What is the best practice for this ? Should I initilize the User.java in the constructor on UserBackingBean ? Is this the proper approach ? Please suggest if there is any other way out ?
b) Also please suggest on the above architecture I have decided upon for my project ? Is it the proper approach ?
The general rule I follow is that transaction boundaries are marked in the service beans therefore I don't like to modify hibernate POJO outside of a service because I don't know if there is a transaction already running. So from the backing bean I would call the service layer pass in the parameters that the service layer needs to build up the hibernate pojo and save it, update it, ... etc.
Another way to do this would be have your backing bean implement an interface defined by the service layer and then pass the backing bean to the service layer. For example.
public interface UserInfoRequest {
public String getName();
}
#Service
public class SomeSpringService {
#Transactional(.....)
public void registerNewUser(UserInfoRequest request)
{
}
}
public class SomeBackingBean implements UserInfoRequest {
private SomeService someSpringService;
public void someMethodBoundToSJF()
{
this.someSpringService.registerNewUser(this);
}
}
Regarding your last question I am not a fan of JSF, I think JSF is fundamentally flawed because it is a server component based framework. So my argument against JSF is a generic argument against server side component based frameworks.
The primary flaw with server side component based frameworks is that you don't control what the component will output which means you are stuck with the look of the component, if you want something that looks different you have to write your own component or you have to modify an existing component. Web browsers are currently evolving very quickly adding new features which can really improve the quality of an application UI but to you those features you have to write HTML, CSS, and JavaScript directly and the server side components make that harder.
Client side component architectures are here and much better than doing components on the server side. Here is my recommend stack.
Client Side Architecture:
jquery.js - Basic libary to make all browser look the same to JavaScript
backbone.js + underscore.js - High level client side component based architecture
handlebars.js - for the client side templates
Twitter bootstrap - to get a decent starter set of CSS & widgets
You write code in HTML, CSS and JavaScript organized as backbone views that talk to server side
models using AJAX. You have complete control over the client side user experience with enough
structure to really make nice reusable code.
Server Side Architecture:
Annotation Driven Spring MVC, Services and Dao (#Controller, #Service, #Repository)
Spring component scanning with autowiring by type (#Autowired, #Inject)
AspectJ Load Time Weaving or Compile Time Weaving
Hibernate
Tomcat 7
JSP as the view technology for Spring MVC (yes it cluncuky but you wont be creating
too many jsp pages, mostly for usng <% #inculde > directive
Tooling:
- Spring Tool suite
- JRebel (so that you don't have to start and stop the server) it really works really worth the money
- Tomcat 7