The PR fixes the bug, however, the ProviderFactory::postInit invoked this way will have limitations, e.g. won't be able to access java:comp JNDI namespace; the other stuff like accessing the data model works well nevertheless. This is because the code is executed in WildFly's "MSC service thread", unlike application code that uses "ServerService Thread Pool". If we are to get rid of this limitation, I think there exists an approach that will by the way fix KEYCLOAK-5132 too. Let me know if this is topical, so we can discuss it further.

Yep, seems like a bug On 28 June 2017 at 03:35, Dmitry Telegin <mitya(a)cargosoft.ru&gt; wrote: > Hi, > > Seems like o.k.provider.ProviderFactory::postInit() is called only > upon > server startup, no matter which way the provider has been deployed, > as > a module or via the deployments dir. However, if the provider is > hot > (re)deployed on the running server, the method is not called. > (ProviderFactory::init() is called always, but it's insufficient > for > most init phase tasks since normally a KeycloakSessionFactory > instance > is required.) > > Indeed, o.k.services.DefaultKeycloakSessionFactory::deploy() > doesn't > contain mentions of postInit, contrary to > DefaultKeycloakSessionFactory::init(). Seems like a bug to me, OK > to > file JIRA issue and PR? > > Regards, > Dmitry > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user >