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. 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. 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. Best Regards, Tim Ward OSGi IoT Expert Group Chair tim.w...@paremus.com > On 1 Aug 2016, at 09:40, list+org.o...@io7m.com wrote: > > Hi! > > Responses inline. > > On 2016-08-01T00:08:11 +0100 > Neil Bartlett <njbartl...@gmail.com> wrote: >> >> Be aware that this level of sandboxing will require you to enable Java 2 >> Security, which adds a performance overhead to any application. Since this >> is a game, you might not want to pay that penalty. Why do you need this… >> what’s the worst that could happen? > > The overhead in JDK 9 seems to be roughly 4-5%: > > https://www.youtube.com/watch?v=8W_8Vp6IVE0#t=38m15s > > I think I can probably live with that (I'm more likely to be GPU > and I/O bound than I am CPU-bound). > > The reason for sandboxing is really the same reason for sandboxing > anywhere: People running the game will be running third party > modifications that are likely totally untrustworthy. The worst that can > happen is that someone slips some hostile code into a modification that > installs malware, trashes the user's files, etc. I'm not sure anyone has > demonstrated a JVM sandbox escape that doesn't require some level of > elevated privileges (such as overriding serialization, accessing > private members via reflection, loading native code, or subverting > access checks), so I feel like enabling security with an empty set of > permissions is the right thing to do. > >> It’s “normal" to deliver your whole application as bundles. What’s sauce for >> the goose is sauce for the gander. Of course you can write your application >> outside OSGi and only use OSGi for the “external plugins”, but why would you >> do this? > > At this point, I'm not sure why I would or why I wouldn't. I guess it > comes down to how much of a pain OSGi turns out to be to develop > against. It has a good reputation, so I'm optimistic. I suspect the > idea to use OSGi only for the plugins is rooted in the idea that if > OSGi turns out to be bad, I've not tied the entire application to it > and can simply replace the parts that use it. > >> Also you don’t really need to interact with the OSGi APIs, either in the >> core application or the plugins. You will need to touch OSGi APIs in >> management or “plumbing” code, e.g. where you need to download, install or >> update plugins… but aside from that, you should avoid them as much as >> possible. Use the Declarative Services annotations to write your code as >> Components with injected dependencies. > > Right. I think the service APIs were the main issue so if they can be > avoided via annotations, then that seems good. > >>> Is there a common way to engineer >>> libraries such that they can use if available but not actually require >>> OSGi services to work? >> >> Yes. If you write Components with Declarative Services, they only depend on >> the annotation library at build time and will still be compatible with a >> non-OSGi runtime. You can hide dynamics from them by using the static policy >> for references. >> > > I've not heard of the "static policy for references". Is there > something I should be looking at specifically? > > M > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
