Great Aaron. I'll bring this to Henning's attention and we will try and
give you some feedback and advice on the path forwards.
Thanks,
Scott
Aaron Smuts wrote:
Proposal for JCS Project Promotion
I. Rational
JCS (Java Caching System) was the first major
open-source Java caching solution. After a few years
of incubation within the Turbine project, JCS is ready
to become a top-level Jakarta project. The scope and
maturity of JCS make it suitable for top level project
status.
The JCS project is of the scope of a project such as
log4j, which its sub project status does not indicate.
Since JCS has no dependencies on Turbine, it would
less confusing to users if it were its own top-level
project. Given the size and coherence of the
code-base it is not well suited in as a module of any
other project, such as commons.
JCS is ready for a production release. Over the past
year, we solved all major, known bugs. Although there
are a growing number of competitors, JCS has a good
number of users and is currently at a 1.2.1
development version.
JCS would be a good addition to the list of current
top level Jakarta projects, and, perhaps more
importantly, it would benefit from the input of a
larger community that increased exposure would afford.
II. Scope of the Package
JCS is a distributed caching system written in java
for server-side java applications. The project is an
attempt to build a system close to JCACHE , JSR-107, a
description of the caching system used in Oracle9i.
JCS is intended to speed up dynamic web applications
by providing a means to manage cached data of various
dynamic natures. Like any caching system, JCS is most
useful for high read, low put applications.
JCS is essentially a cache hub and several production
ready and experimental modules that can be plugged
into the hub. In JCS, cached data is stored in a
region. Each region can be configured independently
of the others. JCS is modeled on log4j, where various
appenders can be defined for specific regions.
JCS defines four types of appenders, or what we call
auxiliaries: memory, disk, lateral, and remote. A
memory auxiliary manages items stored in memory. Disk
auxiliaries manage memory overflow and persistence of
cached data. Lateral auxiliaries communicate directly
with other caches. Remote auxiliaries communicate
with a remote server to which other caches are
connected. At least one production ready
implementation of each type of auxiliary is included
in the core JCS jar. The LRU memory cache, indexed
disk cache, TCP lateral cache, JGroups lateral cache,
and RMI remote cache auxiliaries form the core suite
of stable JCS auxiliaries.
JCS is extremely configurable. Every auxiliary
exposes detailed configuration options. For example,
the indexed disk cache allows you to configure such
things as the maximum number of keys in memory, the
size of the recycle bin for reusing empty spots on
disk, whether it should defragment and if so when, and
the type of event queue to use. More information on
the available disk cache configuration options can be
found here:
http://jakarta.apache.org/turbine/jcs/IndexedDiskAuxCache.html
One of the most important features of JCS is that you
can plug in new auxiliaries. Each type of auxiliary
has a defined interface, and the implementation class
can be defined in the JCS configuration file.
The cache hub and the core auxiliaries are contained
in a JAR file that is JDK 1.3 compatible. Other JDK
1.4 specific features are contained in another
optional JAR.
III. Interaction with other packages
JCS has dependencies on several standard commons
packages, including: commons-lang,
commons-collections, and commons-logging. We also
depend on Doug Lea's util concurrent JAR for some of
our locking and thread pools. Some of the optional
auxiliaries depend on other libraries. For instance,
the JGroups jar depends on the JGroups release. The,
JDK 1.4 optional, Berkeley DB auxiliary depends on the
related project.
The Cocoon project currently uses JCS as its caching
mechanism.
IV. Source of the package
I contributed JCS to the Stratum project, a subproject
of Turbine, over three years ago. It has been a sub
project of Turbine for about 2 years.
V. Base name for the package
The JCS code is currently checked into CVS with the
following root package name:
org.apache.jcs
VI. Coding conventions
The code follows a modified version of Sun's standard
coding conventions, with the following stylistic
changes:
• instance variables are prefixed with an underscore
• a newline is inserted before all braces
VII. Jakarta resources to be created
The current mailing lists are turbine-jcs-user@
jakarta.apache.org and turbine-jcs-dev@
jakarta.apache.org. We should forward these lists to,
or just create, these two new lists:
[EMAIL PROTECTED] -- User discussions
[EMAIL PROTECTED] -- Developer discussions
and CVS update notifications
VIII. Initial set of committers
There are currently four committers on the JCS
project, all of whom have licenses on file.
Aaron Smuts <[EMAIL PROTECTED]>
James Taylor <[EMAIL PROTECTED]>
Hanson Char <[EMAIL PROTECTED]>
Travis Savo <[EMAIL PROTECTED]>
VIII. Documentation
You can find the current JCS documentation here:
http://jakarta.apache.org/turbine/jcs/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
