Entries Tagged 'frame2' ↓

Currently, Frame2 does not work on Macs. This, of course, is due to the fact that there is no (easily) available Java 6 implementation for MacOS. I’ve been trying to decide if this is an issue or not.

Reasons why it might be an issue:

• I use a Mac for most of development, and I hate having to drop into an emulator to work on Frame2
• I really would like Frame2 to run on the Mac, if just for completeness.

Reasons why it probably doesn’t matter:

• Who really runs Java webapps on Macs? Tomcat on Windows or Linux is OK, but it just feels dirty to me on the Mac.

Hopefully, there will be a version of Java 6 available for the Mac soon. At that point, I’ll probably make the necessary updates to make everything work. Until then, if you’re writing a web app and using a Mac - go with Rails.

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.

Version 1.3 of Frame2 is officially available. The framework can be downloaded here, and the sample applications are available here.

Work on the Eclipse plugin continues, with a (hopeful) release date in the next week or two.

I’ve pretty much wrapped up the coding for the next version of Frame2, and decided to give the documentation a once-over. All in all, it’s not too bad, but it’s not great either. There’s some real improvements that can be made, but I don’t see it happening any time soon.

Don’t get me wrong - I don’t mind writing doc. One of the most annoying things is to download some open source project and not have any idea how to use it. The issue I have with writing doc is that the feedback loop is entirely different than for code. When writing code with automated tests, there’s immediate feedback if you’ve done the right thing or not. With doc, I have to wait for someone to actually read the doc and give me feedback. This is frustrating because: 1) I don’t know if anybody even uses Frame2, 2) of the people that do use it, I don’t know if they read the doc, and 3) if the doc sucks, does anybody care enough to tell me?

So, for now I’ve corrected obvious errors in the doc, but I haven’t added anything. I’ve started a list of things to cover, but I don’t know when I’ll get to them. Third party dependencies need to be explained better, and web services interaction needs a LOT of coverage.

I feel that the getting started guides and the example applications are sufficient to get somebody up and running with a basic Frame2 application. If I’m wrong, hopefully somebody will let me know!

This seems to happen to me no matter what project I’m on. I try to implement a simple (or not so simple) feature and end up exposing at least one bug that’s been hiding around for quite some time.

As an illustration, I was adding a feature to Frame2 today to allow some parameters to be passed between events within a mapping - without making developers use the HttpSession. After a couple of false starts, I had a pretty good idea of how to make the changes and starting ripping out code. I came up with several unit tests, and modifying code to make the tests pass. Pretty standard Test Driven Development…until I wrote the test that made sure event chain validation was working.

Before I explain the bug, I’ll give a high level description of how Frame2 works when submitting form data:

1. Form is filled out by user and submitted.
2. Frame2 looks up the appropriate event from the form action.
3. An instance of the appropriate event is created and populated by the introspector.
4. Based on the mapping for the event, Frame2 will then validate the event. This may involve the Commons Validator if it is enabled and/or overriding the Event.validate() method.
5. If validation fails, the mapping must specify a location for the framework to forward back to. This is usually the same page where the data was entered.
6. If validation passes, the framework then iterates through the list of event handlers, calling the handle() method. If handle() returns null, the framework continues to the next handler. A non-null result usually indicates an error, and the framework will forward to the location named by the result.
7. Once all of the handlers have been invoked, the framework will default to the view specified in the mapping. Usually this is just a JSP, but Frame2 supports forwarding to events - called “chaining”.
8. For the chained event, Frame2 is supposed to start back at step 2 and continue processing until it gets to the end of the chain.

Notice how I say “supposed to” in step 9? The framework was actually only going back to step 6, bypassing validation for all events except the first in the chain. Subtle, yes, and unlikely to be noticed by most users - but it’s still a bug. The bug has now been fixed so that the framework goes back to step 2 like it’s supposed to.

In case you’re wondering what use event chaining is, here’s an example:

1. User enters a blog entry and submits the form.
2. Frame2 validates the form data and begins invoking handlers.
3. The blog entry handler persists the data, perhaps to a database.
4. The default view for the event mapping tells the framework to forward to the “View All Blog Entries” event.
5. The framework creates the appropriate object and begins invoking the handlers in the “View All” mapping.
6. The “View All” handler populates all of the blog entries into the “View All” event.
7. The default view for the “View All” mapping is a JSP page, which renders the blog entries using JSTL.

Chaining allows the “View All” event to remain its own entity that can be invoked separately, while allowing the same functionality to be used in other places where appropriate.

By way of comparison, the feature I added allows the above sequence to be reworked like this:

1. User enters a blog entry and submits the form.
2. Frame2 validates the form data and begins invoking handlers.
3. The blog entry handler persists the data, perhaps to a database.
4. The blog entry handler sets an attribute with the new entry id into the context.
5. The default view for the event mapping tells the framework to forward to the “View Specific Blog Entry” event.
6. The framework creates the appropriate object and uses the context value(s) with the introspector to set some values in the event.
7. The framework then begins invoking the handlers in the “View Specific” mapping.
8. The “View Specific” handler looks up the entry with the specified id and sets its data into the event.
9. The default view for the “View Specific” mapping is a JSP page, which renders the blog entry using JSTL.