[OpenAFS-devel] (no subject)

[Jeremy Stribling]

Hi Jim,

Sorry for the much delayed response.   We do have an implementation tha=
t
emphasizes on performance.  We might be able to help specify a Java obj=
ect
interface that can be standardized.

What we have in mind (and what we have done some work on) is a Java API=
 for
the AFS administrative functions, written in an object-oriented manner
based on the standard AFS entities.  For example, an AFS volume would h=
ave
a corresponding Volume object in Java.  We envision the following types=
 of
objects:  Cells, Servers, Partitions, Volumes, Processes, Keys, Users, =
and
Groups.  Each of these objects would have fields corresponding to the
actual AFS attributes of the entity and methods corresponding to the AF=
S
operations on these entities.  For example, a Volume might have a field=

called "quota", which of course corresponds to the actual quota of the =
AFS
volume.  A partition object would have a method called getVolumes that
would return a list of volume objects contained in the partition.

The implementation of the Java API would communicate with the native AF=
S
administrative library (libadmin) through a layer of static Java native=

functions (also organized based on entity) and a JNI library (written i=
n C)
implementing those native functions.  Most of these native functions wo=
uld
correspond almost exactly to functions in libadmin; the main purpose of=
 the
JNI library would simply be to translate between the Java and the C, an=
d
vice versa, not really to add any new functionality.

The error/exception model used employs a fundamental class architecture=

that is sub-classable.  At the top of the hierarchy, the super class
AFSException is the principal exception class that introduces two basic=

types of construction:  (1) construction using an integer value that
represents the AFS error code, Unix error code, and/or custom applicati=
on
error code; (2) construction using the said integer error code and a st=
ring
message that overrides the default message associated with the provided=

error code.  To properly interpret the error code, and return the
corresponding error message via the getMessage method (which is inherit=
ed
from java.lang.Exception), the AFSException object calls a static metho=
d
from an error message management class (ErrorCodes).  This error messag=
e
management class manages multi-language support as well as a flexible
message resource bundle model that allows easy administration of error
codes, and corresponding messages.  The AFS error codes and correspondi=
ng
messages are currently derived from a dynamic application (JETC ? Java
Error Table Compiler) that traverses the entire AFS source tree and
articulates all of the defined errors and their respective constants an=
d
integer values.

Your comments and collaboration are welcome.


Jim Doyle <doyle@world.std.com> on 2001/12/15 11:53:44 AM

To:   Shyh-Wei Luan/Almaden/IBM@IBMUS
cc:
Subject:  Re: [OpenAFS-devel] Java JNI access to Venus, Vlserver and
      Volserver ??



> We are working on a Java programming interface spec for review/discus=
sion
> and hopefully standardization.   Let me know if you are interested an=
d I
> will keep you posted on our progress.

Interesting.. Are you guys still in the formal design phase ??  I assum=
e
that you already have prototype code working as a proof of concept..

My questions are:

     Have you actually modelled the interface with Objects?  Or do you
just have a 1:1 mapping of primitive Java objects and function calls th=
at
map directly to the Rx Interfaces?

     Have you determined how to map error codes to run-time exceptions?=


-- Jim
=