> -----Original Message-----
> From: Marcel Offermans [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 27, 2008 2:37 PM
> To: [email protected]
> Subject: Re: Java Sandbox and OSGi
>
> > 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.
No, not me, but the General Dynamics customer in question is, well,
quite large and the organization has one of the larger budgets on the
planet. Java happens to be one of their supported platforms, and
they've reviewed it enough to feel comfortable that on top of everything
else they've got protecting the system, the Java applet sandbox is
secure enough. Maybe someday OSGi will be part of their supported
configuration. I hope so.
> 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.
I understand that the environment I'll be running in when packaged as an
applet will definitely not be OSGi spec-compliant. I'm looking for my
core library code, though, to (as I termed it in my reply) degrade
gracefully such that I can still use the same codebase and statically
link it all together in this limited deployment. So for applets we'll
be no worse off than we are today, but we can use the strength of OSGi
for our much more typical desktop deployment and use the same codebase
where possible for both.
> > 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.
That sounds reasonable...
>
> > 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.
That sounds a little annoying but reasonable :)... I think the thing
that would be the hardest to "fake" here is the Bundle/BundleContext
that might be used by activator code.
Any other areas where the typical application becomes dependent on OSGi
code and would have to be refactored out? Resource loading comes to
mind...
>
> > 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).
I agree... And since we're already in that world today, we already have
had to deconflict all our dependencies to use the same version. While
I'd like to lift that restriction for application code, I can suggest
that rule be maintained for the core engine so it could be used in this
fashion.
--Sam Kass
Systems Engineer, Command Post Of the Future
General Dynamics C4 Systems
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
