JH On Java

The Quest for Parallelism - Slides from JFall

2009-11-12T11:44:00+01:00

Yesterday, at the 2009 edition of JFall, I gave a talk about parallelism. The slides from that presentation can now be downloaded here.

For those of you who missed my talk, stay tuned to this blog. I am working out a summary article.

--JH

Easy Event-Driven Application With Spring!

2009-11-05T18:18:00+01:00

Suppose you are making an event-driven application. You have your listener interfaces and your event-generating objects. What is the most annoying part of getting this all to work?

Connecting your listeners to the event-generating objects. Every time you want some object to receive certain events, you have to register your listener with the correct producer object. This has some nasty effects on your code:

Either your listeners know to which object they are subscribing, or your event generators know who should be listening to their events
Due to this coupling, listeners and producers are difficult to test
Adding a new listener to your project requires some boilerplate code to get it working

Spring has a feature that can take care of all of this hassle: autowiring. For normal dependency injection, autowiring feels icky. It's just too magical and leaves me with a feeling I am not in control. The great thing about autowiring is that it can be used on a per-method base.

Suppose you have a listener interface:



 1
 2
 3
 4

public interface MyEventListener
{
  public void onMyEvent(MyEvent me);
}

And suppose you have some class that implements this interface:



 1
 2
 3
 4
 5
 6
 7

public class MyListener implements MyEventListener
{
  public void onMyEvent(MyEvent me)
  {
    System.out.println("My Event was raised!");
  }
}

Cool, so now we still need some event-generating class:



 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

public class MyGenerator
{
  private MyEventListener[] listeners;

  public void generateEvent()
  {
    MyEvent me = new MyEvent();
    
    for (MyEventListener mel: listeners)
    {
      mel.onMyEvent(me);
    }
  }

  public void setMyEventListeners(MyEventListener[] listeners)
  {
    this.listeners = listeners;
  }
}

If you looked at the above class and wondered why I've made a setter for an array of listeners, instead of a method that registers a single listener, then prepare to be amazed. If you are familiar with Spring and autowiring, you probably know where I am headed :).

Neither the event listener, nor the event generator have any knowledge of each other. This is perfect, we can write unittests for each class without having to mock the other. However, the event generator still needs a reference to the listener for this thing to work. Let's put these two objects in a Spring context together:



 1
 2
 3
 4
 5
 6
 7

<beans ...>

  <bean name="myGenerator" class="MyEventGenerator"/>

  <bean name="myListener" class="MyListener"/>

</beans>

Great! Almost there, all we need now is some magic. The magic requires two components, one in the Spring config and one in the event generator class. The Spring config requires the <context:annotation-config/> tag, to enable the annotations:



 1
 2
 3
 4
 5
 6
 7

<beans ...>

  <context:annotation-config/>

  ...

</beans>

And finally, the generator class will get its listeners autowired:



 1
 2
 3
 4
 5

  @Autowire(required=false)
  public void setMyEventListeners(MyEventListener[] listeners)
  {
    this.listeners = listeners;
  }

Tada! The generator class will now automatically have an array of listeners injected into its setter. The Spring container selects all beans that are assignable to the array value type and passes them to the event generator. The required = false bit ensures Spring won't throw an exception when you have no listeners configured.

If you now want more than one bean to listen to these events, all you have to do is add a bean to the Spring config that implements the MyEventListener interface and it will automatically get added to the array. Yes, it is really that simple.

Have fun!

--JH

New: GnuPG plugin for Outlook 2007

2009-10-29T17:27:00+01:00

David Cumps has gone about developing a working GPG plugin for Outlook 2007. Now you can sign your emails from Outlook 2007 using the great Open Source GPG. He describes the installation and usage at his own blog.

--JH

New Concurrency Classes in Java 7

2009-09-15T11:51:35+02:00

I just read a few posts on the new concurrency classes available in the upcoming Java 7. Altough I haven't yet had the time to dive into them, the fork-join library and parallel collections seem very promising.

See for yourself:

Eclipse Galileo and NTLMv2 Proxies

2009-08-13T09:49:00+02:00

While configuring the newest installment of Eclipse, Eclipse 3.5 (Galileo), I ran into some proxy trouble. After setting the proxy-configuration, the 'Install New Software...' window would structurally say 'No repository found on <location>'.

