I want to load my Spring application context via annotations like this:
#RunWith(SpringJUnit4ClassRunner.class)
#ContextConfiguration(locations = { "file:/path/to/spring-context1.xml", "file:/path/to/spring-context2.xml"})
I am trying this because the context file is not in my classpath.
I've read several times that this was possible but it does not seem to work.
So my question is: "Is this really possible and am I doing something wrong?
I've got another question if this happens to be possible: if I want to use a relative path instead of an absolute one, from where should it be relative? From the pom.xml location?
As said in the comments of my first post, the problem came from me ;)
So the answers are :
yes, you can use the "file:" prefix to set your Spring context
yes, you can use relative path, relative to the pom.xml directory
Hope this helps.
Related
Spring Boot supports Kotlin data classes for #ConfigurationProperties.
#ConstructorBinding
#ConfigurationProperties(prefix = "prefix")
data class AppProperties (
val something: String
)
But val and #ConstructorBinding has some limitations. You cannot alias one variable to another. Let's say you're running in Kubernetes and want to capture the hostname, which is given by the env var HOSTNAME. The easiest way to do this is to apply #Value("\${HOSTNAME}:)" to a property, but it only works for a mutable property and without constructor binding.
The Spring Boot GitHub issue tracker says:
STOP!! Please ask questions about how to use something, or to understand why something isn't
working as you expect it to, on Stack Overflow using the spring-boot tag.
So, is this a known limitation or should I create a ticket for them to fix it?
Edit:
Opened https://github.com/spring-projects/spring-boot/issues/25552
#ConfigurationProperties is an alternative to #Value and the two are not designed to be used together. It may work with JavaBean-style binding but that would be by accident rather than by design and it shouldn't be relied upon.
Instead of using #Value to alias something bound via #ConfigurationProperties, it's recommended that you do so via some other means. For example you could use one of the approaches suggested in this answer that Marcos Barbero linked to in the comments on your question. Alternatively, you could take some inspiration from this example in the documentation and use a placeholder in application.properties:
prefix.something=${hostname}
Another option would be to register via META-INF/spring.factories an implementation of EnvironmentPostProcessor that adds a PropertySource to the environment to set up the desired aliasing. For the time being, this is probably the best approach if you want to do something in a reusable library. There's an open issue to remove some of the ceremony that's currently involved.
I have a executeable jar what I want to configure by properties outside of the jar. What works fine is application.properties, when putting it to config folder close to the jar. But I have a second property-file what seems not to be picked up and I would like to have the best practice for that.
The folder config looks like:
In the config-folder you will find:
Both property-files are also in the src/main/resources folder.
My StartClass looks like:
#SpringBootApplication
#PropertySource("migration-shrink.properties")
public class MigrationShrinkApplication implements CommandLineRunner {}
My bat file looks like:
java -jar migration-shrink-0.0.1-SNAPSHOT.jar -Dspring.config.location=./config/migration-shrink.properties
I wanted to separate Spring-Configuration from Application-Configuration, thats why I have two different property-files.
Thank you!
The #PropertySource annotation is not necessary.
As of Spring Boot 2.0, you can declare additional locations with:
-Dspring.config.additional-location=./config/migration-shrink.properties
Keep in mind that those additional locations are searched before others, so values can be overridden in the other locations.
See the Spring Boot reference documentation.
I'm working in:
Eclipse (Version: Neon.1a Release (4.6.1))
, using:
Jersey 2.25.1
Jersey MVC
Apache Tomcat 7.0.76.
Here's the structure of my application:
Classes:
Jsp:
I'm configuring my application by extending ResourceConfig:
AppConfigs.java.
Here's the resource class:
ForumsController.java
The problem is that I get 404-Not found (for: http://localhost:8080/StudSiteProj/).
Can you, please, help me understand what's the cause?
I specified an absolute path in return new Viewable(..), so I guess the application should search for index.jsp using this path. Why isn't this working then?
I finally found the solution.
I found 2 problems:
First problem
Cause:
The way #ApplicationPath annotation was written.
Conclusion:
It should not be like:
or
or
Solution:
So now my AppConfigs class is:
Second problem
Cause:
JspMvcFeature.TEMPLATE_BASE_PATH property was not set.
Conclusion:
I understood that this property might be what's missing by looking in apidocs here. It said that:
So, if there isn't one, I have to set some.
Solution:
I set it to: /WEB-INF/app/views
Now, my AppConfigs class looks like this:
The resource class ForumsController is now:
See, it's only:
, because the value in JspMvcFeature.TEMPLATE_BASE_PATH will be prefixed to it. So "index.jsp" will be searched in:
This path is relative to servlet context path ( ex.: for my project, named StudSiteProj, the context path is /StudSiteProj).
Here I worked with absolute paths (paths specified in Viewable).
But there exists another approach in Jersey MVC (relative paths).
Here's my answer to my question =) on another stackoverflow page.
can someone please tell me where I can find the source code that processes #RequestMapping annotation. I want to make a similiar annotation.
I know it's somewhere on https://github.com/spring-projects/spring-framework/
But i haven't found so far where the actual processing takes place.
You can simply plug #RequestMapping text to the search field on the top of GitHub project page to see where that class is used.
Here is the direct link. https://github.com/spring-projects/spring-framework/blob/1204d2aef4afdefb4ba73c86565aab3f5b2a6931/spring-webmvc/src/main/java/org/springframework/web/servlet/mvc/annotation/DefaultAnnotationHandlerMapping.java
Spring-namespaces allows you to define your own structure how spring beans could be configured. Very cool.
I have to use a 3rd party software (Assentis Docbase) which defines in its spring.schemas the following (example below simplified)
http\://com.apress.prospring2/ch07/custom.xsd=custDir:/custom.xsd
Meaning: If user defines in its spring-xml with schema-location: "http://com.apress.prospring2/ch07/custom.xsd" spring will validate this file against custom.xsd.
custDir is a directory OUTSIDE the provided jar. Does anyone have an idea how I can set this custDir to point to a valid path during junit test? I already tried -DcustDir=/pathToXsd/ but it did not work.
If I remove custDir than everything works as expected, but I can not remove it from provided spring.schemas since it is 3rd party software.
Maybe this is an issue how property-files are handled in java but I have no idea.
You may be able to "override" this entry by providing your own custom spring.schemas file with the same entry but with a location to your custom xsd file. The catch is that this is highly dependent on the order in which the spring.schemas are loaded up, but could be worth a try.
Since custDir is not a place holder, you cannot replace it the way you are doing it, I am surprised that the third party schema location is outside of the classpath.
The syntax of spring.schemas I provided in my question is a properitary definition of 3.rd party software. They implemented there own EntityResolver which manually reacts on "custDir:" and starts some magic algorithm. So I came to the following workaround.
You have to create your own my_spring.schemas which must be live in META-INF/. Than you have to make sure that spring loads my_spring.schemas and NOT spring.schemas.
I achieved it with implementing my own TestingContext which is a subclass of ClassPathXmlApplicationContext. In TestingContext I overwrote method protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws IOException and filled it with implementation from org.springframework.context.support.AbstractXmlApplicationContext. The only change I made was to line beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this)) to beanDefinitionReader.setEntityResolver(new PluggableSchemaResolver(getClassLoader(), "META-INF/my_spring.schemas). And voila if I use TestingContext my own my_spring.schemas is loaded.
Drawback with this solution is that you have to provide all xsd in your jar because the default name, where spring looks up definitions has been changed.