log4ray - Rene's useless Blog

Fixing Redeployment Issues for Servlet Applications on Windows

2011-05-28T21:58:00.001+02:00

Deployment is hard, redeployment even harder from time to time - especially when your web container, say Tomcat, runs on Windows. Even if you did a good job in avoiding memory leaks and classloader issues, you may experience the problem that the running application fails to undeploy, leaving a couple of files in the webapps folder that could not be deleted.

When Bill designed his beautiful operating system (or whatever you want to call it), he decided to introduce pessimistic locking for file system resources. While this generally sounds good regarding concurrency issues, most of us will already have seen some downsides of this behavior, e.g. when trying to open a document by two users or performing an mvn clean or whatever.

The web container will feel this pain, too. Due to the nature of the JRE, resources are not immediately freed when an application is undeployed - they are just candidates to garbage collection now. So when the application's classloader is de-referenced due to application shutdown, resources such as file system handles may stay open for a while, until our friend GC comes along. If things turn out badly, this will cause the described interference with our redeployment process, since files with open handles cannot be deleted.

There are a couple of things you can do:

ditch Windows - seriously, you're doing server side stuff!! Grab any Linux, Solaris, *BSD (including MacOS) or whateverNIX and enjoy...
get help from my friends at Zeroturnaround and check out LiveRebel, their new magical tool for rolling out seemlessly
or: add the following listener to your servlet application


/**
 * ServletContextCleanupListener uses a little hack to get rid of undeployment issues under Windows.
 * Just in case you may ask: Free under Apache Software License
 *
 * @author Rene Gielen
 */
public class ServletContextCleanupListener implements ServletContextListener {

	@Override
	public void contextInitialized( ServletContextEvent sce ) {
		// nothing to do
	}

	@Override
	public void contextDestroyed( ServletContextEvent sce ) {
		System.gc(); // No excuse - gc NOW
		try {
			Thread.sleep(1000); // ease, dude...
		} catch ( InterruptedException ex ) {
			// Intentionally left blank
		}
	}
}

My client is really happy now, since it solved all his problems. Actually it did not help me to convince him to ditch Windows *sigh*

Create and Run a JEE6 Client Application with Netbeans 6.8 and Glassfish V3 - Part 2: Enhancing and Deploying the Application

2010-02-17T15:44:00.000+01:00

This is the second part of a two part article aiming to share some experiences with developing JEE6 client applications. In the first part the skeleton of a basic micro-blogging enterprise application was set up, composed of a client application and an EJB module. In this part we will add a simple Swing form to enable users to post messages and to check the central timeline. It will be covered how to deploy to a standalone server and run the client both with the appclient tool and with Java Web Start.

First off, we want to add a JFrame based form to the application. Right click on the Glitter-app-client source package and chose New > JFrame Form. In our example the class will be named GlitterJFrame. In the visual editor, add a couple of UI elements: two text fields, one for the username input and the other for a message to post, along with a list box for the message timeline and two buttons to initiate posting and refreshing of messages.

Switch to the source code and add a DefaultListModel property named timelineModel, which we will use to populate the message list with the posts from the server. We also need a reference to our GlitterPostEJBRemote, which will be wired up on application start.

public class GlitterJFrame extends javax.swing.JFrame {
    @EJB
    private static GlitterPostEJBRemote glitterPostEJB;
    
    private DefaultListModel timelineModel = new DefaultListModel();
    ...
}

Switch back to design mode, select the list box and activate the editor for model property in the properties view. Select Custom code, and fill in the name of the newly created property:

To make our life a little bit easier, we add a convenience constructor as well as an useful toString implementation to our GlitterPost entity model class:

public class GlitterPost implements Serializable {

    public GlitterPost() {
    }

    public GlitterPost(String username, String content) {
        this.username = username;
        this.content = content;
    }
    ...
    @Override
    public String toString() {
        StringBuilder sb = new StringBuilder("<")
                .append(username).append("> ")
                .append(content);
        return sb.toString();
    }
}

Now it's time to perform some action. Double click the Refresh button to insert a new click handler. The following code snippet is responsible to perform the actual refresh:

    private void refreshActionPerformed(java.awt.event.ActionEvent evt) {
        refresh();
    }

    private void refresh() {
        timelineModel.clear();
        List<GlitterPost> posts = glitterPostEJB.findPosts();
        for (GlitterPost post : posts) {
            timelineModel.addElement(post.toString());
        }
    }

In similar manner a handler for the Post button is added:

    private void postActionPerformed(java.awt.event.ActionEvent evt) {
        glitterPostEJB.createPost(new GlitterPost(username.getText(), message.getText()));
        refresh();
        message.setText("");
    }

Time to run the application: since we already had a Main class defined in the application client project, we have to change configuration to run the new Swing UI main class rather than the initial one. Right click on the Glitter-app-client project and select Properties > Run. Change Main Class to GlitterJFrame:

Run the GlitterEA application. If everything worked out well, the application window appears and the functionality can be tested:

At this point, the application could be considered to have it's initial functionality in place and is ready to be rolled out. The Glassfish V3 infrastructure imposes two basic ways to enable a server deployed client application to be run locally on client computers:

Using a local appclient container
Provisioning via Java WebStart

The Application Client Container (ACC) is a runtime environment for running a JEE client application locally, featuring transparent communication with the server based enterprise application as well as serving dependency injection. The appclient utility enables you to start a downloaded client application locally.

With the Netbeans embedded Glassfish instance still running, it is quite easy to give this a try. To get a version of the client application that can be run locally, we need to download the client stubs from the server. Open a command shell and change to a folder of your choice. Locate the Glassfish home and invoke $GLASSFISH_HOME/bin/asadmin with the get-client-stubs command:
> /Applications/NetBeans/sges-v3/glassfish/bin/asadmin get-client-stubs --appname GlitterEA .

After having issued this command, the current working directory should contain the file GlitterEAClient.jar along with a folder named GlitterEAClient which contains further resources. To start the application, the $GLASSFISH_HOME/bin/appclient tool is needed:

> /Applications/NetBeans/sges-v3/glassfish/bin/appclient -client GlitterEAClient.jar

Most likely some exceptions with complaints about recursive invocations will occur, which seem to be safe to be ignored. After a short while the client window should appear and work as expected.

Nevertheless, this solves only half of the problem. Running the application against a standalone server opposed to the instance started and controlled by Netbeans might cause some troubles, especially when using the same Glassfish installation for both Netbeans and standalone deployment.

To get an understanding what the troubles are, try the following:

Stop the Netbeans controlled Glassfish instance under Services > Servers
Stop the Netbeans controlled JavaDB instance under Services > Databases
Switch to your command shell
Start the standalone JavaDB instance:
$GLASSFISH_HOME/bin/asadmin start-database
Start the standalone Glassfish domain:
$GLASSFISH_HOME/bin/asadmin start-domain domain1
Invoke the client application with appclient as described above

You will notice a couple of things going wrong:

While the application may seem to start up normally and without problems, as soon as you hit the Refresh or Post button exceptions will be thrown. A short investigation reveals that the glitter database is missing.
Indeed the standalone JavaDB instance does not know anything about the glitter database yet, since we created it against the Netbeans managed instance which uses a local storage folder in the user's home directory. For the standalone instance we need to create the glitter database again.
If you activate Java Web Start for the GlitterEA application via the Glassfish web administration console on http://localhost:4848 (detailed description follows), you will notice that starting the application fails when trying to launch it.
The reason is that Netbeans uses a simplified deployment process when running the application from within the IDE, which besides others will cause the server side client application jars not to be signed as needed for Web Start. See this java.net forum thread for more detailed information on that topic.

Let's start a deployment from scratch to get around these problems. We now assume that $GLASSFISH_HOME/bin is in your path, to invoke asadmin and appclient. If not, prefix the commands with the correct directory as shown above. We also assume that the standalone Glassfish instance as well as the standalone JavaDB instance are already started as describes earlier.

