Is SetCharacterEncodingFilter a thing of the past?

I thought so. But I was wrong. I thought after all those years of hacking the encoding parameters in our java application they had sorted it out. In our latest migration to JBoss EAP 5 i made sure that we didn't need those hacks. But we also had to change the jsp and response encoding to UTF-8 for other reasons.

This turned out bad. JBOSS is hard set to ISO-8859-1 internally which means that a form submission in UTF-8 will decode incorrectly. Now, we did set the accept-charset tag on all forms, but Internet Explorer ignores the property. We tried to hack the poor explorer with ugly javascripts which made it work. But finally we let in an added the good old encoding filter anyway.

Our options was to either change the page encoding to ISO. This would have broken an old external system (yepp, it's old, it must get UTF-8, it "can't" be changed). Or we could have changed the encoding settings in the JBoss configuration files. This would have broken other applications on the same server.

But still, why did the JBoss community decide to take this path? How does users in non-western countries do? Is JBoss designed for Europe only?

Struts 2 convention plugin in a WAR in a EAR in Jboss

This issue has been bugging my for a while and I have not found any solution to it so far. It seems from google results that I am not alone with this problem.

The problem occurs when you have a Struts 2 convention based web application (WAR) inside an EAR package. And deploy it on jboss. Because of Jboss using the vfszip packaging the open symphony ClassFinder fails with a message like

c.o.x.u.f.ClassFinder - Unable to read URL 
    [vfszip:/.../server/default/deploy/MyEar.ear/MyWebApp.war/WEB-INF/classes/]
    java.io.FileNotFoundException: 
    /.../server/default/deploy/MyEar.ear/MyWebApp.war/WEB-INF/classes/ 

So. Nobody solved it in a good way yet. I'm gonna go with this solution, it'll have to do for now.

Update: I tried to implement the linked solution using reflections, but failed. Basically it has the same issue and I'm still left with hard coding the list of classes.

Surefire plugin wont run my JUnit tests!

I spent way to much time on this trivial issue to not write it down. I ran into an issue where my unit tests (JUnit 4) were running fine in Eclipse but not by the maven surefire plugin.

Google served up numerous solutions to my problem but it didn't help me. My problem was much simpler. Eclipse will run any test in any class where the method is annotated with @Test. This does not apply to surefire. If the class is not named Test, surefire will not even look for tests in it. Hence, in maven projects, we should always name test classes that way.

Code coverage on JDK7 with Emma

The latest upgrade to JDK7 did go without any issues what so ever in terms of application functionality.

The only issue so far is with Emma which stopped recording code coverage and turned to breaking tests instead giving an "Illegal local variable table length 5 in method" error instead.

What you need is this:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
  <version>2.12</version>
  <configuration>
    <argLine>-XX:-UseSplitVerifier</argLine>
  </configuration>
</plugin>

Relative file paths on JBoss EAP 5.1.2

Apparently there was a change in which kind of file URLs are correct in JBoss EAP 5.1.2. This tiny little change caused a great deal of pain in my case throwing

"IllegalArgumentException: URI is not hierarchical" in one environment but not the other.

Very well. We use the PropertyPlaceholderConfigurer with relative paths for file locations to greatly simplify the configuration differences between deployement and development environments. This is all done by simply stating

<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="locations">
        <value>config/application.properties</value>
    </property>
</bean> 

In the applicationContext.xml to load properties from a path relative to the execution path. Running the application with maven jetty makes development rapid and simply and almost no setup is required for new developers.

With the latest change in JBoss, this could have become a very big issue. However, after a long days fiddling, here's the solution with maintained behavior.

<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="locations">
        <value>file:${user.dir}/config/application.properties</value>
    </property>
</bean>

Migration from Weblogic 8.1 to JBoss 6

This post is not about a tiny application. Whilst still interested in building small, simple and single purpose application and modules one must also make a living.
Right now, one of my assignments is to evaluate the possibility of migrating a large near-legacy J2EE application from Weblogic 8.1 to JBoss 6.

The business case behind this is simple. The weblogic license is more expensive, we are not using any power-features of weblogic and the licensing is unsuitable for the new virtual environments. And yes, we must upgrade in any case. Here are my notes of what has to be done to make it run in JBoss. Since I know beforehand that security might be an issue, and we are not using security, if you have it, you may stop reading.

Many of the issues I had is because the weblogic seems less strict, and only small corrections was required.

JSP tags and TLDs

For some reason, once upon a time, there was an urge to copy TLDs (like the struts ones) and place them in the war/WEB-INF folder. They would then be referenced from the web.xml and incorrectly by path from the JSPs. I have seen this many times and it's probably not a special case. This has to be cleaned up. Removed the TLDs that are in some jar-file somewhere. Removed the references in web.xml and fix the declarations in your JSPs. The uri parameter must match the uri declared in the tld-file.

A small note on custom tags. If you have tag parameters in your jsps which are not in the TLD, JBoss (catalina) will throw an exception. Weblogic will silently ignore it.

EJBs and naming

Weblogic and JBoss does create JNDI names for EJBs differently. They are placed in different namespaces and you need to change which ContextFactory is used. Most importantly you should declare names for you EJBs in the jboss.xml file, otherwise it can be hard to figure out and pick up in your code.

ear Packaging

JBoss gets really cranky if you happing to package classes multiple times in your ear-archive. This easily happens when you have ejb-jars in the ear and also includes the ejb-client jars for dependent ejbs and wars. In maven, this is an easy fix by using the "provided" scope for client dependencies and possibly also using the skinnyWars option for maven-ear-plugin. With ant, you'll have figure it out manually of course and with an older version of maven-ear-plugin you have to put in packagingExcludes in you war-plugins.

Persistence

This part is maybe the most complicated one. This is due to two main reasons. Weblogics implementation of EJBQL is more powerful and you'll have to build up the jboss.xml and jbosscmp-jdbc.xml files, corresponding to weblogic.xml and weblogic-cmp-jdbc.xml, respectlively.

EJBQL

The weblogic implementation of EJBQL supports aggregate functions like MAX and SUM. This is not supported in EJB 2.0 but in 2.1. Thus it should not be a problem in JBoss 6. However, JBoss does not support aggregated functions in nested query and a query like this

SELECT OBJECT(logg1) FROM LOGG logg1 WHERE logg1.systemId = ?1 AND
    logg1.created = (SELECT MAX(logg2.created)
                   FROM LOGG logg2
                   WHERE logg2.systemId = logg1.systemId)

won't work!
Some on these can be rewritten. They can be split into two and programmatically merged or they can be reimplemented with JPA. I haven't determined the best solution yet.

A small note on EJBQL is, like with JSPs, Weblogic is much more tolerant to small grammatical errors. You might need to put in the whitespaces and missing closing parenthesis here and there.

Persistence mappings

For the jboss files mentioned above you can find xslt templates online to convert them. They might not help you with everything thou. I haven't seen one that handles the relational mappings between entities yet and you will need to read up on this in the JBoss documentation.

ID Sequences (auto-increment kind of)
This is quite simple once you've figured it out, however it took me a while. Just add this to each entity in jbosscmp-jdbc.xml

<entity-command name="oracle-sequence">
    <attribute name="sequence">THE_TABLE_IN_QUESTION_SEQ</attribute>
</entity-command>

Datasources

We are blessed with Oracle databases. You have to add the jdbc client jar to the default/server/lib directory and then you can setup the data source in the admin console. It seems buggy however and you might need to edit the xml-file on disk which is created. Pay attention that even if you set the JNDI name to MyDataSource the JNDI name becomes java:MyDataSource.

Painful unit testing in struts 2

If you plan on doing unit testing and truly decoupled action classes in struts 2 I must recommend you not to use the abstract (but helpful) ActionSupport class in your class hierarchy. Why? Many reasons, here's one.

The ActionSupport class contains some hard coupling which makes unit testing outside of a struts 2 "ActionContext" impossible. Of course, you can set up an ActionContext in the tests setUp() method and you're home free, but it's a heavy and unnecessary fixture. Inheriting the ActionSupport class binds you to this solution in some cases. Amongs others, this field

private final transient TextProvider textProvider = 
    new TextProviderFactory().createInstance(getClass(), this);

is a pain.
If the ActionContext is not setup, any call to getText(...) will cause a null-pointer exception at this line

ValueStack valueStack = ActionContext.getContext().getValueStack();

for obvious reasons.

This leaves you with three options. either you build up that awful fixture and build fragile tests which all fails in groups and tests much more logic than they should. Or you avoid testing code which touches this stuff. Or you copy the ActionSupport class (watch out for the license!) and set the field to default visibility instead of private final and replace it with a mock in the unit test.

Workaround for buggy struts 2 portlet plugin

The Struts portlet plugin makes portlet development almost as smooth as web development with struts. Except that there is no server environment like tomcat in eclipse the portlet plugin makes portlet behave just as applications.

In my setups I create maven profiles for building the portlet and developing in eclipse. By adding a webapp profile with sitemesh and setting up a basic sitemesh decorator for the portlet styling can be done without deploying to the container all the time.

Now, there are a few issues with the portlet plugin. One of them turned out to risk becoming a show-stopper for struts usage in my latest project. I've been spending some free time on digging into this and here's what I have come up with.

When form urls are rendered with the portlet plugin, the plugin adds a parameters containing the namespace and action (path) that should be executed when the form is submitted. This path is constructed from a number of parameters, the portlet namespace, current portlet mode namespace and the namespace declaration on the s:form tag. Normally, a simple test form would look like

<s:form>
 <s:textfield name="value"/>
 <s:submit method="submit" />
</s:form>

which is simple and clean and what I like about struts 2! Now let's say the action is executing in namespace /test/view as declared in the viewNamespace parameter from portlet.xml. Then the portlet url will become portlet namespace + mode namespace + tag namespace which results in "/test/view" + "" + "/test/view" since the third part is by default the namespace of the current action. Of course, this will not work.

Loosing some of the clean and simple and reusability the form can be fixed to work properly by manually setting the namespace to "nothing" and thus using only the mode namespace. This form can of course never be reused for other actions, but that might be a minor problem.

<s:form namespace="/">
 <s:textfield name="value"/>
 <s:submit method="submit" />
</s:form>

If you are also using a portlet namespace, then it probably gets worse and I won't even try to go there.

Decoupling struts actions

Searching Google for struts unit test techniques you find a lot of discussions and blogs on the subject. The only ones I've found are either discussing the StrutsTestCase or how in some other way (manual) setup the entire struts machinery to run unit tests. I have however not found anything about how to test action classes alone.

Testing struts actions with the StrutsTestCase tests much more than just the logic in the action class itself, which is normally what you want to do in a well isolated and simple unit test. I am not interested in whether urls are correctly mapped or request parameters are set on my models by struts. This is something the struts developers do themselves, I assume, and for me it is actually more of an integration test.

So, to my issue. Trying to unit test my actions I ran into a new issue the other day testing an action using the getText(..) method. This particular method, in the end, locates package resources in it's own directory (from the action class) and parent packages until a resource is perhaps finally found. This requires the environment to know about which action class is executing. I've been trying to mock this condition away with combinations of easyMock and the struts bundled mock classes. To no avail.

The problem here is a classic one when you try to unit test. It is because I have extended the bundled ActionSupport (for convenience) and it contains:

private final transient TextProvider textProvider = 
    new TextProviderFactory().createInstance(getClass(), this);
private final ValidationAwareSupport validationAware = 
    new ValidationAwareSupport();

The ValidationAwareSupport is just a datastructure to decrease code size of the validation aware class and has no external dependencies, which makes it a non-issue.
The TextProviderFactory however, is a big issue. Skipping a few details, digging into it, it depends on just about everthing. There are utility methods accessing action context and the valuestack and so forth. Wanting to avoid the execution context, in this case the action context (and possibly more), this should of course be decoupled.

I have already, since long back written my own ActionSupport since I didn't want it to be serializable. And, now decoupling the TextProvider is not very hard. I just add an interceptor that injects the TextProvider into the action during struts invocation. After this I'm free to provide a truly decoupled mock TextProvider in my unit test.

@Override
public String intercept(ActionInvocation invocation) throws Exception {
    Object action = invocation.getAction();
    if (action instanceof TransientActionSupport) {
        if (logger.isDebugEnabled()) {
            logger.debug("Setting text provider on action");
        }
        ((TransientActionSupport)action).setTextProvider(
            new TextProviderFactory().createInstance(
                action.getClass(), (LocaleProvider)action));
    }
    return invocation.invoke();
}

The next step is just to add the interceptor to your default interceptor stack, and you have the same functionality in your webapp as before.

Finally some java

After being trapped in a vicious circle of microsoft projects the last year, there is finally an upcoming java project at work. As the lone java/web experienced developer I'll be putting in 50% on the project as a tech support, kinda.

What we're going to do is a portal based on sitevision. Having fresh bad experience from EPiServer i fear the magic Strings tying together interface entered data in some spooky database with our java modules. We'll see what it might give in a couple of weeks.

My first and most obvious task is to build google maps module for the site. This is of course done using a portlet. Having never used portlets before I have some learning to do, starting in a few weeks. I couldn't help myself however... To try out to see how nice such things can done, without outputting html in the portlet code, I plugged the latest struts onto it. And, out of the box, struts with the excellent convention plugin just works.

I've put the code up on github. It's not working ultra smooth, but might give some inspiration, I'll be happy to merge in any improvements.

Spring annotations on google app engine

Peter Backlund has an excellent post on running Spring on Google App Engine. He lists the issues, with references. The first one, the one with the javax.naming.NamingException, is the first one you run into using annotation driven configuration. One workaround is not to use JPA. However, if you still want it you can always disable the black sheep, doing this in your applicationContext.xml:

<bean id="org.springframework.context.annotation.
    internalPersistenceAnnotationProcessor" class="java.lang.Object" />

This disables the bean that wanted the NamingException. I have only verified that bean configuration and autowiring works as expected, transactions are the next step.

Dysfunctional persistence in GAE

So, just how dysfunctional is the persistence API(s) in Google App Engine. I've been elaborating with alot of different mappings and queries lately to see what can be done. Well, not much. I've mainly given up on creating mappings and using keys instead. The latest released promised to improve on this, but I haven't taken the time to try it out yet.

Today, I stumbled upon a new horrifying error message (among others...)

java.lang.IllegalArgumentException: can't operate on multiple entity groups in a single transaction.

This means I cannot use transactions for assuring the datastore state when I have dependent entities, what is transactions for then?

Adjusting GAE eclipse plugin for maven

The last months, I've been working in a application maintenance team. Yes I know, it sucks. But since I met with the CEO of the company I work for (which happens to be in the top 10 worldwide) he inspired me that working with maintenance is vital to understanding how to write maintainable applications in the future. He admitted that most people dislike it, but it is also what most developers do in the industry.

Even worse, I'm maintaining Microßoft-based applications. C#, VB, MSSQL. That shit. Throw in a little oracle as well to top it of.

So now, I'm looking at trying out something modern on my spare time. GAE (Google App Engine) released java support some time ago and I managed to get an account. I strongly like eclipse and the ease of deploying applications from it. However, the applications are not structured to my liking, which is the maven convention, and I want them all to look the same, and build the same way. In the name of maintainability. What I want to do basically, is to create a project for app engine, with the maven structure and add some of the eclipse stuff to it.

First, create a new GAE project using the eclipse plugin. You now have a project with some basic directories and files. Just hit deploy to send it the GAE and get the Hello World servlet up.

Next, we have to move and separate source and resource directories. This is no problem whatsoever. Just separate the resource and java files to src/main/resources and src/main/java respectively.

The war directory cannot be moved, as of now. So we'll have to leave it where it is (sucks).

Next. I want a faceted project with the dynamic web module (just because other java projects are like this). To enable the facet, just go into project properties and enable the java facet with version 1.6 and then the dynamic web module facet. Watch out! A notification with be displayed to configure the facet, you have the click it and change the web content directory, or you'll have a nice WebContent directory to deal with.

Most facet setting cannot be changed from Eclipse. You can however do this yourself.

If you missed out changing the war directory, edit .settings/org.eclipse.wst.common.component and set wb-resource::source-path to /war.
The web module version is default set to 2.4, if you need to change this, edit the file .settings/org.eclipse.wst.common.project.facet.core.xml

Those two files can be added to source control as well to get people started faster (maintenance thinking again).