I am currently not using any frameworks (other than bootstrap) for my java-ee application. But i came across a problem in using server side validation for servlets. I am finding it difficult to implement validation like this
http://spring.io/guides/gs/validating-form-input/
I could use request dispatcher, but I am not sure if it's the right way.
So i wanted to ask is it advisable to use the spring framework just for the validation?
is there any way to convert my entire java application to use spring or should i build the application from the ground up again?
If you just need the validation, then I recommend to use JSR-303/349 Bean Validation 1.0/1.1. The default implementation is done by Hiberante-Validator (this is NOT the Hibernate-ORM project!). It is relative easy to use out of the box.
http://hibernate.org/validator/documentation/getting-started/
Related
Is it possible to add route in Spring Integration during execution? I'm doing project in Spring Boot and I need to use Spring Integration to make routes able to create during runtime. I can't find proper example or documentation that describes is it possible and how to to that.
What is route in your mind? Are you really referring to the router component? Why then dynamic routers doesn’t work for you: https://docs.spring.io/spring-integration/docs/5.2.2.RELEASE/reference/html/message-routing.html#dynamic-routers?
So, you can populate router mappings at runtime using an AbstractMappingMessageRouter.
Since some version, we don’t require initial mapping any more.
If you speak about something what we call flows, then you need to take a look into Java DSL and it dynamic flows registration: https://docs.spring.io/spring-integration/docs/5.2.2.RELEASE/reference/html/dsl.html#java-dsl-runtime-flows
I want to create new RESTful application. I am bit confused about framework I can do it with spring+jersey , but can I do same application using jersey alone?
What is major difference between SpringREST and jersey?
Which is more convenient? why?
I've used both frameworks a bit. Spring is a large framework/API that covers many areas, one of which is rest services. Jersey on the other hand just covers rest. It's the reference implementation for the JAX-RS API (JSR 311 & JSR 339).
This is basically the "standard" way to do rest in Java. There are also other implementations like RestEasy. In theory your code will only need to reference the common JAX-RS interfaces meaning you ought to be able to swap to a different implementation later if required. This obviously only works if you don't become reliant on bespoke functionality that isn't part of the JAX-RS standard.
If you were to use Jersey, you might still decide you want spring. It can be useful just for its dependency injection alone. In this case you might have a JAX-RS class handling rest requests which then calls a spring service which has been injected. This is actually how I'm writing rest API's.
Whether you should use spring to write the rest services or JAX-RS is subjective and really up to you. Personally I went with the standard JAX-RS API because I found it was more focused on rest. The spring rest approach is basically an extension of spring-mvc which was originally intended for JSP's. I found things like error handling were easier using JAX-RS than spring-mvc. That said someone else may beg to differ. The other benefit is by following the standard in theory you have more flexibility in future if you want to switch to a different provider.
The main difference is that Jersey is standards-based, and Spring MVC is not, if that matters to you. Both are very good.
The main advantage I found in Jersey (I used 1.x) was that it could automatically use Jackson JSON Views automatically, and Spring MVC could not. Also, error handling in Spring MVC is kind of irritating, as error pages default to standard HTML.
There is another project you have not listed, and that is Spring Data + Spring HATEOAS, which is newer, but seems pretty good.
Spring Framework provides a wonderful abstraction layer for low-level resource access in Java (the Resource and ResourceLoader interfaces). I'm developing a library which should not be dependent on Spring, and am looking for an equivalent for this capability in a stand-alone Java library. Anyone familiar with one?
Why not just use the one from Spring by itself? It doesn't look like it has any dependencies on the rest of Spring.
Edit
Not sure I understand the problem - you want something that does exactly the same thing, but doesn't come from Spring? Is it a licensing issue?
You only need half a dozen classes from it, if you don't want to add them as an extra jar, move them to your own namespace (good idea anyway, in case you do use Spring at some point, after all) and distribute with your library. Again, assuming your licensing allows it.
If licensing isn't the problem, can you be more specific about why you can't use the Spring implementation in your own library?
You can use Jsr-303 (DI) to match your requirments. The most known implementation is Google Guice. It's a javaEE standard (maybe JavaSE).
I'm having a hard time deciding which "Open Session In View" to use: configuring OpenSessionInViewInterceptor using Spring MVC's interceptor with or configuring OpenSessionInViewFilter in web.xml's filter? From what I have researched, they do pretty much the same thing, but I'm trying to understand the difference and the usage of each type.
The biggest difference between the two is for folks who can't use a filter in web.xml (say, servlet 2.2 and earlier), their only option is to use OpenSessionInViewInterceptor. Somehow, I'm leaning towards the interceptor simply because I have to create a custom interceptor for my project, so I'm thinking of grouping all these "filters" in Spring MVC config file rather than having OpenSessionInViewFilter in web.xml and my custom interceptor in Spring MVC config file. It's really a lame way to decide which one to use, and my curiosity kills me here.
Can anyone share your thoughts about this? Which one do you guys use?
Thanks.
As you say, the two are more or less equivalent. Spring provides them both so that you can pick the one that fits best with your existing application.
If you use Spring MVC, then it makes sense to use the interceptor, since it's easier to configure and better integrates with Spring MVC.
However, if you don't use Spring MVC, and only use Spring at the business-logic level, then the interceptor isn't really an option, and the filter becomes more appropriate. Because filters are not managed by Spring, they're harder to configure to integrate with Spring, but that's the trade-off.
If you have any requests that are not going to go through a spring controller, i.e. legacy code that goes through a custom servlet, or jsp's that are hit directly, then the filter will cover those and make sure they get wrapped in a session. The interceptor will not cover those since those requests will not get picked up by the spring DispatcherServlet.
In Asp.Net MVC 2.0, at least in the beta, you could decoration your model classes with data annotation attributes and enable client side validation that leverages that criteria defined in your model data annotation attibutes. Is there anything similar for Java Spring MVC 3.0?
Is it possible to inject a component into the response pipeline that can inspect the model's annotated properties and render client side validation logic to complement the server side validation logic that is invoked prior to the controller handling the request?
Actually, there is something a little bit like it, based on the JSR-303 Bean Validation spec, which is now final and fully supported by Spring 3.0.
Recently, as part of Spring Webflow, Springsource has released Spring JS (javascript) which uses Dojo. You can use that for your client side validation. Check out this howto
Obviously, component-frameworks such as Wicket (like fraido mentioned) have better support for this kind of usecase. So if you have to implement a lot of similar usecases, that is probably a better fit for your project. However, if it is sporadic, Spring JS / Bean validation could be the way to go.
Spring MVC is a fairly low level framework. It doesn't extend to doing client side validation.
There are other Java Web frameworks that do this such as Tapestry, Wicket and JSF (IceFaces, etc). These are what I tend to call "component frameworks".
In Spring MVC 3.0 there's nothing like that at the moment. As cletus said frameworks like Tapestry (ex), Wicket (ex) and others have some sort of Client Validation that uses JavaScript to validate forms etc.
You can write your own validation Jstl taglib maybe with the help of a JS Library (jQuery, ...) and Plugins like : jQuery Validation Plugin
edit: I've just found this: Mediawidget. Maybe it's worth having a look.
It says: "Metawidget reads Bean Validation annotations and generates forms with
widgets that are pre-configured for minimum/maximum values, lengths etc."
Spring integration Link1, Link2
This project looks to be exactly what you're looking for: http://kenai.com/projects/jsr303js
2011-12-06: I'm just about to try it myself
2013-12-09: Update on this answer: I did try the library out, and it worked very well. It needed some tweaking (it's a prototype patch for Spring, not a finished plugin), but it was the best solution I could find at the time. Perhaps there is a new solution, or perhaps someone has finished off this prototype since I posted? If not, I can recommend this one.
Ok, this is a variation on what's already been said, but one of the big strengths of Spring-MVC is its ability to integrate with other libraries, like the different JSF variations that do give client side validation.