Sometimes, you’re just having a wonderful day and suddenly the worst just happens:

[ServiceController] Problem starting service jboss:service=Naming
    java.rmi.server.ExportException: Port already in use: 1198; nested exception is:
    java.net.BindException: Address already in use: JVM_Bind
    at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:243)
    ............

The regular solution is to check if the port is actually used. So fire up a command prompt and netstat –aon.

If you find the port, see what process is using it and kill it .

If you don’t see the port you can reserve it by following the information in KB812873 – http://support.microsoft.com/kb/812873.

My ReservedPorts entry contains:

1433-1434

1097-1200

4543-4545

That should fix it. The bad thing is that it requires a restart.

Writing transactional unit test with JUnit, Spring and Hibernate is easy, what you want to do is:

- Add a transaction management bean in your test context:

<bean id="transactionManager"
class="org.springframework.orm.hibernate3.HibernateTransactionManager">
<property name="sessionFactory" ref="sessionFactory"/>
</bean>


- Make your test extend AbstractTransactionalJUnit4SpringContextTests
- Annotate you test class with @TransactionConfiguration and @Transactional

If your transaction demarcation is correct( surrounding your dao or service ) you should be done. This is the cleanest way that I found.

Everything until now is fine and dandy. The problem arises when one of the injected beans is bound to a scope. It can be any scope but for this example I’ll take the simplest scope – the ‘session’ scope.

In a non-transactional situation this should be pretty straight forward, just implement Scope and using a ConfigurableBeanFactory register it. The fact that we are extending and that our context is automatically created really kills the simple path.

You’ll get a org.springframework.beans.factory.BeanCreationException with a nested “java.lang.IllegalStateException: No Scope registered for scope ‘session’”.

But do not despair, there is simple solution available and it’s called CustomScopeConfigurer.

The fastest and cleanest way to use it is:
- Create a simple class that will be used as our scope manager. Let’s call it MockSessionScope.

- In your test context, create a CustomScopeConfigurer that will automatically register your scope on context creation:

<bean class="org.springframework.beans.factory.config.CustomScopeConfigurer">
<property name="scopes">
<map>
<entry key="session">
<bean class="com.gridpulse.xandria.translator.MockSessionScope"/>
</entry>
</map>
</property>
</bean>


Run your tests and you’re done!

Not ever line of code can be reused. A lot of web development is about crafting a very specific solution. Localization, error handling, and coding conventions introduce challenges.

This is part of a post from one of the Mozilla blogs that I’m following, namely the blog of Austin King.

Now, this is as straight forward and clear as it is correct, not ever line of code can be reused. Putting it out of its initial context (web development that is) and bringing it into to context of enterprise applications it becomes pure evil, used as an excuse to re-invent a perfectly good wheel.

Photo by tcp909

Some advice:

• Reuse as much as you can, extracting recurring pieces of code as methods
• If common code spawns between projects, always extract it in a common library
• Run a copy-paste detector such as CPD. Extract the code to methods.
• Try to keep your methods under a fixed number of lines, let’s say 20. Doing this will force you to extract consistent pieces of code in separate methods, making them more re-usable
• Try to maintain low cyclomatic complexity. Use a metrics package such as PMD or Panopticode. Refactor complex methods to smaller, less complex chunks of reusable code.
• If you have the feeling that it’s the second time you’ve written a piece of code, search for the first one, because it’s usually true.

Now go and read a good book about this kind of stuff. I recommend The Productive Programmer by Neal Ford. It’s an excellent book for beginners but don’t fear – it’s superb even if you’re an experienced developer, I caught some nice Groovy tips that made the reading worth while, maybe you’ll find something interesting too.

1. Forget about XML Schema, use DTD’s

As I was about to touch the first base, after throwing my exploded WAR in j2ee applications, OC4J started complaining about XML issues. This is what I mean:


javax.xml.parsers.ParserConfigurationException: Unable to validate using XSD: Your JAXP provider [oracle.xml.jaxp.JXDocumentBuilderFactory@1571dff] does not support XML Schema. Are you running on Java 1.4 or below with Apache Crimson? Upgrade to Apache Xerces (or Java 1.5) for full XSD support.


Yea, …nasty. As you don’t want to place Xerces and Xalan in your JRE/JDK lib, all you must do is strip the XML Schema related information and use Spring DTD’s.

2. Use ContextLoaderServlet, bootstrap listeners are for smart containers!

Don’t use ContextLoaderListener. It won’t work, as OC4J is Servlet 2.3 compliant and does not enforce loading of Listeners before load-on-startup Servlets. So, to escape the bean not found hell, use ContextLoaderServlet.


<servlet>
<servlet-name>context</servlet-name>
<servlet-class>
org.springframework.web.context.ContextLoaderServlet
</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>


Read more about it in the Spring Framework ContextLoaderServlet javadoc.

3. Specify UTF-8 encoding

No encoding filters needed, as oposed to the Tomcat crowd. All you need to do is edit global-web-application.xml and make sure that you specify default-charset. Read more about it in the web module configuration files documentation at Oracle.

Example:

<orion-web-app
jsp-cache-directory="./persistence"
servlet-webdir="/servlet"
development="false" jsp-timeout="0"
default-charset="UTF-8" >


