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.
В Wed, 28/06/2017 в 07:15 +0200, Stian Thorgersen пишет:
Yep, seems like a bug
On 28 June 2017 at 03:35, Dmitry Telegin <mitya(a)cargosoft.ru> wrote:
> Seems like o.k.provider.ProviderFactory::postInit() is called only
> server startup, no matter which way the provider has been deployed,
> a module or via the deployments dir. However, if the provider is
> (re)deployed on the running server, the method is not called.
> (ProviderFactory::init() is called always, but it's insufficient
> most init phase tasks since normally a KeycloakSessionFactory
> is required.)
> Indeed, o.k.services.DefaultKeycloakSessionFactory::deploy()
> contain mentions of postInit, contrary to
> DefaultKeycloakSessionFactory::init(). Seems like a bug to me, OK
> file JIRA issue and PR?
> keycloak-user mailing list