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]