Frame2 1.3.1 is now available. The full source package is not updated yet, but it should be in the next day or so. This is a pretty minor release – only two changes, but I think they’re important changes.

1. Enums are now supported in Events. This relies on the Enum.valueOf() behavior, so the values passed in to the event must be legal values that enum values can be built from. This means that things like case are important.
2. Input views can now be events. I don’t know why this feature was missing. Frame2 already supported using an event for a cancel view (although the unit test didn’t actually test for that). What does it mean to be able to specify events in addition to forwards for input and cancel views? There may be cases where some data needs to be loaded or verified prior to displaying a JSP page. Sometimes this information can be lost when simply redirecting back to a JSP page. By specifying an event, the developer can be sure that the required data has been loaded before the JSP has been displayed.

The Eclipse plugins and sample web applications have been updated with the latest Frame2 jars. Follow the download links in the sidebar, or go to http://sourceforge.net/projects/frame2 if you don’t see the sidebar.

I don’t think It’s just me, but maybe I am the only person who gets easily frustrated working on Eclipse plugins. I almost feel like I’ve missed a secret meeting sometimes that ties together all of the loose ends of plugin development. One particular problem I ran into lately was with adding a project decorator. I thought it would be nice if Frame2 projects had some kind of icon that identified them. I added the extension to the plugin and set the enablement for IJavaProject. I thought this was appropriate, since Frame2 projects are Java projects. This setting resulted in every single file in the project being decorated. I thought this was a bit strange, so I added a lightweight label decorator class. The ILightweightLabelDecorator interface defines a method that implementors use to apply the decorator to objects. Sure enough, this method was called once for every file in the project. However, I could not filter these inputs since every time the method was called, the input parameter was the same!

Changing the enablement class to IProject yielded the desired behavior – the decorator method only gets called once for each project in the workspace. A little filtering to check if a project is a Java project and has the Frame2 nature, and presto! – project decorators.

Now, why did I see the behavior I did? Chances are it’s a bug, but it seems equally likely that it’s supposed to behave that way and I haven’t found the decoder ring that tells me that.

There’s been a bug in the Frame2 Eclipse plugin from day 1 that I believe I have finally squashed. The reading and writing of the frame2-config file happened outside of the Eclipse API, and when the file was updated using a wizard the resource got out of sync with the workspace. It hasn’t really been a big issue, but it’s annoying to always be asked by Eclipse if you’d like to reload the file since it has changed.

My original stab at fixing the problem was to change the file as it’s always been changed, but call refreshLocal() on the Eclipse IFile representation. The call never threw an exception, but it also never seemed to do anything. I finally refactored the model reading and writing code to use Eclipse APIs and platform objects. This worked fine until I got to the point where I needed to write the modified configuration to file. The existing API required an OutputStream, while the Eclipse API wanted an InputStream.

Luckily, Google turned up some suggestions, most notably using piped streams. My first attempt looked like this:

PipedInputStream in = new PipedInputStream();
PipedOutputStream out = new PipedOutputStream(in);
config.write(out);
modelFile.setContents(in, true, true, monitor);

Config is the Frame2 model object that knows how to write itself to an OutputStream, and modelFile is the IFile object representing the config file in Eclipse. Anybody who’s ever used piped streams in Java should be able to tell what happened when I ran the code – it hung. It always pays to read the JavaDoc in addition to copying somebody’s snippet of code from the web. What the JavaDoc says is this: “Attempting to use both objects from a single thread is not recommended as it may deadlock the thread.” In this case, I think may is a bit soft. It deadlocked every single time I ran it.

Based on another online snippet, I modified the code to this:

PipedInputStream in = new PipedInputStream();
final PipedOutputStream out = new PipedOutputStream(in);
new Thread(new Runnable() {
  public void run() {
    try {
      config.write(out);
    } catch (IOException e) {
      e.printStackTrace();
    }
  }
}).start();
modelFile.setContents(in, true, true, monitor);

This is the variant that I ran across most often online. It uses two threads to avoid deadlocking, but it still has a fatal flaw. The setContents() method always throws an IOException with this code. The IOException’s message is always “Pipe Broken”. I found a *lot* of entries online from people asking how best to ignore this exception. There were lots of helpful explanations as to the cause of the error, but I didn’t see a single solution. Luckily, the answer was easy to find in this case.

The “Pipe Broken” message is happening because the the thread doing the writing to the OutputStream has terminated and nothing more is being added to it. The solution is to simply close the OutputStream after writing the configuration to it. The OutputStream is correctly marked as being finished and the exception is not thrown. An examination of the read() method in PipedInputStream shows why the OutputStream must be closed:

if (closedByWriter) {
  /* closed by writer, return EOF */
  return -1;
}if ((writeSide != null) && (!writeSide.isAlive()) && (--trials < 0)) {
  throw new IOException("Pipe broken");
}

If the writing side of the pipe simply exits, writeSide.isAlive() returns false and the exception is thrown. If the OutputStream is closed, however, the reading side of the pipe sees it as EOF and terminates gracefully.

To sum up, the correct example for using piped streams in Java should look like this:

PipedInputStream in = new PipedInputStream();
PipedOutputStream out = new PipedOutputStream(in);
new Thread(new Runnable() {
  public void run() {
    try {
      doSomethingWithOut(out);
      out.close(); // Critical!
    } catch (IOException e) {
      e.printStackTrace(); // Do more than just this, OK?
    }
  }
}).start();
doSomethingWithIn(in);

The Eclipse plugin has just been updated, and a new plugin has been added to the mix. The new plugin allows users to create Frame2 projects with web services support by adding all of the required libraries and initial configuration. Also in the new plugin are two wizards: one for creating new Responders and one for creating Schema mappings. The Getting Started guide has also been expanded to explain how to add web services support to the example application.

