6:16 p.m.
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
10:19 p.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
9:26 a.m.
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2:43 p.m.
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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2347
days inactive
2489
days old
3 comments
4 participants
participants (4)
-
Bill Burke -
Dmitry -
Dmitry Telegin
-
Marek Posolda