This is the continuation of issue
I'm currently working on a task where it has GWT, Restful and Spring Framework environment.
It has two application; Application #1 which expose some information through Restful Webservice and Application #2 which consume that service and display those details in GWT.
For Application #2, I have used Spring RestTemplate to consume the Restful Webservice and return backs the List of Details through an Interface. And at the GWT end, there was some DataListProvider to set the Data List in GWT-DataGrid.
Now the problem is, I doesn't know how to make the interaction with GWT DataListProvider with my DetailService Class(this returns the List<Details> in a method). When I directly call the Service Class in GWT- OnModule() method, during GWT Compile, i'm facing some UnResolved Type Error, Since this class indirectly calls the Spring Libraries classes, thus GWT cannot compile this.
com.google.gwt.dev.jjs.InternalCompilerException: Failed to get JNode
at com.google.gwt.dev.jjs.impl.TypeMap.get(TypeMap.java:140)
at com.google.gwt.dev.jjs.impl.TypeMap.get(TypeMap.java:71)
at com.google.gwt.dev.jjs.impl.BuildTypeMap.getType(BuildTypeMap.java:730)
at com.google.gwt.dev.jjs.impl.BuildTypeMap.createField(BuildTypeMap.java:570)
at com.google.gwt.dev.jjs.impl.BuildTypeMap.access$300(BuildTypeMap.java:99)
at com.google.gwt.dev.jjs.impl.BuildTypeMap$BuildDeclMapVisitor.visit(BuildTypeMap.java:180)
at org.eclipse.jdt.internal.compiler.ast.FieldDeclaration.traverse(FieldDeclaration.java:285)
at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.traverse(TypeDeclaration.java:1232)
at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.traverse(CompilationUnitDeclaration.java:687)
at com.google.gwt.dev.jjs.impl.BuildTypeMap.createPeersForNonTypeDecls(BuildTypeMap.java:637)
at com.google.gwt.dev.jjs.impl.BuildTypeMap.exec(BuildTypeMap.java:514)
at com.google.gwt.dev.jjs.impl.BuildTypeMap.exec(BuildTypeMap.java:523)
at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.precompile(JavaToJavaScriptCompiler.java:599)
at com.google.gwt.dev.jjs.JavaScriptCompiler.precompile(JavaScriptCompiler.java:33)
at com.google.gwt.dev.Precompile.precompile(Precompile.java:284)
at com.google.gwt.dev.Precompile.precompile(Precompile.java:233)
at com.google.gwt.dev.Precompile.precompile(Precompile.java:145)
at com.google.gwt.dev.Compiler.run(Compiler.java:232)
at com.google.gwt.dev.Compiler.run(Compiler.java:198)
at com.google.gwt.dev.Compiler$1.run(Compiler.java:170)
at com.google.gwt.dev.CompileTaskRunner.doRun(CompileTaskRunner.java:88)
at com.google.gwt.dev.CompileTaskRunner.runWithAppropriateLogger(CompileTaskRunner.java:82)
at com.google.gwt.dev.Compiler.main(Compiler.java:177)
[ERROR] <no source info>: public class org.springframework.web.client.RestTemplate
extends org.springframework.http.client.support.InterceptingHttpAccessor
implements : Unresolved type org.springframework.web.client.RestOperations
Please provide your suggestion how to make an interaction between these Service Class and GWT.
You cannot have Spring in client side code.
Options available are:
A callback in a presenter where an asynchronous interface makes a GWT-RPC call to a service controller (on server-side of App#2). You could have an #RequestMapping annotated method whose internals employ the RestTemplate.
Have the presenter employ a RequestFactory and make use of GWT overlay feature for your payload.
Related
We use Spring to implement REST controller, for example:
#Controller
#RequestMapping("/myservice")
public class MyController {
#RequestMapping(value = "foo", method = RequestMethod.GET)
public #ResponseBody string foo() {...}
}
I can call this service using spring RestTemplate, and it works fine, but I would prefer to invoke it using a proxy, instead of typeless invocation using string url:
// client code:
MyController proxy = getProxy("baseUrl", MyController.class);
String results = proxy.foo();
So the input to proxy generation is java interface with annotations describing REST details.
I read this article and it looks like all types of remote calls do have proxies, and all I need for REST is something like RestProxyFactoryBean, that would take my REST java interface and return type-safe proxy that uses RestTemplate as implementation.
The closest solution I found is JBoss RESTEasy.
But it seems to use different set of annotations, so I am not sure it will work with annotations I already have: #Controller, #RequestMapping.
Are there other options, or RESTEasy is the only one?
Note, I am spring newbie so some obvious spring things are pretty new to me.
Thank you.
Dima
You can try Feign by Netflix, a lightweight proxy-based REST client. It works declaratively through annotations, and it's used by Spring Cloud projects to interact with Netflix Eureka.
One of the reasons the REST paradigm was invented was because expirience with other remoting technologies (RMI, CORBA, SOAP) shows us that often, the proxy-based approach creates more problems than it solves.
Theoretically, a proxy makes the fact that a function call is remote transparent to its users, so they can use the function exactly the same way as if it were a local function call.
In practice however this promise cannot be fulfilled, because remote function calls simply have other properties than local calls. Network outages, congestion, timeouts, load problems to name just a few. If you choose to ignore all these things that can go wrong with remote calls, your code probably won't be very stable.
TL;DR: You probably shouldn't work with a proxy, it's not state of the art any more. Just use RestTemplate.
Here is a project trying to generate runtime proxies from the controller annotations (using RestTemplate in the background to handle proxy calls): spring-rest-proxy-client Very early in implementation though.
This seems to do it: https://swagger.io/swagger-codegen/, and swagger has many other nice things for REST API.
Have a look at https://github.com/ggeorgovassilis/spring-rest-invoker.
All you need is to register FactoryBean:
#Configuration
public class MyConfiguration {
#Bean
SpringRestInvokerProxyFactoryBean BankService() {
SpringRestInvokerProxyFactoryBean proxyFactory = new SpringRestInvokerProxyFactoryBean();
proxyFactory.setBaseUrl("http://localhost/bankservice");
proxyFactory.setRemoteServiceInterfaceClass(BankService.class);
return proxyFactory;
}
and after that you can autowire the interface class:
#Autowired
BookService bookService;
I also ended up making my own library for this. I wanted something that is as small as possible, adds only itself to classpath and no transitive dependencies.
A client is created like:
final StoreApi storeApi = SpringRestTemplateClientBuilder
.create(StoreApi.class)
.setRestTemplate(restTemplate)
.setUrl(this.getMockUrl())
.build();
And rest-requests will be performed when invoking the methods:
storeApi.deleteOrder(1234L);
The is supports both method signatures:
ResponseEntity<X> deleteOrder(Long)
X deleteOrder(Long)
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
I've got spring web application with jersey rest services. However rest is secured via spring security and login process is very hard to perform from unit test code. I'd like to test rest services with whole spring security disabled. Is it even possible?
One of the advantages of annotation based web services is that you can unit-test them easily.
class WebServiceEndpoint {
#Path("/foo/{fooId}")
#POST
#Produces({ MediaType.APPLICATION_XML })
public Response doFoo(#PathParam("fooId") Integer fooId) {
/// ... web service endpoint implementation
}
}
If you're using Spring's servlet filter for security, then there shouldn't be any security-related code in the doFoo method, so you can just create a new WebServiceEndpoint class and call the method. So that's one way of 'disabling' security.
When you say the login process is 'hard', what do you mean? If you've succeeded in logging in once, then you can just reuse the same code in your other unit tests (e.g. in a #Before method).
Just test it as a pojo. Pass in whatever, return whatever, don't load an app context at all - that would be an integration test.
The ability to easily test functionality without the framework loaded is one of the key advantages of spring.
You don't say what's "hard," so I'm assuming that you've got something in your REST service, i.e. in the java method that you want to test, which requires authentication results. Spring has utilities for mocking the authentication results. For example, you can do the following in a #Before setup method:
Object principal = null; // fix this
Object credentials = null; // fix this
Authentication auth = new org.springframework.security.authentication.TestingAuthenticationToken(principal, credentials);
SecurityContextHolder.getContext().setAuthentication(auth);
But again, you haven't said what problem you're actually trying to solve...
I have a Java method I want to Unit test, but it requires a mocked SOAP response which contains multiple lists and layers of nodes. I am doing this with a handwritten mock i.e. just manually creating the objects and setting the values, but as the response is quite complex its a pain building up the response. I have a sample XML response is there an easy way of creating the mock using the XML?
Also I looked at Mockito and it looks fine for simple Objects, but it doesnt seem that good for complex responses (I may not be using it to its full potential).
The app stack is Java 1.6, Spring 3 and using JAX-WS.
I do something like this
#WebService
public class MyWebService {
#Autowired
private ServiceBean serviceBean;
public SomeReturedData getData(SomeInputData inputData) {
return serviceBean.getData(inputData);
}
}
For my UnitTest, I have a mock instanciation of "ServiceBean" which I inject in to #MyWebService, and "MyWebService" is deployed using the "in-vm" transport as described here
By Using the in-vm transport, All the XML marshalling/unmarshalling is still done by the web-service framework ,and you only have to deal with Java part.
Now someone might ask, why not test the "ServiceBean" directly, why the need to deply a WS using in-vm transport ? Well 2 things, Using in-vm transport you get to test that the JAXB XML marshalling/unmarshalling is working correctly, and it also allows you to test any intercepting handlers that you might have defined for your webservice.
What could the best strategy for writing validation layer for mid-enterprise level business application built on Spring 2.5
I know that Spring provides facility where we can implement Validator interface and write validation logic in validate method. But this will be restricted to only web requests coming through spring controller.
I would like to develop the validation framework which can be utilized during web-services calls.
In other words, the framework can remain and be called independently without the need of implementing Validator interface and then too it can be automatically integrated into Spring MVC flow.
Hope you get my point.
The Spring Validation framework can be used outside of Spring MVC. What WebServices Stack are you using? If you are using Spring-WS (Spring's Web Services stack) they have special instructions on how to set up the validator here:
http://static.springframework.org/spring-ws/sites/1.5/reference/html/server.html#d0e2313
If you are using some other stack, it is probably easier to implement something for that stack (or find one) that will use Spring's validation framework.
Recall that the Validator interface defines two methods:
boolean supports(Class clazz)
void validate(Object target, Errors errors)
The Object target is your form object, which is the whole object representing the page to be shown to the user. The Errors instance will contain the errors that will be displayed to the user.
So, what you need to do is define an intermediary that can be called with the specifics in your form that you want to validate which are also the same as in your web service. The intermediary can take one of two forms:
(probably the best):
public interface ErrorReturning {
public void getErrors(Errors errors);
}
(this can get ugly really fast if more than two states are added):
public interface ValidationObject {
public Errors getErrors(Errors errors);
public Object getResultOfWebServiceValidation();
}
I would suggest that the first approach be implemented. With your common validation, pass an object that can be used for web service validation directly, but allow it to implement the getErrors() method. This way, in your validator for Spring, inside your validation method you can simply call:
getCommonValidator().validate(partialObject).getErrors(errors);
Your web service would be based around calls to getCommonValidator().validate(partialObject) for a direct object to be used in the web service.
The second approach is like this, though the interface only allows for an object to be returned from the given object for a web service validation object, instead of the object being a usable web service validation object in and of itself.