reflectutils | reflection utilities and miscellaneous utilities | Reflection library

Chin Huang was correct above, changing to project to use version 2.6.3 of spring-boot fixed the issue.

From previous comments:

The unfound classes are dynamic proxies which are heavily used by the Spring Framework in order to implement AOP. Spring can use both JDK dynamic interface proxies and CGLIB proxies, the latter of which is what we are seeing here. Maybe you should simply ignore those types of classes. They are in fact created dynamically, hence the name. But they are rather a result of dynamic (sub-)class generation than of bytecode transformation.

Yes, I have considered just ignoring those dynamically generated classes, but the whole point of my application was to capture every single method invocation as a user interacts with the web application (such as clicking on a button, etc). In this case, would it be okay to ignore these types of dynamically generated classes? I want to make sure I do not miss any method calls.

As those classes are just dynamic proxies, they will either forward the calls to the original methods or call some AOP or interceptor logic first/instead. Either way, you would not miss anything essential, those proxies are more like switchboards or routers, the actual show happens somewhere else. I recommend you to simply try in a little playgrounds project with an aspect or two.

You also asked how to detect and ignore dynamic proxies by their names:

• CGLIB proxies: Spring's CGLIB proxies contain substrings like $$FastClassBySpringCGLIB$$ or $$EnhancerBySpringCGLIB$$, followed by 8 characters representing 4 hexadecimal bytes. You could either match with a regular expression of just keep it simple and match the substring BySpringCGLIB$$. If non-Spring CGLIB proxies are also in use somewhere in your application, you would have to watch for other naming patterns. But probably you would get similar errors as before when not filtering them, so you would notice automatically.

• JDK proxies: If your Spring application also happens to use JDK proxies, you can identify them easily using JRE API call Proxy.isProxyClass(Class). Thanks to Johannes Kuhn for his comment.

• JDK proxies (old answer): You can filter class names beginning with $Proxy, usually something like com.sun.proxy.$Proxy2 (the trailing number being different). According to the JDK documentation: "The unqualified name of a proxy class is unspecified. The space of class names that begin with the string "$Proxy" is, however, to be reserved for proxy classes." At least for Oracle and probably OpenJDK, you can match for that naming pattern. If that holds true for all JVMs, is up to you to test, if chances are that in your environments others are being used. I quickly tried with Semeru OpenJ9, and the proxy naming pattern is identical, even the package name com.sun.proxy. Pleasae note that in more recent JDK versions, JDK proxies will have fully qualified names like jdk.proxy2.$Proxy25, so in e.g. Java 16 or 17 you should not rely on package name com.sun.proxy. Either add more cases or limit matching to the leading $Proxy in the simple class name.

Update 2022-02-26: Because there was activity on this question, I decided to add some more information about Spring-specific tools which can determine whether an object (or a class) is an AOP proxy (class) and, more specifically, if it is a CGLIB or JDK proxy:

Take a look at tool class AopUtils and its handy methods

• isAopProxy(Object),
• isCglibProxy(Object),
• isJdkDynamicProxy(Object).

No more String matching, simply ask Spring.

BTW, there is also a method net.sf.cglib.proxy.Proxy.isProxyClass(Class) directly in CGLIB, which is supposed to do the same, but within Spring it does not work, probably because Spring uses CGLIB in a non-canonical way. Because Spring embeds a package-relocated CGLIB in its core, the corresponding method org.springframework.cglib.proxy.Proxy.isProxyClass(Class) yields the same faulty result. So if you are working within Spring, please do not use those methods, better use AopUtils.

Here is some example code for your convenience, showing how to determine Spring AOP proxy types (JDK vs. CGLIB proxies) using AopUtils. See also my answer here for how to configure Spring in order to use both proxy types.

BTW, instead of Javassist you could also use AspectJ for your purpose. It sounds like a pretty typical use case.

It is a feature, not a bug of AOP that you can implement cross-cutting concerns which have a wide scope. The wide scope is a default, if you do not limit it. This applies to both native AspectJ and Spring AOP. We are talking about the latter here.

It is a typical AOP beginner's mistake to "weave the world", i.e. to write too widely-scoped pointcuts. In Spring AOP this can lead to intercepting internal Spring components or third-party ones, and sometimes that might be exactly what you want, depending on your aspect's purpose. In many cases, however, you simply want to apply the aspect to your own application, which hopefully lives in its own base package such as org.acme.myapp. Then you simply add && within(org.acme.myapp..*) to your pointcut in order to focus on everything in those packages (and their subpackages by virtue of ..*) as potential AOP targets.

So for your simple logging advice, it would look like this:

You do not need to add below dependency on complete/configuration-client module since you have already added spring-cloud-starter-config.

implementation 'org.springframework.cloud:spring-cloud-starter-bootstrap'

You can add your configurations to application.properties file complete/configuration-client like below:

You might be hitting Spring issue #21674 which was fixed in Spring 5.1. You might want to upgrade, if that is an option. It seems there is a fix which ignores those kinds of methods. If that is OK for you or not, I do not know.

Some background information: Your target method is transactional, so Spring tries to create a CGLIB proxy for it. I quickly verified in a simple Spock (Groovy) test that CGLIB seems to be unable to handle methods containing spaces correctly -probably because it is simply unaware of languages like Groovy and Kotlin which allow such things. Here is a proof of concept. I used Groovy and Spock, because I am lazy and did not want to set up a Kotlin project. But I am expecting the result to be identical.

Java class under test:

Play 2.8 supports Java 8-11, I set my environmental variable "JAVA_HOME" to the Java 8 JDK and the command sbt run worked.

I was able to get the gluonfx:package command to run successfully after fixing the following errors that were pointed out by @JosePerada in the comments.

(1) I removed the environment variables to ANDROID_SDK and ANDROID_NDK. Then, from within Android Studio, I went ahead and removed the NDK(Side by side) package that I had configured in earlier, mistakenly thinking it might be of help.

(2) I changed the value held in GRAALVM_HOME to a subfile of ~/home/ and moved the Graalvm files as well, to match. This was one of several options. The key is that files are downloaded to within this folder, so write privileges are needed. If I leave it in /usr/lib, either sudo or a user with write privileges for the area will need to run the gluonfx:package command. Simplest seem to me to just put it in my user's home area where I already have write privileges.

Once these changes were done, the following command gave "BUILD_SUCCESS" messages for both gluonfx:build and gluonfx:package.

OK, on to attempting to install and run the app on my device. I wonder what I will get wrong about this next step.

The answer given by @JoséPereda in the comments seems to me like something we can post to resolve this particular question. He writes that in order to run the app on the device, the app must first be packaged.

Thus, if I understand this and if it hasn't already been corrected, the steps mentioned in section https://docs.gluonhq.com/#platforms_android_development_run should actually come after packaging, which is discussed in the section https://docs.gluonhq.com/#platforms_android_distribution_build.

Your groupId and artifactId in the parent, are reversed:

Should be: