String.format("%d min, %d sec",
    TimeUnit.MILLISECONDS.toMinutes(millis),
    TimeUnit.MILLISECONDS.toSeconds(millis) -
    TimeUnit.MINUTES.toSeconds(TimeUnit.MILLISECONDS.toMinutes(millis))
);

Enabling JMX without Authentication

JMX is enabled by setting some Java properties in the command used to start an application. You will need to set the CATALINA_OPTS environment variable so the correct properties get set for to Tomcat when it starts. Furthermore, the properties you set will determine if application can access the JMX interface remotely and if they need to authenticate. This section describes how to setup JMX so that applications can access the interface remotely without authenticating. Authentication should be used in production environments, this configuration should only be used for testing. The following commands show how to set the CATALINA_OPTS environment variable so that clients can connect to TCP port 8999 of the host localhost without any authentication:

.
set CATALINA_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8999 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Djava.rmi.server.hostname=localhost";
.

.
$ CATALINA_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8999 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Djava.rmi.server.hostname=localhost";
$ export CATALINA_OPTS;
.

The values in bold should be set to values appropriate for your system. The property com.sun.management.jmxremote indicates that JMX should be activated. The property com.sun.management.jmxremote.port indicates that remote access is allowed and it should occur on the given port (in the example 8999). The next two properties, com.sun.management.jmxremote.ssl=false and com.sun.management.jmxremote.authenticate=false disable SSL and authentication respectively. The final property java.rmi.server.hostname indicates the name of the host on which tomcat is running (NOTE: The JMX documentation did not say this was required but I found that attempting remote access returned ‘Connection failed’ when this property was not set). After setting CATALINA_OPTS you need to restart Tomcat:

After the restart JMX is running and you may test it by following the instructions in the section titled Using JConsole to Monitor Tomcat.

Enabling JMX with Password Authentication

You should enable some type of authentication if you are going to run JMX on Tomcat in a non-testing environment. Simple password authentication is probably the easiest to setup. You may want to setup client SSL authentication instead but instructions for that are left to the Sun documentation. The first thing you need to do is create a password file with the user accounts that can access the monitoring information. I created a file called $CATALINA_HOME/conf/jmxremote.password but it can be located anywhere on the filesystem. The file takes the form of a username and a password separated by a space on each line. An example is below:

The file above create two users, oscars and admin. The “oscars” account has a password “oscars” and the admin account has the password “password”. The next step is to assign permissions to each account. This is done in another text file that I named $CATALINA_HOME/conf/jmxremote.access. An example of that file is below:

See the Sun documentation for more information on what the readonly and readwrite permissions means. After creating these two file you need to set the file permissions such that only the owner can read them. An example of the commands to do this are as follows:

The final step is to add properties to CATALINA_OPTS that initialize JMX and point to the given files. An example of the commands needed to do this are as follows:

.
set CATALINA_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8999 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=true -Djava.rmi.server.hostname=localhost -Dcom.sun.management.jmxremote.password.file=$CATALINA_HOME/conf/jmxremote.password -Dcom.sun.management.jmxremote.access.file=$CATALINA_HOME/conf/jmxremote.access";
.

.
$ CATALINA_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8999 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=true -Djava.rmi.server.hostname=localhost -Dcom.sun.management.jmxremote.password.file=$CATALINA_HOME/conf/jmxremote.password -Dcom.sun.management.jmxremote.access.file=$CATALINA_HOME/conf/jmxremote.access";
$ export CATALINA_OPTS;
.

