Jim Doyle wrote:
I recently discovered that libjafs.so builds out with the default build from the head of the 1.4.x branch. It appears if you got JAVA_HOME in your env path, that configure chases after it and adds it as a build target.>the object identity rule, as opposed to the default reference identity behaviorI was PLEASANTLY suprised to see that not only does it build, but it works (!) with just a few minor bug fixes nonetheless. I was able to traverse my cell and have it dump all the servers, partitions and volumeinformation. Who is using JAFS? Who is relying on it? Who, if anyone, has put time into it to maintain it? There are a number of design and architectural issues with JAFS that I see immediately that I could fix ; provided it isnt being already done by others: 1. hashCode()/equals() is improperly implemented in the current codebase. In particular, the signature equals(Object o) must be implemented properlyand further, hashCode() must ALSO be overriden at the same time to reflect
> I've already fixed this, I'd just need cvs commit privs. Commit privileges for OpenAFS are only granted to the gatekeepers. Send patches to [EMAIL PROTECTED] This will create a ticket in the request tracking system. Send one patch per ticket.
2. The architecture is not suitable for most Java environments because attribute values have been too closed coupled to the behavior specific to native methods. Architecturally, the entity classes (Cell, Volume, etc), need to be Serializable POJOs with no behavioural methods - they are just value objects. The "behavioral" methods should be moved to pure Interfaces (i.e. releaseVolume(...), createVolume(...)). A number of concrete classes can then realize these interfaces ; NAMELY: Proxies for remoting access to JAFS via RMI-IIOP, RMI-JRMP, even web methods. Adapters that implement but hide the specifics of the Java Native Methods glue. Interceptors that can shim ontop the service interfaces to implement auditing, access control etc. This is classis SOA (service oriented architecture) stuff...
There is no one working on such architectural issues. The architecture we have is essentially what was developed internally at IBM.Create a design proposal and it can discussed in this forum. There are not a lot of Java developers here. I have not developed for Java in
quite a number of years but was fairly proficient when I did. I will be able to review your design and provide feedback. We should also see what updates are required to support Kerberos v5 if any.
3. If these minor but significant architectural enhancements can be pulled off (at the cost of breaking the "current" JAFS API signatures!), JAFS should not only be alot easier to maintain, BUT, should be eminently usable by both JFC/Swing UI developers, web developers as well as work with the frameworks (EJB3, Spring). Further, using the classic SOA architecture I proposed, it'd not be hard to wrap the JAFS API with a Webservice to permit other language bindings (Perl, Ruby, etc).
Great.
4. Dump the checked exceptions and use runtime exceptions.
Sure
5. Because we dont know how multiple Java threads hitting multiple methods on the same _impl object and spawning multiple Pthreads for RX is going to behave, it also makes sense to change the JNI methods to use a masterlock to avoid psychotic thread-mapping/thread safety issues. The master lock approach is a hack, but its correct at the expense of performance.
Where are your concerns? RX is thread-safe. As long as the _impl objects are thread safe I would expect the system to be. Global locks
are to be avoided.
That said, I'd like to know who out there is already on JAFS and also who is depending on the current API for production work.... The proposedrefactoring will substantially alter the API.
There are certainly people using the existing API. I suggest making a more complete proposal so that we can see where the breakage will be. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
