I would like to use pointcuts of Aspects (Spring AOP) in Hadoop API. I don't want to modify the API, I just want to intercept the calls to the API methods. Is it possible with Spring AOP?
The bad news: No, it is not because Spring AOP is a proxy-based "AOP lite" framework which only works with Spring components. The syntax of Spring AOP is a subset of AspectJ, though.
The good news: If you use full AspectJ instead of Spring AOP, you can do what you want, because AspectJ is independent of Spring and can be used with any Java class (even with classes produced by other JVM languages such as Groovy or Scala).
Related
The #ControllerAdvice annotation allows us to write global code applicable to a wide range of controllers.
My Question is:
#ControllerAdvice is applicable to only controller level and Spring AOP is based on pointcut.
Other than this, what are the differences between them and when to use #ControllerAdviceand Spring AOP?
I was trying to implement something like shown in this example link.
Link Here
#ControllerAdvice is one of the AOP features Spring offers. The main difference in use case is that #ControllerAdvice is wired up by the Spring MVC infrastructure and uses (and provides) Web-specific features. Use it if you're writing advice that specifically applies to Web requests, such as error handling (e.g., translating exceptions into an enterprise-standard JSON error format). Otherwise, aspects are the approach.
I have seen a Spring application, and it uses spring dependency injection in addition to that some places I find Java Dependency injection. I am not sure why Java DI is used. I googled it, however, I can’t find an exact answer.
Anybody can explain why Java DI is used in addition to Spring DI?
Dependency Injection in Java is a way to achieve Inversion of control (IoC) in our application by moving objects binding from compile time to runtime. We can achieve IoC through Factory Pattern, Template Method Design Pattern, Strategy Pattern and Service Locator pattern too.
Spring Dependency Injection, Google Guice and Java EE CDI frameworks facilitate the process of dependency injection through use of Java Reflection API and java annotations. All we need is to annotate the field, constructor or setter method and configure them in configuration xml files or classes.
This link may help you more
To be simple, If you need Dependency Injection through Java you need to implement using some Design Patterns, which is time consuming. Frameworks like Spring helps to implement DI using annotations and configurations which are developed using specific design patterns. As a developer we need not worry about DI, we can just concentrate on our business logic.
I have an application in which beans are not initialized using the Spring BeanFactory/ApplicationContext.
There are few places where I find that Spring AOP can be useful and I want to apply these AOP features to the beans which are not part of a spring container.
So is it Possible to do so? And if yes, what can use to do the same?
I posted following question for which I am still looking an answer.
Around Advice for methods on Interface
While looking in to this another question has come to my mind:
Are Point-Cuts and Advices only applicable to the classes which are declared as bean in spring's appContext.xml
Are Point-Cuts and Advices Is not applicable to all classes in the code-base ?
Straight from the Spring AOP documentation. THe documentation does say that Spring AOP is only for method execution join points(advising the execution of methods on Spring beans)
6.1.2. Spring AOP capabilities and goals
Spring AOP is implemented in pure Java. There is no need for a special
compilation process. Spring AOP does not need to control the class
loader hierarchy, and is thus suitable for use in a J2EE web container
or application server. Spring AOP currently supports only method
execution join points (advising the execution of methods on Spring
beans). Field interception is not implemented, although support for
field interception could be added without breaking the core Spring AOP
APIs. If you need to advise field access and update join points,
consider a language such as AspectJ. Spring AOP's approach to AOP
differs from that of most other AOP frameworks. The aim is not to
provide the most complete AOP implementation (although Spring AOP is
quite capable); it is rather to provide a close integration between
AOP implementation and Spring IoC to help solve common problems in
enterprise applications. Thus, for example, the Spring Framework's AOP
functionality is normally used in conjunction with the Spring IoC
container. Aspects are configured using normal bean definition syntax
(although this allows powerful "autoproxying" capabilities): this is a
crucial difference from other AOP implementations. There are some
things you cannot do easily or efficiently with Spring AOP, such as
advise very fine-grained objects (such as domain objects typically):
AspectJ is the best choice in such cases. However, our experience is
that Spring AOP provides an excellent solution to most problems in
J2EE applications that are amenable to AOP.
We are using Spring 2.5 and spring-json for JSON support. We have the below configuration in views.xml
<bean name="jsonView" class="org.springframework.web.servlet.view.json.JsonView"/>
Now, we have learnt that Spring 3.x uses JackSon API internally for JSON support. My question is how can we override the default implementation of Spring 2.5 to use JackSon - The way Spring 3.x begins.
Note: We don't want to migrate my Spring version, but, want Spring 2.5 to use this JackSon API instead of Spring-Json
Is it possible to replace Spring's JSON support without breaking it ?
Unfortunately, Spring's own documentation states that Spring-json is "deeply" a component of the existing Spring 2.5 framework.
See : http://spring-json.sourceforge.net/
That said - removing the dependencies on spring-json, adding your own JSON parser, and rebuilding spring can be done. I assume this will require a lot of work given that spring-json is a major component of the whole Spring MVC suite.
An alternative : Building a Facade
In addition, I don't know of any Java EE specification for Json libraries which implies that there is a good chance that all internal Spring json dependencies are specific to the APIs defined by Spring-json [compare this, for example, with JPA, which is generically defined by Java EE, so that it is easy to replace many a DAO framework].
Generally, you can package any sort of JSon library as a Spring component that will be available in the application context. Now - if you reimplement the necessary interfaces using the facade pattern, using Jackson under the hood, your version of Spring 2.5 should work the same. Alternatively, you could intercept Json related calls of interest using Spring's aspect oriented injection libraries, and reroute them as necessary.
Again, however, these are all advanced tasks - they would be excellent learning projects but I'm not sure that the time investment would really pay off if this is a production application.
http://www.javaworld.com/javaworld/jw-02-2008/jw-02-springcomponents.html