In Netbeans, right click on the GlitterEA project and select Clean and Build. This will create an up to date ear-file in the dist folder of our project. We will need this for later deployment.
Undeploy GlitterEA if it is deployed already, either in the web admin console (which is suitable for all the following steps as well) or via shell:
asadmin undeploy GlitterEA
Delete the database pool glitterPool if existent:
asadmin delete-jdbc-connection-pool --cascade=true "glitterPool"
Recreate the connection pool, this time including the advice to create the database if it does not exist:
asadmin create-jdbc-connection-pool \ --datasourceclassname=org.apache.derby.jdbc.ClientConnectionPoolDataSource \ --property user=glitter:password=glitter:databaseName=glitter:connectionAttributes=\;create\\=true \ --restype=javax.sql.DataSource glitterPool
Recreate the JDBC resource:
asadmin create-jdbc-resource --connectionpoolid glitterPool jdbc/glitterDS
Deploy the GlitterEA.ear we created earlier:
asadmin deploy ~/NetBeansProjects/GlitterEA/dist/GlitterEA.ear
Note: Although it is possible to extend the command line with the option --property java-web-start-enabled=true, Glassfish V3 currently does not seem to recognize this to enable WebStart capabilities for the deployed application, which we will cover later
After making sure that your current working directory is the one containing the client stubs we retrieved earlier, or alternatively re-fetching the client stubs to your local directory of choice, try again to start the client application locally:
appclient -client GlitterEAClient.jar

Now the client application should start and work as expected.

Although this is interesting for testing purposes, this is not really a suitable solution for provisioning the application to client desktops. That is where the Java Web Start feature of Glassfish comes more than handy. Given a clean standalone deployment as just described, navigate to your web administration console usually found under http://localhost:4848/. Select Applications > GlitterEA, activate the Java Web Start checkbox and click Save:

After that the Launch action is available for the Glitter-app-client.jar module:

Clicking the Launch link brings you to the application launch page:

Click the Launch button to enjoy the application being run via Java Web Start after having confirmed the security information dialog box. An alternative way to launch the application, also suitable to create a program launcher on the client computers is to use this command line (remember to replace localhost with the server name of choice):
javaws http://localhost:8080/GlitterEA/Glitter-app-client

For more information on how to configure and use Java Web Start with Glassfish V3, see the Glassfish V3 documentation and this useful article.

Please keep in mind that this tutorial was not intended to address Swing or EJB best practices, the idea was to keep these parts as simple as possible and concentrate on the client application concept.

The source code can be found (and forked) at github. For feedback, leave a comment or contact me on Twitter.

Create and Run a JEE6 Client Application with Netbeans 6.8 and Glassfish V3 - Part 1: Creating a Basic Application

2010-02-12T23:18:00.005+01:00

While there are lots of examples around on how to create web based EE6 applications, it is a little harder to find a concise tutorial for developing and deploying EE application clients. This is part one of a two part article aiming to share some experiences on that topic.

Assuming you have a copy of Netbeans 6.8 with Glassfish V3 integration already installed and working, let's start with creating a new Enterprise Application project:

In the next dialog, we name the project "GlitterEA" and stay pretty much with the default options. After clicking next, we configure the application to use the default Glassfish 3 domain and to attach both an EJB and an application client module, the latter one with a suitable main class:

Next up, we want to get our EJB module set up to do something useful. For the example, our domain model is a very simple microblog service, to which users can publish their messages and read what others have written. We will create a single entity, accompanied by a stateless session bean exposing the needed services.

We start bottom up by creating a new JavaDB database from within the Netbeans Services tab as described here in the Netbeans documentation. We name it glitter, which will be also the username and the password, and stay with the default location.

Next we create a suitable connection pool as well as a matching JDBC resource for our application. Right click on the Glitter-ejb project and select New > Other... > Glassfish > JDBC Connection Pool:

We name the pool glitterPool and chose our newly created database for the connection:

In the next dialog, we add something like Glitter Microblogging as description. We leave the connection pool properties as suggested and proceed with the Next button. Since we don't have to change any optional connection pool properties as presented in dialog step 4, we chose to short circuit by clicking Finish.

Now we want to add a JDBC resource to which we can refer in our application. Right click on the Glitter-ejb project and select New > Other... > Glassfish > JDBC Resource. Chose glitterPool as the pool to use, and name the resource jdbc:/glitterDS. We are safe to click finish now since we don't want to provide additional properties.

Now we are ready to actually work on our EJB module. First off, we add an appropriate persistence unit. Right click on the Glitter-ejb project and select New > Persistence Unit. Configure it as seen here:

Note: Please check the generated sun-resources.xml file in the Server Resources folder. After adding the JDBC resource, you might experience an empty <property /> element in there. Remove the line, since Glassfish will give you a terribly long exception stack when parsing an property element without name attribute during resource setup at deploy time.

Let's get to coding. Create a new source package in the Glitter-ejb module, for example net.itneering.glitter.ejb. Right click on the newly created package and chose New > Entity Class. Name it GlitterPost and stay with the Long primary key type. Two more properties need to be added in the resulting Java class, username and content. In addition, a named query for selecting the posting timeline is put in place. Slightly shortened, this will be the resulting code:


