1. Summary
  2. Files
  3. Support
  4. Report Spam
  5. Create account
  6. Log in

Main Page

From jeeutils

Jump to: navigation, search


About the Holy J(2)EE Utils Project

The purpose of this project is to provide to the public a set of utilities I've created or will create to ease J2EE development. Currently this includes only two tools. I plan on improving these tools and likely adding more in the future.For similar stuff see the project Patterns And Utilities For The Java EE 5 Platform (p4j5).

Download it!

Go to the SourceForge download site of the project to get any of its components.


1. ClassLoaderViewer.jsp

A simple JSP for troubleshooting class loader problems:

  1. find out where a class is loaded from (if it can be found at all)
  2. find where a resource is loaded from by a particular class (you can use this also to check the visibility of one class be another one).

It tries to list all class loaders in the hierarchy and all elements on their class paths, if they support it.

Status: This is pretty complete and I've currently no plans to update it.
Latest release: 1.0.0
Screenshot #1

To learn more about locating classes and resources read the excelent blog Locating The Classpath Definition Used in Java Code by Dustin Marx and the resources it does reference.


  • The Classpath Helper project - a special class loader that records all locations of a class and finds out if the definitions differ

2. GroovyConsole servlet or portlet

Presents a web page that lets you type and execute on the server Groovy/Java commands and displays the output. History of previous commands. This tool is incredibly useful when you need to examine and test (and perhaps reconfigure) the behavior of a live system running on an application server - sometimes you just can't test some things offline.

More details on GroovyConsole servlet or portlet.

3. DbUnit Express Test Skeleton

Creating a a DbUnit test case may be time consuming. With this project you can have your DbUnit test including an embedded database with structures and data ready in a few minutes. (At least if you are fast enough in writing SQL and preparing your data :-) ).

This project helps you to setup a DbUnit test using an embedded Derby database by providing

  1. An AbstractEmbeddedDbTestCase.java (DbUnit's DBTestCase extension) and EmbeddedDbTester.java (DbUnit's IDatabaseTester impl.), which create a connection to the database, set some useful defaults, and provide additionaly utility methods and improved error reporting,
  2. The utility DatabaseCreator.java for creating and initializing the embedded DB based on a .ddl file,
  3. Sample create_db_content.ddl and dbunit-test_data_set.xml for creating the database and filling it with test data,
  4. Instructions for using them.

Everything is well commented (I hope) to help you to start using it quickly.

For more details go to the DbUnit Express' page.

4. Code snippets

Useful pieces of code, see CodeSnippets.

Ideas for the future


Application utility module for reading properties that may be either required or optional and without caring about where/how they're stored. The default implementation would read them from a standard .properties file but it would be also possible to read them from a database or elsewhere. The application using it only needs to know the name its properties are registered under (y default = the properties file name). Typical usage:

PropertyManager pm = PropertyManager.getInstance("MyApplication");
pm.getString("myapp.someProperty"); a required property, throws UndefinedProperty exception if the property isn't set or is empty
pm.getInteger("myapp.optionalIntProp", new Integer(0)); an optional property; if undefined then the 2nd parameter (the default value) is returned

An interesting reading in this context is the OSGi Preferences Service and Commons Configuration.


Application utility module for obtaining a Connection to a database via direct JDBC or a DataSource and doing cleanup of statements, the connection etc. The purpose is to simplify this and to isolate the application from the way how the connection is obtained so that it can be easily (unit) tested locally when it connects directly to a DB and than - without a change - deployed to a server where it uses a data source from a JNDI lookup. Internally it would use the PropertyManager to get the JDBC setting or DataSource name.


Servlet for viewing server logs and supporting a subset of the functionallity of grep, tail and perhaps other utils.

Personal tools