Sorry if this is a silly question.
I know how to use #Component #Autowired in projects based on springframework, but I could not find the implementations of those annotation, simply searching in springframework code repository gives me so much thing.
I want to find the work behind those annotation that springframework did for me.
thank you.
Related
I am new to spring boot and want to design my own APIs and test them with Postman client. However, I can't get past the following error.
Any opinions on this one? I found similar topics but none of them fix my problem.
I also give you my controller, model, and service classes.
I believe I clearly initialized LectureService reference by using #Autowired annotation. This error keeps bugging me.
Note: I also added
#SpringBootApplication(scanBasePackages = {
"io.theBMan.springBootStarter.lecture"
})
to my App.java class but didn't help as well.
Adding the answer here as Simon suggested.
You've autowired the service inside controller code but have not annotated the service class with #Service. That is the cause of this issue.
Note:
The following stackoverflow answer beautifully explains about how and why both classes ( in your case LectureService and LectureController) should be defined to live in the application context. It is an excellent read.
I want to implement my own custom annotations, that is why I am looking for Spring annotations' implementation. Which code executes behind the screen when we use an annotation?
Definition of an annotation is pretty simple. You can find definition of #Autowired annotation here:
https://github.com/spring-projects/spring-framework/blob/master/spring-beans/src/main/java/org/springframework/beans/factory/annotation/Autowired.java
If you're interested in its processing, you can clone spring-framework repository and search for its usage in the code of Spring.
If you want to implement your own custom annotation processor, I'd recommend to search for simpler examples than Spring and #Autowired.
I'm also planning to play around with annotation processors and I collected a few links related to this topic. Maybe you'll find them useful.
Java related:
https://github.com/bozaro/example-annotation-processor
https://github.com/eugenp/tutorials/tree/master/annotations
http://www.baeldung.com/java-annotation-processing-builder
https://www.gesellix.net/post/providedcompile-and-compile-dependencies-with-gradle/
http://programmaticallyspeaking.com/playing-with-java-annotation-processing.html
https://github.com/Jimdo/gradle-apt-plugin
http://mrhaki.blogspot.com/2016/03/gradle-goodness-enable-compiler.html
https://github.com/sockeqwe/annotationprocessing101
http://hannesdorfmann.com/annotation-processing/annotationprocessing101
https://www.javacodegeeks.com/2015/09/java-annotation-processors.html
and bonuses
Android related:
https://medium.com/#iammert/annotation-processing-dont-repeat-yourself-generate-your-code-8425e60c6657
https://stablekernel.com/the-10-step-guide-to-annotation-processing-in-android-studio/
https://medium.com/#emmasuzuki/annotation-processor-101-your-first-custom-annotation-a3db9ae48046
http://blog.jensdriller.com/android-annotation-processing-setup-using-gradle/
Kotlin related:
https://blog.jetbrains.com/kotlin/2015/06/better-annotation-processing-supporting-stubs-in-kapt/
Are #InjectParam (com.sun.jersey.api.core.InjectParam) and #Autowired (org.springframework.beans.factory.annotation.Autowired) same?
In one of the project, I have seen both of these are being used for similar purposes, hence I guess both can do the same job.
I am just wondering if my guess is correct or I am missing some critical catch out there.
I would appreciate if someone can explain the difference and which one to use under what situation?
Thanks.
Both #InjectParam and #Autowired are used for dependecy injection purposes.
According to the documentation, Jersey's #InjectParam is used to annotate fields, methods or parameters that shall be injected with instances obtained from Jersey or registered IoC component provider factories that provide support for Guice, Spring or CDI.
Spring's #Autowired is used to perform injections in the Spring Framework and, as far as I know, it won't work in Jersey resources.
From this post #Autowired not working on jersey resource , it seems #Autowired does not work with Jersey resource in which case we have to use #InjectParam for Jersey resouce.
I've been looking for an answer for a while, but no luck so far, thus I'm coming here for some words of wisdom.
I've created an aspect using #Aspect annotation, because I need to #Autowire some singleton dependencies I've decided to annotate this aspect class with #Component and let the Spring to do the magic. It works, however ...
I'm fairly familiar with AOP concept, what's weaving and different flavors of it (cglib vs aspectj) but it's not fully intuitive to me how it works under the hood.
#Component means a given class will be a singleton within a given context, #Aspect means that the content of an aspect class will be somehow weaved into the target class during runtime/compilation - and this target class is not a singleton but prototype for instance. So what I'm ending up with at the end?
Spring AOP does not do compile-time-weaving and does not modify the code of the advised target. Instead it works with proxies that are weaved around the joinpoints. That is why Spring AOP aspects and be used as (singleton) components, have their fields autowired, etc., like any other Spring Proxy.
It is also the reason why Spring AOP aspects only work for public method executions, not field accesses and the like.
The documentation is quite well written and goes into as much (or as little) detail as one might like:
http://docs.spring.io/spring/docs/current/spring-framework-reference/html/aop.html
The book AspectJ in Action's section 2.5 is on the internal working of the weaving step, it is only 2 page but gets the point across well.
Luckily the section is available here.
This is for posterity.
Im working with the Spring Framework 3.0.5 and Spring Security 3.0.5 and Ive got questions to the aspect orientated programming. At the moment Im trying to figure out the disadvantages and advantages of aspect orientated programming. Of course, I know them in theory: I can avoid redundant code, I only have to make changes in the aspect, not everywhere in the code and so on. But I still got some questions:
The disadvantage I found out:
I wrote a sample application using aspects with Spring AOP. I configured an Aspect with Annotations (#Pointcut, #Before, #Aspect and so one). The methods that triggered the aspect (which were part of a Pointcut of course) were of course part of a different class and not annotated with anything.
=> I really think that one big disadvantage is that when watching those methods of the other class it was not clear that they trigger an aspect. They needed no annotations or anything else, they were just mentioned in the pointcut of the aspect. (I really hope you understand what I mean). So thats why I think that AOP makes code also less understandable!
a) Is there a solution to this problem? (Can this maybe be solved when I put the whole configuration in an XML File? I dont think so.)
b) Would this problem still exist when I would use AspectJ instead of Spring AOP?
Springs Features using Spring AOP: they dont have this disadvantage?
As Spring AOP is part of many Spring Features (just like declarative Transaction Management or (maybe) Spring Security(?)) I took a closer look at those Features. I was not able to find any disadvantage at all.
c) Lets take the declarative transaction management as an example: managing transactions is so easy with those annotations (#transactional) and I dont really find the disadvantage I mentioned above. I can see the methods that trigger specific behaviour. (all #transactional methods trigger transactional behaviour) Maybe I misunderstood something and this isnt where AOP is used? But if I did not misunderstood this, why is it here possible to see which methods trigger aspects and why isnt it possible to see in my example above? I would really like to know this!
Thank you for answering! :-)
EDIT: a) and b) are answered (use an IDE which marks those methods), c) is still missing :-)
For Point b)
If you use an Eclipse with Spring IDE and AspectJ plugin, or STS, the IDE will show you where Aspects are woven in.
For Point b)
If you use AspectJ and an IDE that supports AspectJ (Eclipse with AspectJ Plugin, or STS), then you will see markers in the souce-code where the Aspect is woven in.
An disadvantaged of Compile time AspectJ is, that you are not able to wove aspects in libraries. (without advanced techniques).
For Point c)
There is only one disadvantage of declarative Aspects like #Transactional. -- You can forget to put the annotation on the method.
But if you have for example a rule like: every public method in a Class annoteted by #Service (or if you like to build you own #TransactionalService), is transactional, then you do not need to specifiy the #Transactional annotation on each method. -- So in Summary: declarative Aspects are very good for reading (you will not overlook them), and they are good if your code is very (lets say) "individual" (instead of the term "not consistent") . But If you work in an Environment with Strong Architecural Rules (like every public method in a #Service class...), then you can Write this rules down in a Point Cut Definition, instead of using declarative Aspects.
Actually for point a) the same answer holds that Ralph gave: use Eclipse with either AspectJ plugin or if you are using Spring anyway, use STS.
That way you will see in your IDE if a certain method matches a pointcut on the left side of your editor, represented by small red arrows:
Actually, Spring AOP supports creating custom annotations.
I defined a annotation named Loggable binding with Advice.The Loggabel could be applied to any method you want.
public #interface Loggable {
}
#Aspect
public class EmployeeAnnotationAspect {
#Before("#annotation(com.ben.seal.spring.aspect.Loggable)")
public void myAdvice(){
System.out.println("Executing myAdvice!!");
}
}