You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by "Kass, Samuel-P58051" <Sa...@gdc4s.com> on 2008/05/23 21:08:57 UTC
Java Sandbox and OSGi
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
RE: Java Sandbox and OSGi
Posted by "Kass, Samuel-P58051" <Sa...@gdc4s.com>.
> -----Original Message-----
> From: Karl Pauls [mailto:karlpauls@gmail.com]
> Sent: Friday, May 23, 2008 4:26 PM
> To: users@felix.apache.org
> Subject: Re: Java Sandbox and OSGi
>
> OSGi assumes that the framework is given AllPermission.
> Sandboxing of bundles is done using OSGi specific management services.
Just to clarify, you're saying that OSGi assumes AllPermission, and not
just Felix? That it's actually required by any OSGi implementation to
have it?
> > 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.
The goal is to be able to use the same code on an enterprise/desktop
deployment, then still be able to use our back-end engine in an applet
when need be (and if the user is very careful). See the text at the end
of my reply to Marcel about what I want to get out of OSGi. In this
case I'd like to be able to develop the thing in full OSGi then at build
time have the ability to work through any version and packaging
incompatibilities with a no-classloader/no-filesystem implementation and
package it all up into an applet for specific use cases.
> 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).
Well, our "typical" deployment is a full desktop install with
AllPermissions. However, some customers occasionally require unsigned
applet or similar deployments. If I push OSGi into the engine and start
depending on OSGi APIs (BundleActivators, Dynamic Services, ConfigAdmin,
etc), then do I completely lose the ability to re-use that code in an
applet ever again?
--Sam Kass
Systems Engineer, Command Post Of the Future
General Dynamics C4 Systems
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Java Sandbox and OSGi
Posted by Karl Pauls <ka...@gmail.com>.
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
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Java Sandbox and OSGi
Posted by Marcel Offermans <ma...@luminis.nl>.
On May 27, 2008, at 21:10 , Kass, Samuel-P58051 wrote:
>>> 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.
In general, when running in some kind of container, there is some kind
of interface from the component to the container. Obviously for OSGi
this is the BundleContext. You mainly use it to register and lookup
services. This context should only be used in the activator, and if
you don't run your POJO in OSGi, you should loose the activator
completely.
That means that if you have a POJO that depends on some other
services, you need some way to externally "inject" them. That would
again be code you'd have to write yourself when outside of OSGi but it
could be as simple as using invoking a setter on your POJO. You might
need to build a very simple service registry yourself (maybe as simple
as a Map<String, Object> if you don't need services with the same name
but different properties and complex filtering that OSGi supports).
> Any other areas where the typical application becomes dependent on
> OSGi
> code and would have to be refactored out? Resource loading comes to
> mind...
As long as you package your resources in your JAR and load them from
it, there should not be any difference between OSGi and non-OSGi usage
there. I might be forgetting something too, but I think we've already
covered the most common things that might need to be done.
>> 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.
If you really need two different versions of the same class or
package, you can always use byte code manipulation (after compilation)
to simply "rename" these two identical packages to have different
names and manipulate the code that uses these packages in the same
way. That way your sourcecode does not need to be changed and this
step can only be done when not using OSGi. However, I would not
recommend doing that unless you really need to. :)
Greetings, Marcel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: Java Sandbox and OSGi
Posted by "Kass, Samuel-P58051" <Sa...@gdc4s.com>.
> -----Original Message-----
> From: Marcel Offermans [mailto:marcel.offermans@luminis.nl]
> Sent: Tuesday, May 27, 2008 2:37 PM
> To: users@felix.apache.org
> 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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Java Sandbox and OSGi
Posted by Marcel Offermans <ma...@luminis.nl>.
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
RE: Java Sandbox and OSGi
Posted by "Kass, Samuel-P58051" <Sa...@gdc4s.com>.
> -----Original Message-----
> From: Marcel Offermans [mailto:marcel.offermans@luminis.nl]
> Sent: Friday, May 23, 2008 4:29 PM
> To: users@felix.apache.org
> Subject: Re: Java Sandbox and OSGi
>
> 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?
The trust ends at the JVM. The OSGi framework implementation and
everything inside it all have to run in the sandbox.
> 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.
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.
> > I assume the ability to create a new classloader is at
> the top of the
> > list. But if even that was restricted,...
> ...
> 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.
> 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...
Whether or not I deviate from the spec, I have other ways to serialize
information over the network... That may be a more significant change to
Felix, though. (Again, I'll check out the "SIP Communicator" thing you
mention.)
>
> > 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.
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.
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? 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.
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.
>
> 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)?
Being able to upgrade and install without bringing down the system is a
"nice to have". What's got me sold on OSGi is the enforcement of loose
coupling between bundles, the ability to deploy capabilities selectively
without having to worry about unknown interdependencies, being able to
explicitly version third-party dependent libs and my compatibility with
them, the ability of third parties to have an explicit mechanism to add
functionality to our system, and its level of maturity and community
support above other similar solutions to these problems. Being able to
stop, load, and unload at runtime is a minor feature addition to me,
that if it were omitted would barely affect my desire to go with OSGi.
--Sam Kass
Systems Engineer, Command Post Of the Future (CPOF)
General Dynamics C4 Systems
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Java Sandbox and OSGi
Posted by Marcel Offermans <ma...@luminis.nl>.
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org