I have a Spring Boot 1.3 application (deployed as .war) that needs to be able read a .properties file from the following location:
WEB-INF/application.properties (outside the classpath, but relative to the app root folder)
...as opposed to:
WEB-INF/classes/application.properties(inside the classpath, gets loaded automatically)
What worked in Spring Boot 1.3 was the following #PropertySource annotation:
#SpringBootApplication
#PropertySource(value = {"WEB-INF/application.properties"})
public class MyApplication {
public static void main(String[] args) {
SpringApplication.run(MyApplication.class, args);
}
}
It correctly fetched the .properties file relative to the app root. However that stops working after an update to Spring Boot 1.4.0.RC1.
Since then I've tried the following:
#PropertySource("classpath:../application.properties")
#PropertySource("file:WEB-INF/application.properties")
and also
spring.config.location=classpath:../
spring.config.location=file:src/main/webapp/WEB-INF/
spring.config.location=WEB-INF/application.properties
But haven't had any luck loading the .properties.
I'd normally put the .properties file inside the classpath, but in this case this is NOT an option due to the way our deployment works on a remote location.
I'd also prefer to not use an absolute path, as that'll be a nightmare to support with multiple customers.
Edit: Just to be clear - the .properties I'd like to read aren't located outside the JAR (in my case - WAR) file, but inside - just not on the classpath, but directly in the WEB-INF/ folder where normally other resources (pages, images) would be.
As I mentioned in duplicate SO question:
Put this line into your application.properties:
logging.config=file:log4j.xml
Second option is to pass system variable to -Dlogging.config=file:log4j.xml
In this case it is expected to be located in current directory outside of the JAR file.
REACTION ON COMMENT:
If you are using WAR file, your main class is not used at all. So PropertySource annotation doesn't have any effect there.
If the .properties is packed in the .war file. Then you can try the following (assuming that the WEB-INF directory is located in the root of the .war file.
#PropertySource("classpath:/WEB-INF/conf/application.properties")
Turns out this issue was caused by a bug with the SpringBootTestContextBootstrapper in Spring Boot 1.4.0.RC1: https://github.com/spring-projects/spring-boot/issues/6371
Related
I'm trying to create app based on Jetty 9.4.20 (embedded) and Vaadin Flow 14.0.12.
It based on very nice project vaadin14-embedded-jetty.
I want to package app with one main-jar and all dependency libs must be in folder 'libs' near main-jar.
I remove maven-assembly-plugin, instead use maven-dependency-plugin and maven-jar-plugin. In maven-dependency-plugin i add section <execution>get-dependencies</execution> where i unpack directories META-INF/resources/,META-INF/services/ from Vaadin Flow libs to the result JAR.
In this case app work fine. But if i comment section <execution>get-dependencies</execution> then result package didn't contain that directories and app didn't work.
It just cannot give some static files from Vaadin Flow libs.
This error occurs only if i launch packaged app with ...
$ java -jar vaadin14-embedded-jetty-1.0-SNAPSHOT.jar
... but from Intellij Idea it launch correctly.
There was an opinion that is Jetty staring with wrong ClassLoader and cannot maintain requests to static files in Jar-libs.
The META-INF/services/ files MUST be maintained from the Jetty libs.
That's important for Jetty to use java.util.ServiceLoader.
If you are merging contents of JAR files into a single JAR file, that's called a "uber jar".
There are many techniques to do this, but if you are using maven-assembly-plugin or maven-dependency-plugin to build this "uber jar" then you will not be merging critical files that have the same name across multiple JAR files.
Consider using maven-shade-plugin and it's associated Resource Transformers to properly merge these files.
http://maven.apache.org/plugins/maven-shade-plugin/
http://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html
The ServicesResourceTransformer is the one that merges META-INF/services/ files, use it.
As for static content, that works fine, but you have to setup your Base Resource properly.
Looking at your source, you do the following ...
final URI webRootUri = ManualJetty.class.getResource("/webapp/").toURI();
final WebAppContext context = new WebAppContext();
context.setBaseResource(Resource.newResource(webRootUri));
That won't work reliably in 100% of cases (as you have noticed when running in the IDE vs command line).
The Class.getResource(String) is only reliable if you lookup a file (not a directory).
Consider that the Jetty Project Embedded Cookbook recipes have techniques for this.
See:
WebAppContextFromClasspath.java
ResourceHandlerFromClasspath.java
DefaultServletFileServer.java
DefaultServletMultipleBases.java
XmlEnhancedServer.java
MultipartMimeUploadExample.java
Example:
// Figure out what path to serve content from
ClassLoader cl = ManualJetty.class.getClassLoader();
// We look for a file, as ClassLoader.getResource() is not
// designed to look for directories (we resolve the directory later)
URL f = cl.getResource("webapp/index.html");
if (f == null)
{
throw new RuntimeException("Unable to find resource directory");
}
// Resolve file to directory
URI webRootUri = f.toURI().resolve("./").normalize();
System.err.println("WebRoot is " + webRootUri);
WebAppContext context = new WebAppContext();
context.setBaseResource(Resource.newResource(webRootUri));
I try run my R Script within JavaFx. I use Renjin for this purpose and it seems to work properly with statements I run internally. But I want to run an external R Script. The project is set up with Maven so the path should be easy as the R Script is in the resources folder. The path works when I load FXML files, so I'm pretty confused why it can't find my Script.
Here's a short example:
package survey;
import javax.script.*;
import org.renjin.script.*;
import java.io.FileReader;
public class calcFunction {
public static void main(String[] args) throws Exception {
// create a script engine manager:
RenjinScriptEngineFactory factory = new RenjinScriptEngineFactory();
// create a Renjin engine:
ScriptEngine engine = factory.getScriptEngine();
engine.put("x", 4);
engine.put("y", 5);
engine.eval(new FileReader("/test.R"));
}
}
Is something missing? Thanks in advance!
EDIT1:
With my FXML files it works with the "/" path like this:
root = FXMLLoader.load(getClass().getResource("/moduleDa.fxml"));
EDIT2:
Someone who deleted his comment proposed this:
engine.eval(new FileReader(new File(".").getAbsolutePath()+"/test.R"));
It works if the script is in the root directory, where the pom.xml file is located. #James_D made it work so the R script can be located in the resources folder - thanks a lot!
If your R script is bundled as part of the application, it can't be treated as a file - you need to treat it as a resource. Typically, you will deploy your application as a Jar file, and the resources will be elements within that jar file (they won't be files in their own right).
So just treat the R script as a resource and load it as such. I don't know the renjin framework, but I assume ScriptEngine here is a javax.script.ScriptEngine, in which case ScriptEngine.eval(...) takes a Reader as a parameter, and so (if your R script is located in the root of the class path) you can do
engine.eval(new InputStreamReader(getClass().getResourceAsStream("/test.R")));
BLUF: I'm getting a stackoverflow starting my Liberty server with a single war file before it reaches any of my code. I can't debug what is causing the problem. I tried adding trace statements to server.xml but never got files I could interpret (were binary) and trying to Open Log Files had no choices available (greyed out). If anyone has any ideas how to determine what is causing the stack overflow I'd appreciate the help. Thanks in advance. My code does use #Inject but I don't think this is the issue as all works fine if I move code from a separate project/jar into the war project.
Running wlp 17.0.0.1 when starting a single war using shared libraries to jar files in a single directory, I get a StackOverflowError before any of my code is reached (based on setting breakpoints in the RestServicesApplication and any static initializers).
This problem only occurs when some classes have been moved to a separate project and therefore into a separate jar (e.g., moving them back to the war project allows all to run fine).
I've checked that all classes and methods references are public. I'm calling public static methods in the new jar file.
I'm not sure how to figure out the problem as no references to my code are in the ffdc files in the stack traces.
I've verified the needed classes are in the jar file and there are no duplicate classes being referenced.
Essentially, the class in the war file has a call like:
public static JSONObject processFuzzyMatch(ID session,
ID userID, JSONObject request)
throws ILDException {
try {
return NLUFuzzyEntityMatcherFunction.processFuzzyMatch(request);
} catch (Exception e) {
throw new ILDException(e);
}
}
and NLUFuzzyEntityMatcherFunction is in the jar file declared as:
public static JSONObject processFuzzyMatch(JSONObject request)
throws Exception
Here is an example of the reported problem with the last line repeating (for the stack overflow...)
Stack Dump = com.ibm.ws.container.service.state.StateChangeException: java.lang.StackOverflowError
at com.ibm.ws.container.service.state.internal.ApplicationStateManager.fireStarting(ApplicationStateManager.java:33)
at com.ibm.ws.container.service.state.internal.StateChangeServiceImpl.fireApplicationStarting(StateChangeServiceImpl.java:51)
at com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.preDeployApp(DeployedAppInfoBase.java:376)
at com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.deployApp(DeployedAppInfoBase.java:403)
at com.ibm.ws.app.manager.war.internal.WARApplicationHandlerImpl.install(WARApplicationHandlerImpl.java:66)
at com.ibm.ws.app.manager.internal.statemachine.StartAction.execute(StartAction.java:141)
at com.ibm.ws.app.manager.internal.statemachine.ApplicationStateMachineImpl.enterState(ApplicationStateMachineImpl.java:1253)
at com.ibm.ws.app.manager.internal.statemachine.ApplicationStateMachineImpl.run(ApplicationStateMachineImpl.java:866)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.StackOverflowError
at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:242)
at java.io.File.exists(File.java:819)
at com.ibm.wsspi.kernel.service.utils.FileUtils$3.run(FileUtils.java:88)
at com.ibm.wsspi.kernel.service.utils.FileUtils$3.run(FileUtils.java:85)
at java.security.AccessController.doPrivileged(Native Method)
at com.ibm.wsspi.kernel.service.utils.FileUtils.fileExists(FileUtils.java:85)
at com.ibm.ws.artifact.loose.internal.LooseArchive$DirEntryInfo.matches(LooseArchive.java:232)
at com.ibm.ws.artifact.loose.internal.LooseArchive$DirEntryInfo.matches(LooseArchive.java:207)
at com.ibm.ws.artifact.loose.internal.LooseArchive.getEntry(LooseArchive.java:782)
at com.ibm.ws.artifact.overlay.internal.DirectoryBasedOverlayContainerImpl.getEntry(DirectoryBasedOverlayContainerImpl.java:838)
at com.ibm.ws.adaptable.module.internal.AdaptableContainerImpl.getEntry(AdaptableContainerImpl.java:113)
at com.ibm.ws.jsp.taglib.TagLibraryCache.loadWebInfMap(TagLibraryCache.java:613)
at com.ibm.ws.jsp.taglib.TagLibraryCache.loadWebInfMap(TagLibraryCache.java:629)
at com.ibm.ws.jsp.taglib.TagLibraryCache.loadWebInfMap(TagLibraryCache.java:629)
(above line repeats due to stack overflow)
This is a known problem on Liberty. The fix to that problem will be available on Liberty 17.0.0.3.
You can use some workarounds:
I assume you have a folder named WEB-INF within a jar. Change the folder name to something else. That folder name causes the JSP engine to go to the web module's WEB-INF (scanning everything again!), instead of the jar's WEB-INF.
Try setting the JSP configuration parameter disableTldSearch to true; this may be troublesome if you are using custom tag libraries. With the property set, all your custom TLD files need to be declared in the web.xml.
Disable CDI; I know this may not be possible for you as you mentioned you are using injections.
Somehow I screwed up the project settings for the jar project (likely because I'd copied the pom.xml from the Web project and forgot to change it to jar...). This may have resulted in the screwed up xml file in the /apps folder with an embedded reference to a non-existent war file (see below):
<?xml version="1.0" encoding="UTF-8"?>
<archive>
<archive targetInArchive="/WEB-INF/lib/ildMicroServices-1.0.0-SNAPSHOT.jar">
<dir sourceOnDisk="/csnext/ild/ild_framework/ildMicroServices/WebContent" targetInArchive="/"/>
<dir sourceOnDisk="/csnext/ild/ild_framework/ildMicroServices/target/classes" targetInArchive="/WEB-INF/classes"/>
<dir sourceOnDisk="/csnext/ild/ild_framework/ildMicroServices/target/test-
classes" targetInArchive="/WEB-INF/classes"/>
</archive>
<dir sourceOnDisk="/csnext/ild/ild_framework/ildRESTServices/target/m2e-wtp/web-resources" targetInArchive="/"/>
<dir sourceOnDisk="/csnext/ild/ild_framework/ildRESTServices/WebContent" targetInArchive="/"/>
<dir sourceOnDisk="/csnext/ild/ild_framework/ildRESTServices/target/classes" targetInArchive="/WEB-INF/classes"/>
<dir sourceOnDisk="/csnext/ild/ild_framework/ildRESTServices/target/test-classes" targetInArchive="/WEB-INF/classes"/>
</archive>
By deleting this embedded archive the problem went away.
I only found this after upgrading from Neon to Oxygen, and 17.0.0.1 to 17.0.0.2 and when setting up the new server using the old server's artifacts, I noticed the xml file in /apps didn't look correct.
I hope this helps somebody.
I am trying to access static resource (eg. first.html) packed inside the same .jar file (testJetty.jar), which also has a class which starts the jetty (v.8) server (MainTest.java). I am unable to set the resource base correctly.
The structure of my jar file (testJetty.jar):
testJetty.jar
first.html
MainTest.java
==
Works fine on local machine, but when I wrap it in jar file and then run it, it doesn't work, giving "404: File not found" error.
I tried to set the resourcebase with the following values, all of which failed:
a) Tried setting it to .
resource_handler.setResourceBase("."); // Results in directory containing the jar file, D:\Work\eclipseworkspace\testJettyResult
b) Tried getting it from getResource
ClassLoader loader = this.getClass().getClassLoader();
File indexLoc = new File(loader.getResource("first.html").getFile());
String htmlLoc = indexLoc.getAbsolutePath();
resource_handler.setResourceBase(htmloc); // Results in D:\Work\eclipseworkspace\testJettyResult\file:\D:\Work\eclipseworkspace\testJettyResult\testJetty1.jar!\first.html
c) Tried getting the webdir
String webDir = this.getClass().getProtectionDomain()
.getCodeSource().getLocation().toExternalForm();
resource_handler.setResourceBase(webdir); // Results in D:/Work/eclipseworkspace/testJettyResult/testJetty1.jar
None of these 3 approaches worked.
Any help or alternative would be appreciated
Thanks
abbas
The solutions provided in this thread work but I think some clarity to the solution could be useful.
If you are building a fat jar and use the ProtectionDomain way you may hit some issues because you are loading the whole jar!
class.getProtectionDomain().getCodeSource().getLocation().toExternalForm();
So the better solution is the other provided solution
contextHandler.setResourceBase(
YourClass.class
.getClassLoader()
.getResource("WEB-INF")
.toExternalForm());
The problem here is if you are building a fat jar you are not really dumping your webapp resources into WEB-INF but are probably going into the root of the jar, so a simple workaround is to create a folder XXX and use the second approach as follows:
contextHandler.setResourceBase(
YourClass.class
.getClassLoader()
.getResource("XXX")
.toExternalForm());
Or change your build tool to export the webapp files into that given directory. Maybe Maven does this on a Jar for you but gradle does not.
Not unusually, I found a solution to my problem. The 3rd approach mentioned by Stephen in Embedded Jetty : how to use a .war that is included in the .jar from which Jetty starts? worked!
So, I changed from Resource_handler to WebAppContext, where WebAppContext is pointing to the same jar (testJetty.jar) and it worked!
String webDir = MainTest.class.getProtectionDomain()
.getCodeSource().getLocation().toExternalForm(); ; // Results in D:/Work/eclipseworkspace/testJettyResult/testJetty.jar
WebAppContext webappContext = new WebAppContext(webDir, "/");
It looks like ClassLoader.getResource does not understand an empty string or . or / as an argument. In my jar file I had to move all stuf to WEB-INF(any other wrapping dir will do). So the code looks like
contextHandler.setResourceBase(EmbeddedJetty.class.getClassLoader().getResource("WEB-INF").toExternalForm());
so the context looks like this then:
ContextHandler:744 - Started o.e.j.w.WebAppContext#48b3806{/,jar:file:/Users/xxx/projects/dropbox/ui/target/ui-1.0-SNAPSHOT.jar!/WEB-INF,AVAILABLE}
has anyone tried to use a log4j.xml reference within a WinRun4j service configuration. here is a copy of my service.ini file. I have tried many configuration combinations. this is just my latest attempt
service.class=org.boris.winrun4j.MainService
service.id=SimpleBacnetIpDataTransfer
service.name=Simple Backnet IP DataTransfer Service
service.description=This is the service for the Simple Backnet IP DataTransfer.
service.startup=auto
classpath.1=C:\Inbox\DataTransferClient-1.0-SNAPSHOT-jar-with-dependencies.jar
classpath.2=WinRun4J.jar
classpath.3=C:\Inbox\log4j-1.2.16.jar
arg.1=C:\Inbox\DataTransferClient.xml
log=C:\WinRun4J-Service\SimpleBacnetIpDataTransfer\NBP-DT-service.log
log.overwrite=true
log.roll.size=10MB
[MainService]
class=com.shiftenergy.ws.App
vmarg.1=-Xdebug
vmarg.2=-Xnoagent
vmarg.3=-Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n
vmarg.4=-Dlog4j.configuration=file:C:\Inbox\log4j.xml
within the log4j.xml file, there is reference to a log file for when the application runs. if I run the java -jar -Dlog4j.configuration=file:C:\Inbox\log4j.xml ...., the log file is created accordingly. if I register my service and start the service, the log file does not get created.
has anyone had success using the -D log4j configuration, using winrun4j?
thanks
I think that you provided the vmarg.4 parameter incorrectly. In your case it has to be like:
vmarg.4=-Dlog4j.configurationFile=[Path for log4j.xml]
I am also using the same and in my case, it is working perfectly fine. Please see below example:
vmarg.1=-Dlog4j.configurationFile=.\log4j2.xml
Have you tried setting the path in your code instead:
System.setProperty("log4j.configurationFile", "config/log4j.xml");
I'm using a relative path to a folder named config that contains log4j.xml. An absolute path is not recommended, but may work as well.
Just be sure to set this before making any calls to log4j, including any log4j config settings or static method calls!
System.setProperty("log4j.configurationFile", "config/log4j.xml");
final Logger log = Logger.getLogger(Main.class);
log.info("Starting up");
I didn't specify the log4j path in the ini file, only placed log4j.xml file at the same place the jar was placed.
Also without specify the
System.setProperty("log4j.configurationFile", "config/log4j.xml");
In the Java project it was stored in (src/main/resources) and will be included in the jar, but it will not be that one used if placed outside the jar.