Fork me on GitHub
Built by Maven

Weekly Status Report: 08 Feb 2002

What's going on with Turbine these days? Well, quite a lot actually. We were in a lull there for a while but things are back on track so I thought I would try and report some of the work and changes that have been going on recently.

Stratum

Stratum is the repository where we are trying to refactor a lot of the existing Turbine code into modularized components that can be used across all Turbine projects. The short term goal is refactoring for the purpose of clarifying the code for Turbine use, but after this has happened the goal is to move all the code, with thorough units tests of course, into the commons where we can share our code with the Jakarta community.

There are several components in Stratum, most of the code originated in Turbine but there are some new additions. Here is a short run down of the components that will be available in Stratum:

  • Configuration: This code originated in JServ, was brought into Turbine, moved to Velocity and improved, and then moved into the Commons as ExtendedProperties. The code in ExtendedProperties is a little unweildly and deals specifically with properties files. We wanted to use a general Configuration interface and allow the source of the values to vary. Right now we only have the properties file version working, but the XML configuration will soon work.
  • Exception: This code has also wandered around a bit. It started in Turbine 2.x, and subsequently copied around into Torque, Fulcrum, and Turbine 3.x and eventually landed in the Commons Util package. Again we wanted to clean it up a bit, make it work consistently throughout the Turbine code, make sure it will interoperate with chainable exceptions in 1.4 and then put it back in the Commons.
  • Factory: This is essentially the FactoryService refactored into a component. It's my feeling that factories are a fundamental aspect of an application and not a service. The example being Fulcrum where dynamic classloading cannot be performed very easily by the FactoryService within the core service code itself. As a component the factory type behaviour provided can be used in a determined way anywhere, including the core of the Fulcrum service framework.
  • Introspection: This is the introspector that was originally written for Velocity. It has been decoupled from Velocity and is being used in the XO mapper (see below). Once this code is cleaned up it can definitely be reused in Velocity.
  • JCS: This is the new caching system that we plan to use in all the Turbine projects. The package is maintained by Aaron Smuts and you can find a bit out about it here. Aaron has started documenting JCS and we'll get some comprehensive documentation up soon as I'm sure many people will be very interested in this package.
  • Lifecycle: These are interfaces that we are starting to use in the Turbine code to provide a consistent way of dealing with various components like Torque and Fulcrum. By having Torque and Fulcrum implement these new lifecycle interfaces and teaching Turbine to deal with these interfaces we provide a new mechanism whereby any component can be made a subsystem very easily. So for example you could easily make ObjectBridge a subsystem for use in Turbine by providing a small wrapper that implements the lifecycle interfaces.
  • Pool: This is essentially the PoolService refactored into a component. Done so for the exact same reason the FactoryService was turned into a component.
  • Resources: This package is a reworking of the resources package found in Velocity. The Velocity specifics have been removed and hopefully this package will provide facilities for full resource management.
  • XO: This is currently an XML -> Bean mapper that takes an XML file formatted in a common way and maps the content to a Java Bean. Basically, this allows us to simply design our Bean, and provided that the commons XML format is used no mapping rules need to be created. The testbed has full examples, and the Turbine 3.x pipeline descriptors are mapped using the XO package. Again, we're working on full documentation though the JavaDoc is fairly comprehensive.

    • Using DVSL for Documentation

    DVSL is now being used for the Turbine 3.x documentation as it is more flexible and will allow the generation of PDF documents. Work was started in the Velocity repository that transformed the xdocs into FOP documents so I have started from that work to try and produce a good set of PDF docs.

    New Security Model

    Gonzalo and Eric are currently working on some ideas for a new security model for Turbine 3.x. Anyone can view the work being done by looking at the rundata_security_changes branch in the jakarta-turbine-3 repository.

    RunData Reworking

    I am currently reworking the RunData system so that it can be decoupled from Fulcrum and generally work in a more flexible manner. We want to be able to use multiple variants of RunData in an application, and we want each of those variants to house a configurable set of tools: a cookie parser or a parameter parser for example. This work needs to be finished before the security models can be tried and tested. Hopefully the RunData work will be finished next week sometime.

    Turbine 3.x Pipeline

    The Pipeline in Turbine 3.x is now fully functional. Some documentation on the pipeline has been created and it will be posted to the site this weekend. The upshot of this change is that we now have configurable request processing so an application can tailor its pipeline(s) very easily to meet any requirements.

    Introduction of Cactus

    The use of Cactus was introduced in the Turbine 3.x tree so that changes can be tested easily. Jeff has also backported our Cactus based testing framework to the 2.x branch. This is a big step forward for us as we had virtually no testing prior to this addition. Thanks a ton to Jeff for getting this working!

    More Consistent Build Pattern

    The build systems for Turbine 3.x, Turbine 2.x, Fulcrum, Torque and Flux are all now basically the same. There is a new target in each of the respective build files that will allow you to download the JARs necessary for building the project. The TDK has also been outfitted with this feature so developers interested in helping improve the TDK can do so without having to hunt down all the necessary JAR files. We hope that the addition of the JAR downloader will help make it easier for people to participate without having to build everything under the sun.