After some Googling and researching, it appears to be a problem with Eclipse's underlying URL/Proxy handling library. This library is now Apache httpclient, which does not support NTLMv2 proxies. Luckily, there's a workaround.

If you are behind an NTLMv2 proxy, you can force Eclipse to revert its URL/Proxy handling library to the old JRE URLConnection by adding these lines to your eclipse.ini file:

-Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient
-Dhttp.proxyPort=8080
-Dhttp.proxyHost=myproxy
-Dhttp.proxyUser=mydomain\myusername
-Dhttp.proxyPassword=mypassword
-Dhttp.nonProxyHosts=localhost|127.0.0.1

If your proxy does not require authentication, you can leave out the proxyUser and proxyPassword settings.

For more information, see http://wiki.eclipse.org/ECF_Filetransfer_Support_for_NTLMv2_Proxies.

--JH

Connecting JBoss instances through JNDI

2008-12-10T21:02:17+01:00

So here I was, cleanly splitting out the service EJB and web front of an application. We even went so far as to have the two components run in separate JBoss instances, on separate machines. But... they had to communicate to each other through a JNDI lookup. That's where we ran into a ditch, fought with Java and JBoss settings for a few days and came out victorious. Let me help you stay out of these trenches and show how to configure this.

First let me describe the setup of the machines we used. We have two machines in our hosting environment, one of which is accessible from the outside world, let's call this one Whiskey. Whiskey is part of two networks, one goes out to the real world, the other stays on our internal network. The other machine, Sierra, can only be reached from the internal network. Whiskey talks to this machine through its internal interface.

Whiskey is supposed to run our Web-application and delegate service calls to Sierra. No big surprises there. Both machines run JBoss 4.3 on Red Hat Linux. Sierra registers an EJB bean in its JNDI registry and accepts service calls through RMI. All Whiskey has to do is lookup the EJB in Sierra's JNDI and make calls to the returned object. Sounds easy right?

The first try included googling for the words 'connect jndi jboss'. You get all sorts of hits on how to connect to things in a JNDI registry, but not on how to incorporate one server's JNDI into another. If you keep googling and change your keywords to 'integrate jndi jboss', you get a little closer, but the words you are looking for are 'federate jndi jboss'. This will eventually lead to something called the ExternalContext.

The org.jboss.naming.ExternalContext MBean makes it possible to integrate the JNDI directory of one server into another. Since it is itself registered under a JNDI name, every lookup beneath that node is delegated to the other server. For example, if you bind the ExternalContext under /external, then /external/my-service-bean will lookup /my-service-bean in the remote JNDI. In pictures, it comes down to this:

Let's get down to business and see how we can configure this. There are several ways to get an MBean fired up in JBoss, but since this one should be around all the time (at least at our setup), we put it in the conf/jboss-service.xml file of the Whiskey server. The definition looks somewhat like this:

<!-- Declare the MBean, make sure its name is unique within JBoss -->
<mbean code="org.jboss.naming.ExternalContext" name="jboss.jndi:service=ExternalContext,server=Sierra">
   <!-- This denotes the JNDI name under which the remote tree is federated -->
   <attribute name="JndiName">external</attribute>

   <!-- Enter the environment settings for the Context -->
   <attribute name="Properties">
     java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
     java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
     java.naming.provider.url=jnp://<sierra's IP>:1099
   </attribute>

   <!-- Set the type of InitialContext, can also be LDAP or other Contexts -->
   <attribute name="InitialContext">javax.naming.InitialContext</attribute>

   <!-- Declare whether this name is accessible from remote clients calling Whiskey's JNDI -->
   <attribute name="RemoteAccess">false</attribute>
</mbean>

Okay, so now we have a federated JNDI tree and can access JNDI entries which were bound in Sierra from Whiskey. Cool, but our application does not point to /external/my-service-bean, it points to /my-service-bean and I don't want to recompile it or otherwise change it. No worries, this can be resolved by creating a JNDI alias. By creating a file my-service.xml in the /deploy folder of the Whiskey server, we can dynamically create these aliases:

<?xml version="1.0" encoding="UTF-8"?>
<server>
  <mbean code="org.jboss.naming.NamingAlias"
         name="jboss.mq:service=NamingAlias,fromName=my-service-bean">
    <attribute name="FromName">my-service-bean</attribute>
    <attribute name="ToName">external/my-service-bean</attribute>
  </mbean>
