We'd like to configure ESAPI property files directory, in JBOSS WildFly
(What usually done by VM argument: -Dorg.owasp.esapi.resources="/path/to/.esapi")
but prefer to do so in OTHER way, to suppurt diffrent property configuration for diffrent projects
does someone know how to do so?
Thaks!
There's really only two methods for loading these files, neither of them care about the application server you use. The first method, as you suggested is to supply the path via JVM properties.
The second method is via the classpath. I've never worked in JBOSS, but in Weblogic there's a config menu where you can place files on the classpath directly. In your case, it sounds like you want a different properties file for multiple applications? A JVM property or a similar classpath edit to weblogic would be the only choices.
The final classpath method, which I'm only including to be complete, is to compile your own copy of the library with your properties files in src/main/resources. Or--really hacky--crack open the jar file and dump them in by hand. The benefit of the "compile yourself" approach is that you'll have all the unpublished bugfixes, so if another CWE gets assigned to it you don't have to wait for the official release.
Related
I am running Websphere Liberty 8.5. My application reads some files from the file system that are obtained via the Java CLASSPATH and I can't seem to find a way to append a directory from the file system to the CLASSPATH Liberty reads from. I've tried manually changing JAVA_CMD and JAVA_DEBUG but none of them take.
Does anyone know how this is possible?
It is not possible to modify the JVM application classpath (normally specified via the -classpath JVM argument or the CLASSPATH environment variable). I would recommend using a <library> to give your applications visibility to the resources. If you need a directory, you should use <library><folder dir="..."/></library>.
(As an aside, modifying the wlp/bin scripts or setting those "internal" script variables is not a supported external.)
ANOTHER WARNING! It only reads JAR files! I had the same issue with endless frustration. Even if you use the <library><folder dir="..."/></library> method above, it will only read jar files from the classpath. I had a bunch of properties files that I read from the classpath in JBOSS, WebSphere (full), and Glassfish, but the same method doesn't work for Websphere Liberty. What I ended up doing is the above, and putting my properties files all in a .jar file. Very annoying but a work-around, in case you need to read non-jar files.
I have a maven project with several dependencies and use log4j.properties to control output. In some cases the same class may be referenced in different property files with different parameters. Is there a defined protocol for "overriding" properties or does it depend on the order in which packages are loaded?
(I am locating all log4j.properties directly under src/main/resources - is this the correct place?)
UPDATE:
I have accepted #Assen's answer as it makes sense though it doesn't make the solution easy. Essentially he recommends excluding log4j.properties from the jar. In principle I agree, but it puts the burden on the user to control the output and most of my users don't know what Java is, let alone properties files.
Maybe there is a way of renaming the properties files in each jar and using a switch (maybe with -D) to activates the properties.
I often have similar discussions on projects. I thing log4j.properties is typically something you want to keep out of the application, and not pack it in a war and deliver it together with the code. Logging configuration:
is environment specific. When you write the application, you simply can't define the appenders that will be desired, file locations etc.
its lifecycle is totally different than the application's. After an application is deployed, logging properties can be changed several times a day. Redeploying the application shouldn't override your last logging settings.
Why package logging configuration together with your code then? I usually keep somewhere a configuration folder, with soubfolders like 'dev', 'test-server-01', 'macbook-john' etc. Each subfolder contains list own copy of log4j.properties. None of them is included in the build artifact - jar or war.
When deploying, one of thuse subfolders is delivered separately. For the test server 1, this would be the content of test-server-01 subfolder. Dependng on the application server used, thers is a different trick tu put some files on the classpath.
When developing, I take care to set one of those subfolders on the path. When John develops on his macbook, he might want to put 'macbook-jihn' on the classpath, or create a new one. He can change logging settings and commit without conflicts.
Is there a way to include environment specific properties or configuration file while building war.
QA
entity.url=http://qa.test..
prod
entity.url=http://prod...
I need to make around 5 to 6 REST calls. Url is different for each environment. Hence is there any way to configure environment specific conf file?
thanks in advance
The Play Framework has the concept of 'ids' that can be used for different modes see here:
http://www.playframework.org/documentation/1.2.4/ids
This allows you to do:
%qa.entity.url=http://qa.test..
%prod.entity.url=http://qa.test..
The one thing that might not be clear by their documentation is how to set this in a war. When running as a .war file, the play ID is set to 'war' by default. This can be changed in the web.xml of the .war file. You can do that or you can specify the ID when you create the war:
play war -o PATH --%prod
Not that I am aware of (and reading the python source for building the war does not indicate this is available). The war file simply builds up your Play application, as is. If you want to have a different configuration, then this may simply require the loading of it from an external resource (a property file that lives outside of the WAR, that you ship with your WAR file).
Alternatively, you could modify the python script that builds the WAR file to custom add additional properties to your file. Look in the directory framework/pym/commands/ and look at the war.py to read the source for the python war command.
I am developing a framework that needs a lot of stuff to get working. I have several folders inside of my Eclipse project that are needed
[root]
- config
- src
- lib
- serialized
Also there are important files like the log4j.properties and the META-INF dir inside the src directory.
I wonder if there is a way to distribute one JAR containing all essential files so my gui will just have to import one jar. I guess that I have to exclude the config folder in order to make the framework configurable.
I also wonder, if there is a way to move for example the log4j.properties to the config dir so that I have one config folder containg all needed configurations?
Thanks for help and advise on this matter!
Marco
Yes, but not really. You can take all your dependencies, unpack them and simply merge them into a bigger jar. This is what the maven jar plugin does if you make a jar with dependencies. The only problem is that this might result in conflicting files (suppose two of your dependencies contain a log4j.properties). This is one of the problems when doing the above with some of the spring libraries for instance.
I think someone actually wrote a classloader that allows you to bundle the whole jar inside of your jar and use it as is. I'm not sure how mature that is though and can't at the moment recall the name.
I think you're better off distributing all your dependencies separately. Setting up the classpath is a bit of a pain but surely java programmers are used to it by now. You can add dependencies to the Class-Path header in your manifest file, in simple cases. Bigger libraries have to rely on the classpath being set up for them though.
As to the second part of your question, probably dropping the conf/ directory under META-INF is enough for its contents to be picked up. I'm not sure about this. I'm fairly sure it will always be picked up if you put its contents at the top level of the jar. In any case, this is a distribution problem. You can easily have a conf/ directory inside your source tree and have your build scripts (whatever you might be using) copy the files in it to wherever is most convenient.
As to your users configuring. Try to establish some conventions so they have to configure as little as possible. For things that must be configured, it's best to have a basic default configuration and then allow the user to override and add options through his/her own configuration file.
In terms of the resources, it is possible except that if you do that you are not going to be able to load resources (non class files) from the filesystem (via a file path).
It's likely that you're currently loading these resources from the file system. Once in the jar you need to load them as class path resources via the class.getResourceAsStream or similar.
As for the dependent jars you may have, it's common practice for these to be placed as extra jars on the classpath. I know it's complicates things but developers are used to doing this. The nature of the java landscape is that this is inevitable. What the spring framework for example does is supply a bundled zip file with the core jar and the jar dependencies included.
Is your library going to be used in an EE context or an SE context? If it is an EE context then you really don't have to worry about configuration and class path issues as the container takes care of that. In an SE context it is a lot more tricky as that work has to be done manually.
i have a few batch java command-line applications which are planned to be deployed as:
batch_apps
app_1
batch1.jar
run_batch1.sh
app_2
batch2.jar
run_batch3.sh
{...etc...}
what would be the best practice on organizing a shared library pool - for example log4j:
batch_apps
app_1
batch1.jar
run_batch1.sh
app_2
batch2.jar
run_batch3.sh
libs
log4j.jar
ojdbc.jar
?
and include individual log4j.xml's in each app's own jar file?
i understand i would need to add 'libs' to the classpath either in manifests or in run_batchX.sh
(which way is preferable?)
I am mostly wondering what would be the most efficient setup performance-wise.
thanks
Having a shared libs directory at the root of your install dir is definitely the way to go. Since libs will be loaded in memory once, when the JVM launches, there is no impact on performance whatever solution you choose.
I would not put the classpath in the jar files, as this would force you to change your jars if you need to relocate your lib dir. Editing a script is much simpler.
I would not include the log4j conf file in your jar files either, for the same reason.
It appears your applications don't share a single JVM instance. (i.e. They are individually started via 'java -jar batch1.jar' or some such.) Therefore, sharing library .jar files only saves you DISK space not RAM.
If the apps are not sharing a single JVM then ease-of-deployment should take precedence over disk space. (Your time is worth more than a few "wasted" MB.)
In this instance I would recommend making each application self contained, in either a single .jar file including all its libraries, or a single folder of .jar files. (i.e. Put the libs for each app in a folder for that app.)
If the apps were sharing a single JVM then I would recommend the shared library folder option.
You can use the java extension mechanism. Place them in JAVA_HOME/lib/ext and they will be accessible by all apps. Of course, this may not be the best for all deployments, but its certainly easier.
This doesn't directly answer your question, but I have already tried the approach that you propose but would now create a single jar per application (see how to do it with Ant). That way, no need to include anything in the classpath:
java -jar myApp.jar
is all you need. I find it cleaner but everything is debatable.
It doesn't make any difference from a performance point-of-view since each application is run inside its own JVM.
The only downside is that some libraries will be present in each jar file. It only costs more to store on the HD, but these days, MB are pretty cheap :-) I trade simplicity (no external lib folder) and no jar hell (not placing your jars inside the Java ext folder) over storage price any time. If your application doesn't include terrabyte of libraries, I think it's fine.
For the Log4j configuration file, I would place one default file inside the jar but provide a sample config file (log4j-custom.xml.sample) that someone can modify and specify in the command line:
java -Dlog4j.configuration=log4j-custom.xml -jar myApp.jar