@Entity
@NamedQuery(name="findAllPosts",
            query="SELECT p FROM GlitterPost p ORDER BY p.id DESC")
public class GlitterPost implements Serializable {

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;

    String username;
    
    @Column(length = 2000)
    private String content;

    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public String getUsername() {
        return username;
    }

    public void setUsername(String username) {
        this.username = username;
    }

    public String getContent() {
        return content;
    }

    public void setContent(String content) {
        this.content = content;
    }

}

To expose some useful services for the client application, a simple stateless session bean is added by right clicking on the same source package and choosing New > Session Bean. It is called GitterPostEJB and will also need an remote interface:

Some basic CRUD methods are added to GlitterPostEJB, as well as the EntityManager reference to be injected with an EntityManager instance for the GlitterPU persistence unit:


@Stateless
public class GlitterPostEJB implements GlitterPostEJBRemote {

    @PersistenceContext(unitName = "GlitterPU")
    private EntityManager em;

    public GlitterPost createPost(GlitterPost post) {
        em.persist(post);
        return post;
    }

    public void deletePost(GlitterPost post) {
        em.remove(em.merge(post));
    }

    public GlitterPost updatePost(GlitterPost post) {
        return em.merge(post);
    }

    public List<GlitterPost> findPosts() {
        Query query = em.createNamedQuery("findAllPosts");
        return query.getResultList();
    }

    public GlitterPost findPostById(Long id) {
        return em.find(GlitterPost.class, id);
    }
}

Two of these methods we will need for our application client, so let's expose them in the GlitterEJBRemote interface:

@Remote
public interface GlitterPostEJBRemote {
    public List<GlitterPost> findPosts();
    public GlitterPost createPost(GlitterPost post);
}

That's pretty much it for the EJB module. Now it's time to check if the client application will work as expected. We will check both the findPosts and the createPost methods with a simple call sequence and some printing to standard out. Modify the Main class of the Glitter-app-client module as follows:

public class Main {
    @EJB
    private static GlitterPostEJBRemote glitterPostEJB;

    public static void main(String[] args) {
        List<GlitterPost> list = glitterPostEJB.findPosts();
        System.out.println(list);
        glitterPostEJB.createPost(new GlitterPost());
        // Now the list should contain the post we just created
        list = glitterPostEJB.findPosts();
        System.out.println(list);
    }
}

Save the file and right click the GlitterEA project. Select Run to start the application. If everything worked out well, the following output will be shown in the GlitterEA console:

Copying 1 file to /Users/rene/NetBeansProjects/GlitterEA/dist
Copying 4 files to /Users/rene/NetBeansProjects/GlitterEA/dist/GlitterEAClient
Feb 12, 2010 10:25:34 PM com.sun.enterprise.transaction.JavaEETransactionManagerSimplified initDelegates
INFO: Using com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate as the delegate
[]
[net.itneering.glitter.ejb.GlitterPost[id=1]]

In the second part of this article we will add a simple JFrame based Swing form to enable users to post messages and to check the central timeline. It will also cover how to deploy to a standalone server and run the client both with the appclient tool and with Java WebStart. The final source code of the project will then be published as well.

Bootstrap missing Maven project dependencies from source

2010-01-14T20:37:00.001+01:00

From time to time one might face the problem that a required dependency for a Maven based project is not found in a public Maven repository, although it's source is accessible and it even turns out to be a maven based build. If you are fine with downloading the source, building and installing the needed artifacts into your local or company's repository, you are done quite easily. But what if you want to open your own project to a wider community, unable to share a common repository - how to produce a common, reproducible (kind of) and self-contained project build?

Here is where the bootstrap goal of the Maven scm plugin comes handy. It allows you to check out your dependency from source control and build and install it as a subtask of your own project build. If this is done before the main build's dependencies are resolved, you will get a nicely resolved self-contained build.


<dependencies>
    <dependency>
        <groupid>org.jboss.weld</groupid>
        <artifactid>weld-se</artifactid>
        <version>1.0.0-SNAPSHOT</version>
        <scope>test</scope>
    </dependency>
    ...
