Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

2017-02-12 Thread Peter
Also see the OSGi Enterprise specification, v6, Chapter 136, page 691, there's some discussion about the NP-complete nature of dependency resolution there as well. https://www.osgi.org/developer/downloads/release-6/release-6-download/ On 13/02/2017 5:19 PM, Peter wrote: OSGi Dependency resolu

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

2017-02-12 Thread Peter
OSGi Dependency resolution is. http://underlap.blogspot.com.au/2010/02/osgi-resolution-is-np-complete-so-what.html Which means if we want to support an OSGi environment properly, we may need some time to resolve the dependencies for a smart proxy, before deserializing the proxy, rather than do

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

2017-02-12 Thread Michał Kłeczek
Sorry, NP Completness of what? I have been the first to mention NP hardness of constraint satisfaction problem but I am not sure if this is what you are asking about. Thanks, Michal Patricia Shanahan wrote: Are you literally claiming NP Completeness, or just using that as an analogy for reall

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

2017-02-12 Thread Patricia Shanahan
Are you literally claiming NP Completeness, or just using that as an analogy for really, really difficult? On 2/11/2017 1:23 PM, Michał Kłeczek wrote: I am sorry but I think that to solve various issues we need to make sure fundamentals are right: 1. There is NO such a thing as "reflective non

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

2017-02-12 Thread Peter
  Interestingly ServiceCodebaseAccessor.getClassAnnotation() could be modified to accept a string parameter.  This would allow different smart proxy codebases to be provisioned for different environments. By provisioning and deserializing into the ClassLoader for the provisioned codebase,  a se