river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Wright <pdoubl...@gmail.com>
Subject Re: Maven repository Entry was Re: Codebase service?
Date Tue, 25 May 2010 15:56:47 GMT
> 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


View raw message