I am trying to understand Jetty.
Tell me please:
When is it better to use Servlets and when Handlers?
Can I use Connectors with Servlets for "thread-per-request model"?
In Jetty, Handlers handle requests that are coming through Connectors. One of the Handlers, specifically ServletHandler, allows Jetty to (mostly) support servlets. Servlet is a portable Java EE concept, so you can design your application in a more portable way if you use servlets in Jetty. On the other hand, they are likely to bring some overhead, so you might want to implement a Handler directly that would handle requests coming via Connectors.
If you are using servlets in Jetty, you can rely on the servlet security model, on the session support, etc. If this is unnecessary for your application, you might be better off implementing a very simple handler.
One interesting observation I found when played with it. I had a jetty-based application(dropwizard.io) and here I was planning to add handler after actual(there was special use-case for it)
server.start()
using org.eclipse.jetty.servlet.ServletContextHandler.insertHandler(HandlerWrapper handler) it just throws illegalStateException: STARTED if the server already started. Because of:
public void setHandler(Handler handler) {
if (isStarted())
throw new IllegalStateException(STARTED);
//..
But in case of org.eclipse.jetty.servlet.ServletContextHandler.addServlet(ServletHolder servlet,String pathSpec) it will add your servlet to existing servlet collection and everything will work.
Related
I have couple of questions.
What is the main difference between WebAppContext and ServletContextHandler.
My application has pages and restful service. Can ServletContextHandler be intended to use for Rest services than WebAppContext? (That means, is ServletContextHandler better to handler servlets to manage calls/requests to restful services?. But I have encountered running JSP s with ServletContextHandler) What are the advantages and disadvantages?
Is there any drawbacks if I use two contexts: WebAppContext to load JSP and other static contents(like js, css) and ServletContextHandler to handle requests to restful requests ?
WebAppContext represents a traditional webapp like a war file, the ServletContextHandler maps to a servlet
If your rest services are backed by a servlet, then of course, a ServletContextHandler could be used to mound that rest service. JSP support is a servlet so you can just run it that way. The only real advantage or disadvantage is a WebappContext brings all the automatic deployment and wiring of things up with the web.xml...if you don't need that then don't use it and wire things up yourself.
Not really, but if you are just using the WebappContext for jsp and static resources I would just use the JSPServlet and a DefaultServlet for the static content.
There are lots of different ways to do what you are looking to do. If you are comfortable dealing with servlet instances directly then just avoid the whole concept of the WebAppContext entirely. One other thing to be aware of, the WebappContext also provides classloader isolation for the deployed webapp, so that may or may not be a factor or something you are interested in.
I have a JSF2 controller/bean/view that is invoked the standard JSF way. Now I have a need to access this logic from a legacy part of the app that knows servlets and URL params only.
I thought of creating a "loader.xhtm" view that bridges the gap between non-jsf requester and the jsf part of the app. Loader will take URL params and make the necessary JSF post to backing bean. etc. One downside of this approach is - it's one extra client/server hop, a programmatic redirect. However it is simple to implement.
But is there a more clever way? I found someone who created servlet filter and explicitly created a FacesContext, started the lifecycle and the ViewRoot. Conceptually I see what is being done, but I don't know how to put it into practice. Has anyone interfaced with JSF lifecycle directly from a servlet? Do you have a sample?
Another mention of this concept.
What happen even many request comes through one spring controller?
Does Spring pipe it?
How about add #Transactinal on controller?
Is it have a benefit to use on controller layer?
Basically you are asking 2 questions
How are multiple, concurrent, requests handled by a handler.
Should we add #Transactional to a handler.
Multiple concurrent requests are handled concurrently. Each thread has its own callstack and location in memory and doesn't share a thing. In general no problem (used Spring MVC in very high concurrent applications) unless you start, for some reason, sharing state in your singleton, or forget to clean-up ThreadLocals.
Adding #Transactional is something bad, IMHO. The transactional layer is NOT your web but your service layer. So don't add transactions to your web but add them to your service layer.
I'm developing servlets and register them into my OSGI container thanks to HttpService.
My goal is to secure all the servlets registered in my OSGI container.
I saw that I can register my Servlet with an HttpContext with my own handleSecurity method implementation to process my security.
But I'm thinking to the case where a bundle registers a servlet with the default HttpContext (with implies no security).
So my question is, is there a way to force the security of all the servlets deployed in my OSGI container once for all?
I'm going to use the Service hook feature (OSGI 4.3) in order to override the behaviour of HttpService.registerServlet. In my hook I'll force the usage of my HttContext implementation.
With this solution, any bundle that register a servlet with the HttpService will be secured by my HttpContext implementation.
The short answer is No for using the HttpService.
The longer answer, you might achieve something like this if you use the whiteboard-extender which isn't available per OSGi spec yet, but felix and pax-web do provide it.
When using the whiteboard-extender you're able to register your servlet in combination with a reference to a HttpContext (as property). Of course this HttpContext would also need to be a "customized" one but you only need to register it once and are able to reference it from your Servlets.
This is probably the closest you get to your question.
If you use the Apache Felix whiteboard extender you can register a Servlet Filter, this is a much better way to handle security since it is easy to support different strategies. The intention is that Filters and whiteboard will be supported in the next update of the Http Service: https://github.com/osgi/design/tree/master/rfcs/rfc0189
You could use hooks as suggested, but please don't. Hooks were intended for deep middleware, not for application oriented aspects. They create start/stop ordering issues, they make the system more opaque for debugging tools, in short they make your system much more complex. If you start using hooks for these purposes you will find many more use cases and they will start to interact. Stay away from them except for very core system middleware.
This question already has answers here:
How do servlets work? Instantiation, sessions, shared variables and multithreading
(8 answers)
Closed 6 years ago.
I need to know why the servlets are not thread safe ? And whats the reason that in Struts 2.0 framework controller servlet is thread safe ?
I need to know why the servlets are not thread safe ?
Servlet instances are inherently not thread safe because of the multi threaded nature of the Java programming language in general. The Java Virtual Machine supports executing the same code by multiple threads. This is a great performance benefit on machines which have multiple processors. This also allows the same code to be executed by multiple concurrent users without blocking each other.
Imagine a server with 4 processors wherein a normal servlet can handle 1000 requests per second. If that servlet were threadsafe, then the web application would act like as if it runs on a server with 1 processor wherein the servlet can handle only 250 requests per second (okay, it's not exactly like that, but you got the idea).
If you encounter threadsafety issues when using servlets, then it is your fault, not Java's nor Servlet's fault. You'd need to fix the servlet code as such that request or session scoped data is never assigned as an instance variable of the servlet. For an in-depth explanation, see also How do servlets work? Instantiation, sessions, shared variables and multithreading.
And whats the reason that in Struts 2.0 framework controller servlet is thread safe ?
It is not thread safe. You're confusing the Struts dispatcher servlet filter with Struts actions. The struts actions are re-created on every single request. So every single request has its own instance of the request scoped Struts action. The Struts dispatcher servlet filter does not store them as its own instance variable. Instead, it stores it as an attribute of the HttpServletRequest.
Servlets are normal java classes and thus are NOT Thread Safe.
But that said, Java classes are Thread safe if you do not have instance variables. Only instance variables need to synchronize. (Instance variable are variables declared in the class and not in within its methods.
Variables declared in the methods are thread safe as each thread creates it own Program Stack and function variables are allocated in the stack. This means that variable in a methods are created for each thread, hence does not have any thread sync issues associated.
Method variables are thread-safe, class variables are not.
There is a single instance of a servlet per servlet mapping; all instance properties are shared between all requests. Access to those properties must take that in to account.
Struts 2 actions (not "controller servlet", they're neither servlets nor controllers) are instantiated per-request. Action properties will be accessed only by a single request's thread.
Servlets are normally multi-threaded.
Servlet containers usually manage concurrent requests by creating a new Java thread for each request. The new thread is given an object reference to the requested servlet, which issues the response through the same thread. This is why it is important to design for concurrency when you write a servlet, because multiple requests may be handled by the same servlet instance.
The way that servlet containers handle servlet requests is implementation dependent; they may use a single servlet, they may use servlet pooling, it depends on the vendor's system architecture.
Struts 2 Action objects are instantiated for each request, so there are no thread-safety issues.
Servlet is not thread safe but we can make it as a thread safe by implementing that servlet class to SingleThreadModel
like the given below class definition but again the performance problem will be there so better option would be use synchronized portion
public class SurveyServlet extends HttpServlet
implements SingleThreadModel
{
servlet code here..
...
}
Servlet is not thread-safe by itself. You can make it thread-safe by making the service method synchronized.
you need to implement SingleThreadInterface to make it thread-safe.