The values in bold should be set to values appropriate for your system. The property com.sun.management.jmxremote indicates that JMX should be activated. The property com.sun.management.jmxremote.port indicates that remote access is allowed and it should occur on the given port (in the example 8999). The next two properties, com.sun.management.jmxremote.ssl=false and com.sun.management.jmxremote.authenticate=false disable SSL and enable authentication respectively. The next property java.rmi.server.hostname indicates the name of the host on which tomcat is running (NOTE: The JMX documentation did not say this was required but I found that attempting remote access returned ‘Connection failed’ when this property was not set). The last two parameters, com.sun.management.jmxremote.password.file and com.sun.management.jmxremote.password.access, point to your password and access files, respectively. After setting CATALINA_OPTS restart Tomcat and you are ready to test JMX. See the section Using JConsole to Monitor Tomcat for information on how to test.

Using JConsole to Monitor Tomcat

JConsole is a GUI application designed for monitoring Java applications. It acts as a client to the JMX interface and can monitory statistics locally or remotely. JConsole comes preinstalled on many systems that have Java (i.e. Mac OS X). If you don’t have it then you can get it from the latest JDK download here. Basic instructions for running JConsole are below:

1. Open a command-line window (on Mac OS X go to /Applications/Utilities/Terminal).

2. Enter the command jconsole

3. A window will load. What the window displays will depend on whether you are running jconsole on the same machine as you are running Tomcat. If you are running it on the same machine as Tomcat you should see an option to select the Tomcat server in the local tab and should proceed to step 4a. If this is the case your window will look similar to the following:

If you are running Tomcat on a remote machine then you will see a blank box and should proceed to step 4b. If this is the case your window will look similar to the following:

4a. You should be at this step if you want to connect to a Tomcat server running on the same machine as jconsole. To connect to the server select the item listed and click “Connect”.

4b. You should be at this step if Tomcat is running on a machine remote from jconsole. Click on the Remote tab. Enter the hostname to which you’d like to connct and the port on which JMX is listening (these were both specified when configuring Tomcat to use JMX with the java.rmi.server.hostname and com.sun.management.jmxremote.port properties). If authentication is enabled for JMX enter a username and password, otherwise leave those fields blank. When the fields are filled-in click “Connect”.

5. You should connect to the server and see some summary statistics. Navigate the tabs to view the set of information offered. Some screenshots are shown below:

Original post from: https://wiki.internet2.edu/confluence/display/CPD/Monitoring+Tomcat+with+JMX

To make shure Java uses only IPv4 every time a connection is created, just put a new entry in your JAVA_OPTS.

export JAVA_OPTS=$JAVA_OPTS;-Djava.net.preferIPv4Stack=true

The standard approach in Java is to have separated projects for separate purposes. For example the domain model of the application is usually defined in its own project. One way of making these classes available to GWT is to copy them into the package “client” in your GWT project. This is bad practice as it leads to code duplication (which is inherently evil). This chapter describes how you can make these projects available to the GWT compiler as modules.

GWT need to have access to the source files to compile them into Javascript code. If you add the project or the jar file to your GWT classpath then the Java compiler will not complain if you use the classes from the included project / jar but the GWT compiler will not be able to compile them.

To make the Java files available to the GWT compiler you need to

• Create a gwt.xml file in the Java project / jar file which you want to use – This will instruct the GWT compiler to use the listed classes.
• Use the included library via the inherit definition
• If you are using a jar file you also need to include the source files in the jar

Here’s a short example *.gwt.xml file:

To make the classes available for GWT use the inherti tag in your *.gwt.xml file:

org.hibernate.PersistentObjectException: detached entity passed to persist

It’s realy easy to solve this problem, just ensure to create the object to be saved after beginning the transaction.
In my case I just created a constructor like this one:

public MyBean(MyBean entity){
setProp1(entity.getProp1);
setPop2(......
}

Then I created a new Onject to be saved just before the create statement to persist the object.

MyBean myBean = new MyBean(entity);
myDao.create(myBean);

1. Create a controller class to handle the RCP requests:

public class GWTController extends RemoteServiceServlet implements Controller, ServletContextAware {

    /** The Constant serialVersionUID. */
    private static final long serialVersionUID = -6044751640456464234L;
    // Instance fields
    /** The remote service. */
    private RemoteService remoteService;

    /** The remote service class. */
    private Class remoteServiceClass;

    /** The servlet context. */
    private transient ServletContext servletContext;

    // Public methods
    /**
     * Call GWT's RemoteService doPost() method and return null.
     *
     * @param request
     *            The current HTTP request
     * @param response
     *            The current HTTP response
     * @return A ModelAndView to render, or null if handled directly
     * @throws Exception
     *             In case of errors
     */
    @Override
    public ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) throws Exception {
        doPost(request, response);
        return null; // response handled by GWT RPC over XmlHttpRequest
    }

    /**
     * Process the RPC request encoded into the payload string and return a string that encodes either the method return
     * or an exception thrown by it.
     *
     * @param payload
     *            The RPC payload
     * @return the string
     * @throws SerializationException
     *             the serialization exception
     */
    @Override
    public String processCall(String payload) throws SerializationException {
        try {
            if (remoteService instanceof DependencyInjectionRemoteServiceServlet) {
                try {
                    DependencyInjectionRemoteServiceServlet d = (DependencyInjectionRemoteServiceServlet) remoteService;
                    d.setServletContext(getServletContext());
                    d.init();
                } catch (ServletException e) {
                    // TODO Auto-generated catch block
                    e.printStackTrace();
                }
            }
            RPCRequest rpcRequest = RPC.decodeRequest(payload, this.remoteServiceClass);

            // delegate work to the spring injected service
            return RPC.invokeAndEncodeResponse(this.remoteService, rpcRequest.getMethod(), rpcRequest.getParameters());
        } catch (IncompatibleRemoteServiceException e) {
            return RPC.encodeResponseForFailure(null, e);
        }
    }

    /**
     * Setter for Spring injection of the GWT RemoteService object.
     *
     * @param remoteService
     *            the new remote service
     */
    public void setRemoteService(RemoteService remoteService) {
        this.remoteService = remoteService;
        this.remoteServiceClass = this.remoteService.getClass();
    }

    @Override
    public ServletContext getServletContext() {
        return servletContext;
    }

    @Override
    public void setServletContext(ServletContext servletContext) {
        this.servletContext = servletContext;
    }
}

This class includes the remoteServlet as property which is injected by Springs property injection.
Property injection is used because there are much services available which are handles by the
controller class and the used service has to be injected.

In this class I set the ServletContext and call the init method of DependencyInjectionRemoteServiceServlet.
I do this to handle the problems I described above.

2. Change the web.xml to use the dispatcher servlet instead of the documentServlet:

		dispatcher
		org.springframework.web.servlet.DispatcherServlet

contextConfigLocation
classpath:spring/dispatcher-servlet.xml

		1

		dispatcher
		/gwtspring/documentService

3. This is the dispatcher-servlet.xml file:

	

				/gwtspring/documentService=documentGWTService

4. Include a message property in the ServiceSecurityException and create a custumFildSerializer for the
ServiceSecurityException to handle the serialisation of the message.

ServiceSecurityException.java:

@SuppressWarnings("serial")
public class ServiceSecurityException extends Exception {

    private String message;

    /**
     * @return the message
     */
    @Override
    public String getMessage() {
        return message;
    }

    /**
     * @param message
     *            the message to set
     */
    public void setMessage(String message) {
        this.message = message;
    }

}

ServiceSecurityException_CustomFieldSerializer.java:

public final class ServiceSecurityException_CustomFieldSerializer {

    /**
     * Instantiates a new object name dto_ custom field serializer.
     */
    private ServiceSecurityException_CustomFieldSerializer() {

    }

    /**
     * Initiate.
     *
     * @param reader
     *            the reader
     * @return the object name dto
     * @throws SerializationException
     *             the serialization exception
     */
    public static ServiceSecurityException initiate(SerializationStreamReader reader) throws SerializationException {

        return new ServiceSecurityException();

    }

