polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject ServiceActivation
Date Mon, 05 Jun 2017 07:59:48 GMT
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

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

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

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.

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

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