'Lo. On 2016-08-01T10:00:37 +0100 Timothy Ward <[email protected]> wrote: > Hi, > > This sounds like an interesting project, and it also sounds like OSGi would > be a really good fit for what you want to achieve. > > The descriptions of static and dynamic policies for DS references are pretty > good in the annotation Javadoc: > > https://osgi.org/javadoc/r6/cmpn/org/osgi/service/component/annotations/ReferencePolicy.html#STATIC > > <https://osgi.org/javadoc/r6/cmpn/org/osgi/service/component/annotations/ReferencePolicy.html#STATIC> > > Essentially a static policy means that everything gets wired together when > it’s available, and destroyed again when it’s not available. This can add > some overhead in systems that are rapidly changing (i.e. services are being > unregistered and registered frequently) but it does make the code a lot > simpler as you never have to worry about services changing underneath you.
Got it! > You may find that some of your core components do want to be a bit more > sophisticated, for example if you want to reference optional services, or all > services with a particular interface, then you will either want a dynamic > policy, or a greedy policy. Right. > > One more thing that you may need to worry about in your sandboxing is how you > deal with modifications that refuse to release the thread(s) that they’ve > asked for when they’re being stopped. At a guess you will need to use at > least some of the OSGi API to track which bundle(s) are not letting go. > Yeah, that's one of the two things for which the standard JVM security mechanisms still don't have a decent answer. The two being heap exhaustion and runaway threads. At least in those cases, the damage is limited to the application itself. M
pgpWKY_0yMdtU.pgp
Description: OpenPGP digital signature
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
