I used to use the standard annotations #Named and #Inject for dependency injection in my code, and the Spring annotation #Primary to force the usage of a specific implementation in case I have multi implementations.
Unfortunately, this is not working with Quarkus anymore. Is there any specific reason ?
Is there any solution that can work for both Quarkus and a Web Application (The library that I am implementing can be used in both type of applications)?
Thanks
Related
And most important, what's the reason behind the "Auto" prefix? Classes annotated with #Configuration rather than #AutoConfiguration are less automatic or something?
#Configuration is a spring framework annotation and not strictly bound to spring-boot. It was introduced when spring started to allow programmatic creation of spring-beans as to move forward from xml definitions of beans.
#AutoConfiguration is a spring-boot specific annotation not commonly available in spring framework. The reason it exists, is for external providers that cooperate with spring-boot to be able to mark some classes in some libraries they provide with this annotation as to inform spring-boot that those classes could be parsed and make some initializations during start up of spring application automatically.
So if some regular programmer that develops some application happens to have kafka in dependencies then some beans will automatically be created and added in application context and will be ready for the programmer to use, although he has not defined any configuration for them. Spring-boot already knows this as the kafka provider has already informed by marking some class in the jar they provide with the annotation #AutoConfiguration.
For this reason #AutoConfiguration has some more powerful configurations available as before, after, beforeName, afterName as to allow the provider to specify when the configuration is applied during application startup if some order is necessary.
So this annotation is not to be used from some regular programmer that develops an application using spring-boot. It is for someone that develops a library that other users might use with spring-boot. One such example is kafka library.
For this to work in a spring-boot project #EnableAutoConfiguration is needed as well, to enable auto configuration.
From spring documentation
Spring Boot auto-configuration attempts to automatically configure
your Spring application based on the jar dependencies that you have
added. For example, if HSQLDB is on your classpath, and you have not
manually configured any database connection beans, then Spring Boot
auto-configures an in-memory database.
#Configuration instead is to be used from some regular programmer that develops an application using spring-boot or spring-framework as to inform the framework for which beans should be created and how.
#AutoConfiguration was introduced in 2.7 with the idea to mark all auto-configurations with its dedicated annotation and move away from spring.factories for auto-configuration imports in 3.0 as described in Github issue.
According to Spring documentation:
[#AutoConfiguration] indicates that a class provides configuration that can be
automatically applied by Spring Boot. Auto-configuration classes are
regular #Configuration with the exception that
Configuration#proxyBeanMethods() proxyBeanMethods is always false.
Usually, #AutoConfiguration classes automatically configure an application based on the dependencies that are present on the classpath. Those classes are generally marked as #ConditionalOnClass and #ConditionalOnMissingBean annotations that detect the presence or absence of specific classes.
Additionally, if a configuration needs to be applied in a specific order, you can use the before, beforeName, after, and afterName attributes on the #AutoConfiguration, unlike #Configuration which doesn't provide those attributes.
This question already has answers here:
What is the difference between #Inject and #Autowired in Spring Framework? Which one to use under what condition?
(11 answers)
Closed 3 years ago.
Since Spring 3.0, Spring supports the standard JSR 330: Dependency Injection for Java. In a Spring 3 application, you can use
#Inject instead of Spring’s #Autowired to inject a bean.
#Named instead of Spring’s #Component to declare a bean.
When should I use what?
The #Inject annotation also serves the same purpose, but the main difference between them is that #Inject is a standard annotation for dependency injection and #Autowired is spring specific.
Read more: https://javarevisited.blogspot.com/2017/04/difference-between-autowired-and-inject-annotation-in-spring-framework.html#ixzz6Bwt3RUg9
Long story short these annotations are spring guys efforts to support some parts of Java EE (now Jakarta EE) specification, these are injection official annotations there. Spring guys add them in order to facilitate Spring adoption and system migrations from Java EE.
So when to use this annotation?, use them if you are planning to migrate to/from Jakarta EE it makes sense to used them to facilitate the process or keep your system consistent. Otherwise, go for Spring "official" ones.
If you only use spring, and do not special behaviour, you can use any annotations: they will be handled the same.
If you use (or plan to use) other dependency managers (JavaEE, Guice, XWiki internal container, ...) #Inject and #Named are defined by the JSR-330 and are now supported by all of those containers.
On the other side, if you plan to use all spring specific goodies, spring specific annotations may allow finer configuration.
I was reading about Spring core module and came across Spring annotations that I did not see till now in the Hybris project:
#Component,#Qualifier
Are these used in Hybris projects?
Hybris uses both. Annotation Injection and XML Injection. You can also use both. I recommend you, to define a clear strategy when you use which one.
For example:
Controller - Annotation Injection
Facade - XML Injection
Service - XML Injection
To your point, which kind of Annotation you should use, have a look here:
What's the difference between #Component, #Repository & #Service annotations in Spring?
In common said, there is not really a different. It's just nice to use the correct Annotation for the correct class.
Hybris 6.6 uses Spring 4.3. The usual annotations like #Autowired, #Required, #Controller, and many others should work.
If you have access to Hybris Help, have a look at "Spring Framework in SAP Commerce": https://help.hybris.com/6.6.0/hcd/8c63621986691014a7e0a18695d7d410.html
There is:
Dependency Injection
Interface-Driven Design
Beans (and aliasing)
Spring Profiles
Spring MVC
Spring Integration
etc
I have a web project, and I depoly it on tomcat easily. Infact I have a WebAppInitializer class that implements WebApplicationInitializer (this class it's really fat), as you know every application server that supports servlet 3.0, it can easily detect it and try to boot it. Now I wonder that it could be possible to use spring boot starter and without any further configuration, I pass my WebAppInitializer to it and spring boot based on my WebAppInitializer boots my project?
I just want to use the approach of spring-boot to deploy application on Tomcat and I don't want to use other spring-boot's facilities.
Yes, it's an old question. But I do not see an accepted answer and the one closest to a working one only has a link to an external resource. So here it is.
https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#boot-features-embedded-container-context-initializer
28.4.2 Servlet Context Initialization
Embedded servlet containers do not directly execute the Servlet 3.0+
javax.servlet.ServletContainerInitializer interface or Spring’s
org.springframework.web.WebApplicationInitializer interface. This is
an intentional design decision intended to reduce the risk that third
party libraries designed to run inside a war may break Spring Boot
applications.
If you need to perform servlet context initialization in a Spring Boot
application, you should register a bean that implements the
org.springframework.boot.web.servlet.ServletContextInitializer
interface. The single onStartup method provides access to the
ServletContext and, if necessary, can easily be used as an adapter to
an existing WebApplicationInitializer.
Scanning for Servlets, Filters, and listeners
When using an embedded
container, automatic registration of classes annotated with
#WebServlet, #WebFilter, and #WebListener can be enabled by using
#ServletComponentScan.
[Tip] #ServletComponentScan has no effect in a standalone container,
where the container’s built-in discovery mechanisms are used instead.
I've tried it. It works
In my use case I have project containing a few dozens of webapps, designed to run on Tomcat as WAR. Lots of logics was neatly crafted into WebApplicationInitializers and it seemed there should be an easier way to reuse all this. Adding implements ServletContextInitializer to those initializers and exposing them as beans through #Configuration classes lit my webservers up with SpringBoot's embedded Tomcat.
http://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#howto-create-a-deployable-war-file describes precisely how to do it
From the Spring Boot docs:
Servlet 3.0+ applications might translate pretty easily if they already use the Spring Servlet 3.0+ initializer support classes. Normally all the code from an existing WebApplicationInitializer can be moved into a SpringBootServletInitializer. If your existing application has more than one ApplicationContext (e.g. if it uses AbstractDispatcherServletInitializer) then you might be able to squash all your context sources into a single SpringApplication. The main complication you might encounter is if that doesn’t work and you need to maintain the context hierarchy. See the entry on building a hierarchy for examples. An existing parent context that contains web-specific features will usually need to be broken up so that all the ServletContextAware components are in the child context.
So yes, it's possible but you need to convert it to SpringBootServletInitializer, which seems to be quite similar.
I am working on an application using Spring 3 and Hibernate 3.5 with Java 1.6.
So far I've been using JBoss 4.2.1 and everything was fine.
Now while migrating to JBoss 5.1, I encountered lot of issues. One of them is that JBoss is ignoring the Spring #Resource annotation. I get the following exception:
java.lang.RuntimeException: mapped-name is required for serviceManager of deployment pol-1.0.war
at org.jboss.web.tomcat.service.injection.WebResourceHandler.loadXmlResourceEnvRefs(WebResourceHandler.java:287)
at org.jboss.web.tomcat.service.injection.WebResourceHandler.loadXml(WebResourceHandler.java:325)
at org.jboss.web.tomcat.service.TomcatInjectionContainer.processMetadata(TomcatInjectionContainer.java:550)
at org.jboss.web.tomcat.service.WebCtxLoader.start(WebCtxLoader.java:158)
It expects mapped-name for each #Resource like some ejb.
I've seen similar questions but they are without any answer e.g.:
#Resource annotation not working properly with JBoss5.0.1
Please advise.
Adi
Actually your problem is that JBoss doesn't ignore #Resource annotations - it tries to handle them according to EJB rules instead of leaving them to Spring.
Perhaps this feature can be disabled somewhere in JBoss configuration, but the simpliest solution would be to replace #Resource with #Autowired or #Inject.
Sounds like java annotations need namespace support.
Then it would be #Spring:Resource or #EJB:Resource.
Oracle, are you listening?
Short of namespace for Annotations, you could possibly try changing the order of the libraries in your classpath so java would see the Spring annotations first (or last), whichever ends up providing the desired outcome.