    /**
     * Serialize.
     *
     * @param writer
     *            the writer
     * @param instance
     *            the instance
     * @throws SerializationException
     *             the serialization exception
     */
    public static void serialize(SerializationStreamWriter writer, ServiceSecurityException instance)
            throws SerializationException {
        if (instance == null) {
            throw new NullPointerException("ServiceSecurityException object is null");
        } else {
            writer.writeString(instance.getMessage());
        }
    }

    /**
     * Deserialize.
     *
     * @param reader
     *            the reader
     * @param instance
     *            the instance
     * @throws SerializationException
     *             the serialization exception
     */
    public static void deserialize(SerializationStreamReader reader, ServiceSecurityException instance)
            throws SerializationException {
        instance.setMessage(reader.readString());
    }
}

mvn clean install

4. Change actionscriptProperties and remove Snaphot dependencies too
5. Check if all dependencies are set correctly:

mvn release:prepare -DdryRun=true -DautoVersionSubmodules=true -DtagBase=***SVN repository URL***

Attention: Check for right folder, the release has to put in the tags folder!
If errors occurs, run clean install again
6. Reset automatic changes on pom.xml files:

mvn release:clean

7. Prepare release:

mvn release:prepare -DautoVersionSubmodules=true -DtagBase=***SVN repository URL***

Attention: Check for right folder, the release has to put in the tags folder!
8. Perform release:

mvn release:perform

If deployment fails, check out from svn and build locally:

mvn clean install
mvn clean deploy

mvn release:branch -DbranchName=my-branch

By default, the POM in the new branch keeps the same version as the local working copy, and the local POM is incremented to the next revision. If you want to update versions in the new branch and not in the working copy, run:

mvn release:branch -DbranchName=my-branch -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false

Note: This can be useful if you want to create a branch from a tag

Specify versions on the command line
You may want to specify the versions to use on the command line. This can be useful for example if you are running the release in non-interactive mode. The branch goal can use the same properties used by the prepare goal for specifying the versions to be used.

mvn --batch-mode release:branch -DbranchName=my-branch-1.2 -Dproject.rel.org.myCompany:projectA=1.2 \
     -Dproject.dev.org.myCompany:projectA=2.0-SNAPSHOT

In this example, the POM in the new branch will be set to the version 1.2-SNAPSHOT, and the local POM will be set to the version 2.0-SNAPSHOT.

	hsqldb
	

			test.dbms
			hsql
		
	
	


				org.codehaus.mojo
				hibernate3-maven-plugin
				2.1
				
					
						
							hbm2ddl
							jpaconfiguration
						
					
					
mypu
${basedir}/src/test/resources/META-INF/database/hsql.properties
						
						${basedir}/src/test/resources/META-INF/database/datasets.hbm.xml
						
						${project.artifactId}-${project.version}_HSQL_CREATE.sql
						
						true
						false
						false
					
				
				
					
						hsqldb
						hsqldb
						1.8.0.10
						test
					
				
			
			

				maven-surefire-plugin
				
					

							my.test.dbms
							hsqlMemory
						
					
				
			
		
	
	
		
			hsqldb
			hsqldb
			1.8.0.10
			test
		
	

Here’s an example for the properties file for the database connection:

hibernate.connection.driver_class=org.hsqldb.jdbcDriver
hibernate.connection.url=jdbc:hsqldb:hsql://localhost:9112/my
hibernate.connection.username=sa
hibernate.connection.password=
hibernate.dialect=org.hibernate.dialect.HSQLDialect

dbunit.datatypeFactory=org.dbunit.ext.hsqldb.HsqldbDataTypeFactory
project.ddlDirectory=my_db_dictionary/hsql

Here’s the file to declare the mapping files to create the statements from:

In the maven profile you have to use “jpaconfiguration”, if you use “configuration” no sql file is created and you have to copy the sql commands from the command line and create a file by yourself.