I'm creating a JavaModule with some utilities class.
This module will used from some different Java Applications (these projects will be have the dependency into their pom files).
Into my JavaModule I would like to use some properties files to store the settings values. I con't use Spring int this module.
What's the best practice to use the properties files into a JavaModule without using Spring annotations?
Is it the correct way as reported in this example?
What's the correct place where I have to put the properties files? Can I use a dedicated folder?
Is there a way to override a specific value that it's contained into my Java Module's properties file from a Java Application that use my module?
I would use that logic, and afaik is the most common. But I was also in a project in which we used ResourceBundle even though it should be used to retrieve locale specific data, because it was less verbose.
In that case was just:
ResourceBundle.getBundle("properties").getString("my.property");
Once again. The example from mkyong would be my first choice for anything but a POC.
Related
I encountered handful of guides to creating spring data jpa projects and people configured persistence layer using properties file and javaconfig both. If we one uses javaconfig why would they even bother to create another properties file to include configurations? If one strategy is used(i.e. JavaConfig) to configure project , what is the use of the other (i.e. properties file) strategy? Do I have a misunderstanding as to how to configure projects?
JavaConfig was mostly used for old version of Java or legacy projects. It is a helper library used to avoid the boiler plate needed to write a code to open the properties file and map the values directly to a class that can represent your properties in memory.
With JavaConfig your code will looks like this and without it, your code will look like this.
If one strategy is used(i.e. JavaConfig) to configure project , what
is the use of the other (i.e. properties file) strategy? Do I have a
misunderstanding as to how to configure projects?
Properties file, is the standard used in Java to store external configuration values. It is a key/value file, example: application.properties or application.yml are used in modern framework such as Spring, that offer a simple way to manage your properties file.
Assume that
I like to manage the configuration of a Java application in form of one or many classes referencing each other which I de/serialize to/from XML because I like the way how that saves a lot of work.
I have a Java project with interfaces and the application packaged in different JARs where interfaces are designed to allow third-parties to implement interfaces and the user to load them at runtime through a fancy GUI. Configuration classes exist in form of interfaces and thus can occur in the serialized XML.
I would like to have one configuration file only controlling all pathes of all resources (I'll probably have to give that up, but I'm curious about your answers). It is searched for in a default location and created with default values if inexisting or can be specified on command line.
How would I go about getting the information about the location of third-party implementations before loading the configuration and still keep one clean configuration file only?
I
parse the XML once using XStream and XStream.omitField for the field which contains instances of configuration classes which need to be loaded from a referenced JAR.
Then I read the partial configuration to the location of the JARs and load the classes.
Then I overwrite the partially parsed configuration with a completely deserialized one (using a new instance of XStream).
I am trying to create a project with one spring configuration file. but inside the configuration file all beans are interfaces without any implementations. i would create one more project with all implementations. Also can i use abstract = true for all the beans(interfaces) of first project, so that user cannot use them.
Thanks!
I can't imagine a situation where you want to specify interfaces in the spring config file. So I think it is unnecessary for you as well. You can use abstract=true to create reusable or partial bean definitions.
You cannot specify interfaces in in your spring config, since they cannot be instantiated. What exactly are you trying to archive?
I have a Java project that expects external modules to be registered with it. These modules:
Implement a particular interface in the main project
Are packaged into a uni-jar (along with any dependencies)
Contain some human-readable meta-information (like the module name).
My main project needs to be able to load at runtime (e.g. using its own classloader) any of these external modules. My question is: what's the best way of registering these modules with the main project (I'd prefer to keep this vanilla Java, and not use any third-party frameworks/libraries for this isolated issue)?
My current solution is to keep a single .properties file in the main project with key=name, value=class |delimiter| human-readable-name (or coordinate two .properties files in order to avoid the delimiter parsing). At runtime, the main project loads in the .properties file and uses any entries it finds to drive the classloader.
This feels hokey to me. Is there a better way to this?
The standard approach in Java is to define a Service Provider.
Let all module express their metadata via a standard xml file. Call it "my-module-data.xml".
On your main container startup it looks for a classpath*:my-module-data.xml" (which can have a FrontController class) and delegates to the individual modules FrontController class to do whatever it wants :)
Also google for Spring-OSGI and their doco can be helpful here.
Expanding on #ZZ Coder...
The Service Provider pattern mentioned, and used internally within the JDK is now a little more formalized in JDK 6 with ServiceLoader. The concept is further expanded up by the Netbeans Lookup API.
The underlying infrastructure is identical. That is, both API use the same artifacts, the same way. The NetBeans version is just a more flexible and robust API (allowing alternative lookup services, for example, as well as the default one).
Of course, it would be remiss to not mention the dominant, more "heavyweight" standards of EJB, Spring, and OSGi.
I have an application structured as follows:
dao
domain
main
services
utils
I've made a class that reads the application configuration from an XML file. The question is where should it be placed?
By reflex, I'd have placed it in utilities but utility classes have static methods and are stateless whereas this class uses an instance of Apache Commons XMLConfiguration. Should I just adapt the methods so this instance is limited to the scopes of the methods in this class?
I assume the items are packages, so I'd go with the main package.
dao
domain
main contains the application and its configuration readers
config
log
services
utils
Why? The configuration of an application, whether it be in XML or not and whether it is based on an application framework such as Spring or not, is part of its main functionality. Booting up an application is the main responsibility of the application. All the business functionality, all the shiny features it provides are implemented in the domain and service layers.
You're right, utils is all about static or similar tools. As the configuration of an application is very important, I wouldn't declare it a utility. A utility is something which can be easily replaced by another utility of same type (e.g. StringUtil vs. StringUtils vs. IOUtils etc. they all have very similar functionality)
This depends on the build system and application type you use i.g. maven would suggest to place configfiles in src/main/resources
In WAR file you could place them in WEB-INF or WEB-INF/config
According to your project structure I would suggest to introduce a folder config or resources, since almost everybody would expect them there.
If you are working with Spring, take a look at Configuration Placeholders. You can use a simple java properties file for your configuration properties and place it on your class path (or any other location). Alsou you could create your own implementation to use a different form of keeping your configuration values (XML, Database etc.)
As configuration is a cross-cutting aspect it doesn't map exclusively to one of these layers. Place the configuration files (XML or properties) into the classpath and use it via Spring to configure your beans.
For properties based configuration data the PropertyPlaceholderConfigurer is a good solution.
I urge you to have a look at Spring. Might seem like overkill for you in the first place, but you wil love it.