> -----Original Message-----
> From: Karl Pauls [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 23, 2008 4:26 PM
> To: [email protected]
> Subject: Re: Java Sandbox and OSGi
>
> OSGi assumes that the framework is given AllPermission.
> Sandboxing of bundles is done using OSGi specific management services.
Just to clarify, you're saying that OSGi assumes AllPermission, and not
just Felix? That it's actually required by any OSGi implementation to
have it?
> > But if even that was restricted, it's been suggested to me
> that a real
> > expert at OSGi could theoretically create a distribution of
> Felix that
> > could package into a single large jar all the classes and resources
> > required by an OSGi configuration, and call the load/start (but not
> > unload) lifecycle calls and make the service discovery still work.
>
> Not impossible but it would really be nothing like OSGi
> anymore. One could probably reuse some classes like the ldap
> filter, manifest parser, service registry, etc. but it would
> need to be a new kind of framework I guess.
The goal is to be able to use the same code on an enterprise/desktop
deployment, then still be able to use our back-end engine in an applet
when need be (and if the user is very careful). See the text at the end
of my reply to Marcel about what I want to get out of OSGi. In this
case I'd like to be able to develop the thing in full OSGi then at build
time have the ability to work through any version and packaging
incompatibilities with a no-classloader/no-filesystem implementation and
package it all up into an applet for specific use cases.
> I guess the question for me is, what features/benefits are
> you hoping to get from using OSGi in your codebase? It should
> be possible to boil down the required permissions depending
> of what it is you actually hope to achieve. An in-memory
> cache would prevent the need for file permissions at the cost
> of no native library support and many available bundle not
> working, disabling URLHandlers and extension bundle support
> gets you down to mostly classloader permission plus some
> property access permissions. Without classloader however, you
> really end-up with something where it probably is easiest to
> create your own solution (maybe based on some felix classes).
Well, our "typical" deployment is a full desktop install with
AllPermissions. However, some customers occasionally require unsigned
applet or similar deployments. If I push OSGi into the engine and start
depending on OSGi APIs (BundleActivators, Dynamic Services, ConfigAdmin,
etc), then do I completely lose the ability to re-use that code in an
applet ever again?
--Sam Kass
Systems Engineer, Command Post Of the Future
General Dynamics C4 Systems
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
