EAC4J: Apache Commons Configuration via JNDI, and without dependencies!

With EAC4J (External Application Configuration For Java) you can externalize your application’s configuration with Apache Commons Configuration and get a Configuration Object via simple JNDI lookup. The isolated classloader decouples all needed  classess and dependencies from your application except by one interface.

This is a simple Wrapper over Apache Commons Configuration, so you get all the power of it but decoupled from any additional dependency jar. And additionally you can easy reload the configuration without restart the server.

This was initially developed for Glassfish V2 and has been tested on it only.

Glassfish V2 integration:

1. Download the zip here.
2. Unzip it in some folder
3. There will be some files and a directory:
- eac4j-api.jar  Contains shared interfaces and utilities
- eac4j-impl.jar  Contains the Apache Commons Configuration Wrapper
- eac4j-demo.war  Contains a web application demo.
- config.xml  Contains a sample configuration file.
- app.properties  Contains a sample configuration file.
- deps   Contains all dependency jars
- all.src.zip  Contains all source code.
4. Copy eac4j-api.jar into ${glassfish-domain-root}/lib/ext
5. Create folder ${glassfish-domain-root}/lib/eac4j
6. Copy eac4j-impl.jar into ${glassfish-domain-root}/lib/eac4j
7. Copy all files from deps to ${glassfish-domain-root}/lib/eac4j
8. Restart Glassfish
9. Copy config.xml and app.properties somewhere together (And remember where)
10. Open the Admin Console
11. Go to Resources - JNDI - Custom Resources - New
12. Fill the fields: (see the screenshot) IMPORTANT: Do not forget Property configFile

13. deploy eac4j-demo.war
14. Try  http://localhost:8080/eac4j-demo/DemoServlet on your browser.

Replace ${glassfish-domain-root} for your glassfish domain root: for example /var/glassfish/domains/domain1

That’s all, see the source code of eac4j-demo (Just one class: DemoServlet.java) to see how to use it in your applications, the class JNDIServiceLocator.java is just a service locator.

See the Apache Commons Configuration documentation for further details.

If you have any problem, please tell me. If you want to test it in another Application Server, please share your experience.

Thanks,
Frank.

Will be OS Virtualization the end of JVM and CLI?

For years the main JVM advantage was the portability, then Microsoft released Dot Net using the same VM approach trying to get some portability too. But nowadays with VMWare, Xen, VirtualBox, etc … with OS Based Virtualization in general, there is no problem with the portability issue. So the advantages of JVM or CLI environments must be evaluated from other perspectives:

1. Usability
2. Development productivity
3. Scalability
4. Security
5. Reusability
6. Performance
7. Standards compliance
8. Community support
9. Costs and ROI

Virtual appliances are easy to install, easy to manage and easy to restore if there are any problems. The developer is free to select his favorite OS for the development and the customer is free to select his favorite OS for runtime.

- The battle of platforms Round I was portability (IT centric topic)
- The battle of platforms Round II will be Productivity, Time to market and ROI (Business centric topics)

Now the problem is that in few years you will be running all your applications on two levels of virtualization. For example a Java application running on a guest Linux running on a Windows host. or a Dot Net application running on a guest Windows running on a Linux host.

Paradox: Maybe it is time to go back to native compiled code because there will be no real machines anymore in the world.

There are no software SOLUTIONS, the software SOLUTIONS do not exist

I have been working on software development during the last 16 years, i have used many languages and technologies along this time. Then I have learned one thing:

There are no Software solutions, there are only partial implementations of fuzzy human ideas.