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
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)
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.)
So, yeah. That. I'm going through the tutorial one step at a time, so if the answer comes up later, forgive me. It's step 1 in this section.
I understand the ease of using this to have access in other methods in the EntryPoint class, but coming from the Spring MVC world, this sort of thing might be thought of as a controller and be a singleton (bean). Is it wrong to think this way in the GWT world?
With GWT you are coding as if it was a desktop AWT program. So, you do not have CDI or anything similar.
So, if you put all your information in a bean, you still would have to either:
keep a bean attribute in the class
pass it as a parameter in the method call
to get a reference to it (instead of retrieving it from CDI when needed)
While you can still use a bean when needed, these attributes are closely linked to the main class (in fact they are other graphical components to show). In general, I would only use bean when you have a bunch of attributes that are tightly coupled between them but are not tightly coupled to any other class.
I am curious on the way Spring is able to bind together an application (just in simple terms of course). In a standalone Java application you bootstrap the application with a lookup then Spring instantiates and binds the objects together (DI).
If you for example have a for loop where you don't know the number of iterations (user input) would you use the dependency lookup method inside the loop body? And would you implement the BeanFactoryAware interface in this case? Or do you make the object by using new keyword?
Just an thing that came to my mind while reading.
"Lets pretend that you need a new instance each time"
If you have a component A that has a for loop where you need a new instance of a "bean" B on each iteration, why not just inject a B factory into A and call that within a for loop.
It all really comes down to what makes sense:
If you need to create something simple (e.g. a new String) on each iteration, then there is nothing wrong with using a new keyword.
If it is something more complex, where it is best to encapsulate "creation details", it would not do you any good to depend on any particular framework (e.g. BeanFactoryAware). Just use a builder/factory, which can either be another bean that would be injected, or can be called statically.
Less magic more clarity
If I understood your question correctly the answer could be: Spring beans are singletons by default.
So in most cases you would never need to lookup one inside the for loop - you'll use the instance looked up just before your loop.
Also you're probably trying to think about Spring beans as JavaBeans that you create to populate with data. You could read this link to see the difference: http://www.shaunabram.com/beans-vs-pojos/
Spring beans are more like JavaEE Enterprise Beans, you don't create them - you just use them.
I am taking a look into Spring as a web framework, however I am needing a bit of help getting my head around DI.
The concept of objects getting constructed in the container on run time is such a new concept.
I am just wondering how this will reflect in a big application, would I have some modules doing work that are more highly coupled or should every object be initialised at runtime?
It all seems a little intensive to me, I mean say for example I have a CSV file data mining application that removes the data per row - each rows data is encapsulated in one of my own CSVRow objects for processing or whatever. These objects are instantiated whenever an Excel file maybe uploaded to the server. I don't know how many I will need to create?
I seem to be getting a bit lost, any clarity, an overview or some guidance would be much appreciated.
Thanks in advance!
I'll try to put it simply:
use dependency injection for stateless classes that have logic (business logic, persistence logic, front-end logic)
use new for value objects
Broadly speaking, an application is made up of a collection of classes that implement the business logic.
Normally each object is responsible to obtain references of the objects it needs (and this object's dependencies).
I think it is obvious that this leads to:
1) tightly coupled classes
2) code hard to test since each object instantiates specific classes it depends on and if there needs to be a change, the code must be modified.
So using Dependency Injections the objects do not instantiate the dependent objects themselves but an "external component" provides the dependencies at the object creation time i.e. injects the dependencies into the objects.
So in your example, the idea is that you can have for example a CsvRow object instantiated by Spring (along with all its dependencies) and get an object whenever needed. It is also possible to switch to for example CsvRow2 object (another implementation) by just changing your configuration
You don't need to use DI for your CSV row abstraction. Once you get the file, when you start parsing it, your code can create the CSVRow things as it goes. You don't need to wire them up.
You certainly could if you wanted to. You would grab your applicationContext and just get the beans by name. You would want to do this if the CsvRow had dependencies that you wanted Spring to manage for you.
I think of Spring as a way to create "singletons". When I want to guarantee there's only one instance of a class in the application, use Spring to create it. But, instead of being a traditional singleton with a static INSTANCE field or similar, it's a POJO with whatever constructors / setters you need. Spring creates the instance at runtime for you and makes sure that creation only happens once.