I have two eclipse projects.
One of them is a library that contains property files.
Second one is a Dynamic Web Project.
In my library there are few configurable classes, that load their configuration parameters from property files.
String path = "Resources/Properties/Main.properties";
InputStream stream = getClass().getClassLoader().getResourceAsStream(path);
Properties properties = new Properties();
properties.load(stream);
My dilemma is that when I export my Web project into WAR, dependent library project gets packed into a jar and placed inside my WAR into "WEB-INF/lib" directory, which means that I can't load them as I would usually do.
My ideas are:
Copy those property files into my Web Projects, which is very
painful, because this library is meant to be used in many projects,
I do not want to have multiple instances of property files scattered
around projects.
Place property files into some system fixed path on the server, still is a bad desigion, makes it harder to deploy this application.
Is there a way to load property files from JAR files, or maybe a way to tell eclipse project to export property files from my library into my Web Project explicitly?
I would appreciate your help and ideas on this matter.
It works just fine if you load the resource file from classpath.
It goes trough classpath and searches for matching resource.
My problem was classpath resource collision, I had classes with similar package.classname and resources with similar path and filename.
When loading these resources, JVM silently ignores duplicated entities from .jar libraries.
So stay sharp and beware of non-unique entities when composing a complex library structure.
Related
I've got a few web projects that rely, all of them, in a common library. This library includes a few JSP files that are used to display errors (using the web.xml error-page feature). These JSP files are included in the library shared-resources, so they are merged with the files from the application.
What I'd like would be for a way to override thoses files with ones specific to the application if I want. If I include files with the same name in the same location in the application, they are overwritten by those in the library. Is there a way, maybe using maven plugins, so I can copy files from the application AFTER the ones from the library have been copied to the target directory? This way, if the application includes its own files, they are used. If it doesn't, then those in the library are used instead.
I've tried adding a new execution of the maven-resources-plugin, using the goal copy-resources, but they still get overwritten by the ones in the library.
Thanks for the help in advance.
Hy,
I want to get the resource folder (ex: C:\Users\Raul\workspace\Serial\src\test\resources) in a Maven project but every time I run this java code:
System.out.println(getClass().getResource("").getPath());
it returns me this path: C:/Users/Raul/workspace/Serial/target/test-classes/
The last time I used Maven, worked that way without any changes from me.
Thx in advance.
With a typical setup, Maven copies the resources to the target/classes (or target/test-classes) directory. Also, the target/classes (or target/test-classes) directory is added to the classpath.
If you have a file src/test/resources/foo.txt, then you would access the file using getResource("/foo.txt").
Generally speaking, you would not want your code to refer to source folders to access resources. Resources might be put in multiple locations and it is pretty common to "filter" the resources (replace tokens with build property values). In the filtering case, you absolutely do not want the processed resource files to be in the source directory.
I am wondering why some resources files are put under the META-INF directory in the JAR? I am always put the resources like test.properties under the root diretcory. Any advantage to put them in the META-INF?
Lot of Java (EE) APIs have a contract that when you put a specific configuration/metadata file in the META-INF folder of your (or a 3rd party) JAR, then the API will automatically do the API-specific job, such as scanning classes, preloading specific classes and/or executing specific code based on the meta information.
An example provided by the standard Java SE API is the ServiceLoader. Among others, the JDBC 4.0 compatible drivers implement this. This way just dropping the JDBC driver JAR file folder will automatically load the driver class during Java application's startup/initialization without the need for any manual Class.forName("com.example.Driver") line in your code.
Further there is also the Java EE 6 provided JSF 2.0 API which scans during application's startup all JAR files for a faces-config.xml file in the META-INF folder. If present, it then will then take it as a hint to scan the entire JAR file for classes implementing the JSF specific annotations like #ManagedBean so that they get auto-instantiated and auto-configured. This saves time in potentially expensive job of scanning thousands of classes in all JARs in the entire classpath. In older versions of those API's the configuration was usually done by (verbose) XML files.
All with all, the major goal is to save the developer from code and/or configuration boilerplate. The JAR's META-INF folder is used for configuration files/hints. Some API's indeed also put static files/resources in there for own use. The META-INF folder is also part of the classpath, so the loading of those files by the classloader is easy done.
In servlet 3.0, certain static resources are available through the web context, such as .css, java script, and .png files, so you no longer need to use ServletContext getResource() and getResourceAsStream(). For more information, check out web-fragment.xml (https://blogs.oracle.com/swchan/entry/servlet_3_0_web_fragment) which is one resource that covers this subject.
Personally, I prefer to structure my projects the way Maven likes them, with a src/main/resources directory which is part of the application's classpath.
It's just a convention that some (most?) third party jars use to look for files that you provide. For your own classes and files, you can choose to put them where you like.
This is more of a pattern question. I am using maven to create a three module project.
Domain, Services, Site
The services module depends on the domain module. Now in the services module I am using an ORM (MyIbatis) and I need to have lots of XML files in my services module. I could place the XML files in the package that contains the .java files, or I can place the XML files under the resources directory.
My question is, what is the best pattern for when you have resources that are mapped to a single .java in the same module. Would you place that resource in the package that contains the .java or in the "resources" directory that maven uses? What are the pros and cons?
I know at the end of the day the resources and java directories get merged into the artifact (.jar), but on principal I would like to know what others do.
Update -- The reason I would like to place the XMLs in the java src directory is because I dont want to recreate the package structure under the resources directory -- to help with the maintainability of package structure changes, etc.
I would put them alongside my Java files personally. You're going to be bouncing back and forth between the object and the XML a lot, in all likelihood. It's annoying to be constantly switching between the two folders.
I put the stuff I don't go to as much while coding, such as property files or log4j.xml, in the resources folder.
But that's just me.
I'm using internationalization with Spring, and the properties file needs to be on the classpath. I also have some XML files that will need to be on the classpath. Is it acceptable to just include those resources inside the "src" in a sub-directory, and then let them build to the classpath, or is it better to add a different folder to the classpath during startup? I'm using Ant, but from the looks of it this was the approach Maven took (everything under src or test). I'm looking for the most widely accepted industry standards or better alternatives. Thanks!
Is it acceptable to just include those resources inside the "src" in a sub-directory, and then let them build to the classpath
Depends on the sole purpose of the resource in question. With this approach, any minor edit in such a resource file would thus require a full rebuild, redeploy and restart.
This may not necessarily harm for one-time-read startup and applicationwide configuration files like web.xml and application.xml and consorts since that would usually affect (or be affected by) changes in Java source code which require a full rebuild/redeploy/etc anyway.
But in case of runtime files like i18n properties files and environment-specific configuration files (which would/could be managed by a non-developer like a serveradmin or a customer), it is not useful to package it inside the webapplication. This requires knowledge how to rebuild the webapp after edits. You would rather like to externalize it so that only a webapp restart is required to reflect the changes in the configuration, or maybe even not at all, like for ResourceBundle which will just reload automagically.
I myself usually put such files in a fixed path along the servletcontainer and add that path to the servletcontainer's runtime classpath. In case of for example Tomcat, it's configureable as shared.loader property in /conf/catalina.properties. E.g.
shared.loader=/var/webapp
Anything in this folder is then taken in the servletcontainer's (and webapp's) runtime classpath.
Anything you put in your WEB-INF/classes directory is automatically in the CLASSPATH.
I usually put only .java files under /src and /test directories. Any resources that I put elsewhere have to end up in WEB-INF/classes. It's either my IDE (IntelliJ) or Ant that put them there when the WAR file is created.
I would recommend following the Spring examples and put resources where they do.
For example, if you use Velocity as your templating engine, you'll see that Spring configuration allows you to put them under /WEB-INF/vm_views.
Properties are put in WEB-INF/classes.
Check the Spring docs for examples.