My advice is not getting called for method getPOInvoice method from this method, but if I call it separately then advice is getting called and getPOInvoice and getPOInvoice is declared in same class.
public StreamingOutput getPDFStream(String invoiceId, String versionNumber) throws TugnavException {
final POInvoice poInv = getPOInvoice(invoiceId, versionNumber);
...
}
My advice is:
#AfterReturning(value="execution(* com.tugnav.service.facade.*.get*(..))", returning="doc")
public TugnavBaseDocument setupTimeCreatedString(TugnavBaseDocument doc){
...
}
If I call this method from another class then advice is getting called.
Why is it not getting called internally?
You need to read the documentation about proxies here.
Basically, because of the way proxies are generated, a instance method call within another instance method will not trigger an aspect (or proxy behavior).
Given:
class FooBar {
// advised method
public void foo() {
bar();
}
// would've been advised
public void bar() {
// ... do something
}
}
Say an instance of FooBar was proxied, a call to foo() will trigger the aspect because from outside you have a reference to the proxy object. When you call bar() internally, you have access to this (equivalent to this.bar()) which is a reference to the target instance, the actual object, so there is no added behavior.
There are a few ways to solve this problem, but probably not the way you want. See the answer to this question.
AOP would not normally work this way.
AOP is added as an aspect through Proxies, to compiled class, so it does not have any effect on the internal class invocations.
When it's an outer cal, you are actually referring to some Proxy which intercepts your call and triggers appropriate AOP calls.
When it's internal cal, inside the class, it is a direct call, without any Proxy involved.
As a solution you can do following:
Refactore service you are using, to exclude internal calls
Alter bytecode on Class loading, with your AOP functionality :)
If you want that your advice is called for getPOInvoice method when you are invoking from method getPDFStream(..), both in the same bean, you can't use a proxy-based AOP, like Spring use by default. Instead you should use load time weaving(LTW) with AspectJ.
http://static.springsource.org/spring/docs/3.2.2.RELEASE/spring-framework-reference/html/aop.html#aop-aj-ltw
Related
I need to create a custom classes based on some input. What I have atm is this:
final Class service = ...;
final Method method = ...;
final DynamicType.Unloaded unloadedType = new ByteBuddy()
.subclass(Object.class)
.name(service.getClass().getSimpleName() + "DynamicResolver")
.defineMethod(
endpointName,
resolveReturnType(method),
Modifier.PUBLIC)
.withParameters(parameters)
.intercept(MethodDelegation
.withDefaultConfiguration()
.withBinders(Morph.Binder.install(Morphing.class))
.to(interceptor).andThen(
MethodCall.invoke(method).on(service).withArgument(arguments)
))
.make()
What I am doing here is creating a class with a single method that delegates to provided one. However, the created method and delegate method have a bit different parameters. The created method has one argument more (in parameters). The created method does not take that argument, hence the arguments array with argument indexes (one argument less).
So far it's OK. Now, I need to add additional argument when calling delegation method. For the sake of simplicity of the example, imagine we have to add one more string to delegate call.
As I saw from the documentation, the way to manipulate the arguments is using #Morph. So I did:
public interface Morphing<T> {
T invoke(Object[] args);
}
and my interceptor:
public class Interceptor {
#RuntimeType
public Object invoke(
#Morph final Morphing<Integer> m,
#AllArguments final Object[] args
) {
System.out.println("!!!");
return m.invoke(args);
}
}
Unfortunately, this is not working. When I remove the #Morph argument, the interceptor gets called.
What am I missing here?
EDIT: Is the #Morph used only for subclasses and not when delegating to another instance?
EDIT2: example
Byte Buddy is binding a method of the Object class such that your desired interceptor is no longer triggered. You can add filter(isDeclaredBy(MyInterceptor.class)) after the withDefaultConfiguration() to avoid this. Doing so, you will get an exception that Byte Buddy cannot bind any of your methods.
The reason that #Morph makes the class ineligable is that there is no super method to be called. In your example, you are defining a new method which does not have an original implementation. You'd need to override an existing method to use the annotation.
This question already has answers here:
Same class invoke NOT effective in Spring AOP cglib [duplicate]
(2 answers)
Closed 3 years ago.
I want use java bean validation annotations for parameters of my spring services. Consider following service:
public interface MyService {
void methodA();
void methodB(#NotBlank String param)
}
with implementation:
#Validated
public class MyServiceImpl implements MyService {
#Override
public void methodA() {
String param = "";
methodB(param)
}
#Override
public void methodB(#NotBlank String param) {
// some logic
}
}
Can you tell me how to fire validation and throw constraint exception when passed string is blank? When I call service this way:
#Autowired
MyService myService;
myService.methodB("");
When methodB is called from another class, a constraint exception is thrown as expected.
But when the same methodB ias called form MethodA, no exception is thrown. Why no exception is thrown, if the same method with the same parameter is called?
In addition to the other answers and the fact you are aware of the AOP proxies existance let me just point you to the relevant chapter in Spring documentation which mentiones self-invocation problem with AOP proxies that you've come across:
public class Main {
public static void main(String[] args) {
ProxyFactory factory = new ProxyFactory(new SimplePojo());
factory.addInterface(Pojo.class);
factory.addAdvice(new RetryAdvice());
Pojo pojo = (Pojo) factory.getProxy();
// this is a method call on the proxy!
pojo.foo();
}
}
fun main() {
val factory = ProxyFactory(SimplePojo())
factory.addInterface(Pojo::class.java)
factory.addAdvice(RetryAdvice())
val pojo = factory.proxy as Pojo
// this is a method call on the proxy!
pojo.foo()
}
The key thing to understand here is that the client code inside the main(..) method of the Main class has a reference to the proxy. This means that method calls on that object reference are calls on the proxy. As a result, the proxy can delegate to all of the interceptors (advice) that are relevant to that particular method call. However, once the call has finally reached the target object (the SimplePojo, reference in this case), any method calls that it may make on itself, such as this.bar() or this.foo(), are going to be invoked against the this reference, and not the proxy. This has important implications. It means that self-invocation is not going to result in the advice associated with a method invocation getting a chance to execute.
-- https://docs.spring.io/spring/docs/5.2.3.RELEASE/spring-framework-reference/core.html#aop-understanding-aop-proxies
In the next paragraph two solutions are proposed (or in fact three, but switching to AspectJ in this particular case might turn out cumbersome):
Okay, so what is to be done about this? The best approach (the term, “best,” is used loosely here) is to refactor your code such that the self-invocation does not happen. This does entail some work on your part, but it is the best, least-invasive approach. The next approach is absolutely horrendous, and we hesitate to point it out, precisely because it is so horrendous. You can (painful as it is to us) totally tie the logic within your class to Spring AOP, as the following example shows:
public class SimplePojo implements Pojo {
public void foo() {
// this works, but... gah!
((Pojo) AopContext.currentProxy()).bar();
}
public void bar() {
// some logic...
}
}
class SimplePojo : Pojo {
fun foo() {
// this works, but... gah!
(AopContext.currentProxy() as Pojo).bar()
}
fun bar() {
// some logic...
}
}
This totally couples your code to Spring AOP, and it makes the class itself aware of the fact that it is being used in an AOP context, which flies in the face of AOP. It also requires some additional configuration when the proxy is being created, as the following example shows:
public class Main {
public static void main(String[] args) {
ProxyFactory factory = new ProxyFactory(new SimplePojo());
factory.addInterface(Pojo.class);
factory.addAdvice(new RetryAdvice());
factory.setExposeProxy(true);
Pojo pojo = (Pojo) factory.getProxy();
// this is a method call on the proxy!
pojo.foo();
}
}
fun main() {
val factory = ProxyFactory(SimplePojo())
factory.addInterface(Pojo::class.java)
factory.addAdvice(RetryAdvice())
factory.isExposeProxy = true
val pojo = factory.proxy as Pojo
// this is a method call on the proxy!
pojo.foo()
}
Finally, it must be noted that AspectJ does not have this self-invocation issue because it is not a proxy-based AOP framework.
-- https://docs.spring.io/spring/docs/5.2.3.RELEASE/spring-framework-reference/core.html#aop-understanding-aop-proxies
Spring validation is invoked when a managed bean calls another managed bean.
However, spring context is unaware of calls between methods within the same bean, ie intrabean rather than interbean, so #Validation has no influence.
One simple solution is to move the wrapper method out of the class into a utility method, something like:
public static void methodA(MyService myService) {
myService.methodB("");
}
There is no annotation #Validation in Spring. I think you meant #Validated.
To validate parameters, Spring creates kind of proxy using CGLIB. This is mechanism similar to what Spring uses for transactions. Spring adds this code only if your class MyServiceImpl is called from another class, i.e. where a control flow crosses the border between two classes. When you call your methodB from another class, Spring adds validation code. When you call it from the same class, Spring adds no code and thus no validation is triggered.
I have my authentication class where i want to fetch something which require EntityManager which is present in a class. That class only works after authentication is done.
I have tried importing bean of that class in authentication class. Then i tried initializing EntityManager in Authentication class. But i didn't the things i wanted from that class. I looked over AOP and come to know about #Around annotation, which require to have "ProceedingJoinPoint joinPoint" in method argument. But as i have implemented Filter class in Authentication class, i can't override my filter class. Can we have some work around for that?
In AOP, The method you need to annotate with #Around is not the method you want to wrap, but the method you want to be called 'around' it (the aspect method). The joinPoint parameter in the method is there to represent your 'wrapped' method, and there to tell it when to execute it.
I think an example will be best to understand.
Consider this simple AOP method that prints 'before' and 'after' the execution:
This is the aspect class
#Around("execution(* testWrappedMethod(..))")
public void aopSample(ProceedingJoinPoint joinPoint) {
System.out.println("before");
joinPoint.proceed();// this will make the wrapped method execute
System.out.println("after");
}
and this is the 'wrapped' method:
public void testWrappedMethod(String whatever) {
System.out.println("inside");
}
The output of the execution of testWrappedMethod will be:
before
inside
after
I have this code:
How could I make the use of the getService() method mandatory in the getAll methode, that means if I call directly service.findAll() compilation fails ?
Is it possible to create an annotation to prohibit the directly use of the field ?
#Named
#Profile("default")
public class AlfrescoVersionServiceImpl {
#Inject
//Request Scope service
private AlfrescoService service;
#Resource
private WebServiceContext webServiceContext;
public List<Fichier> getAll(){
return getService().findAll();
}
public AlfrescoService getService(){
service.setEnPointAdress("--");
if(webServiceContext.isUserInRole(role)){
service.setRole("--");
}
}
}
Thank you in advance for your reply.
You could move the service field into a super class, and declare it private to prevent the subclass from accessing it, while leaving getService() protected.
Alternatively, you could configure the AlfrescoService in a #Produces method, so everyone asking for an AlfrescoService to be injected gets an instance that has already been configured.
Inside findAll() you could examine the current stack trace using Thread.getStackTrace() and make sure the previous StackTraceElement is the class and method you want:
public List<Fichier> findAll() {
StackTraceElement[] stack = Thread.getStackTrace();
if(stack.length > 1) {
// stack[0] is ourselves, stack[1] is who called us
if(stack[1].getClassName().equals(...) && stack[1].getMethodName().equals(...) {
// execute the business logic
}
}
}
Just beware of a few things:
This is a runtime check, so methods calling findAll() won't be flagged at compile time.
According to the JavaDocs, the getStackTrace() method may not be permitted by some SecurityManagers, and some VMs may omit stack frames in rare cases.
This may not be performant if you do this for every request.
If the service is a Spring bean, you may have to deal with sorting through proxy classes to find the real caller (i.e. the previous stack frame before findAll() may be a spring generated proxy class).
An alternative would be to use an Aspect Oriented framework. For example, Spring AOP has the ControlFlowPointcut that can be used to match caller name, class, and package. This approach is a little more declarative,
but relies on an extra library.
So I am writing a class which I want to follow the best practices and be testable.
I have a new object to be created inside it. So, I am following the factory pattern to achieve it.
public class Apple {
// factory object injected in class
private SeedFactory seedFactory;
// Method to be tested
public void myMethod(String property1, int property2, String depends) {
// Just to set the necessary parameter
seedFactory = new SeedFactory(property1, property2);
// Factory pattern intact. Instance generation depends on only one parameter
SeedFactory result = seedFactory.getInstance(depends);
}
}
EDIT: Adding code for factory as well.
public class SeedFactory{
String property1;
int property2;
SeedFactory(property1,property2){
this.property1 = property1;
this.property2 = property2;
}
SeedFactory getInstance(int depends){
if(depends == 1)
{ // do stuff }
else{ // do stuff and return instance }
Now, before I actually create the new object, I have to make sure that I set two properties for the new instance to be generated, which are needed to be present irrespective of the type of instance generated by the factory. depends is the actual parameter which tells the factory what instance to return.
Now, as far as testability of this code is concerned, I can user PowerMockito to mock the factory object using whenNew but using PowerMockito is not a choice. I have to make it testable without it.
Also, I have tried to encapsulate the new call within a one line function and then use spy. But I want to avoid using spy, since it is not considered a good practice, in context of where this code is being used as a whole.
So my question is, Is there any way, without using PowerMockito, to re-write this class so that it can be unit tested properly?
If the instance to be generated needed only one parameter, then it would have been trivial. However, I don't want to pass more than one parameter to getInstance().
SeedFactory is not Apple's dependancy but your method depends on SeedFactory which has "uses" relationship. So to define proper relation i would suggest you use "USES" relation as below:
public void myMethod(SeedFactory seedFactory, String depends){ // Method to be tested
Now you could mock SeedFactory and can unit test it appropriately.
I think you're doing something wrong.
If SeedFactory isn't an Apple's dependency but an internal concern, hence you don't need to mock a SeedFactory to test Apple. You should test the public API provided by Apple only.
If SeedFactory is an Apple's dependency, so it definitely should be injected.