</server>

If the filename ends in -service.xml, JBoss will automatically pick it up and create the alias. When you delete the file, JBoss will also remove the alias automatically.

If you want to read more about the ExternalContext MBean, head over to the JBoss Manual.

--JH

Configure JBoss WS on a multiple network interfaces

2008-12-05T10:52:45+01:00

The JBoss WebServices package is a nice library to get your webservice kickstarted in no-time. One of its features is the automatic generation of a WSDL for your webservice endpoint. There is however a slight annoyance when you try to use this on a machine with two network interfaces.

On a single interface machine, JBoss automatically fills in the IP address or hostname of that interface in the <soap:address/> WSDL entry. No problems there. But, if you have a machine with two interfaces, for example one for internal and one for external access, then JBoss is likely to screw things up.

This is due to the following configuration directive in the jbossas/server/production/deploy/jbossws.sar/jbossws.beans/META-INF/jboss-beans.xml:

<property name="webServiceHost">${jboss.bind.address}</property>

This property causes JBoss to use the bind address in the WSDL rewriting/generation. Even if you start the server with -b 0.0.0.0, which binds it to all interfaces, JBoss still selects a single interface to use in this property.

The solution to this is luckily very simple: if this property is removed from the configuration file, JBoss will rewrite the WSDL with the address of the interface on which the request came in.

It does make me wonder, why is this not the default setting? Would it not be easier to drop in a server anywhere and it automatically exposes correct WSDL files on all interfaces? Then, if you want to restrict it to a single interface, add the property shown above.

SpringSource Application Platform - My Holy Grail

2008-09-23T11:00:46+02:00

The SpringSource Application Platform has been in beta for some time now. In my rare free time I have been playing with it's amazing set of features. Now that the platform is nearing its final release I want to share some of my thoughts about it.

I have been a fan of modular design even before I switched to my first Object Oriented Language. Although languages like Visual Basic, C++ and Java provide you with the means of building modular software, none ever enforce it. No matter how strict I design modules in my application, they somehow always get tangled up in each other.

That is until I started working with the beta of the SpringSource Application Platform (S2AP). By dividing my application into bundles I can make a truly modular application. Sure, this was already possible with OSGi runtimes, but that required a lot of plumbing and platform management.

The S2AP takes away all hassles and allows me to focus on designing and implementing a truly modular application. Adding a few OSGi-related configuration directives to my context xml enables almost all advanced features of OSGi. Combine that with the huge amount of pre-bundled enterprise libraries and the full Spring Framework at your disposal and you have the ultimate enterprise application platform!

I have been completely taken in by the ease of development and deployment with the SpringSource Application Platform. I certainly hope to use the platform in future projects and I will definitely try to convince other people to do the same. If you ask me, the SpringSource Application Platform is the future of Java EE and other application servers will have to follow in its direction.

Having said that, I would like to take this opportunity to announce that I am working on a whitepaper on the SpringSource Application Platform. There I will dive deeper into my experiences with the platform so far. The timeframe on the whitepaper is a release before the end of this year.

JH out.

Shameless Devoxx Promotion

2008-09-23T08:44:53+02:00

On December 8th-12th, this year's Devoxx (previously JavaPolis) conference takes place in Metropolis, Antwerp. I have been to the conference last year and enjoyed the huge offer of Java talks. I would like to recommend this conference to any Java-enthousiast!

EHWOTAY!

2008-08-05T09:59:58+02:00

A totally nonsensical 'phrase' that has spawned its own community: EHWOTAY!. It is the calling sign of a new entity in the Userfriendly comic.

I just like it, it has a nice ring to it... EHWOTAY!

Fools

2008-07-30T15:28:13+02:00

I am currently reading 'Refactoring: Improving the Design of Existing Code' by Martin Fowler and one of his tips made me smile:

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

It made me smile because it is spot-on when it comes to clean and maintainable code. If only you, the author, understand the code, you've done something wrong! Use a clear coding style, meaningful method/type/variable names and document EVERYTHING.

My Free Flex Training!

2008-06-17T15:22:08+02:00

Today I cashed in the free training I won from Adobe. In april I visited the J-Spring conference in the Netherlands and as usual dropped my businesscard in any box that had some description with the word 'win' in it. Although I had never won anything with this before, this year I won two Flex training sessions.

