mposolda at redhat.com
Tue Jul 4 03:26:13 EDT 2017
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
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:
>> 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
>> 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?
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
More information about the keycloak-dev