Again, the Update Manager site is the preferred method for downloading the plugins, since it will gracefully handle version and dependency conflicts.

Update Site for Eclipse:
http://frame2.megatome.com/eclipse

Sourceforge Downloads:
Main Eclipse Plugin
Web Services Eclipse Plugin (requires at least version 1.3.3 of the regular plugin)

The Eclipse plugin for Frame2 is done, and has been released. Grab the file over at Sourceforge, or point your Eclipse Update Manager to http://frame2.megatome.com/eclipse. Using the Update Manager is the preferred method for installing the plugin.

Sourceforge Download:
Eclipse Plugin

Update Site for Eclipse:
http://frame2.megatome.com/eclipse

As the title says, the Eclipse plugin for Frame2 is almost done. Of course, “done” is a relative term. In this case, it means that the plugin has been updated to work with the latest version of the framework, including the updated DTD. Unfortunately, it also means that it still has the same limitations that previous versions have had. Specifically, the plugin still does not support creating a Frame2 project with web services support. This can be added by hand and the Frame2 plugin won’t stomp on it, but neither are there any nice wizards for the web services tasks. This limitation is the next item on my list – I’m pretty sure that I can create an optional plugin that can be downloaded that will add the web services functionality for anyone that wants it. This will also help keep the download size of the “core” plugin as small as possible.

One other feature that the plugin is missing is a contextual editor for the Frame2 configuration file. It would nice to be able to get contextual help and hints when editing the config by hand, but I don’t think I have the time in the forseeable future to research how this works in Eclipse.

The plugin will be available for download from Sourceforge and I will be creating an update site here at frame2.megatome.com that will be the preferred way of getting the plugin.

Frame2 is almost ready to be released as a new version. I may still make some changes, but it’s definitely in Release Candidate stage now. There are only a few things that I may add before testing the heck out of it:

• Upgrade unit tests to JUnit 4. There are a lot of tests, especially the ones that mock a servlet container, that do a lot of repetitive work in setUp() . JUnit 4 has finally brought the ability to annotate methods to be run before and after all tests in the class with @BeforeClass and @AfterClass, respectively. Individual test setup activities can still be performed by annotating a method with @Before.
• Fix outstanding bugs. There’s only one right now, and it’s SOAP specific, so I may or may not fix it. It may take me longer to figure out how to reproduce the problem with unit tests than it’s worth.
• Add outstanding feature requests. Again, there’s only one, but it’s (in my opinion) a biggie – the ability to add parameters to the response when handling an event.
• Doc updates. The web services doc needs to be written, and I’m sure all of the other doc needs a good examination.

I’ll be testing the latest build with a web application that I’ve been working on for years that I’ve come to think of as an unofficial reference implementation of Frame2. I haven’t decided yet if the web app should become part of the project on Sourceforge or not. We’ll see.

Once the testing is done and I’ve released a new version of Frame2, I plan on working on the Eclipse plugin. The poor plugin has pretty much been ignored for several years now, and it needs some attention.

I’ve mentioned before that I’m using FindBugs to help make sure that the Frame2 code is up to snuff. The Eclipse compiler can catch a lot of things, bug FindBugs has some neat tricks up its sleeve to find things that Eclipse can’t. FindBugs uses static analysis of the code to search for patterns that indicate possible issues. Being the Type A person that I am, I always turn on all of the possible matches and whittle the list down. Quite often, however, FindBugs will find a false positive or two. Up until now, I’ve either tried to rework the code to avoid the warning or disabled the category altogether. I’ve never liked the approach of turning off a whole category just to avoid seeing a warning or two, so I spent the morning muttering to myself how useful it would be if FindBugs allowed me to ignore certain warnings like I can do with @SuppressWarnings.

Then I went and RTFM.

FindBugs has a filtering system that makes @SuppressWarnings look amateur. Here’s an example: in the SoapRequestProcessor, FindBugs marked a warning that an Exception was being caught when no Exception was being thrown. After looking at the code and verifying that the try block in question throws several different exceptions, I created a filter entry. The entry looks like this:

<Match>
<Class name="org.megatome.frame2.front.SoapRequestProcessor"/>
<Method name="getEvents"/>
<Bug pattern="REC_CATCH_EXCEPTION"/>
</Match>

This tells FindBugs to match a specific bug type in a specified method in a desired class. This entry can be used in both an inclusion or exclusion filter – I use it to exclude that warning from the results.

Here’s a more complex example:

<Match>
<Class name="~.*introspector\.Bean\d+" />
<Bug pattern="EI_EXPOSE_REP,EI_EXPOSE_REP2"/>
</Match>

There are some test classes that don’t exactly follow good rules of programming when it comes to dealing with mutability. Since they are test classes, I don’t really care to fix them. Instead I set up the filter to match all classes in an introspector package named Bean1, Bean2, etc. Simple as can be!

If you aren’t using FindBugs, you should be. Go check it out.

The last official release of Frame2 happened in January of 2006, and was Java 1.4 specific. I am currently making changes to the codebase to take advantage of all of the improvements that Java 5 and 6 brought. The process is roughly this:

1. Configure Eclipse with the latest available JDK.
2. Turn on all compiler warnings.
3. Eliminate some warnings.
4. Rerun all unit tests.
5. GOTO 3 until warnings are gone, or at least only in the generated JAXB code.
6. Run FindBugs.
7. Eliminate issues found by FindBugs.
8. Rerun unit tests.
9. GOTO 6 until FindBug issues are minimized.

At least, that’s the plan. Reality usually has different plans – so far they’ve mostly involved obtaining new versions of required libraries and watching the failed unit test count skyrocket. On the plus side, Java 6 has made JAXB significantly less painful – more on that later.