I am using the JAX-WS "WebService" annotation on a class to expose its "WebMethod"s as a web service. The class is denoted as the servlet class handling calls to "/MyService".
As essentially a servlet, I would expect an instance of this class to be created once and to basically be a singleton. I have code in the constructor of this class to create an EntityManagerFactory for assignment to a member variable. What I'm seeing is that the constructor is being called for every client request to the web service. This is not good.
Does anyone know what's going on here? Does anyone understand what I'm trying to ask? :)
Thanks.
As essentially a servlet, I would expect an instance of this class to be created once and to basically be a singleton.
It's up to container. You cannot rely on it.
Create a real singleton -- a simple Java class -- which does all the heavy lifting, and call it from the servlet.
Your topic mentions a SLSB, which I assume is "Stateless Session Bean". In Java EE 5 you can create web services either from a Stateless Session Bean, or you can annotate a class and the runtime will publish it as a webservice when deployed in a compliant web container.
In either case, neither of these are Servlets per se, and don't follow a Servlet lifecycle.
Related
According to the java docs, it says that If SingleThreadModel is used there are two ways a servlet instance will be created and used
1. Create one servlet instance and make the service() method synchronized and thus allow only one thread to execute the service method.
2. Create a pool of servlets and serve the request by using one servlet instance from the pool for each request.
THe question which I want to ask is I have also read a new Servlet instance is created and destroyed for every request. Now which one is correct
Here's what the spec says (version 3.0, section 2.2):
For a servlet not hosted in a distributed environment (the default), the servlet container must use only one instance per servlet declaration. However, for a servlet implementing the SingleThreadModel interface, the servlet container may instantiate multiple instances to handle a heavy request load and serialize requests to a particular instance.
In the case where a servlet was deployed as part of an application marked in the deployment descriptor as distributable, a container may have only one instance per servlet declaration per Java Virtual Machine (JVMTM)1. However, if the servlet in a distributable application implements the SingleThreadModel interface, the container may instantiate multiple instances of that servlet in each JVM of the container.
Note that you should really not use the single thread model. Just make sure your servlet is thread-sae. A servlet is typically stateless, so you don't have anything to do to make it thread-safe.
From the docs for SingleThreadModel:
Ensures that servlets handle only one request at a time
This is in essence a way to make non thread-safe servlet code work. Note that the container is free to choose any of the two implementations to adhere to the spec:
Create a single instance of the servlet and ensure that it handles only one request at a time
Create a pool of servlet instances and hand over a request to an available servlet instance.
I'm far from an expert of the intricacies of Resource Injection, and of indeed DataSources in Java, but I generally understand the process of doing a lookup for a predefined JNDI resource to get a datasource from.
Using Resource Injection as an alternate method, the below syntax works:
#Resource(name="jdbc/Foo")
private javax.sql.DataSource con;
However, I am using this in a servlet and as such wondering, how long this injected connection object's value will exist? Presumably, as it's simply an object within the servlet, it will inject when the servlet is first instantiated and exist for the same duration as the servlet (assuming I don't manually change it). Is this correct? Or does the servlet re-inject the resource everytime the servlet is used?
Thanks
A servlet container only ever creates one instance of your servlet. The IoC container you're using will then instantiate and inject the DataSource, so the value in con will remain the same for the life of your servlet, ie. the life of the application.
As to the underlying connection the DataSource is trying to make will, that's up to your datasource.
it will inject when the servlet is first instantiated and exist for the same duration as the servlet
Correct.
Or does the servlet re-inject the resource everytime the servlet is used?
No, this couldn't be happening because each request is served by a different thread. It wouldn't be good if those threads would modify the fields of the servlet. Request processing methods of the servlet must not modify its fields.
Generally container managed resources are injected using #Resources annotation. And container managed resources live as long as the container is running ( unless your are not manually kill it or any exception happens). Several applications can use the same resource object, provided that they live in the same application server ecosystem (same application server or cluster or server domain). But servlets are managed by your applications and lives within the application's scope as long as your application is running! So in terms of life span, if you compare resources are longer living than servlets.
And yes you are right, if you inject resources to a servlet, the reference of the resource will remain from the creation of the servlet to the end of the servlet's life cycle. The injection is not related with, how you are using the servlet or the resource.
Hope, this answers your question, Thanks!
The new JSR 299 "Contexts and Dependency Injection for Java EE" seems to be based on the concept of "Scope".
The beans are created and associated to one of the supported Scopes: Application, Session (mapped to a HTTP session), Conversation, and Request.
Does it make sense to use CDI if there is no HTTP Session (for example, an Enterprise application that exposes functionality through EJBs remoting) since the Managed Beans are not going to be associated to any Context (since they do not exist)?
Is it even possible to use CDI in such an scenario? Which advantages would it bring to it?
It reminds me of my own question I asked some time ago: How does #SessionScoped work with EJB? Is CDI only for web-tier?
It seems that the idea of 'scope' is relevant only in the case of HTTP Session.
However, I can see a valid use of the #ApplicationScoped scope as a way to implement an application-singleton bean, despite if the request is a HTTP one.
Javadoc says:
The application scope is active:
(...)
during any Java EE web service invocation,
during any remote method invocation of any EJB, during any asynchronous method invocation of any EJB, during any call to an EJB
timeout method and during message delivery to any EJB message-driven
bean,
You can also create your own scopes. CDI is very extensible and can be used in a variety of situations. It's also being used in SE applications where there is neither an HttpSession nor HttpRequest.
Apart from that, CDI is not only for Lifecycle managment, you can use it to do dependency injection thus separating interfaces from their implementations in a very clean way. You can also perform some AOP techniques using interceptors and decorators, or build a very loose-coupled Observer pattern by taking advantage of CDI Events.
I have a webapp on one Glassfish server (front-end) and an EJB 3.1 app (back-end) on another Glassfish server. The webapp communicates with the EJB 3.1 via remote invocation.
I would like to pass context data (user data i.e.) without having to define it as an input parameter of each business operation.
I have one idea, but not sure it will work: use a ThreadLocal to store data, but the ThreadLocal will only be available on one server (meaning JVM) => use the InvocationContext object and create interceptor to add user data to the ContextData Map.
What do you think about it? Any other ideas are more than welcome! ;-)
UPDATE
After first answer, I googled it a little bit and found the annotation #CallerPrincipal.
How can I set this object before the remote invocation?
The container will already handle this so you don't have to code it yourself.
In your EJB, you can access the EJBContext, which has a getCallerPrincipal() method which will give you the callers identity.
I have been working through this tutorial. Halfway though it creates an interface and facades for an EJB. Can anyone tell me when I reference the interface using the #EJB annotation, where does it actually make the link between the interface and the actual enterprise java bean itself.
Thanks for the help.
~ Kyle.
It is AFAIK not mandated by the J2EE specification how this is actually solved or implemented by the application server. The most common solution is that the app server uses its own mapping between bean class names and JNDI names, so that depending on the bean class name, it is bound to a specific JNDI path when deploying the application and the same class name -> JNDI path conversion is used for injecting the EJB reference on the "client side".
It will be done inside the EJB container.
When you add this annotation, you'll actually be telling the IoC container of your application server which implementation of the given EJB you want.