river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michał Kłeczek (XPro Sp. z o. o.)" <michal.klec...@xpro.biz>
Subject Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy
Date Mon, 13 Feb 2017 14:04:48 GMT
Nope - not at all. I am only trying to convince you that there is no 
reason to involve ServiceRegistrar or SDM for code downloading.

HOW the class resolution is done - is another story.
I actually tend to think in a similar way to what Niclas said:
Do not use OSGi to load proxy class - create a separate ClassLoader - 
but make sure it delegates to the client bundle ClassLoader for
non-preferred classes.

Thanks,
Michal

Peter wrote:
> I changed it to highlite Nic's point that it's not feasible to resolve and provision
osgi bundle transitive dependencies during deserialization because the time taken to do that
can be excessive due to NP Complete nature of resolution.
>
> It is incompatible with stream codebase annotations.
>
> I think Mic's currently arguing for a solution that relies on resolution and provisioning
to occur during deserialization and I'm arguing against it.
>
> I'm arguing for a background task that preceeds deserialization of the proxy.
>
> Regards,
>
> Peter.
>
> Sent from my Samsung device.
>   
>    Include original message
> ---- Original message ----
> From: Patricia Shanahan<pats@acm.org>
> Sent: 13/02/2017 11:27:27 pm
> To: dev@river.apache.org
> Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy
>
> Sorry, I'm trying to find out the meaning of the current subject line. 
> I'm not sure when it changed to "OSGi MP Complete".
>
> On 2/12/2017 10:50 PM, Michał Kłeczek wrote:
>>   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 really, really difficult?
>>>
>
>


Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message