Hi Jim,
Sorry for the much delayed response. We do have an implementation that
emphasizes on performance. We might be able to help specify a Java object
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 have
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 AFS
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 AFS
administrative library (libadmin) through a layer of static Java native
functions (also organized based on entity) and a JNI library (written in C)
implementing those native functions. Most of these native functions would
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, and
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 application
error code; (2) construction using the said integer error code and a string
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 inherited
from java.lang.Exception), the AFSException object calls a static method
from an error message management class (ErrorCodes). This error message
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 corresponding
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 and
integer values.
Your comments and collaboration are welcome.
Jim Doyle <[EMAIL PROTECTED]> 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/discussion
> and hopefully standardization. Let me know if you are interested and I
> will keep you posted on our progress.
Interesting.. Are you guys still in the formal design phase ?? I assume
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 that
map directly to the Rx Interfaces?
Have you determined how to map error codes to run-time exceptions?
-- Jim
_______________________________________________
OpenAFS-devel mailing list
[EMAIL PROTECTED]
https://lists.openafs.org/mailman/listinfo/openafs-devel