The usage of maven assumes the presence of all required repositories and most of all the presence of a reliable Internet connection.
What happens when you need artifacts that are temporarily unreachable or you are bound behind an unreliable connection? In the worst case you get build failures but more frequently you get build times that are measured by the tens of minutes.
This would be ok if it happened once a week but it’s not ok when it happens daily to you and a dozen other team members working on the same project.

The solution we used in the past to fix this problem was a maven repository proxy called Proximity.
Proximity introduces other small problems and latencies and has proven a little unstable, requiring weekly restarts. Plus it included some settings.xml modifications in our previously hands-off newbie development setup. If you want to read a little more about Proximity you can take a look at the project website.

Proximity 1 has been deprecated and until the new Nexus will be out I decided to look for something different.

Introducing Artifactory
Artifactory is not (exactly) a caching proxy, like Proximity, it works by simulating and acting as a maven repository.

Every artifact cached is available as part of the local Artifactory repository and when offline, the build process is exactly the same.
It is installed in a copy/unzip and run process and works right out of the box. Some customization is needed only if you use exotic repositories that are not included in the defaults.

Artifactory also returned the development setup to its hands-off svn checkout, mvn eclipse:eclipse or idea:idea nature. It contains a good graphical interface with artifact cache invalidation, which really helps sometimes.

Take a look at the live demo, it’s worth the 5 minutes.

If your application runs as a service (or linux/unix dæmon) you can’t press CTRL+Break, so you have to signal the JVM yourself to produce the stack trace. You can do that on linux by signaling a QUIT to the process, or by using jstack and the PID.
Good news, Java SE 6 on Windows comes with jstack. Yupee! .

So next time you need a thread dump from a java application running as a service just get the pid, fire up a cmd and run jstack <pid>.

Things you might want to know:
* doesn’t work out of the box on JSE6. It actually needs a lot of work, so avoid using for now;
* you need a maven project
* you actually need a valid XSD

The classes are generated by JAXB xjc. You can do this by hand, but using maven and maven-jaxb2-plugin makes it a breeze.

So, this is what you must do:
* Place your schema definition in your src/main/resources directory
* Open you pom.xml and add the following(no worries, you will remove them later):


<repositories>
<repository>
<id>maven2-repository.dev.java.net</id>
<name>Java.net Maven 2 Repository</name>
<url>http://download.java.net/maven/2</url>
</repository>
<repository>
<id>maven-repository.dev.java.net</id>
<name>Java.net Maven 1 Repository (legacy)</name>
<url>http://download.java.net/maven/1</url>
<layout>legacy</layout>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>maven2-repository.dev.java.net</id>
<name>Java.net Maven 2 Repository</name>
<url>http://download.java.net/maven/2</url>
</pluginRepository>
<pluginRepository>
<id>maven-repository.dev.java.net</id>
<name>Java.net Maven 1 Repository (legacy)</name>
<url>http://download.java.net/maven/1</url>
<layout>legacy</layout>
</pluginRepository>
</pluginRepositories>
<dependencies>
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.0</version>
</dependency>
</dependencies>
* In your build section configure the jaxb2 plugin:

<plugin>
<groupid>org.jvnet.jaxb2.maven2</groupid>
<artifactid>maven-jaxb2-plugin</artifactid>
<executions>
<execution>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
<configuration>
<includeschema>**/*.xsd</includeschema>
<generatepackage>com.gridpulse.project.model</generatepackage>
</configuration>
</plugin>

As you can see, you have 2 configuration settings:
* includeSchema - schema file mask to include
* generatePackage - the package that you would like to hold the classes

After setting this up, just fire up a mvn install. This will produce the model classes in the target/generated-sources/xjc/ directory.
You can now copy them to your src directory and clean them up.
Remember to remove the JAXB2 settings from your pom.

Now, although the docs say that the name attribute is optional on collections, it’s actually required in the real world.

Some flexible setups, like mine, get really confused if the name attribute is specified, and, because it is required I can’t even bind it without setting validate to false, and if I set validate to false, the JiBX_MungeAdapter appears in my module root (${basedir}) instead of the required package.

The only solution I found for this problem is to downgrade to JiBX 1.1.3 and maven-jibx-plugin 1.1.3. I know it isn’t a real solution but what can I say, half a day is too long to loose working on something that can be fixed by a minor-version downgrade.

You can do this by using profiles and classifiers.

You can create your pom, the usual way, with profiles…more here, then apply classifiers to the package plugin inside your profile, like this:

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.0</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>war</goal>
</goals>
<configuration>
<classifier>standalone</classifier>
</configuration>
</execution>
</executions>
</plugin>

This will produce an artifact with finalName

${artifactId}-${version}-${clasifier}

that will be accessible by specifying the classifier in your dependency.

Just remember to use executions because it will not work otherwise. It will build the artifacts, but will not deploy them.

I’ve been a Maven user since 2005, but only as a “user”, never creating build files, never really understanding the full picture.

I used to be a skeptic, but now I am fully converted. For the past 3 days I’ve been migrating the build process for a 15 module project from ant to Maven 2 and I have to admin that once you get past the dependency configuration, everything else is a breeze.

The build file size, maintaining every functionality, has decreased by two thirds, and is now more readable.

Everything from JiBX binding to build versioning is almost out of the box by using the plugin system. Plus, the Surefire plugin just works, no hassle there, running all tests with testng, although it’s slower than the direct testing I used to do with ant.

Anyway, it’s worth loosing two or three days, the benefits are huge.