ServiceActivation

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

Hi,
I have probably been "complaining" about the semantics around the
ServiceActivation before, and I am still not satisfied.

It seems broken and I wonder if it is even more broken than can be
tolerated for 3.0.


So, I am working in the Jooq ES, and the ES itself consists of a @This
reference to a class that handles everything about the tables, so there is
a

@This
private SqlTable sqlTable;


and the SqlTable interface and its implementation;


@Mixins( SqlTable.Mixin.class )
public interface SqlTable extends ServiceActivation
{

    class Mixin
        implements SqlTable, ServiceActivation
    {


and this Mixin's activate() and passivate() methods are not called.

I guess that is because the ES Mixin doesn't have ServiceActivation
declared. But IMHO that shouldn't be required. Anything declared with @This
is "partOf" the same composite, i.e. is part of the Service in this case.
It is just that part of the Composite interface is hidden/private.

Ohhhhh!! I was just testing that hypothesis and added ServiceActivation to
the ES;


public class JooqEntityStoreMixin
    implements EntityStore, EntityStoreSPI, ServiceActivation
{



But that also didn't work. In fact, neither the JooqEntityStoreMixin's
activate() nor the SqlTable one are called.

Ah! I need to put it on the JooqEntityStoreService interface,

public interface JooqEntityStoreService
    extends EntityStore, EntityStateVersions, Configuration, ServiceActivation
{


BUT that still only calls the activation on the JooqEntityStoreMixin, i.e
not what is really expected.


So, if I can't get my head around this, a very central concept, then I
would say that we need to improve it.


Now, there is the additional complication of "instantiateOnStartup()" which
has thread-safety issues related to it as well.


So there is an initial question to be answered first;

Is 3.0 really releasable? I could argue that "instantiateOnStartup()" might
have to go. It is too fragile, and I think we can provide a "service
worker" and "deferred" solution for services that are suitable for lazy
initialization. That alone might clean up the congestion around
ServiceActivation

Once that is sorted, then comes semantics such as what is declared where
and what does it mean, overrides, relationship to Initializable and much
more.

And the whole thing is not documented well-enough at the moment, which
makes me even more concerned about a release 3.0 right now. Sorry.


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

Re: ServiceActivation

[Paul Merlin <pa...@apache.org>]

Niclas Hedhman a écrit :
> So there is an initial question to be answered first;
>
> Is 3.0 really releasable? I could argue that "instantiateOnStartup()" might
> have to go. It is too fragile, and I think we can provide a "service
> worker" and "deferred" solution for services that are suitable for lazy
> initialization. That alone might clean up the congestion around
> ServiceActivation
>
> Once that is sorted, then comes semantics such as what is declared where
> and what does it mean, overrides, relationship to Initializable and much
> more.
>
> And the whole thing is not documented well-enough at the moment, which
> makes me even more concerned about a release 3.0 right now. Sorry.
 
Agreed, but I'd prefer a first increment to make things safe if not
convenient.
So we can get 3.0 out the door, and fix this properly in subsequent
releases.
Well, that's exactly what Kent suggests :)

Re: ServiceActivation

[Kent Sølvsten <ke...@gmail.com>]

I believe you intent to make instantiateOnStartup() the default? In that
case i agree, if we do not trust the lazy start, then it has to go for now.

Like you i also dislike the whole @Activators / Activation /
ServiceActivation. I think they do not belong on the composite interface
itself, but should be implementation details in the fragments (probably
almost always the mixins in practice).

I think we should stick to it for now, and then consider creating an
alternative + deprecate it for a future release.

Actually i would be in favor of immediately removing #beforeActivation and
#afterPassivation, since they seem to be redundant (unused) in practice.

One way of declaring lifecycle events (which i like) could be something like


public class JooqEntityStoreMixin
    implements EntityStore, EntityStoreSPI
{
   public void initializeDatabase( @Observes ServiceActivationEvent event )
{
  }
}

which is nicely extensible. But i think we should postpone that.

/Kent


On Mon, Jun 5, 2017 at 9:59 AM, Niclas Hedhman <ni...@hedhman.org> wrote:

> Hi,
> I have probably been "complaining" about the semantics around the
> ServiceActivation before, and I am still not satisfied.
>
> It seems broken and I wonder if it is even more broken than can be
> tolerated for 3.0.
>
>
> So, I am working in the Jooq ES, and the ES itself consists of a @This
> reference to a class that handles everything about the tables, so there is
> a
>
> @This
> private SqlTable sqlTable;
>
>
> and the SqlTable interface and its implementation;
>
>
> @Mixins( SqlTable.Mixin.class )
> public interface SqlTable extends ServiceActivation
> {
>
>     class Mixin
>         implements SqlTable, ServiceActivation
>     {
>
>
> and this Mixin's activate() and passivate() methods are not called.
>
> I guess that is because the ES Mixin doesn't have ServiceActivation
> declared. But IMHO that shouldn't be required. Anything declared with @This
> is "partOf" the same composite, i.e. is part of the Service in this case.
> It is just that part of the Composite interface is hidden/private.
>
> Ohhhhh!! I was just testing that hypothesis and added ServiceActivation to
> the ES;
>
>
> public class JooqEntityStoreMixin
>     implements EntityStore, EntityStoreSPI, ServiceActivation
> {
>
>
>
> But that also didn't work. In fact, neither the JooqEntityStoreMixin's
> activate() nor the SqlTable one are called.
>
> Ah! I need to put it on the JooqEntityStoreService interface,
>
> public interface JooqEntityStoreService
>     extends EntityStore, EntityStateVersions, Configuration,
> ServiceActivation
> {
>
>
> BUT that still only calls the activation on the JooqEntityStoreMixin, i.e
> not what is really expected.
>
>
> So, if I can't get my head around this, a very central concept, then I
> would say that we need to improve it.
>
>
> Now, there is the additional complication of "instantiateOnStartup()" which
> has thread-safety issues related to it as well.
>
>
> So there is an initial question to be answered first;
>
> Is 3.0 really releasable? I could argue that "instantiateOnStartup()" might
> have to go. It is too fragile, and I think we can provide a "service
> worker" and "deferred" solution for services that are suitable for lazy
> initialization. That alone might clean up the congestion around
> ServiceActivation
>
> Once that is sorted, then comes semantics such as what is declared where
> and what does it mean, overrides, relationship to Initializable and much
> more.
>
> And the whole thing is not documented well-enough at the moment, which
> makes me even more concerned about a release 3.0 right now. Sorry.
>
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>