So here I am, sitting in a nice room at Prisma-IT, working on some nifty Flex application. The course is lead by Mark van Hedel, an Adobe Certified Instructor at Prisma-IT and he is giving us a Jumpstart to Adobe Flex 3.

And a jumpstart is exactly what it is. The course started with a very quick overview of the history of Flex. How we've come from mainframes, to client-server applications, to web-applications, to rich internet applications. Subsequently, Mark showed us the basic setup of any Flex application and let us dive into the labs.

I have seen and heard a lot of things here today that I have ran into while hacking around in Flex without guidance. Today's training has really helped me understand Flex better. I wholeheartedly recommend the course to anyone who is currently working with some object oriented language and wants to get his hands dirty trying out the frikkin best framework for Rich Internet Applications.

I'll share some of the handy URLs that Mark shared with us:

www.flugr.nl - Flex Usergroup Netherlands
www.flugr.org - Flex Usergroup Forum (English)
flex.org - Flex Community
flexpair.org - Mark van Hedel's website
asunit.org - AsUnit website (ActionScript Unit Testing)

Cheers!

--JH

SpringOne 2008

2008-06-09T13:56:29+02:00

This year's SpringOne conference is being held this week in Antwerp, Belgium. I will be attending this conference on behalf of my employer. Blogposts about interesting talks there should show up here starting next friday. I am going to try to crosspost the same posts in Dutch at the JCN Blog.

See for more information about SpringOne: SpringOne 2008 website

--JH

SpringSource Application Platform

2008-05-24T13:25:50+02:00

As SpringSource released its first beta version of the SpringSource Application Platform (S2AP), my attention was jerked towards it. In order to get to know more about this new project from Spring I attended a webinar last week. The platform looks very promising in terms of used technologies and the features it offers.

So what is S2AP?

The S2AP is the Spring Dynamic Modules Kernel, running on top of Equinox, hosting a Tomcat server, with a specialized management interface, with some funky new advantages. So you get a Java EE application server with OSGi dynamic modules and all the power of the Spring Framework. Awesome!

The platform aims at being a lightweight, customizable Java EE Server, with a preference for Spring-oriented applications. The platform has no trouble running applications that were not built with Spring technologies though, it accepts standard Java EE WAR-files and also standard OSGi bundles.

Yet Another Application Server?

Definitely not. I have recently been looking at possibilities for running an application server on OSGi, or running OSGi in an application server. However cool this sounds, it proves pretty hard to realize. If you want to run a OSGi inside a web application, you need to somehow proxy the servlet requests to the OSGi subsystem, which then gives it to the right bundle. Suffice to say, it was not easily done.

The S2AP platform does all this for you. Because the platform embeds a Tomcat server and completely controls it, you don't have to worry about proxying requests, delegating them to the right bundle. I should add that this is not entirely new, I have also been looking at the JOnAS project, which is also an OSGi based application server, but I have yet to try it for real.

Hot features!

The platform also comes with handy features in case something goes wrong. I'm pretty sure everyone sometimes gets a part of a logfile from a production server, containing a nasty set of stack traces as some exception has occurred. This generally forces us to try and recreate the situation, but that's not so easy from just a single NullPointerException.

The S2AP comes with 'Data Capture on Failure', meaning it will generate a snapshot of the platform when it detects problems in the application. These snapshots contain information about all active Threads and their current lock-states and supposedly a lot more. This sounds very good, especially since the S2AP also comes with a Deadlock Detection feature, which will also trigger the snapshot. I think I'll have to try it for myself sometime in the near future to see how much information is actually contained in such a snapshot.

Another nice feature is the fact that the platform accepts applications in standard JEE WAR-files and standard OSGi bundles. However, the platform also introduces its own format: the Platform ARchive (PAR). The PAR is actually bringing the modularity to the application level. A PAR is a single deployable unit in which multiple bundles are contained which together form an application. It has its own service namespace to keep the different applications from cluttering the OSGi service registry.

The webinar certainly raised my interest and I am hoping to see and hear more of this on the SpringOne conference in June.

--JH

Fipo!

2008-05-24T00:58:07+02:00

Finally, a personal blog for me to post my thoughts on Java Core/EE, Webapp Security and whatever interesting stuff I see out there.

--JH