I'm not going to do the @KeycloakProvider annotation. Not sure I like
having something that won't work without a deployer.
As for KeycloakSession injection, that would probably be a CDI thing.
On 8/8/16 8:37 AM, Marek Posolda wrote:
Looks cool. Will these annotations be defined in Keycloak or do we
integrate with CDI?
Marek
On 06/08/16 17:43, Bill Burke wrote:
> I've implemented a Keycloak provider deployer and it works great. I
> re-implemented the JPA User Storage SPI example. The provider is now a
> @Stateful EJB and EntityManager access is all managed by
> @PersistenceContext. The example now looks really simple and elegant
> rather than the crap I mentioned before. Would not have worked without
> the JTA integration I did (see previous email). Things left to do:
>
> * hot deployment. Pretty sure I can implement this
>
> * Make sure things work in WARs and EARs.
>
> * Also thinking of defining a @KeycloakProvider annotation that you can
> use on your ProviderFactories. This would remove the need to specify a
> META-INF/services file and the annotation could be scanned for at
> deployment. Would work like this:
>
>
> @KeycloakProvider(UserStorageProviderFactory.class)
>
> public class MyProvider ... {
>
> }
>
> As a side note, one thing I could look into is the ability to use
> @Inject of a KeycloakSession. Developer could then write entire web
> applications that are deployed separately and worked with the keycloak
> API directly. @Inject KeycloakSession would work similarly to
> @PersistenceContexts EntityManager. KeycloakSessions would be
> associated with a transaction. This will give us nice integration with
> Java EE and give a lot of power to developers wanting to extend
> keycloak.
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev