You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Dan Rollo <da...@gmail.com> on 2008/11/30 21:41:29 UTC
Jini Service Container advice...
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
Re: Jini Service Container advice...
Posted by Greg Trasuk <tr...@stratuscom.com>.
On Sun, 2008-11-30 at 15:41, Dan Rollo wrote:
> Hi All,
>
<snip/>
> Harvester
> https://harvester.dev.java.net/
> Is this still active, and has the latest code been published somewhere?
>
Harvester is in active development and use, but aside from being busy
I've been more-or-less waiting for AR2 to do a switch to River and
publish the latest sources. I'd be happy to talk to you off-list about
moving that forward to integrate with DistCC's needs.
Cheers,
Greg.
>
> Thanks!
> Dan Rollo
--
Greg Trasuk, President
StratusCom Manufacturing Systems Inc. - We use information technology to
solve business problems on your plant floor.
http://stratuscom.com
Re: Jini Service Container advice...
Posted by Mark Brouwer <ma...@marbro.org>.
Hi Dan,
Dan Rollo wrote:
> Seven
> http://www.cheiron.org
> This link appears broken. Is it replaced by:
A while ago the new management of Virgil, the owner of the domain
cheiron.org and the copyright holder, removed the DNS entries for the
Cheiron project after the last committer left the company. By adding the
entries below to your host file you can get to the Cheiron site:
62.177.181.217 www.cheiron.org scm.cheiron.org issue.cheiron.org
I hope to resolve some issues with Virgil so they will restore the DNS
entries, or I will have to move Cheiron to another location, but my
problem is that I'm lacking time for that.
Seven is still being used by commercial companies and supported by me,
either the free support that comes with the open source project or on a
commercial basis when I do projects with it. If you have question please
mail me at mark.brouwer@marbro.org because the cheiron.org addresses
were removed as well.
Regards,
--
Mark Brouwer
Re: Jini Service Container advice...
Posted by Dennis Reedy <de...@gmail.com>.
Hi Dan,
On Nov 30, 2008, at 341PM, 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...
The Rio download should not be confused with the Rio distribution
requirements, it depends on what you need. Rio comes bundled with
optional third party technologies that you may not need (take a look
at the third party technologies document in the lib directory for
details on the bundled technologies , their use and licenses). For
example if you dont want Spring and it's required commons jars they
can be removed, junit does not need to be included, tools jars for
classdepandjar, etc...
Let me know if this helps or if you need more clarification. Feel free
to send mail to users@rio.dev.java.net if you need any assistance, or
feel free to contact me directly.
Regards
Dennis
Re: Jini Service Container advice...
Posted by Patrick Wright <pd...@gmail.com>.
Hi Dan
We're using Bantam (https://bantam.dev.java.net/), which hosts Jini
services inside standard Web containers, allowing deployment via
exploded or unexploded WARs. You can host multiple services inside a
WAR, can configure services via Spring if you like (we do), and it
includes (optional) annotations to lower the effort of declaring
services for export.
Regards
Patrick
> While searching for such "Jini Service Containers", I have a few questions
> about what might be the best fit:
Re: Jini Service Container advice...
Posted by Calum Shaw-Mackay <ca...@gmail.com>.
Neon can host Jini services..... well it turns agents into Jini services
2008/11/30 Dan Rollo <da...@gmail.com>:
> 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
>
Re: Jini Service Container advice...
Posted by richard nicholson <ri...@paremus.com>.
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