What does the #TimeLimiter annotation exactly?
Example
#TimeLimiter(name = "abc123")
public <T> CompletableFuture<T> execute(Supplier<T> supplier) {
return CompletableFuture.supplyAsync(supplier);
}
Could be equal to:
public <T> CompletableFuture<T> execute(Supplier<T> supplier) {
TimeLimiter timeLimiter = timeLimiterRegistry.timeLimiter("abc123");
ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(3); // This scheduler must somehow exist with the annotation as well right?
return timeLimiter.executeCompletionStage(
scheduler, () -> CompletableFuture.supplyAsync(supplier)).toCompletableFuture();
}
The scheduler required in the non-blocking variant of the code, is that somehow involved in the annotation?
Research
I've mainly read:
Resilience4J's Guide on TimeLimiter
Reflectoring's blog post Implementing Timeouts with Resilience4j
Is there some other place where I can understand what the annotation does?
The annotation is collected by an annotation-processor like in resilience4j-spring the TimeLimiterAspect.
Here Aspect Oriented Programming (AOP) extension AspectJ is used to create an Advice for the time-limiting resilience Aspect around the JointPoint of the annotated method.
You can look at its code, e.g. line 90 to figure out, how the evaluated annotation and method/class meta-information is used to weave (Advice) the TimeLimiter decoration (Aspect) around the annotated method's execution (JointPoint).
Further reading
For an introduction to AOP with AspectJ you can read Baeldung's Intro to AspectJ .
How Resilience4J leverages AOP can be read in official Resilience4J Guides, Spring Boot 2, Getting started with resilience4j-spring-boot2, Annotations:
The Spring Boot2 starter provides annotations and AOP Aspects which are auto-configured.
Related
I've read several articles about the difference between #Service and #Component. Now I understand that #Component is user to annotate an object as an OSGi component and its lifecycle will then be managed by OSGi.
However, what is the need to declare an object as service with #Service is unknown. What happens if you write your business logic in a object that is declared as a component?
I also want to know what does the below statement means:
Components can refer/call (using container injection – #Reference) other services but not components. In other words, a component cannot be injected into another component / service. Only services can be injected into another component.
Question 1:
What is the #Service annotation in Apache Felix?
http://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/scr-annotations.html#service:
The #Service annotation defines whether and which service interfaces
are provided by the component.
You should understand that this is about the OSGi Service concept, not the Declarative Service (DS) concept described with #Component.
Avoid using annotations from Felix SCR (package org.apache.felix.scr.annotations).
http://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/scr-annotations.html :
The annotations itself do not support the new features from R6 or
above. It is suggested to use the official OSGi annotations for
Declarative Services instead.
Use #Component from package org.osgi.service.component.annotations, this annotation replaces both #Component and #Service from Felix.
Question 2
What happens if you write your business logic in
a object that is declared as a component?
Happens to work fine.
Question 3
I also want to know what does the below statement means:
Components can refer/call (using container injection – #Reference) other services but not components. In other words, a component cannot be injected into another component / service. Only services can be injected into another component there.
This is how components share functionality in OSGi. They offer their features as OSGi services. But when OSGi injects the object into the reference, you get your component.
BONUS: Read this article: https://medium.com/adobetech/using-the-osgi-declarative-service-in-aem-6-4-21102f649d54
I am using JBoss application server 6 and using JBoss AOP aspects in my application.
An example of aspect shown below:
public class DBAspect{
public Object accessDBConnection(FieldReadInvocation invocation) {
return dbConnection;
}
public Object accessDBConnection((FieldWriteInvocation invocation) {
throw exception;
}
}
Currently, these advice methods are applied to a private variable in class say DBUsage by binding it with this aspect.
I am migrating to a new application server and it is not supporting JBoss AOP. So, how do I implement this concept.
How can I implement this behavior. Please help.
Applying field get/set pointcuts to private field does not sound like good application or aspect design to me. Maybe refactoring your application would be a better idea. Anyway, in AspectJ you can use get() and set() pointcuts in order to intercept field get/set actions. If you want to access private fields, you might need to use a privileged aspect.
AspectJ quick reference
Privileged aspects
AspectJ pointcut types (incl. get/set)
I just started playing around with OSGi services and have the following situation. I have a project which contains 2 services. Service A requires Service B, so I tried to inject the dependent service using
#Inject
private ServiceB svc;
but the framework wont inject. If I setup the following two methods in Service A
and set these methods as "bind / undbind" in my OSGi componentA.xml the framework calls
these methods and I can use Service B in Service A.
public synchronized void bind(IServiceB service)
{
this.svc = service;
}
public synchronized void unbind(IServiceB service)
{
if (this.svc == service)
{
this.svc = null;
}
}
The question is, why does it not work with #Inject ? Sorry if this is a stupid question, I'm quite new to this whole topic. Many thanks in advance!
It looks like you are using Declarative Services, which does not support field injection or the JSR-330 annotations. Field injection has limited utility in OSGi, where services may be injected or "un-injected" at any time. Method injection is more generally useful because it gives you an opportunity to do something when this happens.
However I do urge you to use the annotations for Declarative Services. This will save you from having to write the component.xml by hand.
In my open jpa class, we have a method like this:
#Action(Action.ACTION_TYPE.CREATE)
public void createRecord(EntityObject fileStatus) {
EntityManager em = getEntityManager();
em.persist(fileStatus);
em.flush();
}
My question is with the #Action usage. I was of the impression that we use Annotations to avoid writing boilerplate code. In this particular method, what would be the boilerplate code that we would avoid by using the annotation? I think the method would look same even without the Annotation.
It's annotation used by IBM Rational Application Developer (RAD) - Related answer on IBM support page.
Annotations can be used for documenting purposes only - in that case they doesn't affect compiled code.
This one is most likely used by RAD to recognize specific JPA manager methods so it can list them in modeling tools there (this last is only mine guess).
We are migrating our App from JBoss Seam to CDI (JEE6), so we are changing some anotations like #In and #Out, there's a lot of information that we have found helpful, but we have some troubles trying to find out how to replace anotations with particular patterns:
For #In anotation
#Name("comprobantes")//context name
...
#In(create=false,value="autenticadoPOJO",required=false)
private UsuarioPOJO autenticadoPOJO;
We can use #Inject from CDI, but how to set the name of the context variable for this case?.
For the #Out anotation
#Out(scope = ScopeType.SESSION, value = "autenticadoPOJO", required = false)
I have read some blogs and they say that I can use #Produces in CDI, how we can set the scope, before or after adding this anotation?
I appreciate any help or any helpful documentation.
I'm afraid there is no such thing like a 1:1 compatibility for #Out.
Technically, #Out in Seam 2 was realized by an interceptor for all method invocations - this turned out to be quite a performance bottleneck.
In CDI, most managed beans are proxied, this makes it technically impossible to implement outjection in the Seam 2 way.
What you can do (well, what you actually have to do) is going through all usages of #Out and replace it individually with some #Producer logic. Have a look at this official example here. In Seam 2, you would have outjected the authenticated user to the session-scope, in CDI a little producer method does (almost) the same.
That should hopefully give you a good start, feel free to ask further questions :)
http://docs.jboss.org/weld/reference/1.0.0/en-US/html/producermethods.html
8.1. Scope of a producer method
The scope of the producer method defaults to #Dependent, and so it will be called every time the container injects this field or any other field that resolves to the same producer method. Thus, there could be multiple instances of the PaymentStrategy object for each user session.
To change this behavior, we can add a #SessionScoped annotation to the method.
#Produces #Preferred #SessionScoped
public PaymentStrategy getPaymentStrategy() {
...
}