[keycloak-dev] ProviderFactory::postDeploy?

[Dmitry Telegin]

Hi Marek and all,

It's been a while but I didn't want an important topic to be abandoned.

The proposed "lazyInit" approach might be useful per se, but it is
somewhat orthogonal to the original problem, let me explain that.

Matter is, providers might need to execute some post-init code to
access data model, but this should be done differently depending on the
deployment mode:

- if "cold" deployed (i.e. postInit invoked at server startup), we
should listen for PostMigrationEvent and don't wrap the code in a
transaction (it will be active already);
- if hot (re)deployed, do everything in the current thread, but wrap it
in a transaction.

The problem is how to distinguish the two above cases. At the moment,
there are some hackish methods like testing for presence/absence of
JNDI, analyzing current thread name, classloader implementation etc.,
but what I wanted was some standard, reliable mechanism.

Why wouldn't lazyInit be helpful here? Simply because it would happen
at different moments in time for different provider types. For
EntityProviders, first create() call to the factory occurs *before*
realm migration, that means too early. For RealmResourceProviders, it
happens before first actual REST invocation, and for many use cases
that would be too late.

To sum up, we still need a portable and determinate mechanism for
provider post-init. Could it be some callback that would be guaranteed
to:
- be called upon PostMigrationEvent on cold deploy;
- be called immediately upon hot (re)deploy;
- provide equal transactional semantics for both cases?

What do you think?

Thanks,
Dmitry

В Tue, 04/07/2017 в 09:26 +0200, Marek Posolda пишет:
> As Dmitri mentioned, the problem is that "postInit" is called before 
> model is fully initialized (eg. before migration), so it's not
> really 
> safe to access DB from there.
> 
> The bit related issue is, if we can add better support for the 
> "lazyInit" pattern into provider framework instead of make the
> providers 
> to care about the synchronization etc? We can possibly add the
> interface 
> like LazyInitializationProvider with single "lazyInit" method? If 
> provider implements it, the framework will ensure that the method is 
> called just once at the time when provider creation is requested for
> the 
> first time.
> 
> Marek
> 
> On 03/07/17 22:19, Bill Burke wrote:
> > Please see my response to your original problem.
> > 
> > 
> > On 7/3/17 12:16 PM, Dmitry wrote:
> > > Hi,
> > > 
> > > At the moment, the ProviderFactory::postInit() method is not
> > > called
> > > during hot (re)deployment of providers, only during server
> > > startup.
> > > This is considered a bug (see discussion in keycloak-user,
> > > KEYCLOAK-
> > > 5131 and PR #4282).
> > > 
> > > Meanwhile, Marek and I have been discussing the problem of
> > > accessing
> > > data model from postInit (see the keycloak-user post). Turns out
> > > that
> > > the semantics should be significantly different depending on
> > > whether
> > > postInit() is called during server startup or hot deploy. In the
> > > first
> > > case, one should listen for PostMigrationEvent. In the second
> > > case, the
> > > event is not available and thus shouldn't be listened for.
> > > However, the
> > > provider should be able to somehow distinguish the cases. There
> > > are
> > > some hacks like analyzing current thread name, querying JNDI or
> > > Resteasy, but maybe we can come up with something more clean and
> > > simple?
> > > 
> > > Marek has suggested that the new method should be introduced on
> > > the
> > > ProviderFactory interface, with empty default implementation (in
> > > order
> > > not to break the code). What do you think?
> > > 
> > > Dmitry
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev