Which version of Spring Boot will (or does) officially support Servlet 4 spec? Where can one see the new features that come with it documented?
Thank you.
Spring Framework 5 supports the Servlet 4 spec (see SPR-12674).
Not a lot of new features related to that, really. You can now inject a PushBuilder as a controller method argument if it is available (HTTP/2 enabled, supported by the client, etc).
Note that you need to use a Servlet 4 based container to use those features (see SPR-15593), or you'll need to fall back on container specific APIs which have been available for quite a while now.
Spring Framework does the job here, so there isn't anything special scheduled for now in Spring Boot 2.0; don't hesitate to open enhancement requests on the dedicated issue tracker if you've got ideas.
Related
I have seen lot of examples for Servlet3.0, but I couldn't find a single answer with Servlet2.5. But I'm sure there should be a way to do it.
Can anyone tell me how to add a servlet programmatically with tomcat 6.
Thanks.
Of course you can write a servlet that takes all requests you might react on (maybe bound to *.do or the like) and that handles those registrations. But there is no support by the servlet standard and I don't think Tomcat 6 supports programmatic configuration out of the box. However, there might be a framework that does, but I'm not aware of.
I'm selecting a framework for restful service. Restlet looks promising. However, I'd like to pick something that's mainstream enough that it won't go out of support/development too soon. I know restlet has been around for quite some years. However, I'd like to know if it's popular enough. My questions are,
Any big name companies using it?
Is the default http server good enough for production?
thanks
The Restlet Framework has been available since 2005 when it was the first RESTful web framework for Java. It has support for the JAX-RS API, but its own Restlet API is both client and server-side since day one, much more comprehensive and extensible. We are free to innovate based on our community feed-back, without having to go through lengthy JCP standardization processes.
Also, we just published the 'Restlet in Action' book last September along with its version 2.1. Our internal connector is fully asynchronous and based on NIO and we are constantly stabilizing it even though it isn't ready for heavy productions yet (use the Jetty connector or a Java EE container with no change to your Restlet application).
Its consistent support for Java SE/EE, OSGi, Android, GAE and GWT with dedicated editions is unique. A port to JS (Node.js + AJAX) is also under way. We have also started work on version 2.2 with the first milestone being released (with full Java 6 support, OAuth 2.0 extension based on the final spec, etc.).
In term of references, we have many large companies using it including LinkedIn (see their GLU open source project), IBM, NVidia, ForgeRock, NASA, Sonatype, Apache Camel, Mule ESB, etc. Google has been using it internally as well. See some quotes here:
http://restlet.com/discover/quotes
In January, we'll launch a new community web site as well as APISpark, an all-in-one platform to create, host, manage and use web APIs, directly based on Restlet Framework (PaaS), so the project is active and has an exciting future!
Best regards,
Jerome Louvel
PS: I'm the Restlet Framework creator and lead developer.
The most mainstream you can get is Jersey. It is the official implementation of rest in java. Restlet came out before Jersey. But then Jersey surpassed them (in my humble opinion). I have used both Jersey and Restlet on serious projects. They are both good. However, you will find more support, more books, and more examples on Jersey.
Is this about Java? In that case, JAX-RS is the awesome new API for doing this. The best book for this is Restful Java with JAX-RS. My favorite implementation of it is Jersey, but there are others with their own unique features. All JAX-RS implementations are compatible if you don't use their distinctive features (which are minor anyway). The book explains the core API, the REST philosophy, and also some of the features unique to the different implementations. It is an excellent book. I love the introduction, where the author relates how he was used to traditional remote procedure call (like SOAP, WCF, and ordinary OO semantics) but then saw the light of the REST principles as being simpler and more elegant.
I use Tomcat as the HTTP server (servlet container). It is lightweight and is what Amazon Beanstalk uses (you can just upload your application, the WAR file, to it and it just works). You can also use GlassFish which supports many more JavaEE features, or use Apache for static pages and other things, and forward the REST requests to Tomcat/GlassFish.
The annoying thing about JAX-RS is that it's so powerful and easy that you're tempted to write ideologically-sound REST services. Unfortunately, javascript can't use many of the REST features (setting Accept header, calling anything but GET/POST, etc.) But it's not a big deal.
Jersey also has a fantastic client-side Java API that mirrors JAX-RS and reuses the same annotated classes, if your clients will be Java.
From the article
The Servlet API was released in 1998 and its core design hasn't
significantly changed since that time. It is one of the most
successful Java EE APIs, but it suffers from several design flaws and
limitations. For example, the mapping between the URI patterns and the
handlers is limited and centralized in one configuration file. Also,
it gives control of the socket streams directly to the application
developer, preventing some IO optimizations by the Servlet containers
like the full usage of NIO features. Finally it does not support HTTP
features like caching, content negotiation and content compression
very well, causing too much pain to developers and preventing them to
focus on their application specific code.
Another major concern was the lack of a modern HTTP client API in the
Java EE stack. The JDK's HttpURLConnection class is hard to use and
leaves too much HTTP features unsupported like expressing client
preferences for content negotiation.
Frequently, people were relying on third-party HTTP client APIs to
workaround those limitations. Again, NIO can't be supported with
HttpURLConnection.
In 2005, I saw an opportunity to go beyond all those limitations, and
to design a fresh API in the light of the REST principles. For the
first time, we have an API that unifies client-side and server-side
Web applications, an API that fully supports NIO and an API that lets
the developer programmatically control its container, connectors and
deployed applications without having to constantly rely on XML
descriptors.
I am new to Web Development. I am learning Java Spring. I found a good online tutorial for interceptors in Struts 2. My question is, are interceptors in Struts 2 the same as interceptors in Java Spring? If not, what are the differences? If they are different, what are the advantages/disadvantages of using one over the other?
I would suggest that this is not a differentiator in choosing between Spring MVC ( if that's what you mean by Java Spring ) and Struts2. The interceptors in both frameworks play the same architecural role by isolating cross cutting concerns from your core business logic classes.
At least in Struts 2, it's fairly uncommon to code against the interceptor api; <5% of your total development time. This would suggest that you would only really care about the differences in the interceptor api's if you had some particular use case that you felt would be solved by interceptors, and then this use case could help you evaluate the two api's.
If you don't have such a use case, which seems likely if you are new to web app development, I recommend not putting to much into this topic; either framework will most likely server you well. Though there could be other valid reasons for choosing one or the other.
I'd like to use Websockets with a Spring MVC-powered web app. I've read o jWebsockets and bristleback, but I am wondering if that is the best way to integrate. I am sure someone has done this before and has some tips what works and what does not...
Thanx!
since Springframework 4.0 M1 Websocket are supported, see http://blog.springsource.org/2013/05/22/spring-framework-4-0-m1-websocket-support/
Edit - 08 january 2014: Springframework 4.0 released and supports websocket, have fun.
Here is an update on 4.0 M2, see http://blog.springsource.org/2013/07/24/spring-framework-4-0-m2-websocket-messaging-architectures/
Spring MVC will offer you no help here - it supports HTTP traffic using the Servlet and Portlet APIs only. Websockets, I believe, are not HTTP-based.
Spring has plans to implement the WebSocket servlets offered by many popular application servers. The main problem is that, as each server comes out with it's own webscocket implementation, they all vary greatly. The Atmosphere Framework is available, and supports cross server, cross browser implementations.
There are some blog posts available, like combining atmosphere websockets and comet with Spring MVC
I would suggest you research the framework before deciding it's right for you. They have a github src repo with demo's and documentation available as well.
It seems that support is planned, https://jira.springsource.org/browse/SPR-9356 (but they'll need to work around the lack of Servlet API support)
Just about to start a java EE project.(Biz requirement is under change still.)
For the web tier, we looked at various java web frameworks and eliminated component-based ones such as JSF, Wicket. Now it comes to spring mvc 3 or struts 2.
Googled it and found little useful info. Can anyone talk about their pros and cons? Thanks.
I took over a Struts 2 + Guice web app that used the REST plugin to do convention over configuration. It was very easy to work on at first but I ran into a couple of hurdles that were either difficult or impossible to overcome.
One of these was that I needed to have internal dot/period characters in the path of the URI and Struts 2 + REST did not allow this, as it would interpret the dot to indicate a file extension and try to marshall to the appropriate view (e.g. like catching .xml and .json).
So I ended up rewriting the webapp in Spring 3 and was able to fix all those issues I couldn't handle in Struts 2. I've been much happier with Spring 3 and found it just as fast to code in as Struts 2. I've stuck with annotation based configuration as much as possible and tried to use the JSR versions where ever possible (330 #Inject and 303 #Valid, etc), so that if I decide to get rid of Spring I am not stuck with custom Spring annotations.
My vote is Spring 3.
In this other stackoverflow question you have a lot of answers comparing struts and Spring. Though many of them don't mention explicitly the version 3 of Spring the comparison would be similar to the version 2.5.
As many of them say, I'd prefer Spring. It makes things easier when you use annotations. One fact I don't like in Struts 2 in comparison with Spring-mvc is that you have to add getters and setters for every property you want to get in the actions. I think Spring is cleaner in this way.
#Javi
You have various options in Struts2 to avoid these getter and setter one of them id ModelDriven interceptor
Well my vote is for Struts2 since i am working on it from so long but this does not mean Spring MVC is bad i have worked on it also and its equally good..
Choice is all yours and it depends what word you like most Spring or Struts