river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <...@dcrdev.demon.co.uk>
Subject Re: Split JavaSpaces and JINI
Date Sat, 20 Dec 2008 16:39:59 GMT
Niclas Hedhman wrote:
> On Sat, Dec 20, 2008 at 6:21 PM, Dan Creswell <dan@dcrdev.demon.co.uk> wrote:
>>> I am NOT your regular newbie; I adopted Jini 1.0/1.1 in a critical
>> Alas, some of what you're saying suggests otherwise - sorry if that's
>> hurtful but see my comments above re: remote vs local.  Perhaps you do
>> understand this stuff and we're just having a communication problem owing
>> to words used?
> I agree that I am newbie to Jini 2.x, no doubt. But I think it is
> largely a communication problem.
> My *biggest* issue is that Jini is not test-friendly one single bit.
> On top of that, it is not friendly to integrate Jini into other
> open-development projects.
> But when I speak of an in-JVM entry point, I mean many things, but NOT
> abandoning the network-centric view of Jini;
>  * In-JVM implementations that are easy to deploy, don't involve
> network interfaces (which opens a can of testing issues), and possibly
> even have the capability to simulate various network failures.
>  * I think I understand the Remove Event specification, and why
> RemoteListener exists. That does NOT prevent the client listener to
> the space to be a local interface with a semantic-centric meaning. It
> simply builds on the spirit of the local smart proxy, that I think is
> probably the best thing with Jini.
>  * A lot of discussion has been revolving around an in-JVM JavaSpaces
> implementation. I don't agree with McGrady's viewpoint other than that
> I think there should exist one, and that is a drop-in replacement
> (i.e. no client changes needed). I do think that promoting the
> JavaSpaces programming model, in combination of both many
> implementations, from the simplest to the most extreme, is a good
> 'portal' to increase users of River technology. And I expect that
> there will be rub-off effects from "In-JVM JavaSpaces" to full-fledged
> Jini technology.
>>>  *  "Jini is an 'all-or-nothing' commitment.", which requires
>>> decisions higher up in the organization, instead of developers. Such
>>> strategic decisions are made at the golf course or over a $1000
>>> dinner. We must provide in-JVM entry points and ride well inside
>> Sure, provide local entry points but don't think for a second you won't
>> have to change the code when you go remote.
> I somewhat disagree. If you present a programming model with
> "NonAvailability" and "CallFailures", many programmers can code
> against such semantic model. Even more so, if it is reliably testable
> (which the network setup barely can provide).
> Now, my experience with Jini 1.x, resulted in a drastic change in the
> view of how to write the application as a result, since failure on
> every single method call is just too much to deal with. Instead, more
> events and workers. But, I kept that style of programming years after
> I stopped using Jini actively, because it often made sense.
>> That assumes that the containers in question actually have a permissive
>> environment.  Most don't - I know this as I've had to build a new
>> classloader model this week to work around JBoss's classloader mess that
>> doesn't allow multiple versions of code to co-habit at all well.  This
>> same kind of issue makes Jini integration hard.
> Bingo!
> Everybody that messes with classloaders will of course blame the other
> party that an integration doesn't work. Jini is no exception, of
> course it is the other party.

It's not blame - it's technical fact.

If I need to download a bunch of different packages and they aren't all
aligned on dependencies - e.g. one has commons-logging-1.5 and another
1.4 then I need to get them all into separate classloaders otherwise one
gets leaks and classcast exceptions.

Mike Warres a while back wrote some stuff on how we might take next
steps but solving it in a container (at least if you wish to retain all
the Jini goodness) requires the container be equally flexible in it's
classloading model. In Tomcat's case there has been some work to get
Jini up and running (courtesy of Ron Mann) but it's still a workaround
to paste over the fundamentally different approaches Jini has versus
most containers.

> Perhaps the 'vision' of JiniNextLevel is all about better integration
> especially in terms of classloading (which I must say accounts for a
> fair bit of problems in many cases). I have previously promoted
> embracing OSGi as the classloading model used, but that went pretty
> much on deaf ears before. I still think it makes sense, but won't put
> up a fight over it again, and probably doesn't solve container
> integration for now.

OSGI has a classloader model similar to Jini's (highly granular and
compartmentalized, possibly better documented as well) and one might
indeed manage a port to that model but any container that doesn't do
OSGI will still not work right.  I have seen similar approaches to Ron
Mann's to solve this OSGI/Container integration problem via a bridge
servlet.  So I guess if you ported Jini to that model you could save
yourself a package (Ron's) but that's about it.

> So, Dan, you have my utmost respect, and I am not here to diminish,
> destroy or ridicule your and others excellent efforts over the years.
> On the contrary... If we don't act within the next 6-12 months, I fear
> that River incubation will be over, the shop closed and no strength
> left to move it elsewhere, and Jini will fade away on the pages of the
> history books. All that effort going nowhere sounds like a stupid
> idea.

+1 on that and understood.

> One more thing;
> A very common "theme" is;
>  X: "I want to ..."
>  Y: "Well, that is not built-in, but take a look at ..."
> I guess that is actually a VERY GOOD thing. I can start with something
> higher up the technology stack. BUT the bad thing is; I now have 30
> different projects to contend with, and only the effort to figure out
> what could be useful, where is it, and how it would fit into a bigger
> picture will take too much of my time and I'll leave before starting.
> So, I would like to propose that many of these useful projects are
> brought into River, unified into a single source of "Good Stuff". It
> would create a better 'view' to the world what River is all about.
> Perhaps we should even promote the higher layers primarily, and Jini
> Core becomes an underlying component that people don't need to know
> the details about. Does anyone have a comprehensive list of projects
> (and a short description) that are candidates for this?
> I think I will spend a few more cycles on coding over the holidays,
> and see if I can create myself a proposal to changes...
> Cheers
> Niclas

View raw message