More ServiceActivation

[Niclas Hedhman <ni...@hedhman.org>]

I found another bad side-effect of the current Service Activation.

The issue I have is that a Private Mixin is not seen by the Service
Activation system, and activateService() is never called.

So, I thought that I simply do a delegation from the public Mixin to the
private one;

@This
private MyPrivate parts;


public void activateService()
    throw Exception
{
     parts.activateService();
}


Anybody cares to guess what Exception I got?? ;-)

-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: More ServiceActivation

[Stanislav Muhametsin <st...@zest.mail.kapsi.fi>]

On 9.6.2017 13:10, Niclas Hedhman wrote:
> How about the (to me) difference between "Service Activation" (singleton,
> outside view) and "Service Mixin Lifecycle" (typically resource
> initialization that each mixin manage on its own)? Did you figure out the
> detailed semantics here as well?

I took a bit different approach in C# than what was in Java back in that 
time, I think it was originally your suggestion:
Each fragment class can declare any amount of methods, which are 
annotated with annotations recognized by Polygene.
If such method declares any parameters, they all must be injectable.

For example, if fragment class has any methods with [Activation] 
annotation, these methods will be executed when service is activated.
The passivation works similarly for [Passivation] annotation.

Similarly I have [Initialize] annotation, those methods will be executed 
every time instance of fragment has been created and all fields injected.
Typically, instance of fragment is created only once during composite 
lifecycle, but concurrent access may cause additional creations.

Then I have [Prototype] annotation, those methods will be executed when 
the composite factory transforms from prototype phase to actual 
composite phase.
So, the [Prototype] methods will be executed at most once during 
composite lifecycle.
Note that indeed composite factory does not create copy when 
"Instantiate" method is called - composite instance internally goes from 
prototype mode to instance mode.

So far, I've been able to solve all the problems using that approach.
The *earliest* point that user-code may execute is [Inititalize] 
annotation, and I take care of setting up the composite state and all 
fragment instance pools etc before that.

But also, since C# has concept of "property" within language itself, I 
do not have "Property" interface - properties that are left abstract 
(their getter and setter both lack implementation in any fragment type) 
are the ones that the runtime will figure out to be manageable by the 
runtime itself, and which are part of the composite state.
Their property type (return type of getter and parameter type of setter) 
is the type which I think in Java is 'T' of 'Property<T>' interface.
This difference in programming language might have simplified and solved 
some issues that you guys are currently facing in Java.


>
> Cheers
>
> On Fri, Jun 9, 2017 at 4:10 PM, Stanislav Muhametsin <
> stanislav.muhametsin@zest.mail.kapsi.fi> wrote:
>
>> FWIW, I really had to sit down and think a lot about all concurrency etc
>> issues in C# version of Polygene.
>> There, I am using CompareExchange-based algorithms to simulate state
>> machine:
>> 0 - Initial
>> 1 - Activating
>> 2 - Active
>> 3 - Passivating
>> 4 - Passive
>>
>> Legal transitions are:
>> 0 -> 1 (Initial activation)
>> 1 -> 2 (Activation successful)
>> 1 -> 4 (Exception in activation)
>> 2 -> 3 (Starting to passivate)
>> 3 -> 4 (Passivation successful (even if exception))
>> 4 -> 1 (Re-activating)
>>
>> That way, I can also detect recursive calls within activation/passivation
>> methods (when state is 1 or 3), which helps avoid some nasty
>> StackOveflowExceptions and other inconsistencies.
>>
>> I've got things to work very nicely even in very large and complex
>> applications, where service activations can cascade multiple layers down.
>>
>>
>> On 09/06/2017 05:50, Niclas Hedhman wrote:
>>
>>> I found another bad side-effect of the current Service Activation.
>>>
>>> The issue I have is that a Private Mixin is not seen by the Service
>>> Activation system, and activateService() is never called.
>>>
>>> So, I thought that I simply do a delegation from the public Mixin to the
>>> private one;
>>>
>>> @This
>>> private MyPrivate parts;
>>>
>>>
>>> public void activateService()
>>>       throw Exception
>>> {
>>>        parts.activateService();
>>> }
>>>
>>>
>>> Anybody cares to guess what Exception I got?? ;-)
>>>
>>>
>

Re: More ServiceActivation

[Niclas Hedhman <ni...@hedhman.org>]

How about the (to me) difference between "Service Activation" (singleton,
outside view) and "Service Mixin Lifecycle" (typically resource
initialization that each mixin manage on its own)? Did you figure out the
detailed semantics here as well?

Cheers

On Fri, Jun 9, 2017 at 4:10 PM, Stanislav Muhametsin <
stanislav.muhametsin@zest.mail.kapsi.fi> wrote:

> FWIW, I really had to sit down and think a lot about all concurrency etc
> issues in C# version of Polygene.
> There, I am using CompareExchange-based algorithms to simulate state
> machine:
> 0 - Initial
> 1 - Activating
> 2 - Active
> 3 - Passivating
> 4 - Passive
>
> Legal transitions are:
> 0 -> 1 (Initial activation)
> 1 -> 2 (Activation successful)
> 1 -> 4 (Exception in activation)
> 2 -> 3 (Starting to passivate)
> 3 -> 4 (Passivation successful (even if exception))
> 4 -> 1 (Re-activating)
>
> That way, I can also detect recursive calls within activation/passivation
> methods (when state is 1 or 3), which helps avoid some nasty
> StackOveflowExceptions and other inconsistencies.
>
> I've got things to work very nicely even in very large and complex
> applications, where service activations can cascade multiple layers down.
>
>
> On 09/06/2017 05:50, Niclas Hedhman wrote:
>
>> I found another bad side-effect of the current Service Activation.
>>
>> The issue I have is that a Private Mixin is not seen by the Service
>> Activation system, and activateService() is never called.
>>
>> So, I thought that I simply do a delegation from the public Mixin to the
>> private one;
>>
>> @This
>> private MyPrivate parts;
>>
>>
>> public void activateService()
>>      throw Exception
>> {
>>       parts.activateService();
>> }
>>
>>
>> Anybody cares to guess what Exception I got?? ;-)
>>
>>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: More ServiceActivation

[Stanislav Muhametsin <st...@zest.mail.kapsi.fi>]

FWIW, I really had to sit down and think a lot about all concurrency etc 
issues in C# version of Polygene.
There, I am using CompareExchange-based algorithms to simulate state 
machine:
0 - Initial
1 - Activating
2 - Active
3 - Passivating
4 - Passive

Legal transitions are:
0 -> 1 (Initial activation)
1 -> 2 (Activation successful)
1 -> 4 (Exception in activation)
2 -> 3 (Starting to passivate)
3 -> 4 (Passivation successful (even if exception))
4 -> 1 (Re-activating)

That way, I can also detect recursive calls within 
activation/passivation methods (when state is 1 or 3), which helps avoid 
some nasty StackOveflowExceptions and other inconsistencies.

I've got things to work very nicely even in very large and complex 
applications, where service activations can cascade multiple layers down.

On 09/06/2017 05:50, Niclas Hedhman wrote:
> I found another bad side-effect of the current Service Activation.
>
> The issue I have is that a Private Mixin is not seen by the Service
> Activation system, and activateService() is never called.
>
> So, I thought that I simply do a delegation from the public Mixin to the
> private one;
>
> @This
> private MyPrivate parts;
>
>
> public void activateService()
>      throw Exception
> {
>       parts.activateService();
> }
>
>
> Anybody cares to guess what Exception I got?? ;-)
>