I'm running a Spring Boot Application within a Tomcat instance packaged as a war file. I would like to be able to add "packages" to my instance in the form of rest services. To that end I need to be able to configure scanBasePackages in the #SpringBootApplication annotation at runtime. i.e. when tomcat starts up. For now I have ...
#SpringBootApplication(scanBasePackages="path1, path2")
public class RestApplication extends SpringBootServletInitializer {
//code
}
...but I would like to have path2 be configurable and alternately be able to add path3, etc. if desired. How can I achieve this? I understand that I can't configure the String in the annotation so my question is about what other alternatives I have to this annotation for setting this.
Cheers.
you can try to use something like this in your project
#Configuration
#Profile("custom-profile")
#ImportResource( {"file:path/additional-context.xml" } )
public class ConfigClass { }
and configure additional packages scanning in this file then.
<context:component-scan base-package="x.y.z.service, x.y.z.controller, x.y.z.dao" />
Note, your resource additional-context.xml declared as external and you have ability to change it without rebuilding war at all.
#ImportResource will be handled after declaring profile "custom-profile" as active. It's a safe way for starting application with "default configuration" without any "additional-context.xml" file of disk.
Have you tried this:
#SpringBootApplication(scanBasePackages={"path1", "path2"})
Hope this helps :)
Related
I started setting tests for my project. It taked a while to settup the context. Now that I have achived it, I am getting trouble to make the tests work on multiple enviroments.
I set up the application test with these anotations:
#ContextConfiguration({"/applicationContext-test.xml", "/appServlet/servlet-context.xml"})
#WebAppConfiguration
#RunWith(SpringJUnit4ClassRunner.class)
#AutoConfigureMockMvc
public class ControllerUserTest {}
The trouble comes from the config file. When running the project on enviroments a parent config file values get replaced by environment ones. For testing for some reason I don't find a way to reproduce this. Meanwhile I setted up the parent config file with develop variables. To resolve this, the parent file was restored and using anotations like #TestPropertySource(properties="env=pre") or #ActiveProfiles("pre"). Neither way the parent file variables are replaced by environment ones. This kind of annotationa allows to change profile from class but It would be intereset to change the envoroment it from command line.
I also tried to use #BeforeClass annotation but the context annotations are executed before it.
To add more info about how the config is read. On "/appServlet/servlet-context.xml" I have a component-scan that points to a package where ApplicationConfig.java is stored . This config has this anotations #Configuration #PropertySource(value = { "classpath:nsf.properties" }).
In which direction I have to investigate to achieve my goal? Thanks in advance
I have two spring boot apps. The first is an API library that's pulled into the second (a web application) as a dependent jar.
The first, is an API library that houses functions to create "cases" in an IBM solution. It's a standalone type jar that has a service class that exposes methods like getCaseXMLForDocId(String docId) or createCaseForAgreementNumber(String agreementNumber)
The first library called CaseInvocationAPI has an application.properties file which has several properties. For example:
caseinvocation.query.fetchNonProcessedCaseXml=SELECT Id, CaptureSource, AgreementNumber, CaptureSourceID FROM CaseInvocation WHERE ProcessIndicator IN (0, 2)
The service class has a method which makes a query, grabbing that query string from a member variable that's populated with a property from the application.properties file:
#Value("${caseinvocation.query.fetchNonProcessedCaseXml}")
private String selectNonProcessedQueryString;
The second SpringBoot app is a webapplication that has REST controllers. These controllers expose endpoints that call the CaseInvocationAPI library, specifically the CaseInvocationService class.
The problem I am having is that when the SpringBoot WEBAPPLICATION starts up, the context configuration blows up with the following error:
Caused by: java.lang.IllegalArgumentException: Could not resolve placeholder 'caseinvocation.query.fetchNonProcessedCaseXml' in string value "${caseinvocation.query.fetchNonProcessedCaseXml}"
at org.springframework.util.PropertyPlaceholderHelper.parseStringValue(PropertyPlaceholderHelper.java:174)
at org.springframework.util.PropertyPlaceholderHelper.replacePlaceholders(PropertyPlaceholderHelper.java:126)
at org.springframework.core.env.AbstractPropertyResolver.doResolvePlaceholders(AbstractPropertyResolver.java:219)
at org.springframework.core.env.AbstractPropertyResolver.resolveRequiredPlaceholders(AbstractPropertyResolver.java:193)
at org.springframework.context.support.PropertySourcesPlaceholderConfigurer$2.resolveStringValue(PropertySourcesPlaceholderConfigurer.java:172)
at org.springframework.beans.factory.support.AbstractBeanFactory.resolveEmbeddedValue(AbstractBeanFactory.java:813)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1039)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1019)
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:566)
at org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:88)
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:349)
... 45 common frames omitted
It appears that when the WebApp starts up, when it's trying to build the classes from the dependent jar, those properties are not being found.
I didn't think I had to copy each and every property out of the dependent jar application.properties file into an application.properties file in the Webapp project.
Why isn't the WebApp project (CaseInvocationWebApp) picking up the application.properties file from the dependent jar file (CaseInvocationAPI)?
I checked the compiled jar file (CaseInvocationAPI) and the application.properties file is there in the jar.
Looks like the problem was related to the fact that both the child jar and the webapp have application.properties files. I wasn't aware that the parent WebApp application.properties sort of overwrites the others (ignoring all others really).
Special thanks to Paschoal for his response.
You can see details on the answer here:
Adding multiple application.properties files
There are 3 ways (that I can think of) you can approach this:
The dependency, API library, should not have an application.properties since it's a library and not an executable Spring boot application in itself. You only define the properties in your web application's application.properties, even for the API library.
But, here the assumption is that you have access to the API library jar.
You can redefine all the properties in web application's application.properties essentially overriding them.
Explicitly configure the Spring boot application to use both the application.properties files, each for different set of properties.
Caveat: The file names must be different, as config location is classpath for both.
#SpringBootApplication
public class WebApplication {
public static void main(String[] args) {
SpringApplication app = new SpringApplicationBuilder(WebApplication.class)
.properties("spring.config.location=classpath:api-application.properties,classpath:application.properties")
app.run(args);
}
}
I have a Spring Boot application. I have several customers who each have a version of this application, with a few custom #Component, #Service, etc, classes. I am trying to abstract those custom Spring beans out into library jars which I can place on the classpath and load dynamically.
For example, suppose I have an interface in my core library:
public interface MyInterface {
String doSomething();
}
I have a different implementations of MyInterface in my customer-specific libraries, all annotated with #Component.
I want to be able to put
#Autowired
List<MyInterface> components;
in my main application.
Then, I want to just place my main application in a folder with the appropriate customer's library (or multiple) and run it with
java -cp . -jar my-application.jar
and have that #Autowired pick up the customer's specific components.
Is this possible? I don't want to use #Import in the main application, because that requires knowing which customer's library is being loaded.
I did figure this out. Here is a demo project for loading #Component objects from plugins at runtime.
https://github.com/imnotpete/plugin-demo
It uses the loader.properties file to specify a folder to add to the classpath, and then #ComponentScan can include any jars from that folder when autowiring.
loader.properties:
loader.path=plugins
I'm working on a Spring Boot application. I want to provide a (pretty rudimentary) plugin system. Initially I was hoping it'd be enough to just add the JAR to the classpath like so:
URLClassLoader sysloader = (URLClassLoader) ClassLoader.getSystemClassLoader();
Class sysclass = URLClassLoader.class;
Method method = sysclass.getDeclaredMethod("addURL", URL.class);
method.setAccessible(true);
method.invoke(sysloader, new File("./plugin/plugin.jar").toURI().toURL());
SpringApplication.run(Application.class, args);
In the plugin.jar is a class annotated with #Controller and a RequestMapping. The context loads fine and the constructor of the controller is getting called as well. However, looking at the logs, I can see that the RequestMapping did not get picked up.
Additionally, if I try to #Autowire a JpaRepository in the plugin controller it fails complaining that it can't find the repository interface class (which I'm guessing is some problem that arose from me messing around with the ClassLoader).
Just autowiring the repository in my main application works fine though, so it shouldn't be an issue with its configuration.
Is there something I'm doing wrong? Can I maybe configure Springs ApplicationContext or its ClassLoader to make this work correctly?
To summarise, I want to load some Controllers (and maybe other Spring components) at runtime from an external JAR in another folder.
For now I just ended up declaring profiles in my application pom for my various plugins and I just compile it using the profiles of the plugins that I want. It's not very dynamic but at least I can separate the plugin development from the application development completely and have Spring pick up on all of the plugin's components.
This is not exactly what I wanted, but I figured I'd describe how I "solved" it anyway. If anyone knows a way to make this work with external JARs I'd be happy to accept that answer instead!
I solved this by importing the dependency in which my controller resides, and then calling the packages of the controller and the main run method the same name (but in different projects). It's a hack, but it works.
I have a module/jar that I've created and am using as a util library. I created a service in there like so:
#Service
public class PermissionsService { ... }
... where this resides in a package here: com.inin.architect.permissions and in my main application, I'm referencing/loading this jar (i.e. set as a dependency in the maven POM.xml file for the app) like so:
<dependency>
<groupId>com.inin.architect</groupId>
<artifactId>permissions</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
and within the application I want to use that service like:
#Autowired
PermissionsService permissions
In the application's spring setup, I've got this:
#Configuration
#EnableWebMvc
#ComponentScan(basePackages = { "com.inin.generator", "com.inin.architect.permissions" })
public class WebConfig extends WebMvcConfigurerAdapter implements ServletContextAware { }
However when I run my application under tomcat, it complains that there isn't a bean for the PermissionsService: "org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type ..."
So, how can I bring over the bean from the lib into my application? Surely there's a way. Do you have to set the library up as a full blown spring MVC application so that this can work? i.e. do you have to have #Configuration and #ComponentScan setup in the lib as well?
You have to scan at least the package containing the class you want to inject. For example, with Spring 4 annotation:
#Configuration
#ComponentScan("com.package.where.my.class.is")
class Config {
...
}
It is the same principle for XML configuration.
Just a note on this, but you could decouple your dependency from spring. In your #Configuration class create
#Bean public PermissionsService permissionsService(){
return new PermissionsService()
}
This will also allow it to be injected. Not that you have to remove your spring annotation, just an option making it potentially usable outside of spring.
Ok - i had exactly the same problem - i wanted to autowire a mongo db repository interface from an external jar.
I could autowire every bean from that jar with using
#SpringBootApplication(scanBasePackages = {"com.myrootpackage"})
However - autowiring the interface always failed with "Could not find blablabla..."
But the interface was in the same package as the beans i could import.
It turned out that searching for the mongo db interfaces is NOT taking the scanBasePackages from the #SpringBootApplication into consideration!
It has to be explicitly configured via
#EnableMongoRepositories(basePackages = {"com.myrootpackage"})
Or you could move the main class "up" so the default searching works also for the mongo interfaces. So i understood the problem and found a solution. But i am still a bit unhappy because i need to configure the same lookup path twice. I find it stupid honestly.
I faced the same issue while scanning other classes from other project dependencies, The scanning solution depends on the type of classes you need to scan as follows:
if they are normal #Component, #Service annotations use
#ComponentScan({"com.mypackge1","com.mypackage2"})
If the type of classes are domain objects based on entities use
#EntityScan("com.mypackge1.domain")
If JPA repository classes
#EnableJpaRepositories(basePackages = {"com.mypackage.repository"})
If Redis repository classes use
#EnableRedisRepositories(basePackages = {"com.mypackage.repository"})
Same for Mongo, etc.
You can import application-context.xml for com.inin.architect.permissions in the following manner inside your main application.
<import resource="classpath:/permissionApplicationContext.xml" />
This will enable you to autowire beans from com.inin.architect.permissions that you have defined.