Hi Sam, > I'm investigating converting our large codebase to a modular > system.
Good to hear :-). > However, one of the requirements is the ability to run as an > applet or webstart application. Felix can and is used in both scenarios. > In addition, some of our customers are > extremely security-concious and prefer to limit us to the most > restrictive possible Java security settings. Interesting, did you have a look at the security features of OSGi? If not maybe have a look at some slides: http://felix.apache.org/site/presentations.data/Building%20Secure%20OSGi%20Applications.pdf > 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. OSGi assumes that the framework is given AllPermission. Sandboxing of bundles is done using OSGi specific management services. > 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? Well, we don't maintain a real list but it shouldn't be to bad assuming you turn off URLHandlers and extension bundle support. The biggest issue might be the cache (more below). > I assume the ability to create a new classloader is at the top > of the list. Yes, we need to be able to do that. > 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. > 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. This would depend on your codebase. Most OSGi codebases probably would not work like this because they rely on certain features of OSGi that can not be "emulated" by smart classpath arrangement only. For example, OSGi allows side-by-side package instances of different versions of a package or two bundles can use their private version of the same package -- hence, it would only work if the codebase really uses not much of the OSGi module layer. > 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?) It does for native libraries and embedded jar files. It should be possible to create an in memory cache without to much effort (with the restriction that native libraries wouldn't work). The biggest issue probably is that most bundles assume they have access to a private data area inside the cache. In other words, you might have a hard time to reuse existing bundles without a file based cache but assuming you only use your own bundles than you can get away with an in memory cache. > 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? 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). regards, Karl > --Sam Kass > Systems Engineer, Command Post Of the Future > General Dynamics C4 Systems -- Karl Pauls [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
