Re: Modifying service properties in lifecycle and bind methods

I opened FELIX-5621 about this. I still think returning service properties from event methods cannot be made thread safe. As noted in the issue, I think ExtComponentContext can be used safely with code like: final AtomicReference> propRef; .

Re: Modifying service properties in lifecycle and bind methods

We seem to be thinking along similar lines…. earlier today I wrote this but got distracted before sending: At the moment I don’t see how returning the new service properties from bimd/updated/unbind methods can be thread safe. I think the activate/modify/deactivate methods are ok. I wonder if

Re: Modifying service properties in lifecycle and bind methods

I agree that serializing everything would be counterproductive (though the impact could be reduced by limiting synchronization to methods with the Map return signature.) I wonder if it would be possible to implement a lightweight scheme using update counts, though. Otherwise it's probably a bad id

Re: Modifying service properties in lifecycle and bind methods

I don’t think this is a bug. To avoid this behavior I think we’d have to serialize all lifecycle method invocations which I believe to be very undesirable. I could be wrong. david jencks > On Apr 10, 2017, at 2:39 PM, Brent Daniel wrote: > > Should there be any guarantees on the ordering of

Modifying service properties in lifecycle and bind methods

Should there be any guarantees on the ordering of service property updates across methods? For example, say I have an activate method that simply returns the current service properties and a bind method that adds "active=true" to the current properties and returns the updated properties. Both meth