river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Calum Shaw-Mackay" <calum.shawmac...@gmail.com>
Subject Re: Split JavaSpaces and JINI
Date Thu, 11 Dec 2008 08:31:31 GMT
I am quite open as to how we may build a lightweight test
infrastructure for Unit testing, and scripting service interactions -
perhaps this is somewhere we can make a start?

Thanks

Calum

2008/12/11 Niclas Hedhman <niclas@hedhman.org>:
> On Thu, Dec 11, 2008 at 12:13 AM, Gregg Wonderly <gergg@cox.net> wrote:
>
>> Help me understand please!
>>
>> import net.jini.core.transaction.Transaction;
>
> ^^^^ HERE ^^^^
>
> JavaSpaces depends on Transaction. Perhaps you think it is rudimentary
> simple to implement a Transaction system that are semantically
> accurate with the Jini Transaction Specification at in-JVM level.
>
>> import net.jini.core.lease.Lease;
>
> ^^^^ HERE ^^^^
>
> Leases are a good thing. But again, without a light-weight
> implementation, it makes my day miserable.
>
>
>> import net.jini.core.event.RemoteEventListener;
>
> ^^^^ HERE ^^^^
>
> This is probably controversial; Jini's use of local smart proxies is
> brilliant, so why is not this fact used much more in the
> specifications. Why are network protocol details shining through
> everywhere? The notify() method should (of course? obviously not) take
> a SpaceListener at the local interface level, and use the
> RemoteEventListener hidden on remote interface.


There is a point here about whether the detail is about network
protocol (specific case)
or use of the network (the more general case) - there is no doubt that
a class hierarchy
of interfaces (SpaceListener being an example) could be constructed
from REL. The main issue
is that the developer is gently nudged to appreciate ( i thought
forced was a little too strong) that a network may be involved,
hence the name _Remote_EventListener and the inclusion of
RemoteException on these interfaces. That being said
there is no reason why you couldn't have (and this may be even more
controversial) SpaceListener methods
throwing SpaceException which are constructed from RemoteExceptions
caught inside the smart proxy. or SpaceException
from RemoteException

>
> Sorry to say Gregg (and others), I am getting really frustrated with
> the "There is nothing wrong!" attitude from 'old timers', when clearly
> the most clever technology have been unable to conquer every Java
> developer's mind and toolkit, and having had 8-10 years to do so.
> I am NOT your regular newbie; I adopted Jini 1.0/1.1 in a critical
> application in 2001, where we ran both clients, servers and 'device
> drivers' both locally and across the Internet with full blown Jini
> infrastructure. At that time, it was 'somewhat painful' to get things
> operational. When I now return (as a complete 2.x newbie), I notice
> that things are still hard, perhaps even harder. Meanwhile (6 years!),
> I have gone from a heavy and slow development process, to do things
> much, much more light-weight and test driven. And when I now try to
> integrate Jini into an open source framework I am working on, it gives
> me more pain than I could imagine, mostly due to how hard it is to get
> tests working. Sorry, but the whole Jini "setup mentality" is just
> wrong.


> Calum; Stuff like Glyph --> Excellent, things in the right direction,
> but it doesn't solve the underlying problems;
>
>  *  "It is HARD to use Jini and/or Spaces in other projects". Maven
> artifacts are becoming the preferred choice by many. How do we meet
> that? How can I Jini enable (for instance with Glyph) and still test
> that it works in a Jini environment, and not only relying on Calum
> saying "Don't worry, it will!".
>
>  * "Jini HAS FAILED to capture the developers' minds.", and I don't
> care how much people here will jump up and down claiming that that is
> not true.
>
>  *  "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
> Tomcat and other containers, without requiring changes to neither the
> JVM nor the container. Such feature should be advertised up-front and
> not something one needs to go digging for whether it is at all
> possible.
>
> Well, I will stop arguing about what I think is wrong, and just go out
> and make the changes I think is necessary. And funny enough, it is not
> that much that needs to be changed. If I am not welcome to do so that
> here at River, then fine, I bring the codebase elsewhere.
>
>
> Cheers
> Niclas
>

Mime
View raw message