I am trying to use AspectJ for logging in a Spring Boot project. The latter has been set up with a controller class that handles the initial request for a particular document through a related REST controller. This controller class is extended by specific classes for each document, which assemble the end product; inheritance was not my idea.
To measure performance I want to log execution time for individual methods by using an #Around advice. However, even when the functions are individually annotated, those in the subclass are not advised. Methods further in the call stack that are not inherited from the initial controller class are not ignored. The relevant subclass methods are public and they are not inherited from the superclass.
Logging the execution time of the controller method is meant to provide the overall duration. Information with respect to subsequent functions is supposed to indicate possible bottlenecks. How can I include the methods declared in the subclass?
Confidentiality precludes sharing specifics, but the relevant aspects of the class structure can be conveyed using generic names:
[
To follow best practices I always intended to implement custom annotations to be used in pointcuts. Nevertheless, initially, I used signature based pointcuts and their combinations. Ignoring package elements of the pointcut declaration:
#Pointcut("execution(public String Controller.*(..)")
public void controllerPointcut() {}
This approach captures the controller methods, as do similar declarations for the reader classes. However such pointcuts are simply ignored in the case of the subclass. Using the + symbol to target child classes does not help. The documentation indicates that inherited or declared methods in a subclass can be targeted by signature. In the specific case this results in an IllegalStateException due to ambiguous mapping, as does the use of a class level annotation, unsurprisingly.
I only need to log two methods in the child classes, so I hoped to target them directly with a common annotation, which I also added to the controller and reader methods. The pattern, excluding package elements is:
#Pointcut("#annotation(LoggableDuration)")
public void readerControllerPointcut() {}
The functions in the latter two are being advised, so the annotation itself is not the problem. Nevertheless, the implementation has been added below. For thoroughness, I used a combined approach as well. The controller methods were targeted with the kind of signature approach shown above and for the rest an annotation was used. The result is the same. The problem seems to be some element of how AspectJ deals with inheritance that I have not been able to discover. However, I did expect that annotating individual methods could possibly allow me to avoid any such considerations.
#Component
#Target(ElementType.METHOD)
#Retention(RetentionPolicy.RUNTIME)
public #interface LoggableDuration {}
Edit: It seems that Spring Boot was not picking up the subclass. Adding the #Component annotation allows AspectJ to advise the desired methods as does a class level custom annotation with ElementType.Type as the #Target value. However, both lead to an IllegalStateException: ambiguous mapping, presumably because of the inheritance of the Rest controllers. I managed to target the subclass methods with execution based pointcuts, which were not ignored. But, this caused the aforementioned exception to appear again.
#GenerateInterface class A {}
#GenerateInterface class B {
void setA(IA a) {}
}
My annotation processor should generate these interfaces:
interface IA {}
interface IB {
void setA(IA a);
}
B compiles fine with correct import statement. IB however, misses the parameter IA a. I use javapoet to generate the interfaces. Code for compying the method parameters:
method.getParameters().forEach(p -> {
ParameterSpec.Builder parameterBuilder = ParameterSpec.builder(
TypeName.get(p.asType()),
p.getSimpleName().toString(),
p.getModifiers().toArray(new Modifier[p.getModifiers().size()]));
p.getAnnotationMirrors().stream()
.map(AnnotationSpec::get)
.forEach(parameterBuilder::addAnnotation);
methodBuilder.addParameter(parameterBuilder.build());
});
method is an ExecutableElement. p.asType() only holds the simple name IA. At this point, IA has possibly not been generated yet, so no fully qualified name is available.
At the moment I generate interfaces one by one for each annotated class. As far as I understand I first of all need a list of all annotated classes and their derived interface names. Then when I encounter a parameter that is of a yet to be generated type, get the fully qualified name from the list above to insert a correct import statement.
Is there a smart way to do this? Can I at least distinguish yet to be compiled types from already compiled ones?
Edit: full code
I'm working on an Annotation Processor for my Kripton Persistence Library and I have a similar problem. My problem is similar but not the same: in my generated classes I referer other generated classes that are generated in the same round.
The solution that I apply is simply "generate" the TypeName by hand. In my Annotation Processor, I use a specific class, which source you can found here.
Kripton will generate classes that implement SQLite-based DAO pattern for Android platform. When I generated my DataSource, I need to referer the DAO classes that will be generated in the same round. To do this and avoid the same your problem, I generate the associated TypeName. You can see that on method buildDataSource of the class BindDataSourceBuilder.
Hope that information is still useful for you.
After spending quite sometime searching through scala documentations I have not found this particular bit of information. Or at least not phrased in a way I could easily understand or get any certainty out of.
I have this annotation:
class MyAnnotation extends StaticAnnotation {
def macroTransform(annotees: Any*) = macro myImpl
}
And I have used it on two or more classes like this:
#MyAnnotation
class One {}
#MyAnnotation
class Two {}
I would like to know if the annotees will contain both the classes or if the macro will be executed twice (one for each instance of the annotation). Will I have?
annotess.map(_tree).toList == List(oneClassDef /*classdef of One*/, twoClassDef /*classdef of Two*/)
> true
Is it possible to make it so that the annotation trigger only one application of the macro with all the annotated classes in the annotees at once?
Annottees only include the directly annotated member + an enclosing definition (class/trait) for a value/type parameter + a companion for the annotated member (or for the enclosing definition for a value/type parameter).
Unfortunately, it's virtually impossible to implement your request in the current namer/typer architecture of scalac (and, to the best of knowledge, in dotc as well), so I'd suggest a workaround - annotating a definition that encloses all the classes that you want to process.
Can a class add a method to itself at runtime (like from a static block), so that if someone is performing reflection on this class, they'll see the new method, even though it wasn't defined at compile time?
Background:
A framework I'm using expects Action classes to be defined that have a doAction(...) method, by convention. The framework inspects these classes at runtime to see what type of parameters are available in their doAction() method. For example: doAction(String a, Integer b)
I'd like each class to be able to programatically generate its doAction() method with various parameters, just-in-time when it is inspected. The body of the method can be empty.
It's not simple. Once a class is loaded by a classloader, there is no way to change the methods of loaded classes. When a class is requested, a classloader will load it and link it. And there is no way (with Java) to change the linked code or to add/remove methods.
The only trick that comes to my mind is playing with classloaders. If we delete a custom classloader, then the classes loaded by that classloader should be deleted or inaccessible too. The idea that comes to my mind is to
implement one custom classloader
load the dynamic class with that custom classloader
if we have an updated version of this class,
remove the custom classloader and
load the new version of this class with a new instance of the custom classloader
I leave that as food for thought, can't prove, if this leads to a solution or if we have pitfalls.
As a simple answer to the question: No, we can't change a loaded class like we can change the content of fields with reflection. (we can't add or remove fields too).
Andres_D is right, we can very well do so using custom class loading, here is a detailed guide on how to do this: http://www.javaworld.com/javaworld/jw-06-2006/jw-0612-dynamic.html?page=1
The article explains how to write dynamic Java code. It discusses runtime source code compilation, class reloading, and the use of the Proxy design pattern to make modifications to a dynamic class transparent to its caller.
In fact researcher in Austria have written a JVM that even allows reloading classes with different type hierarchies. They have achieved this by using existing thread save points to generate a complete 'side universe' of an object and all it's related references and referenced content and then once fully reshuffled with all required changes simply swap in all changed classes. [1] Here a link to their project http://ssw.jku.at/dcevm/ the oracle sponsorship certainly makes for interesting speculations on future plans.
Less intrusive changes to method bodies and fields are already possible in the standard java VM using the Hot Swap capabilities of the JPDA as introduced in Java 1.4:
docs.oracle.com/javase/1.4.2/docs/guide/jpda/enhancements.html#hotswap
I'm not sure whether it was the first one but this Sun employee's paper from 2001 appears to be one of the early proposals mentioning the capabilities of the HotSpot to Hot Swap. [2]
REFERENCE
[1] T. Würthinger, C. Wimmer, and L. Stadler, “Dynamic Code Evolution for Java,” presented at the 8th International Conference on the Principles and Practice of Programming in Java, Vienna, 2010.
[2] M. Dmitriev, “Towards flexible and safe technology for runtime evolution of java language applications,” in OOPSLA Workshop on Engineering Complex Object-Oriented Systems for Evolution, 2001.
I've never tried anything quite like that myself, but you should have a look at ASM, cglib, and Javassist.
No, that is not (easily) possible in Java.
It sounds like you are trying to use Java as if it is a dynamic programming language. For example, Ruby has open classes: you can add and remove methods from Ruby classes at runtime. In Ruby, you can also have a "method missing" method in your class, that will be called when you try to call a method that doesn't exist in the class. Such a thing also doesn't exist in Java.
There is a version of Ruby that runs on the JVM, JRuby, and it has to do very difficult tricks to make open classes work on the JVM.
You can have a doAction method which does whatever you would like the generated method to do. Is there a reason it needs to be generated or can it be dynamic?
It looks like there is no way to add method dynamically. But you can prepare an class with a list of Methods or an hash like:
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.lang.reflect.Modifier;
import java.util.HashMap;
public class GenericClass {
private HashMap<String, Method> methodMap = new HashMap<String, Method>();
public Object call(String methodName,Object ...args)
throws IllegalAccessException, IllegalArgumentException, InvocationTargetException {
Method method = methodMap.get(methodName);
return method.invoke(null, args);
}
public void add(String name,Method method){
if(Modifier.isStatic(method.getModifiers()))
methodMap.put(name, method);
}
public static void main(String[] args) {
try {
GenericClass task = new GenericClass();
task.add("Name",Object.class.getMethod("Name", new Class<?>[0]));
} catch (NoSuchMethodException | SecurityException e) {
e.printStackTrace();
}
}
}
Than, using reflections you can set or unset the attribute.
I believe you need some byte code altering tool/framework, such as asm, cglib or javassist.
You can achieve this via aspects/weaving like it's done Spring, but I believe you still need to have the method defined first.
Proxy may help. But have to instantiate a Proxy every time you want to add or remove a method.
What I suggest should work for your situation:
1. You have an existing class MyClass with n methods
2. You want to include (n+1) th method which is not in the class while compiling in another .java source file
My way to solve it is Inheritance. Create a new .java source file for a Class MyClassPlusOne extending the first class MyClass. Compile this class and use the object. How can I compile and deploy a java class at runtime?
class MyClassPlusOne extends MyClass
{
void doAction(String a, Integer b)
{
int myNPlus1 = a+b;
//add whatever you want before compiling this code
}
}
I'm not sure that is possible. However, you could use AspectJ, ASM, etc. and weave these methods into the appropriate classes.
The other alternative is to use composition to wrap the target class and provide the doAction method. You would end up delegating to the target class in this case.
This is a rather old question, but I still found myself looking at it today so, just in case, I'll add my two cents.
If you are using Java 8+, you can define "default" implementations of an interface method, so you can just define the interface with all the extra methods with empty default implementations, and add the implements clause in the desired classes. This approach, in some cases, may be the easiest one.
If you don't have control over the definition of the classes, or you need compatibility with older Java versions, you can still define an interface containing all the required extra methods; but in this case, implement a "Decorator" class with a method that receives the object to "decorate" as parameter, and returns a DynamicProxy instance, wrapping the passed object with this interface.
If you are using Spring, the decorator can be added to the context as a #Component, so you can inject it wherever you need to use it. If any of the objects you need to inject are Spring Beans, you could implement a FactoryBean that uses the decorator to return the instances, so you can just forget about calling the decorator explicitly for them.
I have an application that takes some input and generates configuration files as output. Since the exact input or output format could change over time, I defined two interfaces: Importer and Exporter.
Each concrete importer or exporter could have different parameters that need to be initialized to work. For example, if the import data is coming from a CSV file you only need the path of the file, but if the data is coming from a database then you need a connection string, username, password, etc. Same thing for exporters.
My implementation currently is:
public interface Importer {
public void setup(Map<String,String> params);
public List<ConfigEntry> getList();
}
public interface Exporter {
public void setup(Map<String,String> params);
public void writeDocument(List<ConfigEntry> entries) throws IOException;
}
The setup method needs to be called before getList() or writeDocument() can be called. I use a Map to keep parameters because each child class can have different parameters.
Is using JavaBean style parameter initialization a preferred way? That means, adding setConnnectionString(), setCSVFilePath(), setX() to each child class.
What are the advantages, disadvantages of these approaches?
There are two obvious downsides to map-based approach:
Absence of well-defined parameter names. Yes, you could define them as constants somewhere but you'd still need to check that parameter name is valid as passed.
Absence of well-defined parameter types. Even worse then above - if I need to pass an integer I'd have to convert it to String and you'll have to parse it (and deal with possible errors). Can be somewhat mitigated by using Map<String,Object> and auto-bounding but then you'd still need to validate appropriate types.
Setter-based approach has only one downside - it can't be done. That is, it can't be reliably done by using setters ALONE - you need to supplement it with some kind of init() or afterPropertiesSet() method that will be called after all setters and will allow you to perform additional (co-dependent) validation and initialization steps.
Also, something like this practically begs for some kind of Dependency Injection framework. Like Spring, for example.
I wouldn't say that passing a Map (or Properties) object in the constructor is necessarily preferred over child class specific setter, or vice versa. Which approach is best depends on how you are going to instantiate the classes.
If you are going to instantiate the classes directly from Java then the Map approach tends to be neater, especially if you have a good way to assemble the maps. (For example, loading a Properties object from a property file.) The 'setters' approach forces you to write code against each of the child class APIs.
On the other hand, if you are going to instantiate the classes using some container framework that supports "wiring", "inversion of control" or the like (e.g. Spring, PicoContainer, JavaBeans, etc), then setters are generally better. The framework typically takes care of when and how to instantiate the classes and call the setters, using reflection under the hood to do the work.
So the answer is ... it depends ...