</dependencies>
<profiles>
    <profile>
        <id>bootstrap</id>
        <build>
            <plugins>
                <plugin>
                    <groupid>org.apache.maven.plugins</groupid>
                    <artifactid>maven-scm-plugin</artifactid>
                    <version>1.0</version>
                    <executions>
                        <execution>
                            <id>resolve-weld-se</id>
                            <phase>initialize</phase>
                            <goals>
                                <goal>bootstrap</goal>
                            </goals>
                            <configuration>
                                <goals>install</goals>
                                <connectionurl>scm:svn:http://anonsvn.jboss.org/repos/weld/java-se/trunk
                                </connectionurl>
                            </configuration>
                        </execution>
                    </executions>
                </plugin>
            </plugins>
        </build>
    </profile> 
</profiles>

This is an example for resolving JBoss Weld SE, the standalone version of the Weld CDI / JSR299 dependency injection container for JEE6, which I needed to build the Struts 2 CDI plugin. Currently it is not found in a public maven repo, while the source is freely available. Declaring this as a needed dependency would result in Maven not being able to resolve it in against any known repository, finally notifying you that you have to install it manually in your local repository.

But if you now - at least for the first time - call your build with mvn -P bootstrap <goal> to run with activated "bootstrap" profile, the project you depend on will be checked out from source, built and finally installed in your local maven repository during the initialize phase of your own project's build - et voilà, your project will now (hopefully) compile with nicely resolved dependencies.

Setting up a Portlet Development Environment with Eclipse 3.5, Maven and Liferay 5.2

2009-10-16T19:40:00.002+02:00

While normally I would prefer Netbeans or IDEA for developing Liferay based applications, I had to setup an Eclipse based environment due to client's needs. Basically this is a protocol incorporating known sources such as Developing portlets for Liferay in Eclipse or A portlet dev. environment using maven2.

If you haven't already, get a Eclipse copy from Eclipse Downloads. Install it and chose a workspace when starting. I prefer to setup a clean workspace for the Liferay setup, but this is of course no requirement.

Next, we need some plugins, most of which are served by external update sites which have to be added via the Help > Install New Software menu. Click Add... to register a new site, afterwards chose the site in the "Work with..." dropdown box to get a list of available modules. Check the modules of choice and let the wizard do the rest. The following plugins are needed:

Subclipse 1.6
Homepage: subclipse.tigris.org
Update Site URL: http://subclipse.tigris.org/update_1.6.x
Full installation recommended
m2eclipse 0.99 dev
Homepage / Documentation: Maven Integration for Eclipse - Codehaus
Update Site URL: http://m2eclipse.sonatype.org/update-dev
Full install recommended, except "Maven Integration for ADJT", since it seems to have unresolved dependencies (at least by the time of writing this)
BIRT 2.5
Update Site URL: http://download.eclipse.org/birt/update-site/2.5/
Note: Just add the update site, since it is needed for dependency resolving for JBoss Tools
JBoss Tools
Homepage / Documentation: JBoss Tools
Update Site URL: http://download.jboss.org/jbosstools/updates/development/
Feel free to check what you like, but if a feature has something like "Portlet", "Richfaces" or "JSF" in it's name, it is highly recommended to include, while the SDKs should usually be less of interest.

Now it's time to get you a copy of Liferay from the Liferay Portal Download Page. The following steps assume that you get the Community Edition Tomcat 6.0 Bundle. Unzip / untar the bundle into a directory of choice - my recommendation is the Eclipse workspace directory we want to use for our Liferay development.

At first, a new server configuration for our Liferay installation has to be defined. Activate the Server tab at the bottom, right click in the free area and chose "New > Server". Fill the dialog as shown and click "Next". In the following dialog, chose the Tomcat directory within your Liferay installation folder and an appropriate JRE (1.6+ recommended). You are safe to click "Finish" now, since we have no resources to configure for the server yet. Double click the newly configured server in the server tab to open it's configuration options.

There are a couple of things we want to adjust:

Set a longer start (300s) and stop (60s) timeout, since Liferay has to take it's time
Make sure that the Tomcat installation folder will be used for deployment
Select a suitable deploy path. Since we will configure Maven to do our deployment, we chose the Tomcat temp folder rather than webapps or the Liferay hot deployment folder.
Adjust the VM start parameters to increase the heap and PermGen space limit. Therefore, click "Open launch configuration" and add something like -Xmx512m -XX:MaxPermSize=192m to "Arguments > VM arguments"

