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.
Related
Baeldung has this section:
this limits matching to join points where the bean reference is an
instance of the given type, while target limits matching to join
points where the target object is an instance of the given type. The
former works when Spring AOP creates a CGLIB-based proxy, and the
latter is used when a JDK-based proxy is created. Suppose that the
target class implements an interface:
public class FooDao implements BarDao {
...
}
In this case, Spring AOP will use the JDK-based proxy, and we should
use the target PCD because the proxied object will be an instance of
the Proxy class and implement the BarDao interface:
#Pointcut("target(com.baeldung.pointcutadvice.dao.BarDao)")
On the other hand, if FooDao doesn't implement any interface, or the
proxyTargetClass property is set to true, then the proxied object will
be a subclass of FooDao and we can use the this PCD:
#Pointcut("this(com.baeldung.pointcutadvice.dao.FooDao)")
I'm still confuse why this just works with CGLIB proxy and target just works with JDK proxy. Could you help to tell me the different between them?
Actually, the explanation in the tutorial does not make much sense:
Both this(MyInterface) and target(MyInterface) work for JDK proxies, if the bean is declared as a MyInterface type.
Both this(MyClass) and target(MyClass) work for CGLIB proxies, if the bean is declared as a MyClass type.
Just try, and you will see that I am right. In Spring AOP, there is not real difference between this() and target(), because due to its proxy-based nature, it implicitly only supports execution() pointcuts from AspectJ.
In native AspectJ however, you also have other pointcut types such as call(), and there you would see a difference: this() would match the caller's type, while target() would match the callee's type. E.g., if you intercept a method A.a() calling B.b() via pointcut call(B.b()), this() would return an A instance, while target() would return a B instance. Do not worry, if this is difficult to understand for you, because for Spring AOP and execution pointcuts it really does not matter.
The only subtle difference I noticed in Spring AOP is, that for MyInterfaceImpl implements MyInterface, pointcut target(MyInterfaceImpl) would actually match, while this(MyInterfaceImpl) would not. This is because for JDK proxies, the proxy actually extends java.lang.reflect.Proxy, not MyInterfaceImpl. The proxy only delegates to a MyInterfaceImpl instance.
Edit: If you keep in mind that, in contrast to native AspectJ which involves no dynamic proxies, the semantics in Spring AOP are such that
this() relates to the proxy object, while
target() relates to the proxied object (proxy target),
it becomes clear why in this special case for JDK proxies target() matches, but this() does not.
Reference: Spring manual, section "Declaring a pointcut - examples":
this(com.xyz.service.AccountService): Any join point (method execution only in Spring AOP) where the proxy implements the AccountService interface.
target(com.xyz.service.AccountService): Any join point (method execution only in Spring AOP) where the target object implements the AccountService interface.
Only in this case, we are not asking for the interface class (which both the proxy and the target object implement), but for the implementation class itself.
Bottom line: For all intents and purposes, in normal use cases you can use either this() or target() for both JDK and CGLIB proxies. I recommend to stick with target(), because it best matches the implicit execution() semantics of Spring AOP, and usually you are interested in information about the target rather than about the proxy..
I would like to use a JsonConverter<> which has dependency, and that dependency can not be a singleton, instead should be resolve as scoped...
I have to configure my System.Text.JsonConverter in Startup, so I must provide the JsonSerializaionOptions along with my JsonConverter<> instance in Startup. I can live together the JsonConverter<> as singleton, I instantiate myself, but how can I inject its scoped dependencies?
The only horrible thing comes in my mind to have a IServiceProvider property, and some other logic later (middleware?) checks if that property is initialized and initializes it. So in the actual Read and Write methods of the JsonConverter<> can access to the scoped dependency via the IServiceProvider.
This sounds sooo errorprone and smells, once because of timing (what is the actual conversion occurs before the property injection), but my main concern is the concurrency, having this JsonConverter<> a singleton by design, so the very same IServiceProvider instance in the injected property will be used concurrently by all the web app threads...
What am I missing here?
Is having a scoped dependency for a JsonConverter<> smells?
Is there a way to not instantiate the JsonConverter<> in Startup? (yes I know I could instantiate JsonSerializerOptions and do manually the serialization with JsonConverter), but this way I can not use many built in json support of ASP.NET Core
I am trying to convert a Guice inject project to a Java EE project, that is to run on glassfish.
I have a lib project, that defines an interface, Hello, annotated with #Remote. Then I have an impl project that has a bean, HelloBean, annotated with #Stateless, and a single constructor with parameters and #Inject.
Then I have a was project that depends on the lib and it's interface to create a webservice, HelloService, annotated with #WebService, and Hello as a member annotated with #EJB.
This does not seem to work. Since beans must have a no-args constructor, I created HelloBean as a bean, and HelloImpl as a Pojo with a single #Inject constructor, with arguments. I have tried then injecting Hello and HelloImpl into HelloBean with both #Inject, #Resource and #EJB. None seem to work.
If I #Inject Hello or HelloImpl into HelloBean, I get a NPE.
If I #Resource Hello or HelloImpl, I get an Lookup failed for delegate.
If I #EJB HelloImpl, same error. #EJB Hello and I get stackoverflows (understandably).
I do want to use constructor injection, as I feel it's a more correct way of creating classes (they are always valid once constructed). But I don't see how it's possible to combine CDI and EJBs.
How can I get a Pojo with an #Inject constructor into a bean? Or is my plan fundamentally flawed?
A better way is to define a initialize method annotated with #Inject. Any parameters will be injection points and should be supplied via CDI. You can also do this with constructors. Make sure you have WEB-INF/beans.xml as well.
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().
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).