I have a Spring Boot Jersey Application. I want to use a custom class loader with it to allow loading classes and resources from outside of standard web application classpath. (I need it to allow customers to add "plugins" to the application without disturbing original application file structure). Any suggestions how can I do that?
Related
I'm currently trying to shift my existing dynamic web project to Spring boot project and it uses web.xml for servlet mapping. I understand that spring would ignore the web.xml file, what should be the correct approach for spring to use the existing web.xml? And yes, I still need to stick to using web.xml for this project.
I'm kinda new to this, please guide me through! Thanks!
I suppose that you need to stick with a web.xml because your container uses an older version of Servlet than 3.0.
Spring Boot is built on Servlet 3.0. You have to update your main class to extend SpringBootServletInitializer and override configure method, which tells spring to use its Servlet 3.0 support. Embedded containers like Tomcat need Servlet 3.0, so if you want to start your project during the development process (including JUnit tests) in embedded containers, I think, from what I know, the only way is to rewrite your web.xml to Servlet 3.0 java config. But if you really want to deploy you app in an older container, you still can by using spring-boot-legacy module. It allows you to use web.xml for older containers; only thing you have to do is to add
org.springframework.boot.legacy.context.web.SpringBootContextLoaderListener in your web.xml.
For more information about deploying war in an old container, take a look at Spring Boot's official documentation.
Spring Boot uses Servlet 3.0 APIs to initialize the ServletContext
(register Servlets etc.) so you can’t use the same application out of
the box in a Servlet 2.5 container. It is however possible to run a
Spring Boot application on an older container with some special tools.
If you include org.springframework.boot:spring-boot-legacy as a
dependency (maintained separately to the core of Spring Boot and
currently available at 1.0.2.RELEASE), all you should need to do is
create a web.xml and declare a context listener to create the
application context and your filters and servlets.
This is a very old question, but I'm currently on the same situation and I will share my experience.
I extended the SpringBootServletInitializer class to create my #SpringBootApplication, and it will INCLUDE your web.xml configuration by default. I'm still able to declare or edit existing servlet mapping, and it will be taken in account.
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'm developing a Spring Boot app using Jersey for Rest.
The app will regularly have Rest controller and supporting classes added to it, basically adding small, specific logic at specific endpoints.
I'd like to be able to drop jars containing Jersey controllers into a directory specified by loader.path and have them created (including Spring auto-wiring) by just restarting the server.
Some Jersey resources form the base of the application and these are working fine because I've registered them via a ResourceConfig class but I'd really like to add resources without requiring a rebuild of the app.
Is this possible? I'm failing to get the resources created, I'm not even sure they're in the classpath.
In application.properites, I added:
-Dloader.path=lib/,resources/
and I've copied the jars into these folders, but they don't get instantiated.
Anybody got any ideas?
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 :-)
Problem:
I have a custom implementation of java.util.prefs in a maven jar module.
I am providing the system property to -djava.util.prefs.PreferencesFactory=com.blah.CustomePrefsFactory
to my Spring boot app that is using the custom preferences.
When the Spring boot app uses the Preferences for the first time, the Java.util.Preferences.java tries to load the CustomePrefsFactory using the
ClassLoader.getSystemClassLoader().
This results in errors as nested jar classes are not available to a system class loader of the spring boot app.
Is there a way to make nested jar classes available to the system class loader?
The short answer is no.
System ClassLoader delegates to the Bootstrap ClassLoader and Extension ClassLoader and then tries to load classes from classpath, but not from nested JARs.
You have to implement or use an existing ClassLoader that supports that functionality.