I'm new to dependency injection w/ Spring and am facing a seemingly challenging scenario.
My application receives data from a legacy system over a plain old socket, does Interesting Things (tm) with the data, then uses an embedded Jetty instance to pump out Really Interesting Results (tm) via HTML5 Web Sockets. Additionally, the Jetty server hosts a Jersey servlet that provides a RESTful interface to all of that Interesting Stuff (tm).
I'd like to use Spring to inject shared DAOs and application service objects into both the legacy side and into my Jersey resources. This requires that an ApplicationContext be shared between the legacy components and Jersey. It seems that I would need to create the application context, wire it to my legacy components and then pass the application context to the Jersey ServletContext when configuring the embedded Jetty server (which I'm currently doing programatically).
Unfortunately, it's not clear how I can pass an existing application context into the Jersey ServletContext. Can it be done? Is there a better approach?
I'd like to note that this differs from the other Jersey + Jetty + Spring questions I've found on SO, which don't require an application context to be shared outside of Jersey.
I assume that your code starting Jetty is something like:
Server server = new Server(...);
server.setHandler(new WebAppContext(...));
You can get the ServletContext from WebAppContext and set the SpringContext on it:
WebAppContext wac = new WebAppContext(...);
ServletContext sc = wac.getServletContext();
sc.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE, springContext);
Related
Dose Web Application Context and Servlet Application Context is same thing?
I think these are same but different name.
Am I right?
If you speak about Servlet Context and not spring-servlet:
They are different things.
Every Java web applications that use Servlet technology will have a servlet context, doesn't related to Spring.
Servlet-context started when a Servlet application is deployed. Servlet Context holds all the configurations.
On the other hand, ApplicationContext is a Spring tech; i.e., it's a container to hold Spring beans.
So, for your questions, those are different.
BTW, spring-servlet it's a single front servlet handles all the HTTP requests of a particular web application. This front servlet has all the controls over incoming requests.
what is the flow diagram of interactions between tomcat web server/servlet container and dispatcher servlet . tomcat servlet container is separate from spring IOC container or applicationcontext ?
Tomcat is a web server. It "knows" how to deal with web applications according to the web applications specification.
This specification defines means of servlets declaration, their order, etc. It also defines additional notions like filters, listeners, etc. This specification has nothing to do with spring. Basically, you can use tomcat to host the application with servlets, filters, listeners without spring dependencies, so you won't even have an application context.
With this in mind, Spring MVC (to which the Dispatcher Servlet actually belongs) is just a third-party among many others from the Tomcat standpoint.
DispatcherServlet is an ordinary servlet that the spring team has developed. It is an entry point to all spring infrastructure in web applications managed by a web server, it's a "glue" that acts as a "driver" - it loads the application context (all the beans), handles all the requests coming to the controllers, etc.
I have moderate understanding of Spring Framework, and in various books I read that Spring acts as a container.
Q1) What does it mean to say that Spring is a container?
Q2) Does spring as a container provide services like transactional, connection pooling etc.
Q3) what difference are in containers spring container vs web container -> It might be totally irrelevant comparsion, but if anyone can help me get this understand, really appreciate.
In spring: Spring container contains beans (Java objects that are subject to dependency-injection). It provides the space for residing these beans and maintains the life-cycle of the Java beans.
this is referred as Spring IOC container because of it provides Spring Inversion of Control.
You can learn more about Spring IOC container at http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html
Web Container, Specially Servlet containers contain servlets, filters, listeners, etc. and manages their state and lifecycle.That is the place where you can deploy your java based web applications.(any java web app e.g:- JSP/Servlet based web app, spring based web app etc...)
So keep it remember that these are two different things.
I am currently working on a set of REST resources that are deployed in a Tomcat servlet container. I have been using the Camel REST dsl (kickstarted by Spring) and it works very well. Now, I would like to get access to some parameters specified in the container's context.xml but havn't been able to figure out how to do that as I do not have access to the Servlet context in my route builder. Any suggestions?
Even though you are hosting your Spring-app on Tomcat, Camel is using a separate, internally loaded web server implementation for it's REST endpoints, e.g. Restlet or Spark-rest (for more infos check here). For that reason your Camel route is ignorant and entirely disconnected to your Tomcat let alone its Servlets contexts.
looks to me you need tomcat or some other servlet engine for the web part.
what about data access part using hibernate and jms? Thanks.
No, you don't need an application server, you can see Spring as a proprietary, modular application server implementation / adapter. But you still need an a servlet container.
Data access part: you can use hibernate and some standalone connection pool
jms: Spring is not a JMS provider, but it nicely integrates POJOs with any JMS provider
Spring also has comprehensive transactions support
Finally you have jmx and aop support built-in and easy integration with bean validation, jpa, web services, rmi, jci, task scheduling, caching...
As you can see you can either use certified application server and Java EE stack or built on top of Tomcat and pick Spring modules you need. Sometimes Spring uses standard Java EE APIs (like JPA), more often it builts its own.