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 <niclas@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
>
|