Not being a guru of any description I can't help you with the specific OSGi questions, but your post makes me assume a few things about your intentions. Can you clarify, if only for my benefit, please?
> Or does the JERI Endpoint catch the exception and try to find it itself? The Endpoint finds the service based on identity, it has moved, we must re verify our Trust because the Conditions have changed. This suggests to me, and I've been wrong before so it's no surprise if I am again, that you're starting to couple the OSGi security mechanisms into this custom JERI Endpoint. If that assumption is correct, can you start referring to it as an OSGi Endpoint (which should be able to swap between JERI and JRMP, maybe)? Or a Secure JERI Endpoint that is configured to use the OSGi security mechanism although another, as yet unspecified one, could be swapped in instead (which means hiding the OSGi stuff behind a common interface). I've been involved with wrapping proxies to provide auto-discovery behaviour before and it works very well. The business code only ever gets RemoteExceptions when a service really can't be found which means a lot less "wait-and-retry" boilerplate code has to be written. Barring someone categorically declaring that the EndPoint is the Wrong Place to do it because the Jini spec says "xyz", it's probably just a matter of taste which approach is the 'right' one. Personally speaking, it doesn't "seem" like it's the EndPoint's job to go away and find a replacement for a broken/missing service, as far as I'm aware no other EndPoint does that (again, I'm happy to be corrected). If you do this, do you now call it a Service Refinding Secure JERI EndPoint? Which makes it sound like the one area of code is now doing a lot of different jobs... Sorry I can't help with the OSGi specific questions. Tom On Thu, Feb 4, 2010 at 6:23 AM, Peter Firmstone <[email protected]> wrote: > I want to load Marshalled Objects from different locations with identical > bytecode into the same ClassLoader, I want to do this using codebase > services and OSGi, which gives me another level of indirection and a richer > security model with Condition's > > PermissionDomain has a 1:1 relationship with ClassLoader > > Trust Verifiication. > > Identity and Authentication. > > What distinguishes different services (from different remote locations and > domains) utilising the same ClassLoader, PermissionDomain and bytecode? > > Principals. > > I wonder if Conditions can apply to Principals? Such that when a proxy has > lost connection with its service node, the Condition denies a Principal > relating to that proxy any Permission, until the Service can be asked to > verify it's proxy again? I was thinking that the proxy itself doesn't > attempt to find its lost service, instead that would be done by a new JERI > Endpoint implementation, to do that the Endpoint needs to know the Service's > Identity. > > Any OSGi guru's out there? > > So we have Permissions being granted at different levels and we have > Conditions that make those Permissions Dynamic: > > Principal - Can I trust the service? Can I grant it a Permission? What > are the current Conditions? > PermissionDomain & ClassLoader - relates to the Code Signer (which may be > different to the Service Principal). Do I trust the bytecode? If I do, the > bundle tells me the Permissions required to execute that bytecode. > > Lets imagine for a moment, were happily using a Service, and suddenly it > throws a RemoteException, after some a wait period, we retry, the service > hasn't returned, so do we ask the JERI Endpoint to find the service? Or > does the JERI Endpoint catch the exception and try to find it itself? The > Endpoint finds the service based on identity, it has moved, we must re > verify our Trust because the Conditions have changed. So now we must catch > a Permission denied exception, and go through the re-verification process. > > Does Bob Scheifler still watch the list? Anyone know where I can find Bob? > >
