I have a cache of objects (not the HTTP session attributes) and I want to be able to get an object from this cache when a Hessian request comes in and have Hessian execute the call on this object instead of the servlet.
I can control the class that the request is executed on by setting the service-class and api-class init parameters on the HessianServlet. However, it is performing the instantiation of objects itself and it does not look like I can control this.
I've tried to override the execute() method of HessianServlet and calling setService() or setObject() but it does not use the object I've passed in. Instead it seems to instantiate its own.
A simple hack is create a service class that has the same interface on your object, which delegates to an instance of your object it fetches to the pool, expose this service through Hessian.
Related
I am injecting the HttpServletRequest class into a class with the #Service annotation passing the instance of the HttpServletRequest class to a utility class (AuthorizationUtils) to get the authorization header. Is there any risk in this, such as my AuthorizationUtils trying to call the method below and my service class or HttpServletRequest class already being destroyed?
request.getHeader("Authorization")
I would avoid doing that (for architectural reasons), but no, there is no risk.
What would be incorrect would be to pass the request to a separate thread (or an async method, which is executed in a separate thread). Not because the class would be "destroyed" (that doesn't exist), but because the specification says:
Each request object is valid only within the scope of a servlet’s service method. [...] Containers commonly recycle request objects in order to avoid the performance overhead of request object creation. The developer must be aware that maintaining references to request objects for which startAsync has not been called outside the scope described above is not recommended as it may have indeterminate results.
If your service is synchronous, then the service() method of the servlet hasn't returned yet when your service method is executed, so that's fine.
I've got a large Java-based API and for security reasons I'm trying to divide it into a client-to-application server architecture. I've already determined that there are no so-called "Java Application Servers" (frameworks) extant that can help me here, but if I'm wrong, please point me at one that's not restricted to web-oriented applications. That is, I'm "rolling my own" application server.
The existing API is already accessed via method calls to an instantiated instance of a single "object" that implements what needs to be done.
IIUC (If I understand correctly), I can set up an RMI server that instantiates individual instances of the API object - maybe instantiate a pool of them - and then "hand them" as object instances to inbound RMI calls from clients who ask for an instance. They can then call any methods of that instance, and all the actual processing of those methods happens on the server's side, with any results returned through the RMI mechanism.
So far so good, I think. Now for the tricky part I'd like clarification on, please:
If I've got it right, I further understand that either all the methods and attributes are exposed (via "extends UnicastRemoteObject" or I can restrict the attributes and methods I'd like to have available remotely by creating an intermediary class definition whose methods are all defined in an interface.
Am I correct in understanding that using this approach I can then have my original API as-was, and only need to create this one "encapsulating class" which exposes what needs to be exposed?
And moving to a more advanced design, as instantiation is expensive, I'd like to have a pool of pre-instantiated instances; would I need yet another class that instantiates a bunch of these exposable objects and then "returns" them to a calling client? Or, can I do that somehow within the existing RMI machinery - or within my encapsulating API-Server class itself?
When you extend UnicastRemoteObject (or export a Remote object) and implement an interface that extends Remote, the methods declared in that Remote interface are exposed for remote invocation. When these methods are invoked by a client, the execution of the method takes place on the server. Only data contained in the method result, if any, is exposed to the client.
If you want multiple instances of the remote object, you can bind them in a registry under distinct names, or you can create another remote type that returns instances of your Remote service. Here is a simple sketch:
interface MyService extends Remote {
void doStuff() throws RemoteException;
}
interface MyServiceManager extends Remote {
MyService getService() throws RemoteException;
}
You would then bind a single MyServiceManager instance in an RMI registry so that clients can find it. The MyService instances should not be bound in the registry; anonymous instances will be returned via MyServiceManager. Since these objects are also Remote, only a stub will be returned to the client, and when the client invokes a method on it, the method will be executed on the server.
Is there any point in having a constructor in a Java Web Service class? (There seems to be no consensus in the articles I have found so far.)
I am using Jersey to implement a REST web service that needs to have a non-static common object (a string-processing utility class) made available to various (non-static) methods of the service.
Initializing this common object would typically happen in the constructor of the class, if that were not a web service. But what about now that it is?
If a constructor cannot be used, should I put, in every relevant method, a synchronized block that checks whether the common object is available and, if not, initialize it? Or is there a better approach?
Every web service class does have a constructor. If you don't include one then Java automatically adds the default no-arg constructor for you. You can:
Initialize the utility instance when declaring it's class variable
Manually add the default constructor and initialize the utility
instance in it
Or if your using JEE6 you can inject the utility instance into your
web service
It's just an opinion, but if you want to adhere 100% to REST your web service should be stateless. Initializing common objects in web service method calls implies state so it's not the best idea.*
*this is debatable, as can be seen in comments. However any synchronization and shared object initialization if not necesarry IMO should be a no-no in REST applications.
Contructor certainly is a solution, even better one would be to use dependency injection and inject the object you need to your webservice instance at creation.
Try #PostConstruct annotation. It might help you.
When using Spring AOP to create a proxy for a class using NameMatchMethodPointcutAdvisor and BeanNameAutoProxyCreator does this essentially proxy every call to the object, but only apply the advice to the matched methods, or somehow create a Proxied object that only has those methods and uses the normal object for the calls that are supposed to be intercepted?
The way, I think I understand it is that it does proxy every call to the object but then only calls the Advisor on the methods that match - but I can't find a good example/post to confirm this.
Depends on the technique used. (It is configurable by an attribute proxy-target-class in your aop config)
JDK dynamic proxies are proxies by interface - each methods of the interface goes through the proxy, as you said, and if it matches happens to be an "advised" method, the advisor is applied. Otherwise it is delegated to the original object
CGLIB proxies are effectively subclasses defined at runtime of your concrete classes. I can't be sure in this, but I assume only the "advised" methods are overridden, the rest retain the definition of the superclass.
However, no matter which mechanism is used:
it isn't your concern how exactly are the proxies implemented
this doesn't impact performance in a significant way - Debunking myths: proxies impact performance by the Spring team about proxy performance myths
or somehow create a Proxied object that only has those methods and uses the normal object for the calls that are supposed to be intercepted?
How would this actually work? When a class has a reference to the class that is being proxied, it only has one reference to it. It either has to invoke a proxy class or a non-proxied class. Spring can't know which methods you are calling and therefore can't give you one type if you need to call the advised method and another type if you're not.
I am learning Servlets and JSP. I am wondering about the "doGet" and other methods that may be overidden. The "doGet" takes 2 params - HTTPServletRequest request, and HTTPServletResponse response. This is my question: The request and response objects are used within the method body but I do not see any object creation e.g. request = new HTTPServletRequest. Are these objects created elsewhere e.g. in the superclass? This is just a Java question really as I often wonder about this with Applets also, i.e. the Graphics g object is passed to the "paint" method but I don't see it's creation anywhere?
GF
In the two examples you gave, servlets and applets, the code is running inside of a container. Tomcat is the container for servlets and that means that the container provides certain functionality. In this case the container will create the request and response objects and pass it to your servlet for you.
If you write a plain Java program that runs by itself, then you are responsible for creating all objects.
Generally, in any programming language, when a method is called with instances of an object (or any parameter for that matter), yes, those objects are created somewhere.
For the most part, you don't have to worry about the where, just that they are when dealing with them inside of your functions.
Getting back to your question though, while there might be certain situations that an object was created through non-traditional means (depending on the technology stack), you can be assured that more often than not, if you have a reference to an object passed to you in a method you wrote, then it was created using traditonal means somewhere in the call stack (or another, if you have multiple threads).
In the case of Java, this would mean that someone called new ... at some point, and made it available to the call site of your method in order to pass it in as a parameter.
It's created by the web server (tomcat, for example), and it calling your servlet with this parameters
The objects are created at the call-site. I.e. whoever calls the method is responsible for creating the objects that he/she passed to the method as parameters (unless he passes already existing objects, of course, but those have previously been created somewhere as well).
all methods in servlets are invoked by servlet container such as tomcat