The following screenshot shows the values chosen in the server configuration tab.

Now is a good time to start the configured server for the first time and check that everything works. Especially if starting the very first time, some patience is needed since Liferay will need a lot of time to initialize. If everything went well, your browser should open a new window or tab with the portal content.

For the first portlet application, m2eclipse's feature to create new Maven projects based on Maven archetypes comes handy. Select "File > New > Other ... > Maven > Maven Project" and click "Next". The following dialog may remain unchanged, so click "Next" again. The next dialog gives you the actual archetype selection. Chose the "internal" catalog to find the standard portlet archetype. After clicking "Next", you will be able to provide a group and artifact id, an initial version and the main package to place your Java classes. Hitting the "Finish" button will make the new project show up in the Project Explorer. Check that it is marked as a web project. If not, you may have missed to in install the m2eclipse WTP support feature.

Check the project properties and make sure that the JRE System Library under "Java Build Path > Libraries" points to a "modern" Java execution environment such as 1.6. If not, hit the "Edit" button to fix this.

Next step is to fix the portlet-class entry in portlet.xml, which the current maven portlet archetype seems to mess up with a combination of group id with artifact id. Replace it with the fully qualified name of the MyPortlet class found under the package you provided when creating the project from the archetype:


<?xml version="1.0" encoding="UTF-8"?>
<portlet-app xsi:schemalocation="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd
                            http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd" version="1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd">

    <portlet>
        <description>Write here a short description about your portlet.</description>
        <portlet-name>simple-portlet</portlet-name>
        <display-name>simple-portlet Portlet</display-name>

        <portlet-class>net.itneering.simpleportlet.MyPortlet</portlet-class>

        <supports>
            <mime-type>text/html</mime-type>
            <portlet-mode>VIEW</portlet-mode>
        </supports>

        <supported-locale>en</supported-locale>

        <portlet-info>
            <title>Put the portlet title here</title>
            <short-title>Portlet Short Title</short-title>
            <keywords>put keywords here</keywords>
        </portlet-info>
    </portlet>
</portlet-app>

Now everything is ready to configure our pom to let Maven do the deployment to Liferay. For the hot deployment, Liferay requires us to drop a war file in <Liferay Home Directory>/deploy. While you could configure this to be some other directory, the requirement for the war packaging remains. The usual way Eclipse handles the deployment, which is copying the web application resources to the configured Tomcat webapps folder, will not work, since Liferay has to get it's hand on the configured portlets before Tomcat.

For that reason Maven will be utilized to not only build the war artifact, but also copy it to the Liferay's hot deployment directory. While copying the artifact to an arbitrary filesystem location is not a core feature of Maven nor a Maven plugin I'm aware of, it is quite easy to accomplish since Maven's antrun plugin can do the job for us. All we have to do is bind it to a suitable phase, in this case the package phase which will be targeted by invoking package, install and deploy goals. To do so, add the following snippet to the pom.xml file:


<build>
    <finalname>simple-portlet</finalname>
    <plugins>
        <plugin>
            <artifactid>maven-antrun-plugin</artifactid>
            <executions>
                <execution>
                    <phase>package</phase>
                    <configuration>
                        <tasks>
                            <copy todir="../liferay-portal-5.2.3/deploy" file="target/simple-portlet.war">
                        </copy></tasks>
                    </configuration>
                    <goals>
                        <goal>run</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

Please note that if you change the finalName, you will have to adjust the copy target as well. Unfortunately, the ${finalName} variable will not get substituted if you'd try this.

While we do not have to, as a final step the application should be added to the server profile we created. This will help Eclipse to find the code of our project and it's dependencies when it comes to debugging. To do so, right click the server in the Servers tab and chose "Add and remove ...", then add the portlet application to the "Configured" list.

Now start the server, if you like in debug mode. When Liferay is up and running, right click your pom.xml and chose "Run as > Maven package". The war file gets built and copied the deployment folder. A few seconds later you should notice Liferay registering the portlet application in the console. You are now ready to add the portlet to a portal page and set breakpoints or do hot code replacements in debug mode.

Git-a-bit - How Git can be useful when being tied to Subversion

2009-05-07T00:26:00.002+02:00

