I see here spring boot packages the microservice artifact as jar file . It handles the http web request through module spring-boot-starter-web.
My understanding is spring boot internally does is
Makes the web server up
creates the war file , then host the war file on server.
Then http requests are handled through servlet lying under spring-boot-starter-web
Is my understnading correct ?
Your understanding is almost correct:
Starts a embedded tomcat server
Instructs the tomcat server how to act
HTTP requests are handled by an underlaying DispatcherServlet
spring boot entry point is main method, inside the main method we are calling SpringApplication.run(<#SpringBootApplication annotated class name> ,arguments);
when we invoking main method, SpringApplication class internally start the embedded server, configuratation and deploy the application in server...
here dispatcher servlet registered in servlet context on OnCondtion checking basis, if we are added spring-boot-starter-web then it checking condtion dispatcher-servlet available or not inside the class path if available then it will in registers the dispatcher-servlet in servlet context
Related
I have been using Jersey, Tomcat, and Dropwizard for quite some time. But I am still not able to get what all actions happen from the point a request reaches port 8080 of a server to the point when it hits one of the methods annotated with #Path.
It will be really helpful if someone can help me with all(or a few important) layers in the whole architecture of restful API. For simplicity assume I have an application built with glassfish-jersey and deployed as the fat war using Tomcat.
When Jersey starts up, it will introspect registered resource classes and build a model of all the resources. This model includes the resource classes, the resources methods, and the paths and content-types that map to those resources/resource methods.
Jersey itself runs as a Servlet inside a Servlet container (e.g. Tomcat, Grizzly). The entry point Servlet is the Jersey ServletContainer. So when a request comes in, if the requested URI matches the configured servlet-mapping, the Servlet container will forward the request to the Jersey Servlet. Based on the requested URI and content negotiation, Jersey will go into the model mapping and determine which resource class and method should be called, and then call that method.
As per my understanding when a spring application starts, request goes to dispatcher Servlet and from there it gets dispatched to respective controllers. In spring mvc we define Dispatcher Servlet in web.xml file. I want to know is the process is same for Spring boot application also means application request goes to dispatcher Servlet and from there it gets dispatched to respective controllers.
And if it is where are we defining our dispatcher Servlet in Spring boot application?
yes spring boot uses dispatcher servlet and it is located in DispatcherServlet
fully qualified name of class:
org.springframework.web.servlet.DispatcherServlet
in normal java web application web.xml is the source of declaring main components and structure definition of web application like servlets , filters and so on, in other words it's meta data of our web application that the servlet containers like tomcat uses to know how run the application.
in spring boot as mentioned above, dispatcher servelet is declared inside DispatcherServletAutoConfiguration
fully qualified name of class:
org.springframework.boot.autoconfigure.web.servlet.DispatcherServletAutoConfiguration
Dispatcher Servlet is a part of 'Spring MVC'.
Strictly speaking, Spring boot application doesn't necessarily has to run Spring MVC, although in most of practical cases it does.
So, If spring boot application runs spring mvc there is certainly a DispatcherServlet exists under the hood.
I have seen many examples on how to configure Jetty for HTTPS SSL for Jetty but they all seem to utilize a separate Server class containing a main method for execution. I want to execute my WebServlet as a standard servlet configured via the web.xml file. I currently have:
#WebServlet
public class MonitoringServlet extends WebSocketServlet {
#Override
public void configure(WebSocketServletFactory factory) {
factory.register(MonitoringSocket.class);
}
}
Where would I place my SSL Servlet configuration code? In the configure method of this Servlet? In the init method?
I do understand that in this case there is no need for instantiating a Server object and using .start() and .join
Servlets are just a means of producing a response to a request.
Typically a request can be from HTTP/0.9, HTTP/1.0, HTTP/1.1, or HTTP/2.
Using SSL/TLS for the secure part of the protocol.
Technically speaking, HTTP isn't even required for Servlets to function.
The protocol used to submit the request is outside of the control of the Servlet you are implementing to provide a response.
In Jetty, you'll want:
a Server instance
at least 1 Connector configured for SSL/TLS
at least 1 handler assigned to the Server
Using servlets without all of the baggage of a "web application" (a "web application" typically has a WEB-INF/web.xml, WEB-INF/classes, and WEB-INF/lib/*.jar) this would be a ServletContextHandler
Using servlets with a "web application" this would be a WebAppContext
This setup can come from a configured ${jetty.base} in the jetty-distribution or via embedded-jetty use of Java to build up the server, its connectors, and its handlers.
We have an spring-boot application deployed in embedded jetty server listening on port X. Now I am integrating Apache Camel in this existing application by defining routes. The goal is to move few rest end points to camel routes that will be proxied to some other service. I am unable to understand following
When I use "jetty:http://localhost:Y/myapp" as one of route endpoints. It worked without any error. Does that mean Camel created its own jetty instance ?
When I use "jetty:http://localhost:X/myapp" - it again worked without giving error that address X is in use
I would like to keep control of jetty server configuration as they were and let camel listen to already existing rest end points.
If you can configure a servlet mapping which matches all paths which need to be redirected (for example, paths like foo/* are always redirected), then things are pretty easy. If this doesn't work you, I will try to edit my answer later.
The relevant page from the official docs is here. The interesting example for you is the one using the servlet component, because you already have a servlet container (Jetty) configured and running.
First, need to configure the Camel servlet. It depends on how your existing servlet(s) are configured; for instance, using a web.xml file, add:
<servlet>
<servlet-name>CamelServlet</servlet-name>
<servlet-class>org.apache.camel.component.servlet.CamelHttpTransportServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>CamelServlet</servlet-name>
<url-pattern>/foo/*</url-pattern>
</servlet-mapping>
Or, if you are using spring-boot, you can just register the following bean:
#Bean
public ServletRegistrationBean servletRegistrationBean() {
CamelHttpTransportServlet servlet = new CamelHttpTransportServlet("CamelServlet");
servlet.setServletName();
return new ServletRegistrationBean(servlet,"/foo/*");
}
Anyway, once you have the Camel servlet registered with your Jetty instance, you can use the servlet component, and redirect everything:
from("servlet:foo?matchOnUriPrefix=true")
.to("http4://new.com/foo?bridgeEndpoint=true&throwExceptionOnFailure=false");
http4 is the HTTP4 component, based on Apache HTTPClient 4.x. (you can still use the HTTP component base on HTTPClient 3.x if you want).
matchOnUriPrefix=true will match wildcards
bridgeEndpoint=true means we are acting as a proxy
throwExceptionOnFailure=false means errors returned by the new server will just be relayed to the caller, without being handled by Camel.
A request to http://old.com/foo/some/crazy/path/i/just/made/up should be redirected to http://new.com/foo/some/crazy/path/i/just/made/up (and likely result in a 404 error from the new.com server, which will be simply forwarded to the initial caller).
Camel does not listen to "already existing" endpoints in the way you're expecting; it creates its own using the scheme-indicated component. You've created a Jetty endpoint (i.e. "jetty:..."), so Camel spins up a Camel Jetty component to handle HTTP requests at that endpoint.
If you want to use Camel as a proxy to redirect (which might be more easily accomplished with a network load balancer), then you'd spin up Camel routes to replace the existing endpoints and route them to the new endpoints.
from("jetty:http://oldendpoint.com")
.to("jetty:http://newendpoint.com");
All of our spring cloud microservices make use of Spring REST docs to generate documentation and serve it from /docs/index.html. This works well.
Not so for the config server. I'm running it embedded with #EnableConfigServer. I've moved the config root to /config with spring.cloud.config.server.prefix and can see that it has indeed been relocated both in the config server startup logs and the Eureka metadataMap for the config server (nice bit of integration there).
The documentation index.html is bound into the spring boot jar at the correct /static/docs/index.html location but it is not reachable on the config server's port.
I must be missing something straightforward here. What do I need to do to re-enable /static as a root for static resources in the jar?