Now, with EJB 3.1, we can find the javax.ejb.Singleton annocation that can ensure that this bean is going to be singleton.
Is there a way that i can ensure singleton using stateless beans in EJB 3.0 with some modifications in my code (use of the keyword static, or other way to do that....)
If you're able to limit your #Stateless bean pool size to exactly 1, then you can get pretty close to an #Singleton.
The effect would be like having an #Singleton that uses #Lock(WRITE) for all calls (i.e. no concurrency) and does not eagerly startup via #Startup (it will start on first access).
You might still be able to get the effect of #Startup if your platform has the option to eagerly fill #Stateless bean pools.
Is there a way that I can ensure singleton using stateless beans in EJB 3.0 with some modifications in my code (use of the keyword static, or other way to do that....)
No, nothing standard. Your container might provide some specific extensions though (e.g. JBoss has a proprietary #Service annotation).
Related
I have few beans which needs to be initialized either parallely or eagerly and to do this while reading the docs of micronaut, I noticed #Parallel annotation which can be used to initialize beans parallely and I came across #Context annotation which I am not able to understand clearly.
As for as my understanding is concerned, #Parallel annotation will shutdown the application if any of the beans executing simultaneously fails whereas #Context will not even startup the application if there is any failure.
I just wanted to check if this correct? Also, if I want to do eager initialization of bean rather than on-demand which annotation is the best one to use?
Any help appreciated, thanks in advance!
When you annotate a bean using the Context annotation, it simply means that the bean gets initialised earlier and eagerly (with the Application Context) than beans annotated with e.g. Singleton or Prototype.
Context scope indicates that the bean will be created at the same time as the ApplicationContext (eager initialisation)
With these annotations you define the scope of your bean within the application context.
Parallel does not define a bean scope, but as you found out yourself behaves accordingly to Context.
As a rule of thumb: If you have beans that need to start early, with the application context, annotate them using #Context.
If you have a singleton bean with a slow startup path declare it with #Singleton and #Parallel.
This is how I understud the documentation.
I wonder if it's possible to get an instance of the JAX-RS Application a resource is attached on. Ideally a way that isn't dependent to a specific implementation. For example using dependency injection...
Thanks very much for your help,
Thierry
As stated in The Spec
5.2.1 Application
The instance of the application-supplied Application subclass can be injected into a class field or method parameter using the #Context annotation. Access to the Application subclass instance allows configuration information to be centralized in that class. Note that this cannot be injected into the Application subclass itself since this would create a circular dependency.
but from I've experienced, it will most likely not be the actual instance, but a proxy. Also if you're looking to alter anything on it, I'm not sure it's possible. It might be read-only.
I wonder if the init method of a HttpServlet is called after deserialization.
I don't know if any container ever serializes a servlet but it implements the Serializable interface so there is a possibility to do that.
The JavaDoc for the init method points out: "Called by the servlet container to indicate to a servlet that the servlet is being placed into service."
Is a deserialization equals "placed into service" ?
While I have never actually dealt with a container that would swap out a servlet by serializing it, and I honestly can't really imagine when a modern container would do this, but I have always understood that init() is called exactly once for the servlet in its lifecycle, so, it would not be called again on deserialization. As with anything Serializable you would need to write special handling by implementing readFields().
I have a multi-module project where the EJB BarService in project bar refers to a FooService EJB in foo project. The #EJB annotation is use to inject the EJB.
#EJB
private FooService fooService;
I'm using IntellijIDEA 11, and it complains with
'Ambiguous EJB reference "beanName" or more precise "beanInterface" should be specified'.
This error is only showing up for EJB references in a different module. If I use the beanName as suggested, the error goes away. However I would prefer not to use it, since it would be hard to refactor the component name as it is a string.
Is this a bug in IDEA, or am I trying to do something wrong here?
(Noticed this and this asking the exact same question in the JetBrains forums, but there are no replies sadly).
The javadoc for javax.ejb.EJB is somewhat unclear on this point:
If no explicit linking information is provided and there is only one
session bean within the same application that exposes the matching
client view type, by default the EJB dependency resolves to that
session bean.
It's debatable whether application in this context means "EJB module" or "EAR", so I don't necessarily think IDEA is to blame. I'm not familiar with other vendors, but at least WebSphere Application Server will attempt to disambiguate within the client EJB/WAR module before considering all EJBs in all modules in the EAR.
Simple question... I want to use Ninject Interceptors to take care of my NFRs, however alot of my classes require arguments in the constructors. I read that they are looking at allowing constructors with arguments but currently I get an error:
Can not instantiate proxy of class: myClass
Could not find a parameterless constructor.
Parameter name: constructorArguments
I am using version 2.2.1 I think, noticed there is a tagged 2.3 version on the extensions site, but will any of this solve my problems? if not is there any way around this?
2.3 adds support for Interface proxies. This means it will solve the problem for all types that are resolved by interface. It's also planned to add support for classes without default constructor.
But be aware that 2.3 is work in progress. While there aren't any known new problems it is not tested yet against real applications as 2.2 is and interface changes of new stuff can still change. Also InRequestScope support for XML and Conventions has temporarily been disabled.