Navigation

RSS 2.0 New Entries Syndication Feed Atom 0.3 New Entries Syndication Feed

Show blog menu v

 

General

Use it

Documentation

Support

Sibling projects

RIFE powered

Valid XHTML 1.0 Transitional

Valid CSS!

Blogs : Archives

avatar
< JavaPaste 1.0 released : pastebin with highlighting, diffing, private pastebins and image uploads   Nominated and accepted as Java Champion >
RIFE 1.5 released

Update: this announcement was posted on the front page of TheServerSide.com. If you have comments or are interested in what others have to say, it might be a good idea to head over there.

Below are the highlights:

  • Complete injection and outjection support for all element data (bijection) [ more ]
  • Annotations support for element declaration [ more ]
  • Support for parallel and simultaneous continuations [ more ]
  • Fine-grained control over continuation trees and their invalidation [ more ]
  • Step-back continuations [ more ]
  • Stateful components [ more ]
  • Support for creating RIFE applications without any XML [ more ]
  • Performance improvements [ more ]
  • Support for reloading manually declared sites by site listeners [ more ]
  • Automatic recompilation of non-hotswappable or instrumented classes [ more ]
  • Generic Query Manager listeners [ more ]

You can read the full changelog for more details.

This release can be downloaded from the downloads section, as usual.

Complete injection and outjection support for all element data (bijection)

RIFE will now automatically detect setters and getters in your element implementation and map them to the inputs, outputs, parameters, inbeans, outbeans, incookies, outcookies, and file uploads that have been declared. Note that this is purely on a name basis and you're not required to use annotation for this to be supported. However, when you do use the annotations-based declaration (as explained below), your declarations are nicely bundled and you have no duplication of the names.

[ top ]

Annotations support for element declaration

Annotations can now be used to create the element declarations and kick in when you declare an element implementation without an ID or file. All that is needed is the @Elem annotation on the element class.

The following conventions are being used by default:

  • if no ID is provided as an annotation value, the short class name will be used (without the package)
  • if no URL is provided as an annotation value, the lower cased short class name will be used

HelloWorld can thus be rewritten like this:

@Elem
public class HelloWorld extends Element {
    public void processElement() {
        Template template = getHtmlTemplate("helloworld");
        template.setValue("hello", "Hello world.");
        print(template);
    }
}

With the following site declaration:

<site>
    <arrival destid="HelloWorld"/>
    <element implementation="HelloWorld"/>
</site>

The element will automatically have the ID HelloWorld and be accessible through the URL "http://localhost:8080/helloworld".

From here onwards, you can start expanding the element declaration with annotations by adding attributes to the @Elem annotation. You can find detailed information in the Javadocs.

If you use a flowlink or a datalink with a destClass annotation value (instead of destId), the destination element class should also be annotated with @Elem for its ID to be obtained. RIFE assumes that this element has been declared in the site-structure and its ID will be evaluated inside the scope of the active sub-site. If you changed the ID of the destination element in the site structure, RIFE is not able to find that one since it's possible for an element class to be used several times with different IDs. If you need to reference an annotation element class that's part of another site structure, you can use the destClassIdPrefix annotation attribute.

To reduce the duplication of string literals for exit names, you can use the FlowlinkExitField and ExitField annotations. These allow you to annotate public final static String class fields instead of having to specify the exit names in attribute annotations of the main Elem annotation. Afterwards, it's easy to reuse these exit name fields inside your code to trigger the exits. This setup gives you compile-time safety for exit names.

For example:

@Elem
public class ProductListEntry extends Element {
    @FlowlinkExitField(destClass = EditProduct.class,
        destClassIdPrefix = "^Admin",
        datalinks = {
            @Datalink(srcOutput="productId", destInput="productId")
        })
    public static final String EXIT_EDIT_PRODUCT = "editProduct";
     
    @FlowlinkExitField(destClass = ShowProduct.class,
    datalinks = {
        @Datalink(srcOutput="productId", destInput="productId")
    })
    public static final String EXIT_SHOW_PRODUCT = "showProduct";
     
    private Product product;
     
