Using spring boot, deploying on ubuntu tomcat with war
in application.properties,
logging.path = classpath:/log
does not work on local machine or deployed at all. I did check my target/classes/log folder too.
it used to work with
logging.path = src/log
spring.log would be generated.
what am I doing wrong?
logging.path needs to be a directory, not a classpath.
This should work:
logging.path = /log
See this part of the docs for all the legal combinations:
http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-logging.html#boot-features-logging-file-output
You probably shouldn't be trying to log to your classpath in the first place. And it likely doesn't make sense in the context of a deployed application. If you imagine an application packaged as a self-contained executable JAR, your classpath essentially becomes your JRE folder + your JAR. How would you be able to write to a file inside the JAR?
Best bet is to choose a folder somewhere on your file system and log to that. I usually use the same location where I put my JAR file, or use a /var/log/... folder to log to. If it is something only temporary, then I would log it to /tmp, but be careful with that as /tmp can sometimes have cleanup jobs that conflict with your logging settings.
Related
I am unable to find another article that solves my problem but am happy to hear about one if you know the answer.
I have a RESTful service built in Java with Eclipse. It uses Spring and all of its bells and whistles.
After much work with configuration files, I am able to build the service into a war file, deploy it to my Tomcat webapps folder, and run it from standalone Tomcat. However, it still throws several errors on start when I try to start it from a service defined within Eclipse. The errors are the same errors that I was seeing before I got the config files correct for standalone Tomcat. The errors are about the inability to create the required beans because of references to properties that can't be found.
How did I get it running in Tomcat? I added a couple of .properties files to define properties needed by the beans that get launched at startup and then added a 'set CLASSPATH=...' line to the setenv.bat file in the Tomcat bin folder. This new line adds the properties files into the CLASSPATH. That seems to have fixed everything from standalone Tomcat.
So, my question is, "How do I make these same changes inside my Eclipse server?" I have added the properties folder with the property files under the config folder in Eclipse, just like it is in my native Tomcat folders, but I do not know how to modify the CLASSPATH string to specifically point to my .properties files (as I have done in the setenv.bat file for standalone Tomcat).
I think I understand the problem, but have no idea about the solution.
Thanks for listening.
Dave
Eclipse does not use any *.sh/*.bat files to startup Tomcat. In order to modify the way the server is started you have to open the configuration UI of the server by double-clicking on the server in the Servers view.
From there you will be able to modify the classpath of the system classloader through "Open launch configuration".
Another important setting is "Server path" which tells Eclipse, the value of $CATALINA_BASE. You can modify it only after removing all modules and cleaning the server. It is useful to set it to an easily accessible directory: this way you can verify directly that Eclipse didn't mess up your application deployment (sometimes it "forgets" to copy some libraries).
The "Configuration path" setting tells Eclipse where to find the files (but not subdirectories) that will be copied into $CATALINA_BASE/conf.
Remark: if your application requires you to add libraries to the top classloader, there is probably a problem in your project. The "missing" libraries should be added to WEB-INF/lib of your application instead: look into the "Deployment assembly" of your Eclipse project configuration.
I am trying to create an environment where the application build remains same across environments. To support this I've externalized any property files to be read from an external directory e.g.$CATALINA_BASE/conf/app1/config
We use ehcache for caching (for CAS) and for replication between instances I seem to get the errror if the ehcache-replicated.xml is not present in the WEB-INF/classes directory. I've tried updating the setenv.sh of Tomcat so:
CLASSPATH=$CATALINA_BASE/conf/app1/config/ehcache-replicated.xml
export CLASSPATH
I also tried adding to JAVA_ENDORSED_DIRS but none of them seem to work. Any ideas?
A classpath entry is a directory, not a file. So try CLASSPATH=$CATALINA_BASE/conf/app1/config, it might work.
I am saying might because Tomcat is applying class loader isolation. A war won't see the classpath of the application server. So, it depends where you are setting the classpath.
In general, adding the classpath entry in catalina.properties shared.loader works. But that's from the top of my head.
I am using weblogic 10.3.4, I am trying to write log with log4j. but at runtime my application is not getting any log4j.properties. even this is not generating any warning as "initialization of log4j has error".
I have tried my properties file to put in src folder, classes folder and then I created one jar and put it in domain lib. still its not picking. even when I am writing log with same jar in standalone application, its working fine.
please help me with valuable suggestions.
I tried the solution proposed at Oracle forums.
Excerpt from that link at Oracle forums:
I've only modified the scritp startWebLogic.cmd:
set LOG4J_CONFIG_FILE=log4j.xml
set SAVE_JAVA_OPTIONS=%JAVA_OPTIONS% -Dlog4j.configuration=%LOG4J_CONFIG_FILE%
#REM set SAVE_CLASSPATH=%CLASSPATH%
set SAVE_CLASSPATH=%CLASSPATH%;C:\Oracle\Middleware\user_projects\domains\domain\config
In this way I've put all the config folder inside the classpath, and I can use it in future to hold other libraries configuration files (for example oracle coherence config).
I tried this approach on a different properties file as well and that worked well!
You need to either specify where the application should find its log4j.properties, or put it onto the classpath of the application. Where the classpath is varies, but in general WEB-INF/classes should work. Other options depend upon how you're deploying the application.
A better long term strategy is to configure your system so that you can change the log4j.properties depending upon the environment. When you're in production, you won't want all of the debug information to appear. Look at the answer to this question or this question for more ideas. One strategy is to define a variable on the command line which gets picked up and defines a directory which contains your configuration files. This works for Tomcat, but there may be other, better, strategies for Weblogic.
It is not a good idea to change the configuration of your server, in particular, don't replace the log4j.jar or log4j.properties in your server directories. The server will depend upon the version that it was designed to use, which may or may not be the same as your version. You can do everything you need to do by changing the war that you're deploying.
I have used this code:
ClassLoader cl = this.getClass().getClassLoader();
URL log4jCfg = cl.getResource(configFile);
if (log4jCfg != null) {
DOMConfigurator.configure(log4jCfg);
}
log.info("log4j is now working on Web App.");
In my case, we used XML configuration:
log4jCfg = "mylog4j.xml";
In WebLogic, we were able to place such file (mylog4j.xml), equivalent to your log4j.properties file, at WebLogic's domain path (specific to the domain were we deploy). This means that domain folder belongs to your application's path. I just tested it with Web applications, I'm not sure if with SOA or EJB projects it works the same way.
When you deploy any application on any server that application should use servers log4j jar.
So if you have added any log4j jar in your application jar/tar/ear, remove it and copy log4j.properties file in the conf folder of the server from where server is picking its configuration files. Or just copy your log4j property content in servers log4j property file.
When I put a new war file in the webapps directory and restart tomcat, my war file is exploded but the servlets are not available and their respective log files are not created in the logs directory. When I bounce tomcat again, then the servlets are available and the log files are created. I'm assuming I have setting(s) not correct within tomcat, but I'm not sure where to start.
Does anyone know the cause of my current situation? Or even what parameters to review?
New Additional/Comments: Our setup allows us to have our app 'myApp' be the default application that is seen at root of our URL. On the first starting of tomcat, I can get to myApp by going to /myApp/index.html - whereas on the second start of tomcat I can then just goto and myApp/index.html is displayed.
My welcome file list is the 'myApp/index.html'
I had a similar problem with Tomcat 6.0.26. I worked around it by deleting the exploded webapps before copying the new war file to the webapps directory. Maybe a little kludgy, but it solved my problem.
http://tomcat.apache.org/tomcat-6.0-doc/config/context.html
antiJARLocking
If true, the Tomcat classloader will take extra measures to avoid JAR file locking when resources are accessed inside JARs through URLs. This will impact startup time of applications, but could prove to be useful on platforms or configurations where file locking can occur. If not specified, the default value is false.
have you set unpackWars and autoDeploy params to true in your server.xml file?
Try to do unpackwars=false and always make sure tomat is not running when you do deployment try to avoid hot deployment...
I am running several webapps on Jetty 6 through Apache. They are set to hot deploy using .xml files in the contexts/ directory. Those .xml files simply define WebAppContext instances and tell them where to look for a WAR file. `touch'-ing their contexts/.xml files picks up changes to JSPs defined in the relavnt WAR file, which is great.
The problem is that changes to the JARs contained in the WAR file's WEB-INF/lib folder are not picked up. I assume that this is because these JARs are cached somewhere. That assumption is based on the fact that restarting Jetty picks up the changes.
So, the question is: Is it possible to turn off this caching behavior or in some other way get WebAppContext instances to pick up library changes? If so, how?
JBoss hot deploy scanning doesn't check the lib folder:
http://community.jboss.org/wiki/HotDeployLibDirectory
Not sure if Jetty has the same behaviour, but, you could try moving one of your jars into the same folder as one of your jsps to see if this is the case.
If that's not an option then this might help:
http://www.jroller.com/larrywilliams/entry/jetty_hot_deploy
You need to set the scanInterval property to a number larger than zero.
See more here