the cajo project
Free, simple, powerful: Transparent Distributed Computing
Some folks who are making a big difference
  • Richard M. Stallman, and the Free Software Foundation, for starting it all; and for donating the cajo namespace. If you don't know who RMS is, you should definitely read this excellent book about him. Also thank you very much Richard, for all of your patient guidance, and excellent input, during my formulation of this project's licence page description. OK, well, technically; I have only requested the cajo namespace.

  • Eric S. Raymond (aka) esr, and also Rob Landley, with whom I had the pleasure to confer over the years, at Penguicon. For encouraging me to open my most precious and personal source code; you made the case guys, I did it! And by the way, congratulations Eric, on your latest excellent book.

  • Chris DiBona, your advice and encouragement really meant a lot to me at the start of this adventure. Even before that, your book was a pivotal inspiration. Update: I also look forward to reading the much appreciated sequel.

  • Esmond Pitt (aka) ejp on the Sun Java RMI forum; for patiently answering my, and many others questions over the years, especially as they became more esoteric. Also for your outstanding book.

  • Project member Fredrik Larsen, who with assistance from project member Li Ma, 'changed the rules' for Java reflection. Now, for the project's invoke paradigm: Subclass and subinterface arguments will be recognised.

  • Project member Ekkehard Gentz; who demonstrated that the example needed a root properties file, to work on non-English localised machines. He also provided the example properties file, translated auf Deutsch.

  • Jean-Marie Dautelle, for your experienced feedback to this project, and the generous contribution of an ant script, to build the framework. Jean-Marie heads two excellent open source projects. They provide classes and packages missing from core Java; for real-time, scientific, and safety-critical applications. I highly recommend a visit to learn more about both: JScience and javolution. He even provided the example properties file, translated en français.

  • Olivier Brizard, for your proposal to include support for HTTP proxy tunnels, as required by so many corporations. He both made the case, and validated its operation. For helping to foster a new era of cooperation, between fiercely firewalled corporations: Détente.

  • Project member Zac Wolfe, for your proposal to manually autobox server method arguments, as needed during remote invocation. This allows server methods to use primitive argument types, in addition to primitive return types.

  • Project member Martin Zardeki, for developing a technology adoption path for the JEE developer community. He created a detailed wiki page to document the process, and also furnished complete source code. Thanks for building a very valuable bridge, between two innovative communities.

  • Project member Bharavi Gade, for your proposal to add JRE 1.3 dynamic object proxy support to the codebase. He very patiently made the case, past my initial objections. Now we can all enjoy the amazingly simple, yet extremely powerful, abstraction of the TransparentItemProxy.

  • Project member Keith Oswald, who in concert with project member Pavel Krupets, recognised potential shortcomings in the ItemProxy / ClientProxy mechanism for JVMs behind firewalls. Based on their issues, and some extremely interesting commentary in the Client/Server Computing forum; this mechanism now works significantly better than ever.

  • Mike Decker, who made three very significant contributions to our project. He recognised the need to have CodebaseServer able to serve application specific graphical clients. He also contributed to a generic Swing compatible proxy JClient. Finally he saw the need for having CodebaseServer able to support multiple jar classpaths. He did all this, and a considerable amount of testing as well. Together these refinements make the project much more appealing to sophisticated proxy GUI developers.

  • Petr Štěpán, made two interesting contributions. First he proposed allowing objects exported by Remote to optionally support the Unreferenced interface -- to receive notification each time the group of remote clients of the item reaches zero. Second he proposed TransparentItemProxy should unpack InvocationTargetExceptions into the original exception thrown by the wrapped object method; this is a much more intuitive thing to do. Further explanation on the topic can be found here.

  • Project member Jörg Hubschneider, who made the astute observation that the bind operations in gnu.cajo.utils.ItemServer were not threadsafe. This could cause potentially disastrous exceptions in an highly dynamic application; wherein binding of items was performed in different threads. He also noticed that AsyncMethod would benefit from unpacking potential InvocationTargetExceptions too.

  • Project member Bertrand Goetzmann, who provided three fascinating applications of scripting cajo using the Groovy language. The original french articles can be found here; otherwise an oftentimes humourously machine translated version to English can be found here.

  • Project member Boris Lemus, who following an extensive overhaul of the of the gnu.cajo.Remote package, discovered two errors which broke operation using NAT. He dug deep into the inner workings of the class to find the errors, corrected and tested it, and generously submitted a patch. Also, he discovered that gnu.cajo.utils.CodebaseServer needed to provide a Last-Modified tag in the HTTP response headers, otherwise server resources would be re-fetched -- even if they had not changed!

  • More to come...

  • A special thanks to the entire community... Together Everyone Achieves More!
    © 2004 GNU FDL