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.
Related
Small question regarding using Mono<ServerResponse> vs Mono<ResponseEntity<MyPojo>> as return type please.
I am seeing examples where sometimes, Mono<ServerResponse> is used as return type in a functional route from Spring Webflux.
But also seeing examples where sometimes, Mono<ResponseEntity<MyPojo>> is used as return type in a Spring functional route.
Moreover, there are many examples where Mono<ResponseEntity<MyPojo>> is used in the #Controller, #RequestMapping (Get, Post mapping etc...) as return type.
But there are also few examples with returning Mono<ServerResponse>.
May I ask, what is the difference between returning either one please?
The short of it, as I understand it, is that org.springframework.http.ResponseEntity is from the original Spring Mvc Framework package and org.springframework.web.reactive.function.server.ServerResponse is from the spring Reactive package.
The reactive package has a "compatibility" mode that lets you use the backward compatible #RestController annotations and they would generally return a ResponseEntity as before.
The Reactive package implementation without the compatibility features use a Router and Handler and generally return a ServerResponse. See Building a Reactive RESTful Web Service for a tutorial from spring.
See also the Spring WebFlux guide, chapters 1.4. Annotated Controllers for the compatibility reactive way and 1.5. Functional Endpoints for the functional way.
If you look under the covers at the Annotated Controllers code you will see it uses the Functional Endpoints code.
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).
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.
I've read that the new way of creating Hibernate DAO is using Hibernate contextual sessions. The main reason being to avoid the Spring based HibernateTemplate/HiberateDaoSupport and thus Spring-Free DAO.
When I searched what to do with Exception translation? It's written everywhere that I should use #Repository! #Repository does need import and creates dependencies in my code. Am I right?
Aren't annotations considered dependency? If they are, is there anyway I can have that using XML? Or should I use the old HibernateDaoSupport way, since I'm going to have my code coupled with Spring anyway?
Update
Found a similar question: "integrate hibernate with spring without spring dependency in dao" but:
The first paragraph of the answer that #pap has given does not specify any clear XML alternative for #Repository.
The insight offered in the rest of that answer is plausible, yet my question remains unanswered that if decoupling is not much of a concern, why did Spring try proposing the new approach to Hibernate DAO?
P.S. This is not a criticism. It's rather an attempt to learn the proper way of thinking about this topic (i.e. the dependency).
The point of Spring exception translation in the first place is to break a dependency on Hibernate by creating a dependency on Spring. Regardless of the annotation, Spring exception translation catches a Hibernate exception and turns it into a Spring exception. By putting catch statements in your code tied to the Spring exception you are coupling your code to Spring far more directly than by adding any #Repository annotations. If you don't want to depend on Spring then simply use the Hibernate exceptions directly. Basically, there are two approaches:
Use Hibernate for exceptions and contextual sessions (no coupling to Spring). In this case, simply don't use Spring exception translation at all.
Use Spring for exceptions and session handling (looser coupling to Hibernate, additional coupling to Spring).
i wonder how to create security annotation like spring security does (#PreAuthorized or #Secured) that will check session than do something to decide how application will threat the authority to log on user.
is any resource i can read or any recommendation?
best regards
ps: for some reason, i cannot use spring security
The technique behind these annotations is called Aspect Oriented Programming (AOP).
Spring Security relies on Spring AOP, which allows you to intercept particular method calls on Spring-managed object, so that you can apply security checks to them.
See Aspect Oriented Programming with Spring. Alternatively, if you want to do it without Spring, see standalone AOP implementations such as AspectJ.
The best tutorial for 'how does Spring Security work' is 'the source of Spring Security'. It is open source. You can read it. Honestly, the question as posed is much to broad to allow for much more of an answer.