What's new?

Version 1.5.1

of June 10, 2006 has these improvements:

• A few additions to the OCSServerAdminInterface and OCSServerUserInterface classes were made. In particular, OCSServerUserInterface has received getSubject()-methods, which together with addSubject(), can be used to transfer subjects from one server to another.
• One bug was detected and fixed: the OCSClient-methods getServerUserProxy() and getServerAdminProxy() had ignored the OCSClient they were bound to and used the standard client instance instead.
• OCSClassProxyFactory was augmented to add the serialVersionUID-field to generated class proxy code.

Version 1.5

of April 12, 2006 was mainly a technical update:

• With this release, OCSelot makes use of generic types and other advanced features of Java 5 (hence the leap over version no. 1.4).
  For the users, this means that OCSelot requires a Java "Tiger" virtual machine from now on. Rest assured, however: OCSelot will remain the handy cat it was... ;-)
• A few methods of OCSClient and OCSServer were changed to return type safe collections.
• Two methods of class OCSServer that by now had returned an ArrayList, now return a less specific List<T>.
• OCSClient has been added a method isStandardInstance().
• In OCSClassProxyFactory a minor bug was removed.

Version 1.3.1

of Feb 21, 2006 had these changes:

• A gap in thread-safety, which showed when an OCSClient was used by many proxies in parallel, has been detected and filled.
• The method used to install OCSClient instances in proxy classes for use by static methods has been renamed to ocsSetClientForClassMethods().
  Also, the role of clients so installed, has been clarified: From now on they are used solely for class methods, and they are never bound to the standard OCSClient instance automatically. (Before, switching the standard OCSClient wasn't properly reflected in proxy instance allocation and class method invocation.)
• OCSClient has been given a method setAsStandardInstance() to allow making an existing OCSClient instance the new standard instance.
• And, last not least: This new version is considerably faster than 1.3!

Version 1.3

of Feb 16, 2006 had the following improvements:

• Most notably, this version introduces distributed garbage collection: If a proxy goes out of scope, it now automatically detaches from its subject, and once a subject isn't referenced by proxies anymore, it is removed and garbage collected. This is always the case for subjects created by class proxies, and it is an option for subjects added to the server from the outside through one of the addSubject() methods. See the API for (the very simple) details.
• Secondly, data transfer can now be made secure by using encryption. To use this feature, simply specify an encryption key to both client and server. The server can even be configured to allow both encrypting and non-encrypting clients. See the API for how it's done.
• The way to set restrictions on IPs of clients allowed to connect to the server, has been enhanced: Previously you could only allow certain IPs (specifying IPs or patterns of such), now you can also forbid clients connecting from certain IPs. Allowing and forbidding can be combined. See the API for details.
• The OCSClient has been made thread-safe [almost, see version 1.3.1]. Now there may be several proxies living in separate threads, each using the same OCSClient instance for request transmission.
• There are additional methods on OCSClient and OCSServer to access instances of these classes.
• Names of new OCSClient and OCSServer instances are now guaranteed to be unique by automatic renaming, if necessary.
• In the same way, IDs of subjects installed in the server are now guaranteed to be unique.
• Proxies allow to retrieve the OCSClient instance they use for communication.
• And there's a number of minor improvements and modifications, like changes of method names and additions to the API documentation.

Version 1.2

of Jan 20, 2006 has been the first release of OCSelot.

Why 1.2 instead of 1.0? That's because OCSelot grew out of a forerunner developed early in 2004, a simple, handcrafted "system" that used an individual class for every method to be called from remote and instances of the classes to carry the method parameters.

This quick hack helped overcome some trouble with CORBA setup, in a web application that needed to transfer sound data captured in an applet to a servlet. After an incubation time of more than two years, this seed led to OCSelot.