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
Related
My question would be: how do I add a servlet filter, or a Spring AOP method (or a third solution - you name it) that cannot be removed from a web application without recompiling?
I'd like to solve license handling that way, but if anyone modifies the web.xml or the Spring config, the protection is gone.
Licence handling is definitely a cross-cutting concern which could (and IMO should) be modelled by means of AOP.
I cannot say much about servlet filters, being unexperienced in this regard, but
I know that Spring AOP is proxy-based, i.e. it does not modify the source code directly, which is not what you want.
AspectJ, on the other hand, when used at compile-time (not via load-time weaving as is the usual approach in Spring), does compile aspect code right into your core class files, "baking" them into your byte code. This is probably what you want. I do not say it cannot be reverse-engineered - there always is this option - but the code would not run without the AspectJ runtime on the classpath and you could not remove the licencing aspects without recompilation. So this is the option I recomment for that purpose.
Interesting question, by the way.
I am new to Spring framework and have seen annotations at many places. I understand Built-in Java Annotations like #Deprecated, #Override, #SuppressWarnings.
I have below questions:
Does one need to understand creating custom annotations to understand Spring framework?
For what purpose annotations are required?
Annotations are used to describe elements and clarify their meaning. Prior to their inclusion, that information had to be kept somewhere else, generally a file.
Also, knowing how a java feature works is always useful. So despite you don't need to know how to create your own annotations, it might give you some insight on the internals.
Have a read here:
How and where are Annotations used in Java?
For the first question: You do not need to know how to write an annotation to use it.
For the second:
Annotations are used for many different reasons:
To execute code during runtime based on annotations (e.g. #Transactional in spring)
To create different code during compile dependeing on the annotation (e.g. #AspectJ)
To evaluate code (e.g. javac or FindBugs)
...
There are many things that could be done with annotations.
You need not know about the custom annotations in order to learn Spring annotations.
For Spring annotations, you may start with this link and then explore as you learn further. It explains the usage/need to each of the Spring annotations to get started with.
While not actually answering your questions (which others already answered), this should give you enough information to comfortably use them.
For annotations to actually be useful, you need code which looks for them and handles them accordingly. The same goes for writing your own custom annotations.
Simplified example with #Transactional should make things clear for you. When you put #Transactional on a bean method, there is some Spring code which scans these beans and methods, and picks up your annotated method. Whenever that method is called (won't go into proxies right now), Spring opens a transaction, executes your method, and closes the transaction. You get all of that just by putting annotation on your method.
So, each annotation comes with code that handles it's wanted behavior.
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 have a few questions about Spring paradigm in Java:
1) Suppose I have an application where I write everything to interfaces, and then at the very last moment, somewhere in my actual main() or maybe in a config file, I define my specific classes to be used. Have I achieved the same objective as Spring? In that case, why do I need Spring's DI? Writing to interfaces, and leaving specifics till the very last moment, is standard practice that programmers have been using for decades.
2) If the objection is to new'ing objects at some (final) point in time, this has to be done at some point in my interface-driven app, but what's wrong with that? How does having a "new" statement make a class unusable or untestable - or is it just readability/transparency?
3) People say that declaratively using objects "gets rid of dependencies." But we still have a dependency: we have to import a new class, even if we don't "new" it, before we can compile the code?
Some people, like me, prefer to configure the wiring of dependencies and interface implementations using Spring XML rather than hardcode them. All the wirings are in one place (assuming you are not using annotations) and I can also argue that modifying the configuration of the XML file is easier than modifying code. You can also tweak the Spring file between runs of your application if there is something that needs to change.
Spring is a good framework that has been around for a while. I find it's really really good at Dependency Injection (DI). While there is nothing "wrong" with your approach in #1, I think using Spring will give you a more robust implementation. Why reinvent the wheel?
I have an application that is using Spring AOP with AspcetJ, and I want to convert it so that it can be used with spring auto proxy. Which means that I need to go through the code base looking for calls to #Transactional methods that are calling other #Transactional Methods within the same class and thus not going through the proxy, as well as #Transactional methods that are on private methods.
What tool or technique can I use to automatically find all the usages of #Transactional that would work with ApsectJ but not with auto prox?
Well, you are using AspectJ already, so why not use AspectJ to find out about such control flows dynamically and log them? So you could get rid of AspectJ by using AspectJ as an analysis tool. ;-)
I don't know of any tool that will find these out of the box. So you will probably need to write your own; but it is not trivial.
You can write an annotation processor to process methods/fields/classes with annotations on them. See the APT docs for how to write one and run it. (Note that in Java 6, apt is built into javac.)
However, finding out which methods call which other methods is quite difficult. Since you're talking about methods in the same class, it's a bit easier. You could use bytecode analysis for this (see this post for some relevant libraries): just parse out the invokevirtual and invokeinterface instructions in your class' methods, and see if they match the ones with #Transactional annotations on them.