> These are all good issues. I think more rigor needs to be put into how > service artifacts are updated, and what attributes we look for when we seek > to discover services. Using version numbers in both the produced artifacts > and ensuring that services advertise version numbers (as part of > net.jini.lookup.entry.ServiceInfo), and that we look for specific version > numbers for a service we want to use can help with this issue. > > Perhaps (and I'm not sure this has been discussed before) having a range of > versions that a service provides support for could also help address this > issue. If the client determines it is out of synch, the deferred update > approach certainly allows the client to choose to use remote class loading or > provision that requisite jars.
To add to that--two solutions that we have to address "does the client have the latest (and correct) version of the service downloadable JARs?" are first, to always download those JARs on discovering the service, and second, to implement a versioning scheme such that the client, on discovery, verifies that it has the version available locally and in classpath. >From my perspective, I'm happy to apply a version number/string as we have already converged on Maven at our shop, and there are rules for when we update version numbers. There are some cases where a developer working in a branch will not update versions during their development work, and versions are overwritten in-place (not exactly, Maven will track multiple instances of the same version using a timestamp). But in deployment the versions are fixed. We haven't (in around 3 years of using Jini here) had to update the -dl.jars at runtime and have the clients pick up the new versions. We just have a different deployment process that works for us. I understand that different users of Jini have other needs. I think posting the artifact's hash along with other identifying information helps you here--if the version of the local file matches, but the hash doesn't, then the client either has to find the correct version or give up. Since the hash would presumably be posted along with the service Entries, it would prevent clients from trying to use outdated artifacts for a given service. I think River needs to support both dynamic codebase downloading (via codebase services) and local repository storage. Some way to mix the two as per Gregg's suggestion sounds good as well (e.g. local lookup but allowing dynamic downloading when needed). I myself would just like to see River move away from the idea that dynamic download via codebase services is a requirement, more or less, of using Jini, and to provide a reasonable/workable alternative for those that don't need it. Patrick
