So I Want to build projects using spring Boot directly as I'm under a bit of time crunch. Please help me out.
What you need to know about JSP: nothing. JSP is old and clunky, use Thymeleaf instead. But if you're building single page web apps you don't need any templates, you just need to know how to accept and return JSON.
Servlets: you need to understand the threading model, that there's only one servlet being traversed by multiple threads, and any instance variables will be accessed by all the http request threads. More than servlets you need to know filters, because Spring Security uses them.
Related
I have a design problem at hand. Traditionally I had been developing Spring MVC/Struts/jsf applications with either REST/SOAP service serving the data.
Now we have HTML5 and other javascript frameworks. In this light, do we still need to create Spring MVC applicationS as such (assume that the data is served from a RESTful service)
If I go ahead with pure HTML5, CSS UI (with Ajax calls to RESTful services), what are the possible issues that I may get into? does this approach have security holes like being prone to cross site scripting?
Is it a good approach to start off with? Would this approach be called a single page app?
You still need to serve your single page app from somewhere, along w images and css files. This could be a Spring MVC servlet, or whatever.
I'd look into Spring Data REST which is a servlet that creates RESTful HATEOAS endpoints for you.
It's probably easier if your SPA and REST service are on the same domain, so you don't have to worry about cross-domain restrictions.
They are still vulnerable to XSS, as is any system unless you take counter-measures. Spring security can help here. Make sure you follow the OWASP guidelines.
Use Hibernate Validator's #SafeHTML annotation to prevent unsafe HTML input into your database. Use Spring Security's <content-type-options/> , <xss-protection/> , and <header name="Content-Security-Policy" value="..."/> settings to help fight XSS.
Spring MVC, Struts, etc. provide two core functions: Routing, and Binding.
Routing is dispatching an HTTP request to the relevant piece of code.
Binding is converting the world of Strings that the HTTP request sends you in to something more useful, such as a generic Java bean with not just Strings, but integers and dates.
Along for the ride are aspects such as validation.
Finally, they provide an environment that's particularly friendly to your view layer.
None of these aspects, per se, are obsolete in a world where all you have is JSON coming up and JSON heading back. You still need routing, but now you may care to route not simply on the request url itself, but on HTTP verb. You still need binding, having the framework marshal the JSON payload into some easier for java to work with is very handy.
But, (and I speak in general terms, not specifics as I don't know Spring or Struts well at all), while the MVC frameworks can fill the role of a backend system for a more JSON oriented and raw HTTP world, the specific REST frameworks do the job better.
There's no mistake that the MVC frameworks were a significant step up over raw Servlets. Raw Servlets are functional, but simply too primitive for real work. But with design decisions made from a world 10 years ago, some parts show their age and get in the way in the new world of more raw HTTP requests.
If you're doing a mixed app, some MVC, and some HTTP/Ajax methods, then it's better to work with your MVC framework than adopt a new one.
If you're doing a pure singe page app, then it's worth your while to adopt a framework that tends to that niche. They'll simply be a better fit.
Mind, also, they can live side by side. You can have both co-habitate in a single WAR if you wish, particularly if you're adding SPA features to a legacy application. It doesn't have to be an either/or situation.
But I wouldn't introduce an entire new infrastructure component simply to handle a couple of ajax calls. In the end, they're just HTTP calls, and the MVC frameworks (in contrast to most component frameworks) do just fine with raw HTTP for the most part.
I've inherited an incomplete but small web project (Java EE 5, running on WebSphere 7).
The project consists mostly of JSPs that are accessed directly via their URL, and most JSPs look up their own reference to the EJBs (services) they need. Also, there's a Servlet for every form that gets submitted by the HTML code in the JSPs.
Architecturally speaking, is there anything wrong with this?
I was thinking it would be better to have an MVC design. I don't want to convert everything to JSF because I don't want to convert all the HTML and embedded Java scriptlets into JSF tags and managed beans.
I don't really want to use Struts or Spring MVC because they're not part of the Java EE 5 toolkit that comes out of the box with WebSphere, and I don't want to add additional complexity with the additional libs and config files.
I was thinking about building my own little MVC with a "ControllerServlet" that accepts a command and dynamically build and execute the command object, and redirect to the JSP view.
But I ask myself again, is there anything "wrong" with JSPs that post to Servlets? It's actually kind of elegant in its simplicity.
What do you think?
Any suggestions are GREATLY appreciated! Rob
You're asking a rather subjective/localized question. But ala.
There's technically nothing wrong with individual JSPs that submit to individual servlets. The only real problem is when the servlets turn out to contain duplicated code for quite common tasks like collecting request parameters, converting/validating them, setting bean properties, invoking actions, performing navigation. That is not DRY and is what a MVC framework with a single front controller and a well definied lifecycle is supposed to solve.
Or, if the servlet's tasks are actually well refactored with homegrown code to perform those common tasks, then this is in turn not very maintainable as no one else than the original developer knows the ins and outs of this custom framework. So it's hard to find anyone else willing to maintain this webapp without learning another framework again which the new developer wouldn't likely to see in other future webapps. That is why companies usually adopt an existing and well-developed MVC framework like JSF, Spring MVC, Stripes, Struts, etc.
I'm trying to integrate Struts 2 with Spring and Hibernate. There are things that I don't understand in the web.xml :
What's the difference between the Struts 2 "filter-class" tags which have the following values:
org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter <br/>
or
org.apache.struts2.dispatcher.FilterDispatcher <br/><br/>
Why do we use a Filter for Struts and use a Listener for Spring, and shat is the difference between them.
Why in some projects we can omit the hibernate filter and in the others we use it.
Its like a lot of questions and here are answers to few of them.
Filter Dispatcher and StrutsPrepareAndExecuteFilter are there to perform same work and StrutsPrepareAndExecuteFilter is the latest version of FiterDispatcher with a lots of improvement and keep in mind the future needs. So in short FiterDispatcher is deprecated.
StrutsPrepareAndExecuteFilter is the entry point of S2 and is responsible for handling any request and response.In short Filter is used for monitoring request and response from client to the servlet, or to modify the request and response, or to audit and log.
Listener is used for listening to events in a web containers, such as when you create a session, or place an attribute in an session.
So this gives a brief idea about whey we are using Filters for S2 and Listeners for Spring and you can do more googling to get more information about there differences and how hey work.
Hibernate filters are used in some specific use-cases.one such use case is to filtering the results of searches. Sometimes it is required to only process a subset of the data in the underlying Database tables and there can be many more such use case for hibernate filters and they only come in to play if you need them.
We have a web application that uses spring, struts and camel right now and there is a lot of customization we have done to allow us to know when beans are added to the context.
So, we have gotten to a point where we would like to remove struts from the application, because we are only using it to handle actions and we figure we could either use spring or camel to do the same thing. So I was able to get it to work with camel/velocity, but we didn't like how we really couldn't use the request object directly in the jsp (afaik, you have to put everything in the header of the Exchange and in the jsp you would do ${header.someReqVariableName}).
So we wanted to go the spring route, but since we load the context.xml directly, we have a provider that extends ContextSingletonBeanFactoryLocator and we pass the xml file name as a param, we haven't been able to figure out how to get the DispatcherServlet to work without giving it another configuration xml.
Is there a way to either:
Have camel use jsp for processing a jsp (and have all the usage of jsp tags)?
or
Have spring to see that a context has already been loaded and use that instead of having another new one?
or
Something better I have thought up?
You can use camel-jetty to expose HTTP endpoints, but I wouldn't use it for any complex web app development (JPS, etc). I'd use use Spring MVC (or similar) and use Camel for any complex routing/messaging requirements...
Here is another way, you can use the producer template to send the request to the camel context if you can get the reference of the camel context from the spring.
(I am not familar with technologies related to HTML delivery, like JSP... But I know basic concepts...)
In my application I use Spring Beans and Spring Security together with Blaze DS to communicate with Flex applications over AMF protocol. Everything works just fine.
Now I have a task to deliver some services via HTTP/HTML eg. it should be some sort of servlets or JSP pages that generates HTML for users. To not reproduce all business and data access logic I want to utilize my existing Spring Beans (I love Spring.). So, basically I want to create HTML view for my Spring Beans.
My question: What would be the best way to do it? Which technologies I should use? What guru-guys will suggest?
The best tip would be a link to small tutorial that will explain how to access Spring Beans for JSP pages. I tried to goole myself but there are too much information and I am a little bit nixed up with different version - so I really have no clue what should I start with...
You should look into Spring MVC. You can find an introduction here.
Also the accepted answer to this question discusses how to do what you want specifically (i.e. access your Spring Beans from JSP pages).