Hello Sam,

On May 23, 2008, at 21:08 , Kass, Samuel-P58051 wrote:

        I'm investigating converting our large codebase to a modular
system.  However, one of the requirements is the ability to run as an
applet or webstart application. In addition, some of our customers are
extremely security-concious and prefer to limit us to the most
restrictive possible Java security settings.

Would these restrictions then apply to the OSGi framework implementation itself or the bundles that are deployed inside the framework? I mean your users probably trust the Java Virtual Machine, so where exactly does their trust end?

If you want to run the bundles in secure sandboxes, you can run the OSGi framework with security. See the Conditional Permission Admin part of the spec for more information on what this brings you. In short, you can create security policies for each individual bundle.

        All the advice I've found so far says that OSGi, and Felix in
particular, can be used for applets or webstart as long as they are
signed and given full permissions. My question is how far can we crank
the permissions back and still have Felix work?  What permissions
specifically does Felix require to do its job?

Off the top of my head, classloading, file permissions on the bundle cache.

        I assume the ability to create a new classloader is at the top
of the list. 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.  Classpath protection of depedencies and versions would become
non-existent, as would the dynamicity of OSGi, but it would even allow a
single OSGi codebase to-- with extreme care-- be packaged into an
unsigned applet.

That could be done. You might actually be able to feed all bundle activators to the system bundle to have everything running as extensions of the system bundle. That will probably still require some changes to eliminate all use of classloaders though.

Something similar, although a bit different, is currently being discussed within the SIP Communicator community (they're also using Apache Felix). They are trying to make their application run as an applet and have all persistence on the server.

        In addition, I've noted that Felix likes to make caches of the
plugins it sees on the local file system. Is that a real requirement of
Felix, or just an optimization?  (Does it need local filesystem access
at a fundamental level?)

Caching the bundles and their state actually is a requirement of the OSGi spec, which basically says that if a frameworked is stopped and started again, all bundles should still be there and in the same state as when you stopped the framework. Of course you could deviate from the spec here...

        Since much of our codebase is in the form of a re-usable engine
that is shared from server to applet, without this possibility pushing
OSGi into our core codebase is an extremely hard sell.  Thoughts?

If your codebase is modular, then it should not be too hard to use OSGi in such a way that the modules themselves have no knowledge of being bundles. In other words, you can probably make sure your components are POJO's that somehow get their dependencies injected. At Felix we have several utilities (Dependency Manager, Declarative Services and iPOJO) that help you with that. In that case, if you don't need modularity at runtime (when the code runs in an applet) you can simply package the code differently.

Is it true that you sometimes need modularity at runtime, being able to install or upgrade certain modules without bringing down the whole system, whilst sometimes you don't need it (in an applet)?

Greetings, Marcel

PS: I just saw that Karl replied to your message too, so there might be some overlap :)

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to