I'm trying to make my action classes singletons. The point is to make action classes real controllers in MVC pattern. Especially when implementing REST controllers the scope of the controller could be extended to the life of the application. Like in Spring framework the controller is put to the default scope by default, the default scope in Spring is singleton.
Struts 2 has also a default scope, and it's also singleton. I want to put my action classes to this scope and remove them from the value stack.
How could I modify Struts 2 framework to make my actions like a controller in Spring? I know that I could just delegate management of action classes to Spring, but I can't use a default scope, and Struts 2 container is still keep running. I can't remove it from the framework, because it's not pluggable.
So, walking around Spring and Struts2 container I can't make my action classes singletons because Struts 2 instantiate and put them to the ValueStack.
This is my question:
If I choose the container between Struts 2 and Spring to put my action classes to default scope, how could I tell Struts 2 framework not to put them to the ValueStack?
Assuming you're using XWork's DefaultActionInvocation implementation, it's done there, by the init method. Pulling that out is a bit of a pain because it's layered underneath action proxies and action proxy factories in both XWork and S2.
That said, I'd be very hesitant at making a change like this; it has system-wide implications and is counter to essentially everything about XW/WW/S2.
(Unrelated, but singleton nature isn't what defines a controller, it's the responsibilities that define what a component is.)
Related
I have two projects, A and B. B consumes A as a jar. B is not always used in other projects (for example, projects C, D, E, etc. can either consume or not consume B, but always consume A). I can modify both projects.
There is a controller in A that I want to add functionalities related to B's bussiness model (entities, services, that kind of stuff). Of course, writing the new functionality in A won't work (compiling mainly, but also would break the well-defined structure of both projects).
The controller in A is defined as a spring bean in the Java class itself, and also is related to a zul page that uses it. Relevant code:
Java
#Controller("userController")
#Scope("prototype")
public class UserController extends GenericForwardComposer
ZUL page
<window apply="${userController}" >
How could I add the functionality in B and avoid as much possible unnecesary complexity? I want to avoid extending the controller and adding a #Primary definition. Since I'm working with Java 8, I was thinking on interfaces with default behaviour, but I haven't figured how to make the execution pick an interface in B rather than in A. Composition is also an option, but the bean in A wouldn't be properly initializated (there are components in the zul page).
Any help or pointers will be appreciated.
From a ZK's perspective there's nothing to do here. So no need to look in this direction. (based on the details/code provided so far - unless your last comment ...
there are components in the zul page
... means/should indicate something specific)
It rather seems to be a Spring topic, how to resolve duplicate bean definitions (default in A, something advanced in B), if you don't like #Primary then maybe #Priority/#Order can help to determine which bean get's injected.
Another way to manage such scenarios are spring profiles or more general the #Conditional annotations which allow dynamic configuration/instantiation of beans.
E.g. spring-boot auto-configuration as these #ConditionalOn...-annotations, which I used in zk-springboot-autoconfig de-/activate beans based on the existence of certain classes on the classpath, or other conditions based on properties.
There are many ways to achieve a dynamic bean configuration in spring. In case you need dedicated help with ZK you can try the zk forum or zk support (disclaimer: I work for ZK)
1) I would like to know which main classes in Struts 1 are are Singleton classes. Main classes like ActionServlet, RequestProcessor, Action, ActionForm etc.
2) Also, I heard from somebody that if we have multiple struts confix xml file in our struts application then for each module a new RequestProcessor will be instanstiated. Is this true ?
Thanks.
1) there is Actionclass which will be singleton like as we are not going to generate object explicitly.
2) and whatever number of struts-config file is there for that only requestProcessor instantiated
To understand classes that are used by the Struts framework better look the the source code. If you did it you'll see that none of the classes you've mentioned implement a Singlton pattern. That means that nothing prevent them to make as many instances as you needed. But it depends on how these instances are managed.
Not exactly, the request processor is created for each module in the case if there's not one is already created for a concrete module. See ActionServlet.getRequestProcessor
i have a question that is more design and architecture related. I am coming from a classical MVC based background and have to get my hands dirty on JSF2. I read the IBM articles on JSF2 (http://www.ibm.com/developerworks/library/j-jsf1/) and think i understand the overall concept.
I started to get in touch with JSF2 trough ROO. I have the feeling that ROO (maybe this is true for any JSF2-Type App, or maybe not) is making very strange/unclear use of beans. It is in general really not clear to me what the actual role of a Bean is! For example, if i have a view with a form that is for editing a single user-entry, i would initialize the user in a, lets call it UserBean (maybe store in in a member variable) and access this variable trough getters. If i now want to overview all users, i would again render the view in in the UserBean hold a collection of users and again access this collection trough getters. The previous description is actually the way i would do things with jsf. This means i would user the UserBean more as a statefull-service as a controller.
In a typical controller situation i would create for every type of action (list user, edit user, view user, etc) a separate controller, with specific initialized data and this way i would separated the context of the logic by controllers.
I often make use of context specific services, e.g. if i handle user's often an spread over the application, i create a user-service that handles user specific logic that is maybe to complex to be put into the itself. If i now for example look into roo generated Beans, i would find methods that programatically render forms, input fields, labels, that again store list's of users, boolean fields that indicate if data had already been loaded, single user members and a lot of methods that more look like to be put into a UserService (or whatever). I am wondering if this is the way JSF2 is intended to be used, in words: pushing everything that is related to one context into on bean, not making use of service and writing "super-controller-beans" that handle everything.
I don't really know if you get the question right, but what would maybe help me is, a hint to
a very exemplary and commendable example application that makes use of beans the way they where intended to be used in combination with jsf2 features and usecases that for example implement basic CRUD usecases around a given type of entity. (One big confusing point is, that in my case ROO always makes use of AJAX and javascript stuff like Modal-Dialogs to implement CRUD logic. I wonder if with JSF there is a more classical way to to this?[With 'classical' i mean for example URL-Based views and separated views for listing, editing and viewing entities])
a resource that enlightens typical "thats-the-way-the-good-guys-do-it" JSF-Patterns (maybe this is J2EE Patterns?).
Thanks you so much!
Please feel free the push me to concretize specific points if i am not clear!
The link for JSF2 you have posted points to JSF1.2 article. In case you want to start of with JSF2 or JSF I suggest following links.
JSF 2.0 Tutorial # mkYong.com
BalusC JSF blog
Stackoverflow wiki for jsf
I'll suggest start with plain vanilla JSF rather than ROO with JSF to get a hang of JSF.
To answer your question
First link provides you with simple jsf examples, in JSF you can have both ajax based and classical way of submitting form. In JSF 1.x versions ajax was not part and parcel of JSF it was implemented by third party component library mainly RichFaces and PrimeFaces to name few. In JSF2 there is inbuilt support for ajax, this does not apply third party components are no longer required, they still provide some extended features. I'll suggest go through this link to find differences between JSF 1.x and JSF 2.
Patterns I am not aware of as such as specific to JSF apart code can be categorized in model - view - controller. Typical case Person represents model, PersonMangedBean plays role of controller which plays central role of getting data from view(jsp/facelets) and after processing data in bean itself or service beans handles navigation to classic views may be listPersons.xhtml.
JSF managed beans are not "super-controller-beans" handling every thing in that bean. I try to categorize things the way you mentioned i.e. have a service layer where we have all business logic may be EJB or Spring managed bean and it decouples at-least business logic away from view technology JSF whereby it(service) can be reused somewhere else as a library if designed properly.
Tip: JSF is component based framework not an action based and it has lifecycle of its own, do get a grip of that life-cycle will save lots of time and proper understanding of the framework. This link though for JSF 1.x holds good for JSF2 too, for basic understanding of life-cycle.
Hope this helps.
Yes, I searched for questions about backing beans and I found many questions. I read them, and I get some parts of it but I need to ask another question, sorry.
After what I understand backing beans are needed because of JSF MVC pattern. Backing beans are the model. So if you have a page that displays a form, an image and a login box the backing beans will have getter/setter pairs for the data that needs to be exposed or changed in the view. And the backing beans will also have methods related to this such as what happen when you submit the form, login in etc.
So my question is if the statements above is correct, and the number of backing beans you make for the components above is dependent on how much code it is?
Would one backing bean exposing methods and getter/setter pairs for all components on this page be legal and "correct" (meaning that I don't do any wrong) in the same way as making 3 backing beans; one for each component would also be fine.
Does it all boil down to experience to see when you should separate vs. making one backing bean for each page, and also the logical part of it? I heard one guy made a backing bean for each component on the page but it sounds like you end up with a lot of small classes.
I would highly apprciate if somebody could verify and correct me.
It is legal for all components in a view to be bound to one managed bean for properties and actions. IDE tooling may encourage you to do this with a single backing bean.
From a class point of view however this approach lacks granularity and can make the managed beans difficult to test. If a class doesn't have a clearly defined purpose then it can be difficult to assert they are doing that job. See warning sign "Summing up what the class does includes the word “and”". All versions of JSF support dependency injection so it is relatively easy to rely on composition to assemble your managed beans.
This is a somewhat subjective topic and the answer depends on other factors (application scale; view design; page function.)
I've just inherited some old Struts code.
If Struts (1.3) follows the MVC pattern, how do the Action classes fill the View with variables to render in HTML ?
So far, I've seen the Action classes push variables in (1) the HTTP request with
request.setAttribute("name", user.getName())
(2) in ActionForm classes, using methods specific to the application:
UserForm form = (UserForm) actionForm;
form.setUserName(user.getName());
and (3) a requestScope variable, that I see in the JSP layer (the view uses JSP), but I can't see in the Action classes.
<p style='color: red'><c:out value='${requestScope.userName}' /></p>
So, which of these is considered old-school, and what's the recommended way of pushing variables in the View in Struts ?
My Struts days are long over, but as far as I remember we used to place one view-specific bean (which would work as a holder for fine-graner beans or collections of beans) into the request scope within our Action.perform() implementation. This view-specific bean would then be rendered by the view.
As Struts 1.3 is considered old-school, I'd recommend to go with the flow and use the style that already is used throughout the application you inherited.
If all different styles are already used, pick the most used one. After that, pick your personal favourite. Mine would be 1 or 3 - the form (2) is usually best suited for data that will eventually be rendered inside some form controls. If this is the case - use the form, otherwise - don't.