Entries Tagged 'eclipse' ↓

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.