    @OutputProperty
    public int getProductId() {
        if (product != null) return product.getId();
        return -1;
    }
     
    public void processElement() {
        // ... your logic ...
        exit(EXIT_SHOW_PRODUCT);
    }
}

Instead of declaring inputs, outputs, inbeans, outbeans, incookies, outcookies, submissions, parameters, submission beans and files inside the @Elem annotation, you can reduce name duplication by annotating them directly on setters, getters and submission method handlers (doSubmissionname format) with the InputProperty, OutputProperty, InBeanProperty, OutBeanProperty, InCookieProperty, OutCookieProperty, SubmissionHandler, ParamProperty, SubmissionBeanProperty, and FileProperty annotations.

Note that for the property declaration of parameters, files, and beans for a submission, RIFE will add them to the last declared submission. However, Java doesn't guarantee the order of methods in a class. That's why you need to use the Priority annotation to prioritize the order in which the annotated methods will be processed. The priority is not a traditional single integer that has to contain the correct sequential order, but it's an array of integers instead. This allows you to create logic prioritized groups and partition your methods like that. The first element of the array can for example be used to give a number to the submissions, and the second array element can then be used to indicate which methods belong to those submissions.

For example:

@Elem
public class MyElement extends Element {
    private String param1;
    private String param2;
    private String param3;
    private UploadedFile file1;
    private UploadedFile file2;
     
    @Priority({1})
    @SubmissionHandler
    public void doMySubmission() {
        // ...
    }
 
    @Priority({1, 1})
    @ParamProperty
    public void setParam1(String param1) {
        this.param1 = param1;
    }
 
    @Priority({1, 1})
    @FileProperty
    public void setFile1(UploadedFile file1) {
        this.file1 = file1;
    }
 
    @Priority({2})
    @SubmissionHandler
    public void doAnotherSubmission() {
        // ...
    }
     
    @Priority({2, 1})
    @ParamProperty
    public void setParam2(String param2) {
        this.param2 = param2;
    }
  
    @Priority({2, 1})
    @ParamProperty
    public void setParam3(String param3) {
        this.param3 = param3;
    }
     
    @Priority({2, 1})
    @FileProperty
    public void setFile2(UploadedFile file2) {
        this.file2 = file2;
    }
     
    public void processElement() {
        // ...
    }
}

The code above declares the submission 'mySubmission' and adds the parameter 'param1' and the file 'file1' to it. The second submission is 'anotherSubmission' and it will contain 'param2', 'param3' and 'file2'. You'll notice that the priorities '1,1' and '2,1' are used several times. This is because the order of the parameters and the files doesn't matter, only the first integer that ties them to the submission with the same priority value is important.

It's important to note that any method that doesn't contain a @Priority annotion will be processed before those that are prioritized. This means that you can still use a @Submission declaration inside the @Elem annotation and add parameters and files to it. The submission in the @Elem annotation will be the first that is processed and the non prioritized methods will be added to it since they come before the rest.

[ top ]

Support for parallel and simultaneous continuations

Continuations can run in embedded elements and any number of them can be active at the same time.

Below is the implementation of a page with multiple counters that all run independently as continuations with while loops.

The Counter.java element:

@Elem(url="", submissions = {
    @Submission(name = "decrease"),
    @Submission(name = "increase")})
public class Counter extends Element {
    public void processElement() {
        int counter = 0;
        Template t = getHtmlTemplate("counter");
        while (true) {
            t.setValue("counter", counter);
            print(t);
            pause();
            if (hasSubmission("decrease")) counter--;
            if (hasSubmission("increase")) counter++;
        }
    }
}

The counter.html template that is used by the element above:

<div>
    <r:v name="counter"/>
     
    <form action="${v SUBMISSION:FORM:decrease/}" method="post">
        <r:v name="SUBMISSION:PARAMS:decrease"/>
        <input type="submit" value=" - " />
    </form>
     
    <form action="${v SUBMISSION:FORM:increase/}" method="post">
        <r:v name="SUBMISSION:PARAMS:increase"/>
        <input type="submit" value=" + " />
    </form>
