I have a web application which needs mybatis to connect to a sql server.
I have a separate property file as jdbc.properties which contains the dburl, username, password etc. and mybatis-config.xml file has following to read that
<properties resource="jdbc.properties"/>
If I add jdbc.properties file to the src folder it works fine.
But I have several other property files located at "catalina_home/bin/config" folder so I would like to move my jdbc.properties file also to that location.
But mybatis is not able to read the property file from their no matter how I changed the path to the resource.
However if I moved the jdbc.properties file to the "catalina_home/lib" folder it works. Therefore then I tries resource path like this "../bin/config" but it didn't worked either.
My question is, can I move the jdbc.properties file to the bin/config folder and let mybatis to read it from there.
EDIT: Since my production environment may change its CATALINA_HOME location I cannot give the full path to the config file location.
The reason that mybatis cannot find these properties files is that tomcat's bin/config folder is not in classpath of tomcat (or your web application) unlike $CATALINA_HOME/lib. And mybatis looks for file specified in resource attribute in classpath.
If you use url attribute you can specify full path name to file there.
<properties url="/full/path/to/you/jdbc.properties"/>
Related
In my web application I have to send email to set of predefined users like finance#xyz.example, so I wish to add that to a .properties file and access it when required. Is this a correct procedure, if so then where should I place this file? I am using Netbeans IDE which is having two separate folders for source and JSP files.
It's your choice. There are basically three ways in a Java web application archive (WAR):
1. Put it in classpath
So that you can load it by ClassLoader#getResourceAsStream() with a classpath-relative path:
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
InputStream input = classLoader.getResourceAsStream("foo.properties");
// ...
Properties properties = new Properties();
properties.load(input);
Here foo.properties is supposed to be placed in one of the roots which are covered by the default classpath of a webapp, e.g. webapp's /WEB-INF/lib and /WEB-INF/classes, server's /lib, or JDK/JRE's /lib. If the propertiesfile is webapp-specific, best is to place it in /WEB-INF/classes. If you're developing a standard WAR project in an IDE, drop it in src folder (the project's source folder). If you're using a Maven project, drop it in /main/resources folder.
You can alternatively also put it somewhere outside the default classpath and add its path to the classpath of the appserver. In for example Tomcat you can configure it as shared.loader property of Tomcat/conf/catalina.properties.
If you have placed the foo.properties it in a Java package structure like com.example, then you need to load it as below
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
InputStream input = classLoader.getResourceAsStream("com/example/foo.properties");
// ...
Note that this path of a context class loader should not start with a /. Only when you're using a "relative" class loader such as SomeClass.class.getClassLoader(), then you indeed need to start it with a /.
ClassLoader classLoader = getClass().getClassLoader();
InputStream input = classLoader.getResourceAsStream("/com/example/foo.properties");
// ...
However, the visibility of the properties file depends then on the class loader in question. It's only visible to the same class loader as the one which loaded the class. So, if the class is loaded by e.g. server common classloader instead of webapp classloader, and the properties file is inside webapp itself, then it's invisible. The context class loader is your safest bet so you can place the properties file "everywhere" in the classpath and/or you intend to be able to override a server-provided one from the webapp on.
2. Put it in webcontent
So that you can load it by ServletContext#getResourceAsStream() with a webcontent-relative path:
InputStream input = getServletContext().getResourceAsStream("/WEB-INF/foo.properties");
// ...
Note that I have demonstrated to place the file in /WEB-INF folder, otherwise it would have been public accessible by any webbrowser. Also note that the ServletContext is in any HttpServlet class just accessible by the inherited GenericServlet#getServletContext() and in Filter by FilterConfig#getServletContext(). In case you're not in a servlet class, it's usually just injectable via #Inject.
3. Put it in local disk file system
So that you can load it the usual java.io way with an absolute local disk file system path:
InputStream input = new FileInputStream("/absolute/path/to/foo.properties");
// ...
Note the importance of using an absolute path. Relative local disk file system paths are an absolute no-go in a Java EE web application. See also the first "See also" link below.
Which to choose?
Just weigh the advantages/disadvantages in your own opinion of maintainability.
If the properties files are "static" and never needs to change during runtime, then you could keep them in the WAR.
If you prefer being able to edit properties files from outside the web application without the need to rebuild and redeploy the WAR every time, then put it in the classpath outside the project (if necessary add the directory to the classpath).
If you prefer being able to edit properties files programmatically from inside the web application using Properties#store() method, put it outside the web application. As the Properties#store() requires a Writer, you can't go around using a disk file system path. That path can in turn be passed to the web application as a VM argument or system property. As a precaution, never use getRealPath(). All changes in deploy folder will get lost on a redeploy for the simple reason that the changes are not reflected back in original WAR file.
See also:
getResourceAsStream() vs FileInputStream
Adding a directory to tomcat classpath
Accessing properties file in a JSF application programmatically
Word of warning: if you put config files in your WEB-INF/classes folder, and your IDE, say Eclipse, does a clean/rebuild, it will nuke your conf files unless they were in the Java source directory. BalusC's great answer alludes to that in option 1 but I wanted to add emphasis.
I learned the hard way that if you "copy" a web project in Eclipse, it does a clean/rebuild from any source folders. In my case I had added a "linked source dir" from our POJO java library, it would compile to the WEB-INF/classes folder. Doing a clean/rebuild in that project (not the web app project) caused the same problem.
I thought about putting my confs in the POJO src folder, but these confs are all for 3rd party libs (like Quartz or URLRewrite) that are in the WEB-INF/lib folder, so that didn't make sense. I plan to test putting it in the web projects "src" folder when i get around to it, but that folder is currently empty and having conf files in it seems inelegant.
So I vote for putting conf files in WEB-INF/commonConfFolder/filename.properties, next to the classes folder, which is Balus option 2.
Ex: In web.xml file the tag
<context-param>
<param-name>chatpropertyfile</param-name>
<!-- Name of the chat properties file. It contains the name and description of rooms.-->
<param-value>chat.properties</param-value>
</context-param>
And chat.properties you can declare your properties like this
For Ex :
Jsp = Discussion about JSP can be made here.
Java = Talk about java and related technologies like J2EE.
ASP = Discuss about Active Server Pages related technologies like VBScript and JScript etc.
Web_Designing = Any discussion related to HTML, JavaScript, DHTML etc.
StartUp = Startup chat room. Chatter is added to this after he logs in.
It just needs to be in the classpath (aka make sure it ends up under /WEB-INF/classes in the .war as part of the build).
You can you with your source folder so whenever you build, those files are automatically copied to the classes directory.
Instead of using properties file, use XML file.
If the data is too small, you can even use web.xml for accessing the properties.
Please note that any of these approach will require app server restart for changes to be reflected.
Assume your code is looking for the file say app.properties. Copy this file to any dir and add this dir to classpath, by creating a setenv.sh in the bin dir of tomcat.
In your setenv.sh of tomcat( if this file is not existing, create one , tomcat will load this setenv.sh file.
#!/bin/sh
CLASSPATH="$CLASSPATH:/home/user/config_my_prod/"
You should not have your properties files in ./webapps//WEB-INF/classes/app.properties
Tomcat class loader will override the with the one from WEB-INF/classes/
A good read:
https://tomcat.apache.org/tomcat-8.0-doc/class-loader-howto.html
As part of a Spring Boot project I need to load certain properties file which, by default, is located under de src/main/resources directory. Also, I need to be able to, instead, load an external properties file (located at the root directory of the project). If this external file exists, the file path should be passed as command line property.
The file structure would be like this:
/app_project
Net.properties (external file)
/src
/main
/resources
Net.properties (default file)
The thing is that the dependency that makes use of those properties wouldn't work unless you copy/overwrite the contents of the external file into the file under the /resources directory.
UPDATED
So far I've tried:
loading the file as an external resource and loading it into a Properties object (https://docs.oracle.com/javase/7/docs/api/java/util/Properties.html)
saving the properties as System Properties
modifying the resource handler to look into other directories by overriding th addResourceHandlers() to include the location
Explicitly including the location of the file in the CLASSPATH with the -cp argument (as #veysiertekin suggested)
Loading it as a #PropertySource (as suggesed by #Nikolay Shevchenko)
Overriding the Spring Boot's config location with the spring.config.location (as suggested by #gWombat)
With all these methods I've tried, the file is indeed read and loaded but, at some point, and every time, the app resorts to the file under src/main/resources .
I suspect it may have to do with the precedence of the file (as described here https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html), but I just couldn't figure out what's happening.
Thanks in advance for your help.
Try smth like
#PropertySources({
#PropertySource(name = "default", value = "classpath:default.properties"),
#PropertySource(name = "external", value = "classpath:external.properties", ignoreResourceNotFound = true)
})
public class YourSpringBootApplication {
...
}
Based on the official doc, you can try to use the propertyspring.config.additional-location to add additional config file , or spring.config.location to override default file location.
You should pass those properties as program arguments so that Spring can use them on application startup.
When spring-boot project is running, it checks files under the builded jar file. You need to add your external file to classpath before running the application:
java -cp 'path-to/spring-boot-application.jar:Net.properties' test.SpringBootApplicationMain
We've purchased a thirdparty servlet that references a properties files from web.xml (i.e. d:\projects\MyProp.Properties) . Since moving to Websphere v8.5, we can no longer have the properties file on a logical drive and have to place it inside our app's project. However, we do not have access to the code to the servlet that open/references the properties file. I've tried changing the properties reference to \WEB-INF\MyProp.properties but it's not found during server startup.
Is there a project reference I can use in web.xml allowing the servlet to open the file?
Here's my solution - because we have a NAS location where we place all the .jars that our WAS v8.5 compatible applications can access, I placed the properties file there, updated the path to the file in web.xml and viola, the servlet was able to access/open/read the properties file!
\is2-cifs.domainname.com\sbl_prod$\propertiesfolder\MyProp.Properties
Where can i store SLF4J configuration file so that all production and test environment may have access to it? I want to store the config file outside of the web app at an arbitrary location and retrieve that location upon startup. I also want to allow for changing location of the config file so no classpath. Im thinking about using getters and setters to retrieve the file path.
Any ideas??
slf4j is (for all practical purposes) just the API. You need a backend which does the actual work.
If you use logback you can ship a logback.xml file with your application which just includes another file. If I recall correctly the filename string can hold a ${variable} which you can then define outside your application.
See https://logback.qos.ch/manual/configuration.html#configFileProperty
You may specify the location of the default configuration file with a system property named "logback.configurationFile". The value of this property can be a URL, a resource on the class path or a path to a file external to the application.
java -Dlogback.configurationFile=/path/to/config.xml chapters.configuration.MyApp1
I need to read an application.properties file from a servlet application using Tomcat container. The file can not be included in my war so it can't be under webapps or Tomcat root folder in any ways. The file has to be somewhere in the folder. I also can not use FileInputStream to read the properties file. Only option I have is to define a JNDI name for a folder / directory and look that JNDI properties during runtime to find the folder location to read the file. Is thee any working example out there?
I have chalked out a solution for myself reading the following similar posts and articles.
The Context Container
Reading a global variable from tomcat with JNDI. Example not working
java:comp/env is not bound
I have defined a Environment inside my Context for my web application under
\conf\Catalina\localhost\mywebapp.xml as follows....
<Environment name="propertiesfilelocation" value="E:\\tmp\\application.properties"
type="java.lang.String" override="false"/>
Then accessed my properties file using a JNDI lookup to get the file name.
Context ctx = new InitialContext();
Context envCtx = (Context)ctx.lookup("java:comp/env");
String propertiesFileLocation = (String) envCtx.lookup("propertiesfilelocation");
LOGGER.info("String property === " + propertiesFileLocation);
properties.load(new FileInputStream(propertiesFileLocation));
#home : Yes you are right it involved FileInputStream. However, I am happy with the solution because I am no longer hard coding my folder location inside my Java code which makes my app more portable.
I have a slightly different approach to a similar problem. I also toyed with the idea of JNDI but I found this a bit of overkill.
I found another article by BalusC. It allows you to specify folder relative to your tomcat installation and deploy all your properties files there. So you keep configuration external to your application but you don't require seperate configuration for every properties file for every app.
Here it the link:
Where to place and how to read configuration resource files in servlet based application?
and the preferred choice is as follows:
Put it in the classpath, so that you can load it by
ClassLoader#getResourceAsStream() with a classpath-relative path:
Properties properties = new Properties();
properties.load(Thread.currentThread().getContextClassLoader().getResourceAsStream("filename.properties"));
Here filename.properties is supposed to be placed in one of the roots
which are covered by the default classpath of a webapp, e.g.
webapp/WEB-INF/lib, webapp/WEB-INF/classes, appserver/lib or JRE/lib.
If the properties file is webapp-specific, best is to place it in
WEB-INF/classes. If you're developing a project in an IDE, you can
also drop it in src folder (the project's source folder).
You can alternatively also put it somewhere outside the default
classpath and add its path to the classpath of the appserver. In for
example Tomcat you can configure it as shared.loader property of
tomcat/conf/catalina.properties.
I hope this helps.
Allan