Just for the sake of learning and understanding proxies, I wanted to see the proxy class generated by Spring AOP. It was not present in the classes folder generated by Eclipse.
Can somebody tell me its location?
If you are using interface-based proxies (default), Spring uses Proxy class to create proxy dynamically and in-memory. There is no .class file associated with that class.
When using class-based proxies (via cglib) Spring creates concrete subclasses of your classes. In the debugger you'll notice they are named something like YourRealService$$EnhancerByCGLIB$$... But again, these classes are only generated in-memory and not stored on disk.
If you really want to see AOP under the hood, you will have to use aspectj and compile-time weaving. Way too much work. So the bottom line is: just trust they work. And if they don't: examine stack traces.
Related
As far as I know whenever I use interfaces for my beans, JDK Dynamic Proxies should be used instead of CGLIB. To be on teh safe side, I make sure I don't even have CGLIB in the classpath of my Spring Boot app.
However, when my controller implements an interface I see this in the stacktrace(never mind the stacktrace rootcause, it was a validation error):
at com.yuranos.documented.api.controllers.BookingControllerImpl.convertToDto(BookingControllerImpl.java:57)
at com.yuranos.documented.api.controllers.BookingControllerImpl.getBookingById(BookingControllerImpl.java:29)
at com.yuranos.documented.api.controllers.BookingControllerImpl$$FastClassBySpringCGLIB$$890fcd8a.invoke(<generated>)
What is even more confusing is that when I remove the interface, this strangely named proxy disappears:
at com.yuranos.documented.api.controllers.BookingControllerImpl.convertToDto(BookingControllerImpl.java:60)
at com.yuranos.documented.api.controllers.BookingControllerImpl.getBookingById(BookingControllerImpl.java:32)
I am use Spring in my app, when we have some class that doesn't implements any interface, Spring will use "cglib" to proxy.
Can I change the cglib to other lib in Spring? If yes, How can I do it?
Thanks!
[EDIT]
Hi, I was wanting because I have problems with PermGen when I use CGLIB, the proxys instance are not cleaning when I do hotdeploy.
Yes, I can change for other stretegy, Aspect etc...
Spring only supports JDK (interface only) and CGLIB based (for classes) proxying, and while it's not explicitly mentioned, it also uses Objenesis with CGLIB for proxying classes with no default constructor. Also see their issues regarding this at https://jira.spring.io/browse/SPR-8190 and https://jira.spring.io/browse/SPR-5654 for further reference. That means there's no drop-in replacement or configuration options in Spring to switch to some other proxy creation method.
If you're still willing to explore uncharted territories, the DefaultAopProxyFactory might be a good place to start as it seems it's a central piece of the proxy creation code in Spring, the proxy creator classes use it as a factory through their common superclass ProxyCreatorSupport.
The docs explain that, the LTW has to enabled either through the use of <context:load-time-weaver/> xml instruction or the use of #EnableLoadTimeWeaving annotation. However, I have done neither, but I still see that aspects are woven correctly in my projects!
In this case, I don't think they are woven at compile-time (but are they?), so it's surely got to be load-time-weaving?
Even if that's the case, how does it automatically choose to weave aspects in during load-time? Shouldn't the aspects remain unwoven if they are not turned on using one of the ways mentioned above as the docs say?
I've got the aspectj-weaver in my classpath, but that can't be enough to choose either of these weaving types anyway, can it?
Spring AOP does not rely on AspectJ byte code weaving. It just borrows the annotations used to define aspects from the AspectJ project. It is a separately implemented framework that uses run-time proxies to implement aspects. If you have <aop:aspectj-autoproxy /> in your application context then spring is using proxies to implement supported aspects defined on beans that are in the container.
Proxies can only achieve a sub-set of the full capabilities of the actual AspectJ system, basically advice that wraps methods. Due to their nature proxies have following limitations:
interception on external calls only (while breaching proxy boundary)
interception on public members only (private/protected can't be intercepted)
unawareness to local calls (or calls with this or super)
If you want to be able to advise fields for example, you would need to enable the use of Native AspectJ.
i want to intercept method from a non-proxied object.
I have a class instance MyClass myClassInstance=new MyClass() and i want to intercept call of myClassInstance methods.
I know all works good with proxies, but i need aspect on non proxied.
Is this possible?
Thanks.
It is possible, but it is not desirable.
You can use #Configurable and AspectJ will intercept calls. Read the 7.8.1 Using AspectJ to dependency inject domain objects with Spring section of the docs about it.
In short - AspectJ plugs some "magic" either compile-time or load-time (with a respective weaver), which modifies the classes so that they become part of the spring context.
As of why I think it is undesirable - this is dark magic that happens by modifying the classes' structure. It's not an object-oriented approach, and I think it will be hard to support. Imagine 6 months later a colleague of yours is debugging a nasty issue. It could take days before he realizes this magic is happening. This opinion is subjection though. The functionality is there and if you need it - use it.
Using Spring, I do not believe so (I appear to be wrong), using AspectJ I believe you can as long as you compile all the code with the AspectJ compiler. However I have never tried it.
You can enable load time weaving in Spring. Then the class loader will weave whatever aspects you define into your classes when they are loaded - regardless of whether they are being created by Spring.
You'll need to enable LTW by adding this line to your context file:
See:
http://static.springsource.org/spring/docs/3.0.0.M4/spring-framework-reference/html/ch07s08.html#aop-aj-ltw
I don't know the meaning of using proxy in spring. what is efficient?
Proxies are used by AOP. In short:
Normally you have.
Caller --> Real object
But when, for example, you want automatic transaction management, spring puts a proxy of your real object
Caller --> Proxy --> Real object
where the proxy starts the transaction.
Here is nice article explaining both the essence of proxies and their efficiency (performance) in spring
The dynamic proxy is a feature of the JDK. It can be used to implement an interface using an invocation handler.
A dynamic proxy class (simply referred
to as a proxy class below) is a class
that implements a list of interfaces
specified at runtime when the class is
created, with behavior as described
below. A proxy interface is such an
interface that is implemented by a
proxy class. A proxy instance is an
instance of a proxy class. Each proxy
instance has an associated invocation
handler object, which implements the
interface InvocationHandler.
A dynamic proxy has some overhead. For most use cases the overhead won't be significant, though. The real problem is that the (over)use of dynamic proxies makes an application harder to understand and debug. For example a dynamic proxy will show up with mulitple lines in a stacktrace.
Dynamic proxies are often used to implement decorators. One example of this is AOP in Spring. (I don't want to go into the details of AOP and won't use AOP terminology to keep things simple). Where certain concerns are implemented in one class and used in many places. The dynamic proxies (and invocation handlers) are only the glue code (provided by Spring) to intercept the method calls. (Actually, dynamic proxies are only an implementation detail of this capability. Generating classes on the fly is another possibility to implement it.)
We can add a functionality to Java class by modifying the source/byte code or by using subclass or proxy which embeds the additional functionality and delegates the calls to underlying object.
The other answers are good, but here's how I think of it in very simple terms.
An annotation means "add hidden code for extra behavior."
The framework (or whatever knows what the annotation means) adds bytecode, Spring at runtime, AspectJ at compile time, for example.
It adds code as a proxy along with an interceptor. (A wrapper, decorator, adapter are similar and may be easier to understand than "proxy".)
When the program runs, the interceptor sends execution to the proxy which does its thing, which then may or may not send execution to the class that you coded and that it "wraps".
AOP can also use CGLIB proxies. This is used to proxy the classes instead of interfaces.