On May 27, 2008, at 19:39 , Kass, Samuel-P58051 wrote:
the framework? I mean your users probably trust the Java
Virtual Machine, so where exactly does their trust end?
The trust ends at the JVM. The OSGi framework implementation and
everything inside it all have to run in the sandbox.
Ok.
I was hoping that OSGi could integrate a little better with existing
Java methodology. Since the OSGi framework implementation(s) would
need
extensive security reviews, but the JVM has already had such a review,
it's not really viable to switch to OSGi security anytime soon.
You mean you actually reviewed the JVM plus all libraries? That sounds
like a really big task. In that case reviewing an actual OSGi
framework implementation might not be that much work, since it's much
smaller.
Anyway, if that's not an option, then you probably cannot use OSGi
since it definitely needs *some* permissions at runtime, meaning it
would probably need a review because of that.
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.
I'll check out the SIP Communicator stuff, thanks. It sounds like
they're attempting something fairly similar.
Ok. As far as I know, they are just talking about it at the moment
though.
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.
The latter sounds like the approach I was thinking of. I would
definitely want to use all the OSGi goodness of enforced versioning
and
encapsulation when our engine is used in an enterprise setting. But
I'd
like to be able to take the same back-end code and stuff it all into a
jar and run it as an applet. I'm concerned if I start using OSGi
services to implement inter-module communication that my core engine
will start to depend on being written on top of an OSGi framework
implementation, and it will lose the ability to support applet
development.
That's a valid concern, but on a "service by service" base I think it
can be resolved.
For example, if I wanted to replace our command-line arguments and XML
settings files with some usage of ConfigAdmin to configure code, I'll
need to run on a system that understands ConfigAdmin, right?
CA configures instances that publish themselves as ManagedService. If
you have a POJO that needs configuration, you can have it implement
that interface (which you can treat as a "normal" Java interface) and
create some code that invokes the update() method in that interface
yourself (that would be the code that parses the command line and/or
reads the XML). If you don't even want to depend on an interface
defined in the OSGi spec you can of course define your own interface.
And if I
want to use an OSGi activator for initialization, I'll need to run
on a
system that calls the start() method of my activators.
For this I would have the activator simply instantiate the POJO and
throw away the whole activator if you don't use OSGi. Then of course
you need a system to instantiate all your POJO's, that's right, so you
might end up mimicking some mechanisms of the OSGi framework.
I guess I'm just asking how to get the power of OSGi when I need it,
but
be able to degrade gracefully into deployments that are too limited
for
OSGi.
Sure, that is an interesting question. Probably some features will be
harder to replicate than others, especially given the constraint that
you basically run in an applet sandbox (those features would be
dynamic updating of code, isolating modules from each other, and
resolving package dependencies, especially if you need to be able to
use different versions of the same package simultaneously). However,
for simpler applications, those features might not be needed at all,
and using OSGi as a way to develop reusable components is still
something worthwhile (in my opinion).
Greetings, Marcel