There's been a lot of talk lately about the new distributed version control systems like Mercurial, Bazaar or Git. It feels like just yesterday we started the fight to convince the world to switch from CVS to Subversion, and hopefully most of us won. But now more and more projects and even companies are switching to one of the new SCM systems, which might make one both consider why they do so and if one would have to undergo all that pain of convincing and migrating again if the concept looks appealing.

Distributed version control systems offer many advantages. They support offline working without the need of large feature cumulating commits when going back online again, which might be the first usecase people see and understand easily. But scratching the surface a bit, it reveals that there is a lot more, like ultra powerful (of course distributed) branching and merging facilities enabling new development team workflows such as continuous integration per developer/pair, enhanced environments for subteam or featureset driven branches, and a lot more.

Let's say you got intrigued by the features and the advanced workflows those new systems offer and you might have decided to give Git a try because you heard that your IDEA IDE now supports full Git integration, and you are convinced that Linus is a cool guy - what next? Move your or your companies' repositories to Git? Even more complicated, if you are a freelancer or consultant like I am, convince all your customers that this is the next cool thing and they have to switch immediately?

A scenario I recently experimented with came up when I was thinking about a feasible process to enable a local CI infrastructure for experimental changes on the Struts 2 codebase. While we have our central CI builds set up, they mostly make sense for features which are targeted for soon to integrate improvements, unless you are working on a fresh early branch like upcoming version 2.2. You would not want to push highly experimental code that might break builds for a longer time or even might never make it into a release to the upstream repository. Nevertheless, when your experiments turn out to be both stable and useful, you would want to push them as a whole to the main repository.

The solution I came up with was to use git-svn locally, which is not only able to make a git repository mirror out of a svn repo, but also to push changes back to the original svn repository. It helped me to introduce a very useful workflow, allowing me to commit small changes to my local git repository, triggering a local Hudson build, while I go over to the next change. I'm also able to pull incoming svn changes easily, improving the quality of the local integration test and solve merge issues upfront. After implementing and testing all changes, the commit to the svn repository then goes as a whole.

I started to build the Git mirror infrastructure from scratch, without knowing the concise Apache documentation on that topic which Don Brown pointed me to later. The only downside for my boilerplate solution was that since our svn tree is part of the huge Apache svn repository containing all revisions of all projects, the initial creation of the git-svn repo took about one (!!) day - it scanned about 7.3 million revisions only to get our "small" tree synced. But once done, things ran very fast, and getting the local infrastructure with Hudson and IDEA Git up and running was just peanuts.

After all, I found this workflow also very useful for my clients' projects, both for having a CI infrastructure set up even when the client refuses to and to have a good offline working infrastructure in place.

Moved - You're now watching my shiny new official blog

2009-03-04T00:12:00.004+01:00

After some weeks of evaluation, I've decided to move my blog over here. The interface is compelling and the tool support, líke e.g. offline authoring, rocks. I still love the fantastic JRoller service and I have to thank for enjoying a free and high quality service there. But now let's start over here, combined with the hope that the easier authoring will push me to write more frequntly (to be proven ...)
I have to admit that I've not posted too many articles yet, but some of them might still be of interest - so here is a short link list of my previous posts on Ray's Blog:

There are already a couple of new topics I want to write about, let's see if I find the passion to do so :)

Howto connect Mini-USB plug to HTC phone

2009-01-13T20:07:00.006+01:00

I ordered a power adapter for my amazing little Android developer phone aka HTC Dream last week. When I unpacked it, I was a little disappointed because it looked like it was the wrong plug to be delivered, namely a conventional Mini-USB plug rather than a HTC ExtUSB one. I contacted the seller and complained, but he was desperately trying to convince me that it would work. Lucky enough, before making a total fool of me, I gave it a second try - and voila, it works! To document this, I recorded a demonstration video (of rather poor quality, better turn of sound) - to help my seller argue, and to convince other people that it works after all.

So empty ...

2009-01-11T18:02:00.005+01:00

After starting this blogger site (and, well, saving this name I really like), I was heading back to my old blog site at JRoller, although it isn't that slick to work with as blogger is. Coming back here after some time now, I realized a couple of things:

this blog is desperately empty
the UI and publishing / linking options are really great here
if you're already googlenized (using GMail, Reader , GTalk, Docs and what not), it is so easy ~~for Google to track my hole life~~ to connect things nicely
sooner or later my brandnew adp1 phone will have a blogger client, I bet
I should spend more time blogging....

I'm seriously considering to move my useless thoughts here, but I'm not convinced yet.