I have an legacy code base , which is built by using ant. I can see lot’s of properties file been used throughout the project, which gives deployment url and other things.
I certainly hate this approach. By any chance, we can remove these properties file and inject these values to Java classes at run time?
And I see most of the properties files are used in build.xml. Does other build tool handles these situation in ease?
Thanks in advance.
Related
I am building a desktop application with NetBeans 8.0.2. For my application, I have to manage 3 differents projects : The main project, and two "tool" projects that are linked to the main.
When I run the main project, it will check the JARs present in his classpath in order to retrieve the Manifest files and do some work with.
In order to have my application run correctly, it has to see the two linked projects' JARs but it doesn't, because NetBeans deals with the compiled classes of the project instead of the JAR (for debugging purposes I presume).
I found nothing about it on the Oracle documentation, and the only thing looking a bit like what I search is to create a big-fat-JAR by using another component.
Is there a way to tell NetBeans to "compile the linked projects and use the JARs instead of the .class" files ? Thanks in advance
EDIT : Here is an example when I add the project with "Add Project .." option
/C:/Users/xxxxx/Documents/GuiceProjectsRD/xxxReaderRef/build/classes/
And here is an example when I add the JAR
/C:/Users/xxxxx/Documents/JavaLib/xxxReaderRef.jar
When I add the JAR, I have the ".jar" extension which helps me identify a JAR and then look into it for a Manifest. When I add the Project, there is no path to the JAR but only to the compiled classes, and I can't work with that.
I would not depend on the Manifests in Jars since you then get this kind of issues.
Have a look at the Typesafe Config library. It's a small 100% pure Java library to work with Json/Hokon configuration.
Instead of relying on a Manifest, create a 'reference.conf' in each tool project. In your application, create an 'application.conf' (if needed). Load the config via 'ConfigFactory.load()'. It will automatically search all available reference.conf's, and application.conf, on the classpath, whether in a jar or not, and merge those configs into a single configuration.
I use this approach in project to be able to plugin extension. Have for example in tool A a configuration like
tool.A.class = 'my-tool-A.class'
or used nested structures like
tool {
A {
class = 'my-tool-A.class'
}
}
Do something similar voor tool B.
Then in your application, from the Config, you can get a list of 'tool' configs and detect the available tools like that.
In a java project where does the application.properties file commonly get stored?
I store my application properties in src.main.resources. Resources package is quite self-explanatory and property files can be easily found there for everyone who looks at this project for the first time. Resouces are stored in main package in case you need different configuration for your tests, therefore I have also src.test.resources package.
In a JAVA project you can keep the properties files wherever you want, as long as you can find them during runtime.
Take a look at this question for more details: Loading a properties file from Java package
For a MAVEN project:
You can of course override this, but normally properties files in maven projects are kept in specific places:
Configuration used during runtime is kept in src/main/resources.
Configuration used during tests is kept in src/test/resources.
I need to create 2 war applications deployed on tomcat server.
One of the applications have the exact same logic and code as the other application but with added changes to the view and controllers.
Then App1 and App2 will have the same code to access data and I don't want to duplicate code.
My idea is create 2 WARs and these WAR files should use a library or other project (I don't know) that has access to the database.
Which solution is the best for performance?
Option 1
If you are sharing code (and it's a big piece of code, which drives you crazy while uploading the war-files) it may be an option to create a jar containing the code and add the jar file to tomcats library-folder, which is ${CATALINA_BASE}/lib/
Note that this is usually not something you want to do lightly, because that jar file will be available to ALL war-files on the tomcat, creating possible namespace-problems.
Option 2
If sharing the code with all the projects on the application-server is not an option you'll have to add the jar-file to the projects and add it into it's classpath (which happens automatically within eclipse if you add the jar into ${PROJECT_ROOT}/WebContent/WEB-INF/lib).
Preformance-wise this doesn't really make a difference since tomcat will load the class-files, which are not very big. The instances might be, but the type of deployment doesn't really have an impact upon instances.
If you want to use the same classes for both projects just simple create one .jar file which will contain those classes. Then add that .jar into your web projects' classpath and use it in both.
You can extract the common part out, and make it as a jar. And then two wars use this jar as library.
If you used maven for building your wars, it would be easier to build a project hierarchy.
something like:
parent
|_common(jar)
|_war1
|_war2
I am using Eclipse and JBoss Tools to generate Java classes from existing Hibernate mappings. Whenever the classes get generated, they have a comment at the top of the class that indicates when the class was auto-generated.
I really want to prevent this from happening since it is a nuisance when these classes are under configuration management. I've looked through all the settings I can think of and online and haven't found out how to do this yet. It seems like it should be very simple, but it hasn't been.
Anyone know how to suppress this comment from being created?
You can edit the tempalte files in the jar file of jboss tools so it does not generate that info. As far as I can remember it uses velocity templates, so you just need to delete that bit from the template files and it wont generate those comments.
When I was using eclipse to generated the POJO's I had the same problem (when working with GIT reporitory). I build a simple program in .Net in order to clean the comments. After I run the hibernate configuration, I run the .exe (it must be located in the same folder of the POJO's files)
You can find the code and an .exe app in https://github.com/jaimeimarin/HibernateHeadersCleaner . If you are working with git remember to add an exception in order to commit the tool.
#Add this line to your .gitignore file
!HibernateHeadersCleaner.exe
I have a main project, which depends on multiple projects (in eclipse).
At the end of the project, I will generate a runnable jar and a log4j.properties. This properties file is an external file, so my client can modify it at will (email address etc).
runnable.jar + log4j.properties.
At the same time, those projects which the main project depends on, have their own log4j properties files.
I want to centralize the setting in log4j.properties into one external file. How to do that?
If you add a JVM parameter -Dlog4j.configuration="file://anywhere/anyfile", all your components will use the same configuration. You can combine all your log4j configuration in this one big file. Is this what you mean by centralizing?
You will have to copy the relevant settings of the log4j.properties from the other projects into your file. But I guess the real question is: Why would you want to do that? Normally you would not care about logging those other projects in detail. A general root level should cover them just fine. And if you do care, you should care in a way that is different from their default.