Greetings,
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.
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?
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.
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?)
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?
--Sam Kass
Systems Engineer, Command Post Of the Future
General Dynamics C4 Systems
