I have an asynchronous method in my EJB singleton that's called from another method in the same class. I already know that I can't call the asynchronous method directly, I have to obtain an EJB proxy. The problem is, I don't want the asynchronous method to be visible outside the class; but when I make it private, it's not executed asynchronously. (I'm using Glassfish v3.)
The javadocs don't say anything about the required access level. So should this be considered a bug in Glassfish?
method annotation cannot be used in private methods. When Glassfish is compiling your EJB it will basically convert your annotation into a piece of code that will surround your code in a proxy. If your method is private it will bypass the proxy Glassfish created... So, in your case I suggest to create a new EJB with your asynchronous method in inject it in your current EJB
That's a very interesting bit of feedback. I can see the value in what you are trying to do. Try marking your bean as an #LocalBean and annotating your #Asynchronous method as protected.
As #LocalBean support is basically done via subclassing the bean class (dynamically or statically), it isn't really possible for the container to override the private method. But I can certainly see your use case. If the protected method approach doesn't work, we can probably add this as an enhancement to EJB.next.
Would still give access to other beans in the same package, but it's at least less public. I've often wished Java had an 'only subclasses' scope. I've almost never used protected and thought, "great, now everyone in my package can access this too."
Related
In a Jersey class, Which is more appropriate of the two:
On an instance variable
#PathParam("service-id")
private String serviceId;
On a method argument
public Response subscribe(#PathParam("service-id") String serviceId){}
I'm using first one only because service-id is required by almost all my methods. However, a colleague of mine had a comment over this approach that ultimately Jersey classes are based on servlets and servlets should not have stateful variables.
I read about this in the JSR-311 java docs
Because injection occurs at object creation time, use of this
annotation on resource class fields and bean properties is only
supported for the default per-request resource class lifecycle.
Resource classes using other lifecycles should only use this
annotation on resource method parameters.
Since in a webapp, my Jersey class is going to follow per-request resource class lifecycle, I feel first approach is safe. Thoughts please :)
It is made safe by virtue of only allowing this annotation in request-scope (so that every request gets its own bean/resource instance and there is no shared state).
I'd probably give each method the full set of parameters, though, even if it is a bit repetitive. Makes it easier to see at a glance what is going on. That's a code style issue, though, and people can have different opinions here.
This is only coding styles issues since this code has exactly the same result.
I also prefer to define it in the method, instead of defining it in the instance.
Whatever, once compiled, the result is the same! :)
I'd like to know what the expected lifecycle behavior is for a class that responds to REST requests.
I have a class that's derived from javax.ws.rs.core.Application that identifies another class for responding to requests.
In that other class, it is annotated with #Path("foo") and methods within this class are annotated with #Path("bar"). When a request is made to foo/bar, I can see that the constructor is executed, then the PostConstruct method is properly called. After the method returns a response to the client, I can see that PreDestroy is called and then the class is squashed. On the next request, the process repeats.
Is this the correct behavior? Or is there a way that this class can remain in memory so that it doesn't need to go through the constructor and PostConstruct each time a request is made? This method relies on JAXB marshalling and various XSL transformations - I would like to cache the compiled XSLT transformation objects as well as the results of some transformations, but if the class is reinstantiated each time it is called, it makes it impossible for local caching.
This is running with Java 7, Wink, and Tomcat 7. Can someone please let me know if this is the expected behavior, or am I missing something that will just keep this class alive?
Thanks.
By JAX-RS specification, the Resources (the classes annotated with #Path) are created per request.
There are several ways to override this behavior.
The simplest way that can be used according to the JAX-RS specification, is to create a resource instance yourself (you are responsible to call the PostConstruct, not sure when and how you call to PostDestroy in this case) and return it using javax.ws.rs.core.Application.getSingletons()
Alternately, you can put #org.apache.wink.common.annotations.Scope(ScopeType.SINGLETON) annotation on your resource.
If you use Spring, Wink has a neat Spring integration module, so the Spring's lifecycle will be used. See http://incubator.apache.org/wink/1.0/html/5.5%20Spring%20Integration.html
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.
I'm in the situation where I need to create a cache to store certains values which need to be updated from the database. Since this cache needs to be singular, some sort of singleton implementation seems appropriate.
The problem is that this cache also needs access to the database via an EJB, which can't be injected since the cache exists outside of context (and yes, I'm looking forward to the #singleton annotation in EJB3.1).
The obvious solution is to pass the EJB into the cache as a parameter, but passing EJBs outside of context feels wrong, though I can't say why. Is it accepted practice?
Do note that you are normally not passing the EJB itself "outside of context". What you are typically passing around is a 'stub'. This stub can be passed around as any other normal object reference. Any calls on it will redirect back to an actual bean instance in the EJB container.
So if you have a cache in say the web module, have a backing bean injected with an EJB (or do a JNDI lookup) and pass that reference to a (static) cache, then I don't see a fundamental problem with that.
For all intends and purposes, the #Singleton annotation was indeed made for something like this. Hope you'll able to use it soon ;)
The main advantage of EJB is inside container. If you pass it outside you loose all the advantages which a container provide. Why don't you create a method in EJB that return the data you need. And the you can do, for example, JNDI lookup and call that method. In this way EJB will stay in the container and you will get your data.
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.