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.
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.
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.
I am going to create Java Application that can load external jar files at runtime by FileChooser. I am using Spring Framework, and I want to load jar file and its applicationContext.xml file and inject its dependencies dynamically. I tried to achieve this by OSGi, but it seems very complicated so that I am searching another appropriate variants.
I want to make something like Intellij IDEA plugin installation from the disk.
How can I do this? (After the jar file chosen restarting an application also accepted)
I realy like your approach, unfortunately spring has lifecycles that are strict. As you might know, spring autowires "beans" only. Exactly one lifecycle registers the different bean candidates. After that lifecycle spring (by default) does not accept new classes.
You must use the spring-osgi.
If you only need the CDI part out of spring, you might like to use a different CDI like red hat's jboss server.
I have a couple of Singleton classes in a Liferay application that hold several configuration parameters and a ServiceLocator with instances to WebServices I need to consume.
I have put these classes in a jar that is declared as a dependency on all my portlets.
The thing is, I have put some logging lines for initialization in theses singleton classes, and when I deploy my portlets I can see these lines multiple times, once for every portlet, since each portlet has its own class context.
For the AppConfig class it might not be such a big deal but my ServiceLocator does actually hold a bunch of references that take a good bit of memory.
Is there any way that I can put these Singleton references in some kind of Shared context in my Liferay Portal?
The problem is that every Portlet runs in its own WAR file and aech war file has its own classloader.
Usually when I had to achieve a requirement like this, I had to put the Singleton classen in a JAR file and this JAR file in the common class loader library instead of packing it into each WAR. (In Tomcat: <tomcatHome>/common/lib or something like that)
Then you'll also have to put all dependent libraries into that common lib dir, too. Don't know how to do that in Liferay, though. For tomcat see this thread: stackoverflow.com/questions/267953/ and this documentation: http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html. Depends on the Servlet container.
Alexander's answer gives the general answer that's true with or without Liferay in mind.
Liferay (as you mention it) adds another option to this: ServiceBuilder. You'll end up with the actual instances contained in exactly one web application, and you'll have an interfacing jar that you can distribute with every dependent application. This way you can more easily update your implementation: It's easy to hot-deploy new and updated web applications to your application server - it's harder to update code that's living on the global classpath.
The global classpath (Alexander's answer) however brings you immediate success while ServiceBuilder comes with its own learning curve and introduces some more dependencies. I don't mind those dependencies, but your mileage might vary. Decide for yourself
With maven portlet you can make a common Spring component and import in the pom of each portlet.
Another solution is to use service builder.
Spring MVC portlet would be the most recommended for this.
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.