[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] OSGi for Server-side...
- From: Niclas Hedhman <niclas@xxxxxxxxxxx>
- Date: Wed, 26 Oct 2005 10:22:33 +0800
- Delivered-to: firstname.lastname@example.org
- Organization: Independent
- User-agent: KMail/1.8
On Tuesday 25 October 2005 21:46, Thomas Watson wrote:
> Yes collaboration is good here. I have spent time discussing this problem
> and possible solutions with Richard Hall. The current solution Richard
> is implementing in Felix is likely the best we can do for this situation.
> Unfortunately the solutions is pretty complex and I would definitely only
> want to enable it if more than one framework is running in the VM.
Yes, I know. And that is essentially not good enough. Having a
cross-application generic mechanism, decoupled from both OSGi implementations
and OSGi itself, would be sweet.
IMHO, the "per bundle" URLStreamHandler is probably overkill, considering the
complexity impact and the performance impact. However, I am aware of
potential conflicts for "context-aware" URL handlers, such as bundle://.
> Here are the technical difficulties:
Yep, I realize those as well :o) Just didn't want to dwell on it.
> - Moving the FrameworkSecurityManager out of the core framework. This has
> issues because it uses some core OSGi interfaces
> (e.g. org.osgi.service.condpermadmin.Condition). These classes would also
> have to be separated from the framework. This is not good situation IMO.
IMHO, a delegation model works here. The command-line SM [A] and the Equinox
SM [B] are two different classes, where [A] is aware that ProtectDomains can
be tagged with a context, and [A] delegates down to [B] of such context.
I think such model can solve the multiple-OSGi issue in respect of security as
> The only reason a "special" FrameworkSecurityManager is needed is to
> process postponed conditions correctly. In Equinox we detect this
> situation and treat all postponed conditions as non-postponed conditions
> if the SecurityManager is not our own "special" implementation. What
> we have to decide is if we care about postponed conditions in the
> scenarios we are trying to run in.
I don't know what "postponed conditions" means... :o(