On Wed, Nov 16, 2016 at 8:43 PM, "Michał Kłeczek (XPro Sp. z o. o.)" < michal.klec...@xpro.biz> wrote:
> 3. My comment about OSGi being "non-deterministic" in resolving dependencies means that the > same bundle installed in two different environments is going to be linked with different dependent > bundles. It basically means the same object graph valid in one VM instance cannot be deserialized > in another VM instance unless: Well, technically speaking this is true in standard Jini classloading approach as well, since you have no control of which classes are being used from parent classloaders. > a) all bundles have their dependencies specified in such a way that exact same dependency graph > is going to be present everywhere (meaning no Package-Imports, no version ranges etc) This is incorrect. You can narrow his down with additional constraints (typically package attributes). Not very well-known feature, but completely possible, and whether you want version ranges or not, is up to you. Again, traditional RMI can be set up to either use versioned or non-versioned classes, in the dynamic loading part. I don't see much of a difference. (Sorry, I can't comment on JBoss Modules as I have no experience) > b) all JVMs have the same set of bundles installed (ie - there is no dynamic code downloading at all > - the code is preloaded) I never worked with Paremus implementation, but I vaguely recall Richard explaining that dynamically loaded bundles would be garbage collected when not needed anymore. Sounds like dynamic code downloading to me. > c) classes of serialized objects are not loaded by OSGi framework class loaders but by other > non-related class loading framework (which is what original old OSGi-Jini spec did) Well, that spec was dropped in OSGi Release 4 because it could not deal with multiple versions of classes, that Release 4 introduced. The bundle would both require DynamicImport-Package, as well as have no means to export "new" functionality discovered, which is why I think it was dropped (I wasn't privvy of the discussion back then) > d) classes of all objects in the object graph are from the same bundle (special case of a) ) Yes, but not in itself a requirement per se. > In general all efforts I am aware of regarding "remoting" in Java didn't really even try to solve issues of > dynamically downloaded code. They were based on all parties having the same code installed and/or > having a central authority providing a shared consistent view of all available software. Yes, I agree. It is an age old issue with any remoting technology, and I think the main reason Jini didn't succeed (except for awkward initial licensing) was that people were weary of "Java only" solutions, effectively making Java a virus. ;-) > I am not saying it is wrong. I am only saying that IMHO it is not something River should do - > it is simply a solved problem and there is not point of re-doing it (JERI is cool but it is simply yet- > another-RPC-stack) JERI is cool because it tries to preserve security contexts. Yes, security is seldom used in Java applications, mainly because we think we trust all the code that is running. I think this assumption is slowly eroding away, as we rely more and more on third-party code, which we can't vet in full to see what is going on. Usage of containers is effectively taking a similar stance at a lower level. > Regarding JBoss Modules: > I am not really advocating this particular library - it is just that it is the only (non-OSGi - see above :) ) > implementation of non-hierarchical class loading that I am aware of which is of good quality and > actively maintained. I wouldn't want to reimplement it by myself. Thought about ClassWorlds but it > doesn't seem to be too active and had some performance problems in the past. JBoss Modules > is Apache licensed so it can be used by River. The only thing I see in the quick browse of documentation is that it was intended for loading JARs inside WARs inside EARs, and figure out how to establish a working classloading mechanism inside such a cluster. Maybe I am missing something really important, but it doesn't seem to be particularly oriented towards ensuring the same classes being present (which seems to be your beef with OSGi) in both JVMs. I am not saying that your effort is bad, and I have no problem it being donated to Apache River (or published elsewhere). I am only criticizing your claims about OSGi, which I find to be not true. Cheers -- Niclas Hedhman, Software Developer http://zest.apache.org - New Energy for Java
