I am new to spring world. I am trying to add to new functionality to an existing spring MVC based reporting project. The new functionality would give the user an ability to schedule a particular report to run every so often.
I see that in current design, model and Controller sections of MVC is tightly coupled. Due to time constraints, I am not trying to separate Model and Controller instead want to use the existing infrastructure as is. My plan is to mimic the browsers request in a pojo and somehow call spring's MVC to handle my request. Am i going in right direction, if so how to I invoke the spring MVC from a POJO, if not, what would be the right approach. Please help........
If i understand you correctly, basically you would like to :
create a non-web application that makes requests to existing Spring MVC controllers
and that you have to reuse existing controllers
and NOT reusing the business model, because you dont have the time to separate the business model from the controller
Basically you are doing web services with this approach, where you make requests to the controllers via http using a http client library. And perhaps, get the response as json, which you can later map into a java bean, and continue your work from there.
You can have the controller to return the view's model as xml, or json, etc, or even directly return a bean as json or xml using spring's message converter.
If you are already using Spring 3, there is a RestTemplate that you can make use of to simplify this.
You could also make use of Apache's HttpClient, whose interesting example that you can see in this REST template code.
This related Q&A on java http clients could also be helpful.
Related
I have built a web app using Spring 4. The app allows search users, create elements and so on.
The requirements changed. Now I have to deliver search results as json instead of html (but keep html just in case).
The question is, should I use controllers and redirect to a jsp with json/html according a parameter? or use Spring restful web service?(I've never used this and need to learn how to) if I use Spring restful do I have to do the same job I've already did with the web version to generate json?
It depends on how did you design your previous MVC application.
My suggestion is follow:
But better to use Spring REST Controller. Mechanism is more or less same like MVC. I assume you have service layer for CRUD data of your application.
Better to use those Service and Repository and just create #RestController for your application. #ResponseBody should be your models which are you returning from controller. And #RequestBody will hold the data for generaly POST, PATCH, DELETE requests.
Good luck.
I am designing a Java web application that will be deployed to the Wildfly or Tomcat (not decided yet).
Basically it's about the offline java application that needs a REST interface for communication (to accept JSON data). The idea is that application runs all the time and processes the requests stored in redis cache (where the received JSON data is stored).
I used the Spring MVC framework for a web site in the past but I don't need the MVC pattern for the REST interface.
Is there a way you can point me to for using a Spring framework (or some other Java framework) to add the capability to recieve a POST requests to the existing offline application? Or it will be better to just write the REST service that will use the same cache as the existing application?
To illustrate my question I am attaching the simplified diagram of the architecture I am looking for:
As soon as you speak of receiving a POST request, you are automatically referring to a HTTP server.
The question is just whether that server is running as a service, or on-demand.
Is there a way you can point me to for using a Spring framework (or some other Java framework) to add the capability to recieve a POST requests to the existing offline application?
Not without introducing some sort of HTTP container, no.
Or it will be better to just write the REST service that will use the same cache as the existing application?
Yes, exactly. And as another mentioned, personally I'd stick with Spring MVC. But Jersey should also work very well for you for your usecase.
I think you should use any light ESB, like Camel, Mule or Spring Integration. If you have already worked with Spring probably the latter will be the easiest for you.
The purpose of this kind of apps is to facilitate the task of communicating anything with anything (on this case, an HTTP endpoint with your offline app).
Take a look at this:
https://www.google.ie/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=spring%20integration%20http-inbound
You can use Spring MVC for that.
The Model are your domain classes, the View is JSON in this case, and the Controllers handle the requests to perform logic operations, business as usual.
You can also take advantage of Spring's #RestController annotation to quickly create your endpoints, like in this java example:
#RestController
public class MovieController {
#Autowired
private MovieRepository movieRepository;
#RequestMapping(value = "/movies/{search}", method = RequestMethod.GET)
public List<Movie> findMovies(#PathVariable String search) {
return movieRepository.findByName(search);
}
#RequestMapping(value = "/movies", method = RequestMethod.POST)
public void postMovie(#RequestBody Movie movie) {
movieRepository.save(movie);
}
}
Answers from Andres, ESala and kervin pointed me to the right direction but the solution I found most suitable was:
implementation of REST services using Spring MVC and
transformation of the main process from the existing application to the Spring scheduled task.
I am new to MVC and searched a lot about it and following are the things which i found on Stackoverflow.
1. With angularJS at client side ---> NodeJS , Rails are good to be used on server side as they have certain benifits.
Now i have a question :-
even spring is an MVC framework, but can i use Servlet and Angular JS and implement MVC with it?
Thanks in advance.
Angular doesn't really care what you're using server side it just expects to be able to send JSON encoded data in the body of requests and get responses that are JSON encoded. So the short answer is yes you can. Regarding MVC there's basically layers of this design pattern used throughout the client side framework itself, on the server side typically I just have code that loads data from a database (or updates/inserts/deletes data) then encodes it and sends it to the client. This way the server is essentially decoupled from the client and either could be rewritten or appended/supplemented without replacing either.
MVC just means model view controller, which is a design pattern for dividing up code. The model is the data itself and is "the source of truth" for updating the view, the controller is responsible for making changes to the model, and the current state of the model is always reflected in the view.
With Spring MVC traditionally the server would be responsible for wholly processing the request using a controller that updates the model then generating a view that was delivered to the client.
With Angular you use AJAX requests to get data from the server, then you update your model (typically through a controller as a proxy to a service/factory in angular terms) and then the bindings/watches in angular automatically update the view.
So in the case of angular really your server side is not responsible for creating the view but only responsible for persisting data (and dealing with authentication and authorization). On your server side you may still maintain a model that corresponds to some schema in a database or otherwise and you may have some route handling layer that you could consider the server side controller that acts on the model, you're just not really dealing with the view at all anymore.
There are lots of advantages to this approach both for the end user and in terms of development. You can test your backend and frontend separately and you can refactor or replace either or build additional frontends (native clients etc.) or add backend modules without disturbing the clients. The only thing you need to take care of is maintaining a consistent interface between your client and server components.
In short, Yes.
Just make sure you are passing the data in JSON format because AngularJS expects JSON, as explained by #shaunhusain.
This link will be very much helpful to understand how to create folder structure for the application.
Let me start by saying I was just thrown into a Spring MVC project and my only experience has been from a GWT project.
In GWT we created a hierarchy of pages filled with 'presenters' which indicated a new page. So if I wanted to create a new page I could simply create a new presenter and widget number and that number was inserted into the URL, thus creating a new web page. From there I could assign text boxes, tables, etc to that widget number, which in turn would populate my new page.
Questions
In a Spring MVC hibernate project how would I indicate I want a new page? where would information for this page be contained? Much of the Java files I see in my project are validators and logic oriented and less page structure and layout.
I used click listeners and handlers a lot in GWT. Why have I been unable to find any in my project's existing code base? How is this type of thing handled in Spring?
1) MVC means model-view-controller pattern, so you need to learn how to integrate your views (html, jsp, jstl) into Spring. Refer here:
http://docs.spring.io/spring/docs/2.0.8/reference/view.html
2) There are also listeners in Spring, for example, ContextLoaderListener.
These might help:
http://www.docbyte.com/fr/blog/integrating-gwt-with-spring-and-hibernate
http://www.javacodegeeks.com/2010/05/gwt-2-spring-3-jpa-2-hibernate-35-2.html
A Spring MVC application is a web application built on top of the Servlet API. You run such an application in a Servlet container which acts as an HTTP server.
Spring MVC follows the Model-View-Controller architectural style. A controller is dispatched to handle the request based on the mappings you configure. The controller performs some logic, delegates to the model, prepares it and makes it available to the view. The view can be pretty much anything. You can have it have it generate HTML, XML, JSON, some other binary content type, etc. That content is written to the HTTP response which your HTTP client can then display/render/download.
In a typical Spring MVC app, you'll have the views setup with JSPs. Your configuration will declare an InternalResourceViewResolver which will forward to JSPs based on view names that the controller handler methods (methods annotated with #RequestMapping) return.
GWT follows a completely different methodology than Spring MVC. Spring MVC is straight up client/server. The client sends a request. Spring MVC receives it, dispatches a controller, and returns a response. The lines are clear. In GWT, not so much. IMO it feels more like a standalone application with buttons and listeners. The actual underlying implementation is still client/server, it's simply hidden from you as a developer.
When you click the button on a form, a browser typically sends an HTTP request to the server, the server responds and the browser renders some other page (or does something else, depending). In Spring, the flow is as described above. The web app receives the request, dispatches to a controller which returns a view, and then returns a response based on that view. As a developer, you code most of that.
Evening all :)
I'm looking to create a Java web application. I envisage that it will use Spring web MVC and JSPs, however I would like to expose certain functionality as REST calls so I can create an android client.
Does spring offer anything to help me in this area? How can I keep the REST code and the web front end code separate yet not have to maintain essentially 2 versions of my application (one for the web, one for REST clients).
Not looking for spoon feeding, just some pointers of where I should start reading.
As others have mentioned, Spring has pretty good in-built REST support now. When combined with annotations, this allows really simple set-up of a RESTful API. Spring can be configured with different view resolvers, which can automatically respond with a different view of the data depending on the Accept header for example. So you could return either JSON or JSP automatically from the same data, see the ContentNegotiatingViewResolver. Your Controller and Model can then be common and implemented once, leaving the work in the View layer.
I've used this approach before to return JSON when the request was via AJAX and a JSP view built with the same data when accessed by a browser.
Jersey is a pretty nifty tool. It integrates well with tools like Spring, Guice, and Jackson to provide you a pretty seamless way to create RESTful resources.
Jersey is pretty simple, works well, and serves as the reference implementation to boot. Plus, it has some nice REST client support, much of which will probably make it into the JAX-RS spec.
In terms of marrying that with Spring MVC, I'd recommend you make sure you model your application so that you have facades (Service classes) that provide all the core functionality you need and then simply reference them as needed in your MVC code or REST code. You shouldn't be duplicating business logic
You can do this using Spring 3.0. Spring 3.0 came out with the ability to specify #PathVariables to pull values out of the URL path (previously this was not easy in Spring MVC).
You would also use #RequestMapping to specify the HTTP method(s) each method in your controller should respond to.
I've also use Spring Security to implement an API key type of functionality. This way you can restrict access to your API in a way that is easy for REST clients to implement. I had to extend org.springframework.web.filter.GenericFilterBean and add a the proper Authentication like this
SecurityContextHolder.getContext().setAuthentication(apiKeyAuth)
There's a new REST API in Spring 3.0 MVC:
http://blog.springsource.com/2009/03/08/rest-in-spring-3-mvc/
http://www.springsource.org/download
Apache CXF integrates well with Spring and offers many method for exposing services. From the overview section of the CXF homepage:
CXF helps you build and develop
services using frontend programming
APIs, like JAX-WS and JAX-RS. These
services can speak a variety of
protocols such as SOAP, XML/HTTP,
RESTful HTTP, or CORBA and work over a
variety of transports such as HTTP,
JMS or JBI.