</div>

The main template that includes three counters as embedded elements:

<body>
    <r:v name="ELEMENT:Counter:1"/>
    <br />
    <r:v name="ELEMENT:Counter:2"/>
    <br />
    <r:v name="ELEMENT:Counter:3"/>
</body>

[ top ]

Fine-grained control over continuation trees and their invalidation

Continuations are perfect for expressing a transactional multi-step process that either fully completes, or not at all. At completion however, you most of the time have the requirement that the same process should not be able to be completed a second time (when a user re-submits the final form, for example a payment, this should not be accepted). It's now very easy to achieve this by using continuations by simply removing the entire continuation tree. This means that when the user re-submits, the corresponding continuation will not be found and instead of resuming at a previously paused location, the execution will jump back all the way to the initial step of the multi-step process.

The get access to the active continuation context and remove the associated continuation tree, you can use this simple call:

ContinuationContext.getActiveContext().removeContextTree();

Additional useful methods are available in the ContinuationContext class and allow you to introspect and manipulate the continuation hierarchy.

[ top ]

Step-back continuations

Continuations have always been used with a 'forward thinking' approach. With that I mean that when you resume after you pause, the next code is executed using the same local variable state. This results in explanations like: you continue where you left off, or continuations contain the remaining work to be done, ... With this release of RIFE, however, we allow you to step back to a previous location in the code. Instead of resuming where you left off when you paused, you can now also resume where you left off in the previous continuation.

The availability of this features makes it extremely easy to add 'back' submit buttons to multi-step flows. You just have to detect that it has been clicked and execute the stepBack() method call. This use of continuations doesn't require an intermediate user reponse step to continue. Instead, it captures the state of the current continuation and immediately resumes where the previous continuation resumed (not the last pause() call, but the one before).

For example (you can try out an online version of this example on the rifers.org website):

// handle the submission of the shipping details
do {
    generateForm(template, order);
    template.setBlock("content_form", "content_shipping");
    print(template);
    pause();
     
    template.clear();
    order.resetValidation();
    fillSubmissionBean(order);
} while (duringStepBack() || !order.validateGroup("shipping"));
 
// handle the submission of the credit card details
do {
    generateForm(template, order);
    template.setBlock("content_form", "content_creditcard");
    print(template);
    pause();
     
    template.clear();
    order.resetValidation();
    fillSubmissionBean(order);
 
    // if the form input button with the name "back1" was
    // pressed, a step-back continuation is executed,
    // this makes the flow jump to first pause() call in
    // this code snippet (not the pause call inside this
    // while loop)
    if (hasParameterValue("back1")) stepBack();
 
} while (!order.validateGroup("creditcard"));
 
// provide an overview of everything that has been submitted
template.setBean(order);
template.setBlock("content", "content_overview");
print(template);
 
// remove any continuation contexts that are active in this tree
ContinuationContext.getActiveContext().removeContextTree();

Note that the first loop contains an additional check: "duringStepBack()". This is needed since the "shipping" group of the OrderData bean is already valid, otherwise it would not have been possible to get to the second while loop. Without the check for an active step-back continuation, the first loop would simply terminate immediately after the step-back and the execution would arrive at the location of the "stepBack()" method call.

A very nice feature of this setup is that the data of the second step (the credit card details) is filled into the bean but not validated when the back button is pressed. Users can thus fill in incomplete data, go to the previous step in the wizard without being interrupted, change the data in the first form, and after submission they will see the same incomplete data that they entered before stepping back.

[ top ]

Stateful components

