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.
