Archive for October, 2007

How Aranea Integration works: part I

Wednesday, October 24th, 2007

This is the first in the series of tutorial articles laying out the foundations of Aranea Integration in practical way. It introduces the base classes of Aranea Integration which form the core of server-side integration—handle sessions, requests and responses in a way that allows hosted components to function (keep this diagram open while reading!).

Base interface for Aranea components that host components/actions from whatever framework is called HostComponent.

/**
* Represents the Aranea {@link Component} that
* hosts some foreign framework component.
*/
public interface HostComponent extends Component {
  /**
  * This method must return the session attribute
  * <em>Map</em> specific to hosted component.
  * @return map that will be used for storing the
  *               session accessible to hosted foreign
  *               component
  */
  public Map getHostedSessionAttributes();
}

and has just one method — for retrieval of session attributes managed by the hosted component. The request and response are tuned to hosted components needs too, but since request and response in HTTP protocol are stateless, these need not be part of HostComponent interface but can be managed separately and statelessly. HostComponent base implementation is extremely simple:

/**
* Base class for Aranea widgets that host foreign
* components. Provides session storage for hosted
* foreign components.
*/
public class BaseHostWidget
extends BaseApplicationWidget implements HostComponent {
  private final Map sessionAttributeMap = new HashMap();

  public Map getHostedSessionAttributes() {
    return sessionAttributeMap;
  }
}

As one can see it completely lacks methods for actual management of session attributes.The class that manages session access is called SessionWrapper:

/* One and only constructor **/
public SessionWrapper(
    HttpSession session,
    HostComponent sessionHolder)

SessionWrapper ensures that the session modifications by hosted component will affect only the concrete hosted component. It is created anew at each request by IntegrationRequestWrapper (note that only way to access session in a web application is through current request).

Other base wrappers that make hosted component feel at home are already mentioned IntegrationRequestWrapper and IntegrationResponseWrapper. IntegrationRequestWrapper is created by some concrete HostComponent implementation, passing in the original request and itself.

new IntegrationRequestWrapper(
    HttpServletRequest original, HostComponent host);

The IntegrationResponseWrapper takes care that everything that is done to it only affects the wrapped instance — so that original request is left unchanged and can be passed to any number of other Aranea components or hosted components (in which case it is obviously wrapped in its own IntegrationRequestWrapper). Often some parts of original request are preprocessed in some way in IntegrationRequestWrapper extensions — i.e. the fully hierarchial component based request parameters that Aranea uses are converted into flat namespace for action-based frameworks, i.e.

public class BaseActionBasedRequestWrapper
(final HttpServletRequest request,
final HostComponent host) {
  super(request, host);
  preprocessRequestParameters();
}

where preprocessRequestParameters() takes all the ’scoped’ data meant for hosted component and converts this into flat namespace parameters that action based frameworks expect. This allows to reuse actions many times on one page, as each action can receive separate data.

Foreign response itself is held in IntegrationResponseWrapper which allows HostComponent to post-process response when needed. Postprocessing is most often done to scope the request parameters expected by hosted component in a way that they will be unique. How exactly this is done is highly dependent on hosted framework. For action-based frameworks this might mean post-processing HTML forms, for component based frameworks the postprocessing might even be unnecessary when the hosted components’ ‘root’ component is given the right scope to begin with (i.e. with JSF NamingContainer).

Other crucial part of the IntegrationResponseWrapper is the overriden encodeURL(url) method. By servlet specification, all URLs that are to generate requests to (hosted) web application must go through this method before written out to response. IntegrationResponseWrapper overrides this method so that later incoming request can be identified as request to component hosted by Aranea. Identification is done by AraneaIntegrationFilter which is quite ordinary servlet filter, except it prevents the request from directly reaching the hosted framework and directs it to Aranea component hierarchy where it will be processed by all interested components including the HostComponent implementation which originally generated the request.

This briefly covers all current integration base classes. For more detailed information, one can take a look at org.araneaframework.integration.common package in the Aranea Integration project.

JavaRebel Brings Class Reloading to Java

Monday, October 8th, 2007

Finally we are ready to unveil what Aranea team has been so busy on. As time went by we realized that one of the main problems impeding developer productivity was lack of class reloading facilities in Java Virtual Machine. We have been working on this for almost a year and today we can show the results.

JavaRebel reloads changes to Java classes on-the-fly without redeploy or restart including new methods and fields. It is a generic solution that works for standalone Java applications as well as application servers.

Watch the demonstration screencast (~5 mins), read the feature list or just download JavaRebel from ZeroTurnaround.com and give it a try. Disclaimer: JavaRebel is commercial software with a free trial for 14 days and developer seat cost at 99$.

ZeroTurnaround is a spinoff of Webmedia, Ltd. that focuses on Java developer productivity tools. Currently we are developing JavaRebel, a generic Java class reloader, and JSP Weaver, an instant JSP interpreter.

WordPress and Plaintext Passwords

Wednesday, October 3rd, 2007

Todays online systems can be implemented in tons of technologies and they can be web 0.1 or web 3.0. There are some guidelines on how to do certain things.

Whenever you’ve given your username, email and a password to a site you can never know if the password was saved in plaintext or just a hash of it. If it was stored in plaintext you can think about the different security implications yourself. Whenever the password remainder sends you your password it was stored in plain text.

One more thing that systems should not do is store these passwords inside cookies in plain-text. See about Cross-site scripting from Wikipedia.

I was working on a project that was using WordPress as a CMS and there was a password protected todo list. As I was inspecting a cache issue I was checking the headers of static files with Firebug and I stumbled upon on some request/response fields. I noticed that one of the cookies had the password of the TODO item in plaintext.

I googled for it and found that it has been reported. The comment to the report is ‘Well it’s not like other sites can access the cookie or anything :) ’.

Whenever I use software that has been around for a while (at least a year) and it has a userspace I expect it to follow at least the most basic guidelines. I hope it gets fixed.

Aranea Development Model

Tuesday, October 2nd, 2007

Introducing the new approved Aranea Development Model. Pair programming at its best, demonstrated by Jevgeni and Toomas.

Aranea-MVC 1.1-M4

Monday, October 1st, 2007

We had somewhat longer gap between releases of M3 and M4 than usual, due to team taking vacation in July and being temporarily involved in three different projects as of late. But now for some highlights of 1.1-M4:

Also, there’s support for context menus in browsers, new control that is hybrid of text and select controls, plus for everyones coding pleasure FormWidget.addElement* and FilterHelper.* methods do not throw checked Exceptions anymore. See full changelog here.

Separate 1.1 demo application is also up. Obviously demos contain more explanations and stuff than mentioned here, so take a look! For everyone who has not yet noticed—already since early 1.0 days there are Widget source and Template source links in our demos (they are not easily spotted sometimes, look at the bottom left corner next to side menu :) ).

NB! It was not mentioned in changelog that comes with distro, but StandardFlowContainerWidget (standard implementation of FlowContext) was modified in a way that is incompatible with some older uses. Namely, when call stack is empty and parent FlowContext exists, StandardFlowContainerWidget.finish() and cancel() methods return control to parent FlowContext (meaning that once active StandardFlowContainerWidget is gone for good). In cases (mainly in menus) where this is unwanted, one must take care and call StandardFlowContainerWidget.setFinishable(false).