RIFE now makes it very easy for element instances to indicate which state needs to be preserved for them (in case you don't want to use continuations for this).

You simply create datalinks that point back to exactly the same element as the one they originate from. These are called reflexive datalinks. The data that's available through the connected outputs will be collected by RIFE and provided as inputs to the element when it's processed the next time. Note, this seperates out the collected data for each individual element instance you use on a site, even for embedded elements. While this is the behavior you would expect, it's worth pointing out that the data is not preserved globally for all the elements of the same type.

Let's look at the same counter example that we used to demonstrate parallel continuations, only this time it uses stateful components (you can try this version out online).

The element implementation Counter.java:

@Elem(
// Setting an empty URL, makes the submissions target the element that embeds
// the embedded Counter elements. Without this declaration, each embedded
// element would become the main element after the submission (since it has
// its own URL).
url="",
// This data link connects the 'counter' output to the 'counter' value. The
// element might have changed the counter property value in the meantime
// (after an 'increase' or 'decrease' submission). The reflective datalink
// will pass the output value to the input at the next submission.
datalinks = {@Datalink(srcOutput="counter", destInput="counter", destClass=Counter.class)}
)
public class Counter extends Element {
    private int counter;
    @InputProperty  public void setCounter(int counter) { this.counter = counter; }
    @OutputProperty public int getCounter() { return counter; }
     
    @SubmissionHandler
    public void doDecrease() {
        counter--;
        processElement();
    }
     
    @SubmissionHandler
    public void doIncrease() {
        counter++;
        processElement();
    }
     
    public void processElement() {
        Template t = getHtmlTemplate("counter");
        t.setValue("counter", counter);
        print(t);
    }
}

The counter.html template that is used by the element above:

<div>
    <r:v name="counter"/>
     
    <form action="${v SUBMISSION:FORM:decrease/}" method="post">
        <r:v name="SUBMISSION:PARAMS:decrease"/>
        <input type="submit" value=" - " />
    </form>
     
    <form action="${v SUBMISSION:FORM:increase/}" method="post">
        <r:v name="SUBMISSION:PARAMS:increase"/>
        <input type="submit" value=" + " />
 
    </form>
</div>

The main template that includes three stateful counters as embedded elements:

<body>
    <r:v name="ELEMENT:Counter:1"/>
    <br />
    <r:v name="ELEMENT:Counter:2"/>
    <br />
    <r:v name="ELEMENT:Counter:3"/>
</body>

[ top ]

Support for creating RIFE applications without any XML

The last part of the architecture of a RIFE web application that still required XML, was the repository setup. You needed to provide a participants.xml file to declare all the participants in the repository. This can now be removed by creating your own LifeCycle implementation. To use this you have to modify RIFE's standard web.xml file and use a lifecycle.classname init-param instead of the rep.path init-param.

For example:

<web-app>
    <filter>
        <filter-name>RIFE</filter-name>
        <filter-class>com.uwyn.rife.servlet.RifeFilter</filter-class>
        <init-param>
            <param-name>lifecycle.classname</param-name>
            <param-value>LifeCycle</param-value>
        </init-param>
    </filter>
 
    <filter-mapping>
        <filter-name>RIFE</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
</web-app>
 

Then you can create your own LifeCycle class like this:

public class LifeCycle extends RifeLifecycle {
    public LifeCycle() {
        BlockingRepository rep = new BlockingRepository();
        rep.addParticipant(ParticipantSite.class);
        rep.runParticipants();
        Rep.setDefaultRepository(rep);
    }
}

Don't forget to set the default repository in your custom lifecycle, since much of RIFE relies on the presence of that.

[ top ]

Performance improvements

A lot of work has been done to improve the performance both for development as for production.

These two are the most noteworthy:

  • When you use the "session" state storage mechanism, instead of the default "query" state storage, RIFE will do its best to prevent data from being encoded and decoded to and from strings. This makes the performance of applications with complex state management a lot better, at the expense of having to manage the state on the server-side.
  • During development time, RIFE constantly checks for changes in the site structure so that it can reload them on the fly. Before, this was done for every single request. This made the performance drop dramatically for complex sites since the checks were done for each and every CSS file and image in the site too (since RIFE is setup as a filter by default). RIFE is now by default setup to only perform these checks once every 10 seconds. This behavior can be configured through the AUTO_RELOAD_DELAY configuration parameter. It's default value is 10000. Of course, auto reloading can be turned of for production deployments, you can find the details on the wiki.

[ top ]

Support for reloading manually declared sites by site listeners

When you create a site through the Java API of the SiteBuilder class, you're able to include sub-sites that are declared with XML. These are registered as reloadable resources and their modification time is stored and checked regularly if the SITE_AUTO_RELOAD configuration parameter is set to true. The same happens for the compiled class files of the element implementations. However, since you manually declared the main site using Java, RIFE can't automatically rebuild it (which is what it does when you create a site using XML). You can now however add a SiteListener to your site that will receive a notification whenever RIFE detects that any of the site's resources has been modified. In your SiteListener implementation you can then rebuild the site and make it the new default instance that is used by RIFE.

For example, this is a custom site participant that does just that:

public class MySiteParticipant extends BlockingParticipant {
    private Site    site;
      
    public void initialize() {
        SiteBuilder builder = new SiteBuilder("main");
        builder
            .enterElement("YourElement")
                // ...
            .leaveElement()
          
            // ... other elements and sub sites
            ;
                  
        site = builder.getSite();
        site.addListener(new SiteListener() {
                public void modified(Site modifiedSite) {
                    initialize();
                    modifiedSite.populateFromOther(site);
                }
            });
    }
      
    protected Object _getObject() {
        return site;
    }
}

[ top ]

Automatic recompilation of non-hotswappable or instrumented classes

RIFE will now always recompile a changed Java implementation of an element if the source is available through the classpath, the ELEMENT_AUTO_RELOAD configuration parameter is set to true and a Java compiler is available. This allows you to add or remove methods to your element imlementations, to change the annotations, to modify the logic of a continuation element, etc. All without restarting the servlet container.

Note that you have to be careful about your application classpath setup here. You have two options:

  • Let RIFE compile all your element implementations:

    To make this possible you have to setup your IDE to not compile the element Java files. This is probably the easiest done by seperating them into a dedicated directory and setting up different compilation rules for them.

  • Let your IDE use hotswap to recompile the changed element implementations:

    RIFE will detect that a class file has changed and re-compile it from source when needed. Each IDE has a different approach to using hotswap: Eclipse does it automatically when you save a Java file when the application is running; X-develop, IDEA and NetBeans make you trigger hotswap explicitly by selecting a menu item or py 5clicking a toolbar button. If you get a message from the IDE, saying that hotswap doesn't support the changes in the reloaded classes, you can ignore it. RIFE's classloader works around this by loading a new copy of the element class.

In either case, you have to take extra care if you setup an application structure yourself outside the traditional WEB-INF web application structure. RIFE's classloader expects a standard structure by default. Otherwise, you have to make sure that the Java classpath contains all the required directories and jar files, and you have to tell RIFE which parts are only part of the web application (the classpath elements that would go into WEB-INF/classes or WEB-INF/lib). This is done by providing them as paths through the rife.webapp.path JVM property at application startup.

[ top ]

Generic Query Manager listeners

Callbacks have been available since RIFE version 1.0. We now however also introduced GenericQueryManagerListeners. These are similar to callbacks, except that they are associated with one particular GenericQueryManager, while Callbacks are associated with your domain model. Listeners are also only called as a notification mechanisms, they don't allow you to intervene in the execution flow. Listeners are called before 'after' callbacks.

[ top ]

Full changelog

2006-07-13 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * RELEASE 1.5

2006-07-12 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Updated mime type property for the examples highlighted source code.

  * Updated changelog

2006-07-11 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Placed empty target types on annotations that can only be used nested
  inside enclosing annotations.

  * RIFE-284 : @Exit annotation should be valid on fields

  * Ant build file fixes

2006-07-10 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Minor refactorings concerning state store extensibility

  * Generated highlighted sources of the latest version of the examples.

  * Example refactoring and source code re-formatting

  * Changed the dominant template tag syntax in the examples into
  <r:v name=""/>

  * Very rare NPE fix.

  * RIFE-291 : Annotation destClass attributes should also support a
  destClassIdPrefix attribute

2006-07-09 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Compilation fixes for windows and environment setup fixes for windows.

  * Tmp path fixes

  * Updated project files.

  * RIFE-281 : INVALID should suppress/clear MANDATORY message
  
2006-07-08 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Upgraded Janino to version 2.4.5

  * Upgraded to Imagero Reader 1.9.1-1, PostgreSQL JDBC 8.1-407, Spring 1.2.8

  * Upgraded bundled Derby to version 10.1.2.1 and
  Groovy to version 1.0 JSR 06

  * RIFE-286 : RIFE should support @Priority annotations for method and
  field annotations on elements.
  
  * Minor cleanups and javadoc fixes to BlockingRepository and
  HierarchicalProperties.
  
  * Added tests for HierarchicalProperties

2006-07-07 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Added support to hierarchical properties for easily adding a map.

  * Convenience API updates to BlockingRepository.

2006-07-06 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Fix to template bean setting where the format constraint wasn't fully
  respected.
  
2006-07-05 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Some LightweightEngineException fixes for Rhino engine

  * Regression fix related to making LightweightEngineException extend Error,
  they weren't properly dispatched inside submission handlers.
  
  * Addition of convenience methods to the BlockRepository.

2006-07-03 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Added support for setting exceptions as "rife.engine.exception" request
  attributes, so that servlet API 2.4 dispatch rule handlers can use it.

  * Replaced some 1.5 API calls with 1.4 counterparts.
  
  * Made other returned collections in templates also unmodifiable.

2006-07-02 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Ensured returned lists of Template getFilteredValues and getFilteredBlocks
  into unmodifiable lists.

  * Bugfix related to the inheritance and precedence order of complex nested
  groups and subsites.

2006-06-30 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Added USE_FAST_EXCEPTIONS configuration parameter to allow people to turn
  on the full strack traces when having to debug weird exception behavior.
  By default it is true.

  * RIFE-288 : Can have two unnamed submission beans with XML declaration but
  not with annotations

  * RIFE-287 : Embedded elements don't inherit parents' authentication data

2006-06-28 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Changed CMF content serving to call ElementSupport.defer() instead of
  setStatus(HttpServletResponse.SC_NOT_FOUND). This means that the CMF URL
  space can be shared with other filters or even with static files in the
  web application directory.

  * Made LightWeightEngineException an Error instead of a RuntimeException.
  This should reduce the probability of people catching it accidentally.

2006-06-27 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Added fix for relative element ID resolving for arrival elements. Instead
  of using the real ID of the arrival, the resolving now happens against the
  ID of the reference element to where the arrival points.

2006-06-26 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * API fix to SubmissionBuilder.
  
  * Made Annotations2ElementInfo work if the element processor type is
  annotations, but there's no @Elem annotation on the class.
  
  * Added support for cloning blueprint instances to create new Element
  instance, instead of having to only rely on instantiating them from the
  class. This is needed to be able to support elements that are implemented
  through anonymous inner classes.
  
2006-06-20 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Performance improvements by caching the injection setter methods for each
  element.

  * Replaced all StringBuffer occurances by StringBuilder and removed the
  thread lock pre-allocations that was needed to achieve a speed increase with
  StringBuffer. RetroWeaver translates all StringBuilder occurances back to
  StringBuffer to make the jar usable on JDK 1.4 (though a bit slower).

  * Added support for StringBuilder where StringBuffer is support for SQL
  conversion and such.

  * Performance optimizations.

  * Stateful embedded element fix that occurred when mixing early embedded
  value tag processing with explicit late processing of the same value ID and
  element differentiator.

2006-06-16 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Made the embed value of embedded elements now always only use the template
  default value instead of the template value (which can change). To pass data
  to an embedded element, an embedding element can provide a data object to
  processEmbeddedElement.

  * Build file fix for examples

2006-06-15 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Updated SVN properties

2006-06-12 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Added some logic to ensure that state stores always have the correct type
  after cloning their container.

  * Regression bugfix with form general for exits without outputs.

2006-06-09 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * RELEASE 1.5M2 (milestone 2)

  * Updated changelog

  * Updated javadocs

  * Updated highlighted syntax for the game example

2006-06-08 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Refactoring of state storage to improve session state handling.

2006-06-07 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Added test for parallel embedded continuation elements.

  * Made session state storage more performant.

  * Added support for not cloned session state storage to reduce the session
  size (SESSION_STATE_STORE_CLONING config param).

  * Fixes to session state storage.

2006-06-06 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Refactored state storage strategies to make session state storage much
  more performant.

2006-06-05 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Added support for simultaneous continuations in different embedded
  elements.

2006-06-02 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Minor bugfix to game example

2006-05-29 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Fixed a bug related to embedded element processing with differentiators.

2006-05-26 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Added GenericQueryManager listeners.
  
  * Added support for the "content-type" content attribute to all content
  stores, so that the content type can always be tailored for content
  serving.

2006-05-23 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Fixes to stateful components.

2006-05-19 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Made the advanced continuations example cleaner and easier to look at.

2006-05-17 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Added better support for continuation tree invalidation.

2006-05-16 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Made request and response encoding easily configurable with
  REQUEST_ENCODING and RESPONSE_ENCODING config parameters.

2006-05-13 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * RELEASE 1.5M1 (milestone 1)

  * Renamed hsqldb jar according to its version number.

2006-05-12 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Added stateful embedded elements explicit processing test.
  
  * Bugfix to stateful embedded elements.

2006-05-11 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Added test for embedded element data passing.

2006-05-09 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Updated activation, javamail, dwr, janino, ognl, postgresql jdbc, hsqldb
  and pnuts jars.

  * Added support for smpt_from task option to mail queue executor to set the
  from envelope address for mail envoys.

  * Regression bug fix to CMF ServeContent element.

2006-05-08 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Restored previous Template.getValue return type and
  ElementSupport.getEmbedValue return type.

  * Updated version to 1.5-snapshot

  * Removed some directories.

  * Updated examples syntax highlighting and moved the resulting html files
  to a dedicated directory to avoid confusion with the actual source files

  * Minor example structure rearrangements and fixes.

  * Fixes to annotation element declaration support.
  
  * Fixes for stateful embedded elements.
  
  * Added hangman example.

2006-05-07 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * X-develop project file fix

  * Added stateful component example

2006-05-06 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Added testcase for stateful embedded elements.

2006-05-03 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Re-implemented stateful component support. It now works exactly as
  expected when coming from other component frameworks.

2006-04-30 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Code cleanups.

  * Added support for stateful embedded element instances.

2006-04-27 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Minor fix to defer.xml element and minor code cleanups.

2006-04-24 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Made standard template factories non final.

  * Updated SVN mime types

  * Updated numberguess example

2006-04-23 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Finished javadocs for element declaration annotations.

2006-04-22 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Added more javadocs for element declaration annotations.

2006-04-21 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Added support for reloading manual site declarations through
  notifications of SiteListeners.

  * Added javadocs.

2006-04-20 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Javadoc additions for element declaration annotations.
  
  * Refactoring of the Site class internals to make it more maintainable.

2006-04-19 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Javadoc additions

  * Bug fixes to automatic site structure reloading.
  
  * Added support for auto-reloading of continuations-able classes.
  
  * You should now be able to use hot-swap to indicate a modified element
  java class and RIFE will auto-compile it, allow hot reloading of class
  structure changes that are not yet supported by hot-swap. You can ignore
  your IDEs warning.

  * Made bean property processing use a predictable order, ie. the order in
  which the properties are defined in the source file of the bean class.

2006-04-18 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * NPE fix to MetaData handling.

  * Updated authentication example to use global cookies instead of global
  vars.

  * Added duringStepBack() method that can be used if a step-back
  continuation happened right before.

  * Fix to stepBack continuations.
  
  * Made the submission parameters validation check all the submissions, not
  just the active one.

  * Improvements and javadoc additions for element declaration annotations

2006-04-17 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Improvements and javadoc additions for element declaration annotations

2006-04-15 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Added support for 'stepBack' continuations.

  * Improved error reporting during repository startup in the RIFE servlet
  or filter

2006-04-14 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Bugfix related to annotations and continuations in element
  implementations

  * Upgraded ASM to v2.2.2

  * Fixed issues when extending MetaData and using submission beans, inbeans
  or outbeans with constraint groups.

  * Opened up some of the ContinuationsManager and ContinuationsContext API.

  * Fixed flowlink-specific datalink bug. When several had the same output,
  input and target element, only one was taken into account due to incomplete
  hashCode and equals methods.

2006-04-13 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Fixed to the project and the annotations to make this work with X-develop

2006-04-13 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Minor config change for MacOSX

2006-04-12 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Updated DWR to 2.0M1.

  * Rewrote the DWR integration element and deployer for the new DWR version.

2006-04-06 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Minor reconfigurations for running on windows

2006-04-05 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Bugfix related to element tracing and continuations.

2006-04-04 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Added outcookie outjection support, fixes to output outjection. This
  finalizes RIFE element bijection support.

2006-04-03 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Added support for output value listener notification from getter
  outjection.

  * Added inheritance and child trigger support to output and outbean
  outjection.

2006-04-02 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Added outbean outjection support

2006-04-01 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Performance optimizations for injection into element instances

  * Added support for output outjection.

2006-03-30 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Upgraded XFire, Pnuts, Spring, Javamail, Janino, ImageJ, ImageroReader to
  their latest versions

2006-03-28 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Test suite fixes

2006-03-27 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Added support for cookie injections. Added also tests for defaults in
  parameter injection.

  * Minor bugfix on mail queue for robustness

2006-03-26 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Added injection support of named input beans, named submission beans and
  uploaded files.

2006-03-22 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Added dedicated exceptions for annotations support for element
  declaration.

2006-03-21 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Fixed bug related to global vars and sibling embedded elements.

2006-03-20 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Updated SVN props

2006-03-16 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Added PROPERTY:name filtered value tags

2006-03-15 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Template auto reload regression fix

  * Updated DWR and integrated Joe's patch

2006-03-14 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Added standard rife/defer.xml and com.uwyn.rife.engine.elements.Defer
  element

  * Updated example source code syntax highlights

2006-03-12 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Added tests for auto reload delay and minor fixes to template auto reload
  delay.

2006-03-11 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Replaced uses of Calendar.getInstance() with either new Date() or
  System.currentTimeInMillis() where appropriate.

  * Added a system-wide auto reload check delay that's by default 10 seconds.
  The configuration parameter AUTO_RELOAD_DELAY can be used to change it.

  * Bugfix to element declarations and 'extends'

2006-03-10 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Added classloader magic to hot reload annotations after hotswap.

  * Added check for missing element declaration and now throwing a meaningful
  exception.

  * Further work on element annotations.

  * Updated X-develop project file.

  * Added JDeveloper project files.

  * Removed unnecessary code.

2006-03-10 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Added experimental work in progress support for Element annotations.

  * NPE fix to IoC.

  * Added lifecycle.classname init parameter for the RIFE filter / servlet
  so that people can opt to extend the RifeLifecycle class and implement a
  Lifecycle in pure Java without relying on XML. With this step, a RIFE
  application can be written without a single line of XML.

2006-03-09 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Fixes to IoC properties declarations inside the repository declaration.

  * Regression fix to meta data merging.

2006-03-08 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Fixed meta data merging for classes with annotations.

  * Fixed instrumenting of annotations in continuations.

2006-03-06 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Workaround for bug in MySQL 5 on Windows that reports BIT columns as
  being VARCHAR.

2006-03-04 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * RIFE-275 : URLs for pathinfo mappings with globalvars are incorrect

2006-03-02 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * NPE fix in bean handling.

2006-03-01 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Minor change to the site.dtd.

2006-02-27 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * MetaData bugfix with regards to X-develop's debug compilation.

2006-02-26  Geert Bevin  <gbevin[remove] at uwyn dot com>

  * RELEASE 1.4

[ top ]
posted by Geert Bevin in RIFE on Jul 31, 2006 3:32 PM : 0 comments [permalink]
 

Comments

Add a new comment
Comments on this blog entry have been closed.

< JavaPaste 1.0 released : pastebin with highlighting, diffing, private pastebins and image uploads   Nominated and accepted as Java Champion >
 
 
 
Google
rifers.org web