You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by mp...@apache.org on 2002/02/16 14:35:30 UTC
cvs commit: jakarta-turbine-stratum deps.list default.properties build.xml
mpoeschl 02/02/16 05:35:30
Modified: . deps.list default.properties build.xml
Added: xdocs JCSPackageInformation.xml JCSandJCACHE.xml
project.xml index.xml toolbox.props building.xml
LocalCacheConfig.xml LateralTCPAuxCache.xml
RemoteAuxCache.xml JavaCachingSystem.xml
xdocs/stylesheets pdf.dvsl site.dvsl
xdocs/images logo.gif
Log:
I just finished converting all of Aaron's JCS documents to xdoc format.
While doing this, I also created the start of a stratum xdoc hierarchy.
This includes Jason's description of stratum from last week's status
update, and all of the JCS documentation that I converted.
Attached to this email is a tarball of the xdoc directory I built and
patches for build.xml, deps.list, and default.properties.
The patch to build.xml adds the 'docs' target which has the DVSL task
that generates the docs and copy task to copy all images over to the
output directory.
The default.properties patch adds dvsl and velocity jars. I used the
latest version of DVSL (0.40) so I could use the 'force' attribute in
the DVSL task which forces all of the docs to be built all of the time.
Unlike, Anakia, if you modify the project.xml file, the other pages are
not automatically regenerated.
pete@kazmier.com
Revision Changes Path
1.1 jakarta-turbine-stratum/xdocs/JCSPackageInformation.xml
Index: JCSPackageInformation.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>JCS Package Information</title>
<author email="pete@kazmier.com">Pete Kazmier</author>
<author email="ASmuts@therealm.com">Aaron Smuts</author>
</properties>
<body>
<section name="JCS Package Information">
<p>
The following tables provide a brief description of all packages
in the Java Caching System.
</p>
<subsection name="Access">
<p>
These packages house the classes that a user of JCS should
need to access the cache.
</p>
<table>
<tr><th>Package</th><th>Description</th></tr>
<tr><td>org.apache.stratum.jcs</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.access</td>
<td>
</td>
</tr>
</table>
</subsection>
<subsection name="Configuration">
<p>
This package contains the cache configuration code.
</p>
<table>
<tr><th>Package</th><th>Description</th></tr>
<tr><td>org.apache.stratum.jcs.config</td>
<td>
</td>
</tr>
</table>
</subsection>
<subsection name="Engine">
<p>
These packages contain the code for the core of the cache:
core interfaces, queues, and the cache hub.
</p>
<table>
<tr><th>Package</th><th>Description</th></tr>
<tr><td>org.apache.stratum.jcs.engine</td>
<td>
Interfaces used by the core and the auxiliary caches.
</td>
</tr>
<tr><td>org.apache.stratum.jcs.engine.behavior</td>
<td>
Interfaces used by the core and the auxiliary caches.
</td>
</tr>
<tr><td>org.apache.stratum.jcs.engine.control</td>
<td>
The primary cache classes and the hub.
</td>
</tr>
<tr><td>org.apache.stratum.jcs.engine.group</td>
<td>
The group cache code. Some classes here should be under
control.
</td>
</tr>
<tr><td>org.apache.stratum.jcs.engine.memory</td>
<td>
Parent package for memory type plugins.
</td>
</tr>
<tr><td>org.apache.stratum.jcs.engine.memory.lru</td>
<td>
The primary memory plugin.
</td>
</tr>
<tr><td>org.apache.stratum.jcs.engine.memory.mru</td>
<td>
</td>
</tr>
</table>
</subsection>
<subsection name="Auxiliary Caches">
<p>
Auxiliary caches generally fall into 3 types: disk, lateral,
and remote. Additional auxiliaries should be put into the
appropriate parent package.
</p>
<table>
<tr><th>Package</th><th>Description</th></tr>
<tr><td>org.apache.stratum.jcs.auxiliary</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.auxiliary.behavior</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.auxiliary.disk</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.auxiliary.disk.jisp</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.auxiliary.disk.hsql</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.auxiliary.lateral</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.auxiliary.lateral.socket</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.auxiliary.lateral.socket.tcp</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.auxiliary.lateral.socket.tcp.behavior</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.auxiliary.lateral.socket.tcp.utils</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.auxiliary.lateral.socket.udp</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.auxiliary.lateral.http</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.auxiliary.lateral.http.server</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.auxiliary.lateral.http.broadcast</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.auxiliary.lateral.http.remove</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.auxiliary.remote</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.auxiliary.remote.server</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.auxiliary.remote.server.behavior</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.auxiliary.remote.server.group</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.auxiliary.remote.group</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.auxiliary.remote.behavior</td>
<td>
</td>
</tr>
</table>
</subsection>
<subsection name="Utilities">
<p>
These packages contain utility classes used by JCS. Many can
eventually be converted to commons utilities.
</p>
<table>
<tr><th>Package</th><th>Description</th></tr>
<tr><td>org.apache.stratum.jcs.utils</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.utils.config</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.utils.data</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.utils.date</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.utils.email</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.utils.file</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.utils.html</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.utils.log</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.utils.net</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.utils.reuse</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.utils.servlet</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.utils.servlet.session</td>
<td>
Contains distributed session code.
</td>
</tr>
<tr><td>org.apache.stratum.jcs.utils.text</td>
<td>
</td>
</tr>
<tr><td>org.apache.stratum.jcs.utils.threads</td>
<td>
</td>
</tr>
</table>
</subsection>
</section>
</body>
</document>
1.1 jakarta-turbine-stratum/xdocs/JCSandJCACHE.xml
Index: JCSandJCACHE.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>JCS and JCACHE (JSR-107)</title>
<author email="pete@kazmier.com">Pete Kazmier</author>
<author email="ASmuts@therealm.com">Aaron Smuts</author>
</properties>
<body>
<section name="JCS and JCACHE (JSR-107)">
<p>
The JCS is an attempt to build a system close to JCACHE , <a
href="http://jcp.org/jsr/detail/107.jsp">JSR-107</a>, a
description of the caching system used in Oracle9i. JCS grew
out of my work over the past two years to build an enterprise
level caching system. Though it is replete with good ideas,
there are some aspects of the JCACHE architecture that could
lead to inefficiency (ex, the lateral distribution and net
searches) and a few programming preferences that I found
cumbersome (ex, the use of exceptions to report the common
place). Subsequently there are a few differences between the
two systems. In some cases I have moved my original system
closer to the JCACHE model where it presented a better idea.
Briefly:
</p>
<subsection name="Element vs. Region Attributes">
<p>
My original cache was regionally defined. Each entry required
a very minimal wrapper. The osc4j specification is an element
driven model where each element is fully configurable. This
could lead to a slight performance penalty, but it is a richer
model, where elements can inherit or have their own
attributes. So, I converted the entire system into element
centered framework.
</p>
</subsection>
<subsection name="Lateral Broadcast vs. Remote Consistency">
<p>
The oracle model is a laterally distributed framework with no
centralized control. The JCS model has the option for lateral
broadcast (which will need to be made more efficient) and a
remote store that coordinates consistency. In the JCS Local
caches send data to the remote store which then notifies other
local caches of changes to "regions" (caches) that are
registered. In JCACHE's lateral model an update is never
broadcast from the remote, rather updates come via the lateral
caches. If you broadcast changes to all servers then every
server must be ready for every user. The usage patterns of a
user on one box can affect the whole. Also, the lateral model
can make it difficult to synchronize combinations of updates
and invalidations.
</p>
<p>
With a remote store the local caches are primed to take on
similar patterns by talking to the remote store, but aren't
flooded with the elements from another machine. This
significantly cuts down on traffic. This way each local cache
is a relatively separate realm with remotely configurable
regions that stay in synch without overriding the user habits
of any machine. It also allows for an efficient mechanism of
retrieval, where searching for an element involves, at
maximum, only as many steps as there are remote servers in the
cluster. In the lateral model a failed net search could take
an extremely long time to complete, making it necessary for
the programmer to decide how long of a wait is acceptable.
</p>
<p>
Though this is by and large a poor model, the JCS will include
the ability to perform full lateral searches. A more
important feature is remote failover and remote server
clustering. With clustering any concerns about the remote
server being a single point of failure vanish and the remote
server model is significantly more robust.
</p>
</subsection>
<subsection name="Put vs. Replace">
<p>
The difference between put and replace is not present in the
JCS by default. The overhead associated with this distinction
is tremendous. However, there will be an alternate "safe-put"
method to deal with special caches.
</p>
</subsection>
<subsection name="Nulls vs. Errors">
<p>
I started to support <code>ObjectNotFoudExceptions</code> for
failed gets but the overhead and cumbersome coding needed to
surround a simple get method is ridiculous. Instead the JCS
return null.
</p>
</subsection>
<subsection name="Cache Loaders">
<p>
I'm not supporting cache loaders at this time. They seem
unnecessary, but may be useful in a smart portal.
</p>
</subsection>
<subsection name="Groups vs. Hierarchy">
<p>
The JCS provides feature rich grouping mechanism, where groups
of elements can be invalidated and whose attributes can be
listed. The grouping feature is much like the session API.
In addition, the JCS provides a mechanism for hierarchical
removal without the overhead of keeping track of all the
elements of a group across machines. Element keys with
"<code>:</code>" separators (a value that will be fully
configurable) can be arranged in a hierarchy. A remove
command ending in a "<code>:</code>" will issue a removal of
all child elements. I can associate search and menu drop down
lists for a particular company in a multi-company system by
starting each key in disparate caches with the company id
followed by "<code>:</code>" and then the normal key.
Invalidating this data when a change is made to data affecting
something falling under that company can be removed by simply
calling <code>cacheAccess.remove(comp_id + ":")</code>.
</p>
</subsection>
</section>
</body>
</document>
1.1 jakarta-turbine-stratum/xdocs/project.xml
Index: project.xml
===================================================================
<?xml version="1.0" encoding="ISO-8859-1"?>
<project name="stratum" href="http://jakarta.apache.org/turbine/stratum/">
<title>Stratum</title>
<logo href="images/logo.gif">Stratum</logo>
<body>
<menu name="Essentials">
<item name="Overview" href="/index.html"/>
<item name="Building" href="/building.html"/>
</menu>
<menu name="JCS Documentation">
<item name="JCS Overview" href="/JavaCachingSystem.html"/>
<item name="JCS Package Info" href="/JCSPackageInformation.html"/>
<item name="JCS and JCACHE" href="/JCSandJCACHE.html"/>
<item name="Local Cache" href="/LocalCacheConfig.html"/>
<item name="Remote Cache" href="/RemoteAuxCache.html"/>
<item name="Lateral TCP Cache" href="/LateralTCPAuxCache.html"/>
</menu>
</body>
</project>
1.1 jakarta-turbine-stratum/xdocs/index.xml
Index: index.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<author email="pete@kazmier.com">Pete Kazmier</author>
<author email="mpoeschl@marmot.at">Martin Poeschl</author>
<author email="jason@zenplex.com">Jason van Zyl</author>
<title>Stratum</title>
</properties>
<body>
<section name="Stratum">
<p>
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.
</p>
<p>
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:
</p>
<table>
<tr><th>Component</th><th>Description</th></tr>
<tr>
<td>Configuration</td>
<td>
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.
</td>
</tr>
<tr>
<td>Exception</td>
<td>
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.
</td>
</tr>
<tr>
<td>Factory</td>
<td>
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.
</td>
</tr>
<tr>
<td>Introspection</td>
<td>
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.
</td>
</tr>
<tr>
<td>JCS</td>
<td>
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 <a
href="http://jpolycache.sourceforge.net">here</a>. 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.
</td>
</tr>
<tr>
<td>Lifecycle</td>
<td>
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 <a
href="http://objectbridge.sourceforge.net">ObjectBridge</a>
a subsystem for use in Turbine by providing a small wrapper
that implements the lifecycle interfaces.
</td>
</tr>
<tr>
<td>Pool</td>
<td>
This is essentially the PoolService refactored into a
component. Done so for the exact same reason the
FactoryService was turned into a component.
</td>
</tr>
<tr>
<td>Resources</td>
<td>
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.
</td>
</tr>
<tr>
<td>XO</td>
<td>
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.
</td>
</tr>
</table>
</section>
</body>
</document>
1.1 jakarta-turbine-stratum/xdocs/toolbox.props
Index: toolbox.props
===================================================================
toolbox.contextname = toolbox
toolbox.tool.htmlescape = org.apache.velocity.anakia.Escape
1.1 jakarta-turbine-stratum/xdocs/building.xml
Index: building.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>Building Stratum</title>
<author email="pete@kazmier.com">Pete Kazmier</author>
</properties>
<body>
<section name="Building Stratum">
<p>
Building Stratum from CVS is now very easy. Recently, changes
have been made to the Stratum build process to simplify the
acquisition of jar dependencies. The entire build process is
now a four-step process.
</p>
<p>
The first step of the process is to obtain the source.
Checkout the <code>jakarta-turbine-stratum</code>
repository. If you are unfamiliar with the Jakarta CVS
repositories, please refer to the
<a href="/site/cvsindex.html">CVS Repositories</a> document
for assistance.
</p>
<p>
Next, you must define the <code>lib.repo</code> property in
your <code>${user.home}/build.properties</code> file. If
you do not have a <code>${user.home}/build.properties</code>
file, create one in your home directory and add the
following line:
</p>
<source><![CDATA[
lib.repo = /path/to/some/directory
]]></source>
<p>
The value of this property determines the location that the
Stratum dependencies will be stored after they have been
downloaded. Note: this directory must exist in the
filesystem.
</p>
<p>
Next, in the top-level directory of the Stratum distribution,
type the following command to download all of the
dependencies required to build Stratum:
</p>
<source><![CDATA[
ant update-jars
]]></source>
<p>
Lastly, after all of the jars have been downloaded to your
<code>lib.repo</code> directory, building the Stratum
distribution is only a matter of typing the following
command:
</p>
<source><![CDATA[
ant
]]></source>
<p>
The resulting jar file will be located in the <code>bin</code>
directory.
</p>
</section>
</body>
</document>
1.1 jakarta-turbine-stratum/xdocs/LocalCacheConfig.xml
Index: LocalCacheConfig.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>Configuring the Local Cache</title>
<author email="pete@kazmier.com">Pete Kazmier</author>
<author email="ASmuts@therealm.com">Aaron Smuts</author>
</properties>
<body>
<section name="Configuring the Local Cache">
<p>
This document is intended to provide various answers to
questions regarding the configuration of a local cache. The
document is presented in a question / answer format.
</p>
<subsection name="Where is the configuration information?">
<p>
Configuration of local caches involves editing the cache
configuration file, named <code>cache.ccf</code>. The
classpath should include the directory where this file is
located or the file should be placed at the root of the
classpath, since it is discovered automatically.
</p>
</subsection>
<subsection name="What is in the cache.ccf file?">
<p>
The <code>cache.ccf</code> file contains default configuration
information for cache regions and specific configuration
information for regions that you predefine. Regions not using
default behaviors should generally be configured via the
<code>cache.ccf</code> file. If you can put configuration
information in a class, you can edit a props file just as
easily. This makes modification of the regional setting more
efficient and allows for startup error checking.
</p>
<p>
There are three main sections of the <code>cache.ccf</code>
file:
</p>
<ul>
<li> the default and system settings </li>
<li> the region specific settings </li>
<li> the auxiliary cache definitions </li>
</ul>
</subsection>
<subsection name="How do I set up default values for regions?">
<p>
You can establish default values that any non-preconfigured
region will inherit. The non-predefined region will be
created when you call
<code>CacheAccess.getAccess("cacheName")</code>. The default
setting look like this:
</p>
<source><![CDATA[
#############################################################
################## DEFAULT CACHE REGION #####################
# sets the default aux value for any non configured caches
jcs.default=DC,RFailover
jcs.default.cacheattributes=org.jcs.engine.CompositeCacheAttributes
jcs.default.cacheattributes.MaxObjects=1000
]]></source>
<p>
The most important line is
<code>jcs.default=DC,Rfailover</code>. This tells the cache
what auxiliary caches should be used. Auxialiary caches are
configured in the third section of the <code>cache.ccf</code>
and are referenced in a comma separated list. You can add as
many auxiliary caches as you want, but the behavior of remote
and lateral auxiliaries may conflict. This allows you to
define different configurations for auxiliary caches and to
use these different configurations for different regions.
</p>
</subsection>
<subsection name="How do I define a region?">
<p>
Defining a region involves specifying which auxiliary caches
it will use and how many objects it will store in memory. A
typical region definition looks like:
</p>
<source><![CDATA[
jcs.region.testCache=DC,RFailover
jcs.region.testCache.cacheattributes=org.jcs.engine.CompositeCacheAttributes
jcs.region.testCache.cacheattributes.MaxObjects=1000
]]></source>
<p>
The region name is <code>testCache</code>. It will have a
1000 item memory limit and will use the DC and RFailover
auxiliary caches. If a typical element for this region was
very large, you might want to lower the number of items stored
in memory. The size of the memory storage is dependent on the
priority of the cache, the size of its elements, and the
amount of RAM on the machine.
</p>
</subsection>
<subsection name="How do I configure an auxiliary cache?">
<p>
Each auxiliary cache is created through a factory that passes
an attribute object to the constructor. The attributes are
set via reflection and should be fairly simple to understand.
Each auxiliary cache will be fully documented. Plugging in
your own auxiliary cache become a simple matter given the
reflexive manner of initialization.
</p>
<p>
The most important settings for common usage are the disk path
and the remote cache location. It is recommended that only
disk and remote auxiliaries be used. The lateral caches are
functional but not as efficient.
</p>
<p>
The default configuration code above specifies that
non-preconfigured caches use the auxiliary cache by the name
DC. This cache is defined in the third section of the file:
</p>
<source><![CDATA[
jcs.auxiliary.DC=org.jcs.auxiliary.disk.DiskCacheFactory
jcs.auxiliary.DC.attributes=org.jcs.auxiliary.disk.DiskCacheAttributes
jcs.auxiliary.DC.attributes.DiskPath=c:/dev/cache/raf
]]></source>
<p>
The only thing that needs to be set here is the
<code>DiskPath</code> value. Change it to wherever you want
the cache to persist unused items.
</p>
<p>
The default region is also set to use an auxiliary called
<code>RFailover</code>. This is a remote cache that is
designed to failover to other remote servers in a cluster:
</p>
<source><![CDATA[
jcs.auxiliary.RFailover=org.jcs.auxiliary.remote.RemoteCacheFactory
jcs.auxiliary.RFailover.attributes=org.jcs.auxiliary.remote.RemoteCacheAttributes
jcs.auxiliary.RFailover.attributes.RemoteTypeName=LOCAL
jcs.auxiliary.RFailover.attributes.FailoverServers=localhost:1102,localhost:1101
]]></source>
<p>
If you don't have more than one remote server running, just
specify it by itself in the <code>FailoverServers</code>
attribute.
</p>
</subsection>
</section>
</body>
</document>
1.1 jakarta-turbine-stratum/xdocs/LateralTCPAuxCache.xml
Index: LateralTCPAuxCache.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>Lateral TCP Auxiliary Cache</title>
<author email="pete@kazmier.com">Pete Kazmier</author>
<author email="ASmuts@therealm.com">Aaron Smuts</author>
</properties>
<body>
<section name="Lateral TCP Auxiliary Cache">
<p>
The TCP Lateral Auxiliary Cache is an optional plug in for the
JCS. It is primarily intended to broadcast puts and removals to
other local caches, though it can also get cached objects. It
functions by opening up a <code> SocketServer</code> that
listens to a configurable port and by creating
<code>Socket</code> connections with other local cache
<code>SocketServers</code>. It can be configured to connect to
any number of servers.
</p>
<p>
If there is an error connecting to another server or if an error
occurs in transmission, it will move into a recovery mode. In
recovery mode the TCP Lateral Auxiliary Cache will continue to
communicate with healthy servers while it tries to restore the
connection with the server that is in error.
</p>
<p>
The cache hub communicates with a facade that implements a
zombie pattern (balking facade) to prevent blocking. Puts and
removals are queued and occur synchronously in the background.
Get requests are synchronous and can potentially block for a
configurable interval if there is a communication problem.
</p>
<subsection name="Configuration">
<p>
The configuration is fairly straightforward and is done in the
auxiliary cache section of the <code>cache.ccf</code>
configuration file. In the example below, I created a TCP
Lateral Auxiliary Cache referenced by <code>LTCP</code>. It
connects to two servers defined in a comma separated list in
the <code>TcpServers</code> attribute. It listens to port
<code>1110</code> and does not run in
<code>PutOnlyMode</code>. Setting <code>PutOnlyMode</code>
equal to <code>true</code> would cause the auxiliary cache to
return <code>null</code> from any get request. In most cases this
attribute should be set to <code>true</code>, since if the
lateral caches were properly configured, the elements in one
would be present in all.
</p>
<source><![CDATA[
jcs.auxiliary.LTCP=org.apache.stratum.jcs.auxiliary.lateral.LateralCacheFactory
jcs.auxiliary.LTCP.attributes=org.apache.stratum.jcs.auxiliary.lateral.LateralCacheAttributes
jcs.auxiliary.LTCP.attributes.TransmissionTypeName=TCP
jcs.auxiliary.LTCP.attributes.TcpServers=localhost:1111,localhost:1112
jcs.auxiliary.LTCP.attributes.TcpListenerPort=1110
jcs.auxiliary.LTCP.attributes.PutOnlyMode=false
]]></source>
</subsection>
<subsection name="Potential Issues">
<p>
The TCP Lateral Auxiliary Cache can provide a high level of
consistency but it does not guarantee consistency between
caches. A put for the same object could be issued in two
different local caches. Since the transmission is queued, a
situation could occur where the item put last in one cache is
overridden by a put request from another local cache. The two
local caches could potentially have different versions of the
same item. Like most caches, this is intended for high get
and low put utilization, and this occurrence would hint at
improper usage. The RMI Remote cache makes this situation a
bit less likely to occur, since the default behavior is to
remove local copies on put operations. If either local cache
needed the item put in the above situation, it would have to
go remote to retrieve it. Both local copies would have been
expired and would end up using the same version, though it is
possible that the version stored remotely would not be the
last version created. The OCS4J tries to implement a locking
system to prevent this from occurring, but the locking system
itself could suffer from similar problems (when granting locks
from two roughly simultaneous lock requests) and it would
create a significant burden on all the caches involved. Since
this situation would be extremely rare and is nearly
impossible to solve practically, for now JCS will not offer
any type of locking.
</p>
</subsection>
<subsection name="TODO">
<p>
I will be adding a <code>RemoveOnPut</code> attribute that
will cause the lateral cache to remove an element from the
cache rather than inserting it when a put command comes from
another lateral cache. This will allow the local caches to
dictate their own memory usage pattern. This setting should
be run with <code>PutOnlyMode</code> set to false.
</p>
</subsection>
</section>
</body>
</document>
1.1 jakarta-turbine-stratum/xdocs/RemoteAuxCache.xml
Index: RemoteAuxCache.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>Remote Auxiliary Cache Client / Server</title>
<author email="pete@kazmier.com">Pete Kazmier</author>
<author email="ASmuts@therealm.com">Aaron Smuts</author>
</properties>
<body>
<section name="Remote Auxiliary Cache Client / Server">
<p>
The Remote Auxiliary Cache is an optional plug in for JCS. It
is intended for use in multi-tiered systems to maintain cache
consistency. It uses a highly reliable RMI client server
framework that currently allows for up to 256 clients. Using a
listener id allows multiple clients running on the same machine
to connect to the remote cache server. All cache regions on one
client share a listener per auxiliary, but register separately.
This minimizes the number of connections necessary and still
avoids unnecessary updates for regions that are not configured
to use the remote cache.
</p>
<p>
Local remote cache clients connect to the remote cache on a
configurable port and register a listener to receive cache
update callbacks at a configurable port.
</p>
<p>
If there is an error connecting to the remote server or if an
error occurs in transmission, the client will retry for a
configurable number of tires before moving into a
failover-recovery mode. If failover servers are configured the
remote cache clients will try to register with other failover
servers in a sequential order. If a connection is made, the
client will broadcast all relevant cache updates to the failover
server while trying periodically to reconnect with the primary
server. If there are no failovers configured the client will
move into a zombie mode while it tries to re-establish the
connection. By default, the cache clients run in an optimistic
mode and the failure of the communication channel is detected by
an attempted update to the server. A pessimistic mode is
configurable so that the clients will engage in active status
checks.
</p>
<p>
The remote cache server broadcasts updates to listeners other
than the originating source. If the remote cache fails to
propagate an update to a client, it will retry for a
configurable number of tries before de-registering the client.
</p>
<p>
The cache hub communicates with a facade that implements a
zombie pattern (balking facade) to prevent blocking. Puts and
removals are queued and occur asynchronously in the background.
Get requests are synchronous and can potentially block if there
is a communication problem.
</p>
<p>
By default client updates are light weight. The client
listeners are configured to remove elements form the local cache
when there is a put order from the remote. This allows the
client memory store to control the memory size algorithm from
local usage, rather than having the usage patterns dictated by
the usage patterns in the system at large.
</p>
<p>
When using a remote cache the local cache hub will propagate
elements in regions configured for the remote cache if the
element attributes specify that the item to be cached can be
sent remotely. By default there are no remote restrictions on
elements and the region will dictate the behavior. The order of
auxiliary requests is dictated by the order in the configuration
file. The examples are configured to look in memory, then disk,
then remote caches. Most elements will only be retrieved from
the remote cache once, when they are not in memory or disk and
are first requested, or after they have been invalidated.
</p>
<subsection name="Client Configuration">
<p>
The configuration is fairly straightforward and is done in the
auxiliary cache section of the <code>cache.ccf</code>
configuration file. In the example below, I created a Remote
Auxiliary Cache Client referenced by <code>RFailover</code>.
</p>
<p>
This auxiliary cache will use <code>localhost:1102</code> as
its primary remote cache server and will attempt to failover
to <code>localhost:1103</code> if the primary is down.
</p>
<p>
Setting <code>RemoveUponRemotePut</code> to <code>false</code>
would cause remote puts to be translated into put requests to
the client region. By default it is <code>true</code>,
causing remote put requests to be issued as removes at the
client level. For groups the put request functions slightly
differently: the item will be removed, since it is no longer
valid in its current form, but the list of group elements will
be updated. This way the client can maintain the complete
list of group elements without the burden of storing all of
the referenced elements. Session distribution works in this
half-lazy replication mode.
</p>
<p>
Setting <code>GetOnly</code> to <code>true</code> would cause
the remote cache client to stop propagating updates to the
remote server, while continuing to get items from the remote
store.
</p>
<source><![CDATA[
# Remote RMI Cache set up to failover
jcs.auxiliary.RFailover=org.apache.stratum.jcs.auxiliary.remote.RemoteCacheFactory
jcs.auxiliary.RFailover.attributes=org.apache.stratum.jcs.auxiliary.remote.RemoteCacheAttributes
jcs.auxiliary.RFailover.attributes.FailoverServers=localhost:1102,localhost:1103
jcs.auxiliary.RC.attributes.RemoveUponRemotePut=true
jcs.auxiliary.RFailover.attributes.GetOnly=false
]]></source>
<p>
This cache region is setup to use a disk cache and the remote
cache configured above:
</p>
<source><![CDATA[
#Regions preconfirgured for caching
jcs.region.testCache1=DC,RFailover
jcs.region.testCache1.cacheattributes=org.apache.stratum.jcs.engine.CompositeCacheAttributes
jcs.region.testCache1.cacheattributes.MaxObjects=1000
jcs.region.testCache1.cacheattributes.MemoryCacheName=org.apache.stratum.jcs.engine.memory.lru.LRUMemoryCache
]]></source>
</subsection>
<subsection name="Server Configuration">
<p>
The remote cache configuration is growing. For now, the
configuration is done at the top of the
<code>remote.cache.ccf</code> file. The
<code>startRemoteCache</code> script passes the configuration
file name to the server when it starts up. The configuration
parameters below will create a remote cache server that
listens to port <code>1102</code> and performs call backs on
the <code>remote.cache.service.port</code>, also specified as
port <code>1102</code>.
</p>
<p>
The tomcat configuration section is evolving. If
<code>remote.tomcat.on</code> is set to <code>true</code> an
embedded tomcat server will run within the remote cache,
allowing the use of management servlets.
</p>
<source><![CDATA[
# Registry used to register and provide the IRemoteCacheService service.
registry.host=localhost
registry.port=1102
# call back port to local caches.
remote.cache.service.port=1102
# tomcat config
remote.tomcat.on=false
remote.tomcat.xml=g:/dev/jakarta-turbine-stratum/bin/conf/remote.tomcat.xml
# cluster setting
remote.cluster.LocalClusterConsistency=true
]]></source>
<p>
The cluster configuration section is currently considered
experimental. The <code>LocalClusterConsistency</code>
setting tells the remote cache server if it should broadcast
updates received from other cluster servers to registered
local caches.
</p>
<p>
To use experimental clustering, the remote cache will have to
be told what regions to cluster. The configuration below will
cluster all non-preconfigured regions with
<code>RCluster1</code>.
</p>
<source><![CDATA[
# sets the default aux value for any non configured caches
jcs.default=DC,RCluster1
jcs.default.cacheattributes=org.apache.stratum.jcs.engine.CompositeCacheAttributes
jcs.default.cacheattributes.MaxObjects=1000
jcs.auxiliary.RCluster1=org.apache.stratum.jcs.auxiliary.remote.RemoteCacheFactory
jcs.auxiliary.RCluster1.attributes=org.apache.stratum.jcs.auxiliary.remote.RemoteCacheAttributes
jcs.auxiliary.RCluster1.attributes.RemoteTypeName=CLUSTER
jcs.auxiliary.RCluster1.attributes.RemoveUponRemotePut=false
jcs.auxiliary.RCluster1.attributes.ClusterServers=localhost:1103
jcs.auxiliary.RCluster1.attributes.GetOnly=false
]]></source>
</subsection>
<subsection name="TODO">
<p>
The clustering behavior needs to be better defined. We may
want to implement clustering with lateral caches between
remotes rather than remote caches talking to each other.
</p>
<p>
Though small, the remote server configuration could be a bit
cleaner.
</p>
<p>
The embedded Tomcat is not workable right now.
</p>
<p>
Parameters need to be added for running the XML-RPC server as
well.
</p>
</subsection>
</section>
</body>
</document>
1.1 jakarta-turbine-stratum/xdocs/JavaCachingSystem.xml
Index: JavaCachingSystem.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>Java Caching System</title>
<author email="pete@kazmier.com">Pete Kazmier</author>
<author email="ASmuts@therealm.com">Aaron Smuts</author>
</properties>
<body>
<section name="Java Caching System">
<p>
JCS is a distributed caching system written in java for
server-side java applications. It is intended to speed up
dynamic web applications by providing a means to manage cached
data of various dynamic natures. Like any caching system, the
JCS is most useful for high read, low put applications. Dynamic
content and reporting systems can benefit most. However, any
site that repeatedly constructs pages, dropdowns, or common
search results form a database that is updated at intervals
(rather than across categories continuously) can improve
performance and scalability by implementing caching. Latency
times drop sharply and bottlenecks move away from the database
in an effectively cached system.
</p>
<p>
The JCS goes beyond simply caching objects in memory. It
provides several important features, necessary for any
Enterprise level caching system:
</p>
<ul>
<li>Memory management</li>
<li>Disk overflow (and defragmentation)</li>
<li>Element grouping</li>
<li>Quick nested categorical removal</li>
<li>Data expiration</li>
<li>Extensible framework</li>
<li>Fully configurable runtime parameters</li>
<li>Remote synchronization</li>
<li>Remote store recovery</li>
<li>Non-blocking "zombie" (balking fa ade) pattern</li>
<li>Optional lateral distribution of elements via HTTP, TCP, or
UDP</li>
<li>Remote server clustering and failover (almost complete)</li>
</ul>
<p>
These features provide a framework with no point of failure,
allowing for full session failover including session data across
up to 256 servers.
</p>
</section>
</body>
</document>
1.1 jakarta-turbine-stratum/xdocs/stylesheets/pdf.dvsl
Index: pdf.dvsl
===================================================================
#document()
<!-- Make a Section header bar -->
#match ( makeSectionHeader $value )
#if ( $value.getAttributeValue("name") )
#set ( $titleName = $value.getAttributeValue("name") )
#else
#set ( $titleName = "" )
#end
<fo:block
font-size="14pt"
font-family="sans-serif"
line-height="24pt"
space-after.optimum="15pt"
background-color="blue"
color="white"
text-align="start"
padding-top="3pt">
$titleName
</fo:block>
#end
<!-- Make a Paragraph -->
#match ( makeParagraph $value )
<fo:block
font-size="12pt"
space-after.optimum="15pt"
font-family="sans-serif"
background-color="white"
color="black"
text-align="start"
padding-top="3pt">
$xmlout.outputString($value)
</fo:block>
#end
<!-- Make a Source Code block -->
#match ( makeSrc $value )
<fo:block
font-size="12pt"
space-after.optimum="15pt"
font-family="sans-serif"
background-color="white"
color="gray"
text-align="start"
padding-top="3pt">
$escape.getText($value.getText())
</fo:block>
#end
<!-- Make an image link -->
#match ( makeLink $value )
<fo:block font-size="12pt"
space-after.optimum="15pt"
font-family="sans-serif"
background-color="white"
color="gray"
text-align="start"
padding-top="3pt">
<fo:basic-link external-destination="http://test">
TO DO
</fo:basic-link>
</fo:block>
#end
#match (document)
<?xml version="1.0" encoding="utf-8"?>
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format">
<!-- defines the layout master -->
<fo:layout-master-set>
<fo:simple-page-master
master-name="Velocity"
page-height="8.5in"
page-width="11in"
margin-top="0.25in"
margin-bottom="0.25in"
margin-left="0.5in"
margin-right="0.5in">
<fo:region-before extent="0.25in"/>
<fo:region-body margin-top="0.25in"/>
</fo:simple-page-master>
</fo:layout-master-set>
<!-- starts actual layout -->
<fo:page-sequence master-name="Velocity">
<!-- header -->
<fo:static-content flow-name="xsl-region-before">
<fo:block
text-align="end"
font-size="10pt"
font-family="serif"
color="black"
padding-right="3pt">
$root.getChild("properties").getChild("title").getText() pg <fo:page-number/>
</fo:block>
</fo:static-content>
<fo:flow flow-name="xsl-region-body">
#set ($allSections = $xpath.applyTo("body/section", $root))
<!-- Walk through the sections -->
#foreach ( $section in $allSections )
#makeSectionHeader($section)
#foreach ( $item in $section.getChildren() )
#if ( $item.getName().equals("p") )
#makeParagraph($item)
#elseif ( $item.getName().equals("source") )
#makeSrc($item)
#end
#end
#end
</fo:flow>
</fo:page-sequence>
</fo:root>
#end
1.1 jakarta-turbine-stratum/xdocs/stylesheets/site.dvsl
Index: site.dvsl
===================================================================
#set( $relative-path = "." )
#set( $body-bg = '#ffffff' )
#set( $body-fg = '#000000' )
#set( $body-link = '#525D76' )
#set( $banner-bg = '#525D76')
#set( $banner-fg = '#ffffff')
#set( $sub-banner-bg = '#828DA6')
#set( $sub-banner-fg = '#ffffff')
#set( $table-th-bg = '#039acc')
#set( $table-td-bg = '#a0ddf0')
#set( $source-color = '#023264')
#match( "document" )
#set( $project = $node.selectSingleNode("document('xdocs/project.xml')/project" ) )
<html>
<head>
<title>$project.title - $node.properties.title</title>
#foreach( $n in $node.properties.selectNodes("author") )
<meta name="author" value="$n"/>
<meta name="email" value="$n.attribute("email")" />
#end
</head>
<body
bgcolor="$body-bg"
text="$body-fg"
link="$body-link"
alink="$body-link"
vlink="$body-link">
<table border="0" width="100%" cellspacing="4">
## PAGE HEADER
<tr><td colspan="2">
## JAKARTA LOGO
<a href="http://jakarta.apache.org/">
<img src="http://jakarta.apache.org/images/jakarta-logo.gif"
align="left" alt="The Jakarta Project" border="0"/>
</a>
#if( $project.logo )
#set( $alt = $project.logo )
#set( $home = $project.attribute("href") )
#set( $src = $project.logo.attribute( "href" ) )
## PROJECT LOGO
<a href="$home">
<img src="$src" align="right" alt="$alt" border="0"/>
</a>
#end
</td></tr>
## HEADER SEPARATOR
<tr>
<td colspan="2">
<hr noshade="" size="1"/>
</td>
</tr>
<tr>
## LEFT SIDE NAVIGATION
<td width="20%" valign="top" nowrap="true">
$context.applyTemplates( $project, "body/menu" )
</td>
<!-- RIGHT SIDE MAIN BODY -->
<td width="80%" valign="top" align="left">
$context.applyTemplates("body/section")
$context.applyTemplates("body/glossary")
</td>
</tr>
<!-- FOOTER SEPARATOR -->
<tr>
<td colspan="2">
<hr noshade="" size="1"/>
</td>
</tr>
<!-- PAGE FOOTER -->
<tr><td colspan="2">
<div align="center"><font color="$body-link" size="-1"><em>
Copyright © 1999-2001, Apache Software Foundation
</em></font></div>
</td></tr>
</table>
</body>
</html>
#end
#*
* Process a menu for the navigation bar
*#
#match( "menu" )
<p>
<strong>$attrib.name</strong>
</p>
<ul>
$context.applyTemplates("item")
</ul>
#end
#*
* Process a menu item for the navigation bar
*#
#match( "item" )
#if( $attrib.href.startsWith("http") )
<li><a href="$attrib.href">$attrib.name</a></li>
#else
<li><a href="${relative-path}$attrib.href">$attrib.name</a></li>
#end
#end
#*
* process a documentation section
*#
#match( "section" )
<table border="0" cellspacing="0" cellpadding="2" width="100%">
<tr><td bgcolor="$banner-bg">
<font color="$banner-fg" face="arial,helvetica.sanserif">
<a name="$attrib.name">
<strong>$attrib.name</strong></a></font>
</td></tr>
<tr><td><blockquote>
$context.applyTemplates("*")
</blockquote></td></tr>
</table>
#end
#match( "subsection" )
<table border="0" cellspacing="0" cellpadding="2" width="100%">
<!-- Subsection heading -->
<tr><td bgcolor="$sub-banner-bg">
<font color="$sub-banner-fg" face="arial,helvetica.sanserif">
<a name="$attrib.name">
<strong>$attrib.name</strong></a></font>
</td></tr>
<!-- Subsection body -->
<tr><td><blockquote>
$context.applyTemplates("*")
</blockquote></td></tr>
</table>
#end
#match( "source" )
<div align="left">
<table cellspacing="4" cellpadding="0" border="0">
<tr>
<td bgcolor="$source-color" width="1" height="1">
<img src="/images/void.gif" width="1" height="1" vspace="0" hspace="0" border="0"/>
</td>
<td bgcolor="$source-color" height="1">
<img src="/images/void.gif" width="1" height="1" vspace="0" hspace="0" border="0"/>
</td>
<td bgcolor="$source-color" width="1" height="1">
<img src="/images/void.gif" width="1" height="1" vspace="0" hspace="0" border="0"/>
</td>
</tr>
<tr>
<td bgcolor="$source-color" width="1">
<img src="/images/void.gif" width="1" height="1" vspace="0" hspace="0" border="0"/>
</td>
<td bgcolor="#ffffff" height="1">
<pre>$toolbox.htmlescape.getText( $node.value() )</pre>
</td>
<td bgcolor="$source-color" width="1">
<img src="/images/void.gif" width="1" height="1" vspace="0" hspace="0" border="0"/>
</td>
</tr>
<tr>
<td bgcolor="$source-color" width="1" height="1">
<img src="/images/void.gif" width="1" height="1" vspace="0" hspace="0" border="0"/>
</td>
<td bgcolor="$source-color" height="1">
<img src="/images/void.gif" width="1" height="1" vspace="0" hspace="0" border="0"/>
</td>
<td bgcolor="$source-color" width="1" height="1">
<img src="/images/void.gif" width="1" height="1" vspace="0" hspace="0" border="0"/>
</td>
</tr>
</table>
</div>
#end
#match("table")
<table>
$context.applyTemplates("*")
</table>
#end
#match("tr")
<tr>
$context.applyTemplates("*")
</tr>
#end
#match( "td" )
#set ($colspan = $attrib.colspan)
#set ($rowspan = $attrib.rowspan)
<td
bgcolor="$table-td-bg"
colspan="$!colspan"
rowspan="$!rowspan"
valign="top"
align="left">
<font
color="#000000"
size="-1"
face="arial,helvetica,sanserif">
$node.copy( $node.children() )
</font>
</td>
#end
#match( "th" )
#set ($colspan = $attrib.colspan )
#set ($rowspan = $attrib.rowspan )
<td
bgcolor="$table-th-bg"
colspan="$!colspan"
rowspan="$!rowspan"
valign="top"
align="left">
<font
color="#000000"
size="-1"
face="arial,helvetica,sanserif">
$node.copy( $node.children())
</font>
</td>
#end
## -----------------------------------------------------
## G L O S S A R Y
## -----------------------------------------------------
#match ( "glossary" )
$context.applyTemplates("entries/entry")
#end
#match ("entry")
<b>$context.node.name</b>
<br/>
$context.node.definition
<p/>
#end
## -----------------------------------------------------
## D E F A U L T C O P Y
## -----------------------------------------------------
#match("*")
$node.copy()
#end
1.1 jakarta-turbine-stratum/xdocs/images/logo.gif
<<Binary file>>
1.8 +2 -0 jakarta-turbine-stratum/deps.list
Index: deps.list
===================================================================
RCS file: /home/cvs/jakarta-turbine-stratum/deps.list,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- deps.list 13 Feb 2002 19:13:59 -0000 1.7
+++ deps.list 16 Feb 2002 13:35:30 -0000 1.8
@@ -18,3 +18,5 @@
jisp_1_0_2.jar
hsqldb.jar
xmlrpc.jar
+velocity-1.3-dev.jar
+velocity-dvsl-0.40.jar
1.19 +2 -0 jakarta-turbine-stratum/default.properties
Index: default.properties
===================================================================
RCS file: /home/cvs/jakarta-turbine-stratum/default.properties,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- default.properties 14 Feb 2002 20:42:44 -0000 1.18
+++ default.properties 16 Feb 2002 13:35:30 -0000 1.19
@@ -49,6 +49,8 @@
concurrent.jar = ${lib.repo}/concurrent.jar
dom4j.jar = ${lib.repo}/dom4j-1.1.jar
junit.jar = ${lib.repo}/junit-3.7.jar
+dvsl.jar = ${lib.repo}/velocity-dvsl-0.40.jar
+velocity.jar = ${lib.repo}/velocity-1.3-dev.jar
# These are required by jcs
jgl.jar = ${lib.repo}/jgl3.1.0.jar
1.21 +53 -31 jakarta-turbine-stratum/build.xml
Index: build.xml
===================================================================
RCS file: /home/cvs/jakarta-turbine-stratum/build.xml,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- build.xml 14 Feb 2002 20:42:44 -0000 1.20
+++ build.xml 16 Feb 2002 13:35:30 -0000 1.21
@@ -34,9 +34,11 @@
<pathelement location="${jaxp.jar}"/>
<pathelement location="${crimson.jar}"/>
<pathelement location="${xmlrpc.jar}"/>
+ <pathelement location="${dvsl.jar}"/>
+ <pathelement location="${velocity.jar}"/>
<pathelement location="${build.dest}"/>
- <!-- AspectJ Jars for non-invasive use of aspects
+ <!-- AspectJ Jars for non-invasive use of aspects
this is needed only for acompile target -->
<pathelement location="${aspectjrt.jar}"/>
<pathelement location="${aspectjtools.jar}"/>
@@ -71,9 +73,6 @@
dest="${lib.repo}"
dependencyFile="deps.list"
/>
-
-
-
</target>
<!-- ================================================================== -->
@@ -118,7 +117,6 @@
property="AnakiaTask.present"
classpathref="classpath"
/>
-
</target>
<!-- ================================================================== -->
@@ -132,11 +130,10 @@
<mkdir dir="${build.dir}"/>
<mkdir dir="${build.src}"/>
<mkdir dir="${build.dest}"/>
-
+
<copy todir="${build.src}">
<fileset dir="${src.dir}/java/"/>
</copy>
-
</target>
<!-- ================================================================== -->
@@ -160,7 +157,6 @@
optimize="${optimize}">
<classpath refid="classpath"/>
</javac>
-
</target>
<target
@@ -186,7 +182,6 @@
<rmic
base="${build.dest}"
classname="org.apache.stratum.jcs.auxiliary.remote.RemoteCacheClientTest"/>
-
</target>
<!-- =================================================================== -->
@@ -219,7 +214,6 @@
<include name="**/*.java"/>
<include name="**/*.aj"/>
</ajc>
-
</target>
<!-- ================================================================== -->
@@ -236,10 +230,8 @@
<exclude name="**/package.html"/>
</fileset>
</jar>
-
</target>
-
<!-- ================================================================== -->
<!-- FILTER Scripts and Config Files -->
<!-- ================================================================== -->
@@ -261,10 +253,8 @@
<copy todir="${build.dir}/conf" filtering="true">
<fileset dir="${src.dir}/conf"/>
</copy>
-
</target>
-
<!-- ================================================================== -->
<!-- Dev Standard Build -->
<!-- ================================================================== -->
@@ -275,6 +265,41 @@
description="==> ">
</target>
+ <!-- ================================================================== -->
+ <!-- D V S L D O C U M E N T A T I O N -->
+ <!-- ================================================================== -->
+
+ <target
+ name="docs"
+ description="==> generates the documentation">
+
+ <taskdef name="dvsl" classname="org.apache.tools.dvsl.DVSLTask">
+ <classpath>
+ <path refid="classpath"/>
+ </classpath>
+ </taskdef>
+
+ <!-- Make sure the target directory -->
+ <mkdir dir="${docs.dest}"/>
+ <dvsl
+ basedir="${docs.src}"
+ destdir="${docs.dest}/"
+ force="true"
+ extension=".html"
+ toolboxfile="${docs.src}/toolbox.props"
+ style="${docs.src}/stylesheets/site.dvsl"
+ excludes="**/project.xml,**/template.xml"
+ includes="**/*.xml"
+ />
+
+ <copy todir="${docs.dest}/images" filtering="no">
+ <fileset dir="${docs.src}/images">
+ <include name="**/*.gif"/>
+ <include name="**/*.jpeg"/>
+ <include name="**/*.jpg"/>
+ </fileset>
+ </copy>
+ </target>
<!-- ================================================================== -->
<!-- J A V A D O C S -->
@@ -323,7 +348,6 @@
name="dist"
depends="jar"
description="==> Creates torque.zip distribution">
-
</target>
<!-- ================================================================== -->
@@ -342,7 +366,6 @@
</copy>
</target>
-
<!-- ================================================================== -->
<!-- Get clean copy of source -->
<!-- ================================================================== -->
@@ -362,26 +385,25 @@
<!-- ================================================================== -->
- <target name="scrubABigMess"
+ <target
+ name="scrubABigMess"
depends="prepare">
- <taskdef name="scrub"
- classname="net.sourceforge.importscrubber.ant.ImportScrubberTask"/>
+ <taskdef name="scrub"
+ classname="net.sourceforge.importscrubber.ant.ImportScrubberTask"/>
- <javac
- deprecation="false"
- debug="true"
- optimize="false"
- srcdir="${src.dir}/java"
- destdir="${src.dir}/java">
+ <javac deprecation="false"
+ debug="true"
+ optimize="false"
+ srcdir="${src.dir}/java"
+ destdir="${src.dir}/java">
<classpath refid="classpath"/>
</javac>
- <scrub root="${src.dir}/java/org/apache/stratum/jcs/" format="top" recurse="true"/>
-
- <delete>
- <fileset dir="${src.dir}" includes="**/*.class"/>
- </delete>
- </target>
+ <scrub root="${src.dir}/java/org/apache/stratum/jcs/" format="top" recurse="true"/>
+ <delete>
+ <fileset dir="${src.dir}" includes="**/*.class"/>
+ </delete>
+ </target>
</project>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>