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 <[EMAIL PROTECTED]>: > On Thu, Dec 11, 2008 at 12:13 AM, Gregg Wonderly <[EMAIL PROTECTED]> 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 >
