I am looking for an elegant solution to writing methods on DTO's
The problem arises from the fact that methods on a DTO can be used both on the client side and server side. Subsequently problems arise when you make use of any Client or server side specific methods. This generally results in an java.lang.NoClassDefFoundError exception.
The project that I am currently working on uses GWT and spring. I experienced this problem when trying to format an date on a DTO. The format method was throwing an java.lang.NoClassDefFoundError when GWT.create(GlobalConstants.class) was called. I am looking for an elegant way to differentiate if an method is being called from the server side or client side and adapt the implementation of the method accordingly.
First off, if you have such methods, then your object is not just a DTO (by definition, a DTO only has accessors and mutators).
That being said, there are several ways to solve your problem with your objects.
to solve the NoClassDefFoundError, use com.google.gwt.core.shared.GWT instead of
com.google.gwt.core.client.GWT. The shared class is present in both gwt-user.jar and gwt-servlet.jar.
You can use GWT.isClient() to tell whether you're on the client-side or server-side and branch to the appropriate code.
Starting with GWT 2.6, GWT.create() can be used outside of a GWT client-side context, so
you can make it work on the server-side (you have to provide your own ClassInstantiator to com.google.gwt.core.server.ServerGwtBridge.getInstance()#register())
If you have a server-side-specific method that wouldn't even transpile to JavaScript, starting with GWT 2.6, you can annotate it with #GwtIncompatible (any such annotation will work, the package doesn't matter, only the annotation name) and GWT will do as if it isn't there at all.
finally, when none of the above works, you can "fork" your code into a super-source, so as to provide distinct server-specific and client-specific implementations. See “Overriding one package implementation with another” in the GWT documentation.
Related
I have read that dependency injection is good for testing, in that a class can be tested without its dependencies, but the question comes to my mind if Class A depends on Class B or C or any class, testing Class A independent of some class is yielding a test result of zero, not a failed or past test.
Class A was created to do something and if it is not fed anything whether using new key word or setting up the extra files in Spring, Class A won't do any work.
About the idea of making code modular, readable and maintainable: so business classes became cleaner, but all we did was shift confusion from dirty Java business classes to convoluted XML files and having to delete interfaces used to inject to our loosened objects.
In short, it seems we have to make edits and changes to a file somewhere,right?
Please feel free to put me in my place if my understanding is lacking, just a little irritated with learning Spring because I see the same amount of work just rearranged.
Dependency injection is good for unit testing because you can individually test each method without that method depending on anything else. That way each unit test can test exactly one method.
I would say that if the xml is what’s annoying you check out Spring boot. It’s based on a java configuration so no xml and it simplifies a lot of configuration for you based on your class path. When I first started spring I found the xml very daunting coming from a java background but the annotation based configuration and the auto configuring done by spring boot is extremely helpful for quickly getting applications working.
IMO biggest advantage of using the spring is dependency injection which makes your life easy. For example if you would like to create a new service with three dependencies, then you can create a class very easily using Spring. But without spring, you will end up writing different factory methods which will return you the instances you are looking for. This makes your code very verbose with static method calls. You may want to take a look at the code repositories before spring era.
Again if you would like to use Spring or not is your personal call based on project complexity. But it's other features/advantages cant be overlooked.
And XML files or Java configs are the ways of achieving spring configuration - where you would like to add your business logic is personal flavour. Only thing is you should be consistent all across your project.
I would suggest that you read Martin Fowler's great article on Inversion of Control and Dependency Injection to gain a better understanding of why frameworks like Spring can be really useful to solve a well known set of common dependency injection problems when writing software.
As others have mentioned, there is no obligation to use Spring; and whatever you can do with Spring, you can probably do it by other means like abstract factories, factory methods, or service locators.
If your project is small enough, then you probably wouldn't mind solving the dependency injection issues on your own using some design patterns like those mentioned above. However, depending on the size of your project, many would prefer to use a framework or a library that already packs a bunch of solutions to these recurrent head scratchers.
In regards to the advantages of dependency injection frameworks when doing unit testing is the idea that you don't need to test the dependencies of your class, but only your class.
For example, most likely your application has a layered design. It is very common to have a data access class or a repository that you use to retrieve data from a datasource. Logically, you also have a class where you use that DAO.
Evidently, you already wrote unit testing for your DAO, and therefore, when you're testing your business class (where the DAO is being used) you don't care about testing your DAO again.
Fortunately, since Spring requires some form of dependency injection for your DAO, this means your class must provide a constructor or a setter method through which we can inject that DAO into our business class, right?
Well, then during unit testing of your business class, you can conveniently use those injection points to inject your own fake DAO (i.e. a mock object). That way, you can focus on the testing of your business class and forget about retesting the DAO again.
Now compare this idea with other solutions you may have done on your own:
You inject the dependency directly by instantiating the DAO within your business class.
You use a static factory method within your code to gain access to the DAO.
You use a static method from a service locator within your code to gain access to the DAO.
None of these solutions would make your code easy to test because there is no simple manner to get in the way of choosing exactly what dependency I want injected into my business class while testing it (e.g. how do you change the static factory method to use a fake DAO for testing purposes?).
So, in Spring, using XML configuration or annotations, you can easily have different dependencies being injected into your service object based on a number of conditions. For example, you may have some configurations for testing that evidently would be different than those used in production. And if you have a staging environment, you may even have different XML configurations of dependencies for your application depending on whether it is running in production or integration environments.
This pluggability of dependencies is the key winning factor here in my opinion.
So, as I was saying, my suggestion to you is that you first expand your understanding of what problems Spring core (and in general all dependency injection frameworks) is trying to solve and why it matters, and that will give you a broader perspective and understanding of these problems in a way that you could to determine when it is a good idea to use Spring and when it is not.
I am using Spring and JSF2 a lot and was wondering what the best way to integrate them is? Now i understand there are basically two ways to do this, but i have some problems with both:
a) Use normal #ManagedBean, and inject Spring-Services into that beans using #ManagedProperty: The problem is that i can't use Spring-AOP inside a #ManagedBean obviously, because it is not Spring-managed. I usually use an arround-aspect on every method annotated with my custom annotation #DatabaseOperation. Another example would be #Secured from Spring-Security and so on. I use a lot of AOP in my project and not beeing able to use them on "the top level" is really limiting for me.
b) Use SpringBeanFacesELResolver to make everything managed by Spring. On the pro side is that AOP works like a charm, but the cons are big too:
No ViewScope. I am not sure if i can trust custom view scope implementations like this https://github.com/michail-nikolaev/primefaces-spring-scopes on productive systems?
Serialization is not possible. It's already pretty complicated, but once i use AOP i can't get it to work because org.springframework.aop.aspectj.AspectJPointcutAdvisor is not Serializable
So my question is: How do you overcome this issues? How do YOU integrate JSF2 and Spring3.x? I have been using possibility b) mostly, but on my next project i need session replication..
Any further suggestions?
The main integration pain point of the two frameworks is that JSF is usually used in a stateful way. to make the integration the most seamless, you would have to let Spring handle the statefulness and page navigations aspects himself instead of JSF, as well as bean creation and scoping.
The second important integration point is at the level of the view expression language. We want to be able to access spring beans while building the view, which means the managed bean layer is no longer needed.
The best integration available for the two frameworks is provided by introducing Spring webflow, see here for further details. With SWF, JSF no longer manages beans itself, this is done by Spring. JSF does not manage page navigation anymore, this handled in the SWF flow definition.
Also the statefulness is handled by SWF. The flow definition XML file replaces large parts of the faces-config.xml for view navigation, transition actions, bean definition, etc.
Using the SWF JSF integration means that your faces-config.xml is mostly empty. Expression language accessing directly spring beans can be used while building the view, and a view scope is available.
If you want to keep a page isolated from the rest of the application, youcan create a flow with a single view state and self-transitions. An advantage of SWF is that it prevents duplicate form submissions via a POST-REDIRECT-GET mechanism that works transparently out of the box.
So this is a rather "big" question, but what I'm trying to accomplish is the following:
I have a Spring application, MVC, JDBC (MySQL) and JSP running on tomcat.
My objective is to test the entire "stack" using a proper method.
What I have so far is Junit using Selenium to simulate an actual user interacting with the application (requires a dummy account for that), and performing different validations such as, see if element is present in the page, see if the database has a specific value or if a value matches the database.
1st concern is that this is actually using the database so it's hard to test certain scenarios. I would really like to be able to mock the database. Have it emulate specific account configs, data states etc
2nd concern is that given the fact that I use what is in the database, and data is continuously changing, it is hard to predict behavior, and therefore properly asserting
I looked at Spring Test but it allows for testing outside a servlet container, so no JSP and no Javascript testing possible.
I saw DBUtils documentation but not sure if it will help me in this case
So, to my fellow developers, I would like to ask for tips to:
Run selenium tests on top of a mocked database
Allow different configs per test
Keep compatibility with Maven/Gradle
I have started with an ordered autowire feature to support this kind of stubbing.
It's basically an idea that i took over from the Seam framework i was working with in the past but i couldnt find yet a similar thing in spring.
The idea is to have a precedence annotation (fw, app,mock,...) that will be used to resolve the current implementation of an autowired bean. This is easy already in xml but not with java config.
So we have our normal repository beans in with app precedence and a test package stubbing these classes with mock precedence.
If both are in the classpath spring would normally fail with a duplicate bean found exception. In our case the extended beanfactory simply takes the bean with the highest precedence.
Im not sure if the order annotation of spring could be used directly but i prefered to have "well defined" precedence scopes anyway, so it will be clear for our developers what this is about.
! While this is a nice approach to stub so beans for testing i would not use it to replace a database definition but rather go with an inmemory database like hsql, like some previous answers mentionned already. !
I am now moving to Struts for my presentation layer. I have done a simple example using Struts alone (not really, actually, I test an example inside a simple maven project). From now on, I am likely to use Struts with Spring so I try to migrate my simple application, my goal was to use service layer to deal with specific operation.
In my simple test, I extend action from Struts action, now that I am using Spring, I extend it from ActionSupport so that I can fully use spring injection. Now it seems like even though I override validate method, it is no longer called. Is that the right behaviour, if so, where should perform operations like checking if my mandatory fields are populated (inside action or service ?)
Thanks for your answer !
I googled but couldn't find any answer.
I am planning to use GWT. I want to know if I can use spring in my GWT code to use the dependency injection framework? I am not talking about GWT gui interaction with backend spring app.
The reason I am asking is the GWT code gets compiled to JavaScript and this is what gets executed in browser. If I am using spring code in that, then would it work or for that matter any other library like log4j, etc.?
Or the GUI code have to be pure GWT API only?
For example,
public class MyTable {
private Button myButton;
#Autowired
public MyTable(Button aMyButton) {
myButton = aMyButton;
}
}
Guice is supported on GWT using GIN. For Spring-like DI with GWT, check out GWT Toolbox or Rocket GWT.
I believe GIN is a more natural choice for GWT. Not because it's also made by Google, but because using XML for GWT configuration makes absolutely no sense. Everything gets statically compiled into JavaScript so there is no need for externalized configuration. Keep your refactoring tools happy; go for GIN.
To answer your other question, you will not find many SE frameworks that work on GWT. First and foremost, it has no support for reflection or bytecode manipulation (everything is JavaScript), which immediately rules out a lot of frameworks. Log4j, on the other hand, doesn't make sense because there is no file system accessible on the client side, but there are libraries available that do things differently.
The Spring libraries for GWT mentioned above are basically a rewrite of the Spring for GWT. They do not share any code with Spring simply because they can't. Those frameworks work by generating code ("factories") that wire up your components as if you were doing DI manually.
This is also how GIN works, it generates Java factories for your classes, and GWT compiles it into optimized JavaScript (meaning little performance overhead). GIN does use Guice behind the scenes though, to validate configuration at compile time and to inspect modules.
No, you won't be able to do that. The DI logic applies at runtime on the server side, and the GWT code is entirely client-side.
I thought it would be simpler to just create a Spring Controller that invoked the doPost method of the GWT RemoteServlet. A sample is provided here. I know this is a little round about. But this shields you from changes to the GWT implementation if any.. Hope it helps.
I wonder if Guice (the Google DI framework) is supported by GWT?
This might be an alternative.
You can implement a Servlet Service in the server side that retrive objects from a Spring ApplicationContext, rendering to JSon Objects (I did it with http://json-lib.sourceforge.net/apidocs/net/sf/json/JSONSerializer.html) by example.
Then you can have a Singleton Facade Service that make the request from the GWT-client side to our Servlet Service.
In this way you can get a runtime depency injection in the GWT-client side .
Spring ME is capable of helping you out here. Although I partly agree with some of the previous responses, it's nice to have the same programming (and plumbing) paradigm across your client and server code.