Dan,
If you are interested in synthesis of OSGi with Jini, check out the
newton project @ newton.codecauldron.org. Newton "Systems" use Jini
discovery and leasing mechanisms, and support dynamic proxies. Spring
"classic" and Spring DM are supported, also Jetty.
Any queries, send them to the newton mail list.
This is an active project, with a series of release planned throughout
09.
Regards
Richard
On 30 Nov 2008, at 20:41, Dan Rollo wrote:
Hi All,
I'm in the midst of some redesign discussions with other devs on the
CruiseControl project (plug link: http://cruisecontrol.sourceforge.net/distributed/index.html)
. ;)
We have a "Distributed extension" aka: DistCC (for remote build
agents) that we are trying to merge into the core of the project. We
are also working to remove some coupling to "shared file systems"
that have limited our options going forward. Towards that end, I see
Jini as a way to keep hostname and other hardcoded network
configuration out of the picture.
In my stumblings with Jini, I've more that once done things the
"wrong way", and I think I have an opportunity to use a nice "Jini
Container" that will do things the "right way", and protect me from
myself in the future. ;)
While searching for such "Jini Service Containers", I have a few
questions about what might be the best fit:
Rio
https://rio.dev.java.net/
This is the one I've heard the most about, but I'm a little
concerned about the size of it's footprint. Any thoughts here? Are
there smaller "rio parts" that could be deployed, without requiring
a ~15mb download on each client? Even if not, it's probably not a
show stopper, but it may be harder to get buy in...
Seven
http://www.cheiron.org
This link appears broken. Is it replaced by:
https://whatsitdo.dev.java.net/ ?
Is there some other "most up to date" URL to use for Seven?
Harvester
https://harvester.dev.java.net/
Is this still active, and has the latest code been published
somewhere?
Others?
CruiseControl has a fairly decent size user base, and I'd really
like to find a way to remove (or at least hide) my "worst practices"
Jini code (and also of course, make the system more stable,
scalable, etc.) ;) Right now, only the "build agents" are
distributed across the network via Jini, but ideally, we'd like to
have every node be able to handle all tasks (bootstrapping,
scheduling, building, publishing, etc). I think a container
framework is the best way to make this happen, and with such a
framework in place, we could then do things like replace the build
queue with a javaspace, etc, but that's step 203 of 5,000. Other
suggestions are also welcome.
Thanks!
Dan Rollo
