I'm writing a Spring Boot Web Services application, thus I'm using #Endpoint and #PayloadRoot annotations.
For documentation purposes I'm using Enunciate, which doesn't support Spring-WS annotatinos at the time of writing.
Would it do any harm if I add the javax.jws.WebService to an already #Endpoint-annotated class too? Should I use only one of them?
As long as you don't have a JAX-WS implementation like CXF in your classpath and configured the WebService annotation will not be considered.
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.
Here, several questions have been asked by many developers about difference between Spring-Rest and JAX-RS.
And, I have also learned that Spring is not following any specification and Spring framework has their own implementation then
Why Spring allows all that Annotations which are supported/used by JAX-RS by default?
Spring does not support JAX-RS annotations. If there is a situation where you think they do, then you are mistaken or it's just a coincidence. Period. If you will add any JAX-RS annotations in my Spring MVC program, nothing will happen. Annotations are just metadata. They are not programs. If Spring does not recognize the metadata, it will ignore it. But if you use a JAX-RS annotation in place of a Spring annotation that is used for the same purpose, respective of their framework, then you will not get the expected Spring behavior. So basically, if you are using Spring MVC, remove any JAX-RS dependencies so you don't mistakenly use them.
I have services developed using Google guice DI framework and I want to inject them in spring boot application. Could anybody thro some light on how we can access the google guice based services in spring boot application? Any pointers to any sample code?
Welcome to StackOverflow!
There are two different things that you could do, depending on what you actually did in the Guice services.
If you used only JSR330 annotations, then you could theoretically simply replace Guice Modules with Spring #Configuration classes and just use Spring to do the D.I. This would work because both Spring and Guice support the JSR330 annotations. In my view, this can work in only fairly simple cases.
Use the org.springframework.guice:spring-guice library from Spring. It allows you to use Guice Modules and the provided beans.
First you need to include it in your pom:
<dependency>
<groupId>org.springframework.guice</groupId>
<artifactId>spring-guice</artifactId>
<version>1.1.3.RELEASE</version>
</dependency>
Then you must configure Spring to use the needed Guice Modules:
#Configuration
#EnableGuiceModules
public static class GuiceConfig {
#Bean
public MyModule myModule() {
return new MyModule();
}
}
You can read more on the GitHub for this project: https://github.com/spring-projects/spring-guice#using-existing-guice-modules-in-a-spring-applicationcontext.
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.
tl/dr (How) Is it possible to use a jar library, that uses Spring Boot for configuration in a non Spring Boot (regular old-school Spring) server.
We have the problem, that we have a Spring server, that is from the pre-Boot times and we want to create a new library for it. We would like to use Spring Boot in the library (i.e. #EnableAutoConfiguration for configuration). To include the library we have put an spring.xml into the library that enables component-scan inside the library. The classes inside the library use #EnableAutoConfiguration and #EnableWebSecurity to enable configuration and security.
If we include now the library into our server and import the XML file from the library into the server's XML file, only parts of the configuration are working. The #RequestMappings in the library are working and the interfaces are available. However Spring security fails to register it's default filter chain, leading to ugly errors, where the regular Spring Boot config should already work with AnonymousAuthorizationFilter, etc.
We debugged, that the FilterRegistrationBean in spring security is never configured when running that way (and is, if we are running as a Spring Boot application).
So is there a common way how to deal with Spring Boot enabled libraries inside old-school Spring servers?
Is placing a single XML to enable component-scan in the library and importing this XML inside the main server's XML the correct way to include Spring Boot libraries (and how would be the best way, if the server would use Spring Boot itself)?
Does anyone know of the issue with a missing Spring Security filter chain?
PS: I know that we can add the required filters manually. However if we would do that, we would anyway get rid of Spring Boot completely in the library, so this question mainly aims for how to do it with Spring Boot. Of course if it is the wrong way to enable Spring Boot inside a library, please also mention that :-)