Aranea Blog

1.0.11 fixes issue with FormWidget.restoreBaseState(). There is some more though, details here.

Although not directly connected to Aranea we are proud to present the first release from our spin-off ZeroTurnaround. The spin-off will focus on increasing developer productivity by reducing development turnaround time.

Our first product JSP Weaver is a JSP interpreter. Usually JSP is first translated to regular Java code and then compiled into a Java servlet. JSP Weaver eliminates the Java generation and compilation stage by interpreting the JSP files on-the-fly. This reduces the time taken to reload a JSP up to 50 times bringing it from seconds down to milliseconds.

Although we will provide full support of JSP standard in the final release, this milestone does not yet include support for the non-XML old style JSP syntax and provides limited support for scriptlets. If you are using XML syntax for your JSPs have a go at it and be amazed by the speedup.

Disclaimer: JSP Weaver is a commercial product that costs about 49$ per developer seat. You can try it out for free with no limitation, but must buy it for development.

There are quite few changes in this latest update to 1.0 branch, so I will list and comment on them all.

• BeanFormWidget.readBean() method destroyed the content of sub-beans when writing nested form to a bean. This was both counterintuitive and wrong because the root bean and the child beans were handled differently (root bean fields were only updated, but child beans always created anew). This has been fixed
• As the naming of BeanFormWidget.readBean() was very confusing, this method is now deprecated in favour of writeToBean(). Analogously, BeanFormWidget.writeBean() is deprecated in favour of readFromBean(). BeanFormWidget‘s readBean() and writeBean() will be removed in 1.1 branch.
• TcdAndTldMerger utility that was distributed only in source form and had to be compiled separately is now included in aranea.jar. Its purpose and usage are documented here.

Are you stuck with a Java web application written in an in-house or legacy web framework? Does management point to the costs of rewriting the application, so you have to continue development using outdated techniques and approaches?

Aranea Integration provides the infrastructure for splitting the existing applications into self-contained components, which can then be rewritten one-by-one only when requirements change. This allows spreading the costs of migration over time and continuing new development using a new framework immediately. It also allows developing individual components using any web framework you like, giving access to a wide variety features and approaches.

Aranea Integration 1.0-M1 includes integration with Struts, JSF and GWT. Although the release lacks comprehensive documentation it comes with a lot of examples, as well as a whitepaper. In addition, TheServerSide Java Symposium presentation contains a good deal of info on step-by-step legacy migration, our approach to getting rid painlessly of legacy and custom web frameworks.

Along with the Aranea Integration subproject we have launched commercial support, training and consulting provided by Webmedia, Ltd. and available from www.araneaframework.com.

Most visible and important news about third milestone of Aranea-MVC 1.1 are:

• pages containing update regions will not sometimes crash with NPE when active flow is finished during request
• few of the Aranea specific request parameters were renamed (prefix was added). For example: ‘transactionId’ vs ‘araTransactionId’. Unless your custom client-side scripts or server-side filters directly used these parameter names (which should not be the case), this will not affect you.

Full changelog for the curious ones.

Those who attend our forums or subscribe to release feeds have already noticed that both stable and development branches saw new releases two days ago. Users of 1.1-M1 should definitely seek upgrade. Sourceforge has it all.

Aranea Continuations project supports waiting on Swing and Aranea events by introducing high-level API over the JavaFlow library, hiding the mechanics of continuations behind an annotation, blocking calls and an instrumentation agent. Download from SourceForge or read the reference.

Continuations is one of the most hip and misused terms in Java community. Popularized by Geert Bevin and RIFE framework they allow to wait for event to happen and resume the method execution from the point on. A common point of comparison is the readln() DOS function that waited for user to input before resuming. In Java we are interested in waiting on events like user clicking a button.

Support for continuations in generic Java has been available for some time via the JavaFlow library. However their API was relatively low-level and clumsy in day-to-day development. As a part of Aranea Continuations project we built a higher level API on top of it, which can be illustrated by the following Swing example:

class BlockingSwingExample extends JPanel {
  //Method with continuations
  @Resumable
  public void init() {
    JButton button = new JButton("Click on me!");
    add(button);
    updateUI();

    for (int i = 1; i <= 10; i++) {
      SwingBlockingUtil.waitForOneAction(button);
      System.out.println("You have clicked me " + i);
    }
    System.exit(0);
  }

  //Swing boilerplate
  public static void main(String[] args) {
    BlockingSwingExample panel =
      new BlockingSwingExample();
    JFrame frame = new JFrame();
    frame.add(panel);
    frame.setVisible(true);
    panel.init();
  }
}

