Simon Brown's Blog

October 2003 Archives

Panther ships with Ant, XDoclet and JBoss

I've just installed Panther and since you don't get stuff like CVS installed by default, I decided to open up the XCode CD and install the developer tools. To my surprise there are some Java tools tucked away including Ant, XDoclet, log4j and JBoss. If you install the Java tools, they can be found in :

• Ant 1.5.3, XDoclet 1.2b and log4j 1.2.8 in /Developer/Java/J2EE
• JBoss 3.2.2 (RC2) in /Library/JBoss/3.2

In Apple's inevitable way, running JBoss is as simple as navigating to the bin directory of the JBoss installation and running the run.sh script. No need to even set up environment variables such as JAVA_HOME. Okay, getting JBoss running on any platform is easy, but you have to admire Apple for making it even easier.

I knew that the server editions of Panther were going to include JBoss, but not the normal editions. Of course, you can already get newer versions of the tools yourself, but it's nice to see Apple making this stuff available and pushing Java as one of their development platforms. It just enables people to get up and running quickly, meaning that they can concentrate on learning how to develop applications rather than setting up tools. I wonder if we can convince Microsoft to include J2SE and Tomcat in the next edition of their OS? ;-)

London Java Meetup gaining momentum

Back in May we finally got around having a London based Java meetup where a small handful of techies turned up to a pub and chatted about Java. Month by month, numbers gradually increased and all was looking good until the Java Meetup website started charging a fee for some of their services. Thankfully, Jez came up with the London Java Meetup blog.

If you've been following the blog, you'll know that we met up last night and attendence was well into double figures, including Jeremy Rayner, Sam Dalton, Ken Horn, Peter Reinhardt, Steve Heath, Pratik Patel, Cameron Purdy and myself. As some of the reviews say, we had a great time just chatting about Java, open source, technology and the industry in general. Cameron even managed to do some live blogging to post some photos of us all. I still don't know how he managed this from a pub.

With so much Java development going on in London, it was great to finally see some more of the faces that make up the Java community. If you are working in or, like Cameron, visiting London and fancy meeting some other like-minded techies, feel free to pop along to the next London Java Meetup, tentatively scheduled for November 17th.

XDoclet in the J2EE web tier

It's common that you'll find somebody using XDoclet to help build their EJBs, but how often do you find people using it to help with the J2EE web tier? In his recent weblog, Dave says he is trying to convince his team that using XDoclet is the way to go for generating artefacts like tag library descriptors and the web.xml file. I must admit that while XDoclet is very useful when building EJBs, I'm not sold on the idea of using for the web tier myself. Why? Well, I think that there are several reasons for this.

For each EJB, you have to build 3 classes and the ejb-jar.xml file - all of which can be automated with XDoclet and a single source file representing the bean implementation. This is nice because the remembering all that nasty EJB deployment descriptor stuff is a pain, and everybody knows it's a pain. In one of the JavaOne sessions that I went to this year, the EJB team talked about how they were thinking of taking advantage of the new J2SE 1.5 (Tiger) feature of annotations/metedata (JSR-175) so that the deployment descriptors were automatically generated. Basically this would make XDoclet-like, attribute-oriented programming available to the J2EE platform, and that can't be a bad thing.

Another reason to use XDoclet is so that package and class names are kept in sync between the Java source and the deployment descriptors. However, when you use tools like IntelliJ to refactor a class/package name, you can ask it to look in other files too so you get the deployment descriptor refactoring for free.

I do like using XDoclet for generating the EJB stuff, but for me it doesn't add much for the web tier technologies. Are you using XDoclet in your J2EE apps? I'd be interested to hear from anybody with thoughts on this.

Integrating Tomcat and Apache on Mac OS X

I've been looking at integrating Apache and Tomcat on my PowerBook so that my dev environment more closely matches the box hosting my domain. Although I really do like open source, one of the biggest problems for me is that I always seem to need software that I have to build from the original source. This is one of the reasons I bought a Mac. I have tried running some of the various Linux distros (e.g. RedHat and Mandrake) and every bit of my hardware seems to need drivers and kernels recompiled. Not my idea of fun!

Anyway, after a quick Google, I came across an article on the MacDevCenter entitled Integrating Tomcat with Apache Via the mod_jk Module. Admittedly it is slightly out of date with respect to the versions of Tomcat and mod_jk available, but the instructions do work and it has a link to download a prebuilt version of mod_jk for Mac OS X. Five minutes is all this took to get running and I didn't even have to recompile anything!

File access in EJB

File access has always been a controversial activity within EJB-based applications because of the restrictions placed upon bean providers by the EJB specification. The part of the specification relevant here is under the section entitled Programming Restrictions, and it states the following about accessing the filing system.

An enterprise bean must not use the java.io package to attempt to access files and directories in the file system.

This is a fairly specific statement, and is followed up by a short explanation of why this is the case.

The file system APIs are not well-suited for business components to access data. Business components should use a resource manager API, such as JDBC, to store data.

While this explanation highlights a key reason for not using file I/O, I think that there is much more to this. However, although this is a well known restriction, actually finding more information on this is a time consuming task. So, in the quest for knowledge, I did some digging and came up with the following reasons why file I/O is "a bad thing"^TM.