The important part of the Aranea Continuations API is the @Resumable annotation and SwingBlockingUtil.waitForOneAction(button) call. The first one tells that the current method can be resumed later while the second will wait until the listener is called. The code will wait till user clicks the button exactly ten times and then will exit (the example is available with distribution by running ant run-swing-example).

To make the example run we need to instrument the classes bytecode. In addition to the preprocessing supported by JavaFlow we have implemented support for Java Instrumentation API, so it becomes as easy as registering an instrumentation agent:
java -javaagent:aranea-blocking.jar=example example.BlockingSwingExample
To limit preprocessing the agent receives a comma-separated list of the application packages as a argument (in this case the example package).

Aranea Continuations provide support for waiting for Aranea MVC events same way as in Swing. The core API here is the AraneaBlockingUtil. However in addition to events we provide support for invoking flows and waiting for the return value:

@Resumable
String askForName() {
  String result =
    AraneaBlockingUtil.call(
      getFlowCtx(),
      new DialogWidget("Please enter your name:"));
  return result;
}

This will display the user a separate page with an input box and return the value of the text box when user submits the form.

Looking under the hood blocking calls are implemented using a simple call/cc semantics:

static void waitForOneAction(final AbstractButton button) {
  BlockingUtil.call(new IndirectCallable() {
    void call(final ReturnContext returnCtx) {
      final ActionListener[] aListener = new ActionListener[1];
      aListener[0] = new ActionListener() {
        public void actionPerformed(ActionEvent e) {
          button.removeActionListener(aListener[0]);
          returnCtx.returnWith(null);
        }
      };

      button.addActionListener(aListener[0]);
    }
  });
}

ReturnContext represents the current continuation that can be called to return from method once or several times:

public interface ReturnContext {
  void returnWith(Object result);
  void failWith(Throwable t);
}

Using that it is trivial to add support for other events or actions. In fact we only implemented Swing blocking API because we realized how easy it is on top of the existing API.

Nothing comes for free and this is doubly so for bytecode modification. JavaFlow will definitely add a performance penalty to your application. However you should consider that it will almost exclusively add CPU consumption and will not stress IO or memory. This means that in most projects the impact will not be considerable or possibly even noticeable. This goes specially to desktop Swing applications, which are highly unlikely to be CPU-bound. Of course one should stress-test the application to make sure what the impact is in your environment.

The first release is available from SourceForge with a (brief) reference also available. We will continue to improve the project and plan to release as much of changes upstream as we can. We are also looking for contributions supporting blocking calls in other frameworks (like SWT). We would like to express our gratitude to Rein Raudjärv for developing the project and to Oleg Mürk for the original idea.

This year we are taking a trip to Barcelona by generous invitation of TheServerSide folks. The talk is Step-by-Step Legacy Migration with Aranea, which is an approach to use the Aranea Integration to migrate web applications from older web frameworks (and not to Aranea, but to any newer framework/technology). We are planning to announce the approach in full at the symposium, so be sure to register while there are still places

Also releases of several subprojects and Aranea 1.1 final are expected to be done by the time of the symposium, so that you could take immediate advantage of the new features.

It is our great pleasure to announce the release of the first milestone in the 1.1 development branch. This milestone includes following improvements:

• Component model. Components are now aware of their name and environment and can use it at any time. The scoping methods from InputData and OutputData have been removed. process() method was removed from the Widget class since it broke in some cases implicit assumptions about the Object-Oriented encapsulation. The component model is now truly OO without any surprises and objects can be used without any restrictions.
• AJAX support. With actions Aranea natively supports AJAX queries to any components. Although actions have been available since the first Aranea release, 1.1 supports sending unsynchronized actions to widgets, which allows implementing truly responsive UIs. Also the JavaScript API now provides methods to send and process actions.
• Partial render support. Aranea has long supported updating only small portions of the page with update regions. However in 1.1 only the surrounding widget gets rendered providing a huge performance boost and making the feature much more useful.
• Rendering model. Rendering was cleaned up removing dependencies between components other than environment. This includes removing the OutputData attributes and forbidding JSP tags to depend on other component tag context entries. This both allows the partial render support and true encapsulation, laying ground for the integration project.

The current reference manual is out of date and we do not yet provide a migration guide, so we suggest to wait until the next milestone before upgrading. However a comprehensive API changelog is available here. Download from SourceForge.

As one would expect from ‘friday-the-thirteenth’ release, 1.0.7 included an accidental change of form list behavior. This caused NPEs in use cases which were legal before 1.0.7. In new release, old behavior is back. We are sorry for any inconvenience!