1. The WORA mantra of Java and J2EE means that there might not actually be a filing system to access. I've seen various comments saying that the J2EE server might be running on some device that doesn't have a filing system, or the application server doesn't have access to the filing because it's deployed in, for example, a database server. Although this is a valid reason, I don't think that this applies to most projects.
2. Access to files isn't transactional. Yes, typically, files aren't transational resources and when building enterprise systems, you usually want to be sure that some information has been correctly and accurately stored, hence the use of relational databases and the like.
3. Accessing file systems is a potential security hole. If we look at how other resources (e.g. JDBC DataSources, JMS Topics, etc) are accessed, it's usually through JNDI. To ensure that only authorised parties can access these, we typically have such resources protected by some sort of authentication mechanism, be it a username/password combination, or an SSL certificate. The problem with filing systems is that they are much more open and it's harder to control access. One solution is to lock file access via the operating system, and another is to use the Java security model to restrict access to only a specific part of the disk. If you are going to access the filing system from your business components, then locking down access will help to make the system more secure and resilient to attacks.

So then, how are we supposed to access files from EJB? Many people advocate the use of an intermediary Java class to wrap up the file access, believing that the EJB specification only disallows access from the bean class itself. Is this true? I'm not convined because all the same reasons apply. The specification itself presents an answer, and that answer is to use a resource manager so that we can treat file access as a secure, transactional, pooled resource. One such implementation is a J2EE Connector Architecture (JCA) adapter that you write, deploy and configure to access your filing system. In fact, some vendors have already built JCA adapters that access flat files and these are particularly useful if you have to access the outputs of legacy, mainframe systems.

Of course, many types of file access can be worked around. For example, configuration information can be placed in LDAP, JNDI, a database, or even properties files delivered inside your JAR files that get loaded as a resource through the classloader. In those circumstances where accessing files is a requirement, then other solutions include loading the file through the servlet container, having it sent to the EJB tier via messaging, downloading the file from a webserver through a socket connection and so on.

These are all workarounds for the programming restriction but at the end of the day I think you have to be pragmatic. Many projects do utilise file access from within the EJB tier and their solutions work. Although the EJB specification imposes a restriction, in reality many vendors choose not to enforce this, meaning that using the java.io package for accessing files is possible. Whatever solution you come up with, you should ideally keep the specification in mind. It's there to help you build portable and upgradable applications, but pragmatism should be employed. Hopefully a future version of the EJB specification will address this issue in more detail and this controversy will become a thing of the past.

How do you test tag libraries?

Matt is looking for a way to test tag libraries and rather than write a lengthy comment, I thought I'd follow it up here.

In the first part of his post, Matt says,

... I've looked briefly at TagUnit, but aren't you just writing JSPs (with custom tags) to test JSPs?

In answer to this question, yes, you're exactly rght in saying that you're just writing JSPs. This is the essence of TagUnit, and why I believe it's a better way to test tags than using something like Cactus. Sure, you can test the various classes with JUnit, but since you don't use the classes in this way from a JSP page, this approach can only take you so far. JSP tags are reusable components and I think that they should be tested as such. For me, this means testing those tags in the same way that they will be used on a JSP page, and that's by writing the tests and assertions as JSP pages.

Doing this has several benefits. First of all, you don't have to start mocking out parts of the servlet specification just to test the tag handlers. Instead, you're running the tests inside a real server. If you've looked into the JSP specification, you'll know that the tag lifecycle is a tricky business because of the way that JSP containers can optionally reuse and pool tag handler instances. By writing your tests as JSP pages, you instantly get all this framework for free, meaning that you can accurately test the behaviour on your desired target platform. Also, if you're aiming for cross-container compatibility, this is as simple as (in theory!) just dropping the WAR file containing the tests into a new container.

Matt wants an Ant/JUnit solution and I can see why this is desirable. I'm far more likely to run the tests if I don't have to keep starting up the JSP container. Unfortunately, there aren't many ways around this without exploring avenues such as mock objects. However, TagUnit does provide an Ant task that can be used to initiate and collect the results of running the JSP-based tests. The basics of this are documented, although this document is being expanded as we speak ... isn't it Sam? ;-) As for whether there are HTML versions of the docs ... not yet, but there might be one day.

I should probably add a disclaimer at this point, and highlight the fact that I created the TagUnit project. Clearly I'm biased, but I do think that it provides an improved way to test custom tags. Whether it's better ... that's for you to decide.

HttpClient - another great Jakarta Commons component

I was putting TrackBack support into Pebble the other day and the found that the technical details of a TrackBack involve sending a HTTP POST request to the remote server. I've implemented HTTP POSTs before using the classes in the java.net package, but rather than write all this code again, I thought that I'd take a look at Jakarta Commons HttpClient. What can I say ... this is another top notch component from the Commons project.

The following code shows how easy it is to make a HTTP POST with some name=value pairs and get the results back as a string.

      HttpClient httpClient = new HttpClient();
      PostMethod postMethod = new PostMethod(url);
      NameValuePair[] data = {
        new NameValuePair("name1", value1),
        new NameValuePair("namen", valuen)
      };
      postMethod.setRequestBody(data);
      int responseCode = httpClient.executeMethod(postMethod);
      String responseBody = postMethod.getResponseBodyAsString();

As you can see, there's not much code here at all, and HTTP GETs are easier still! From start to finish, making use of this component took about five, maybe ten, minutes. If you find you need to access HTTP-based resources, take a look at HttpClient.

This work is licensed under a Creative Commons License.