libre.sh/keycloak-scim
3
0
Fork 0
Code Issues 15 Pull requests Releases 1 Packages Activity Actions

Merge pull request #119 from stianst/master

Browse source 
Update provider deployment approaches
This commit is contained in:
Stian Thorgersen 2017-04-21 11:03:28 +02:00 committed by GitHub
commit 294d91d910
1 changed files with 5 additions and 34 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

39
server_development/topics/providers.adoc
View file

@ -175,14 +175,12 @@ public class MyEventListenerProviderFactory implements EventListenerProviderFact
=== Registering provider implementations === Registering provider implementations
There are two ways to register provider implementations. The easiest way is to just throw your provider jar within There are two ways to register provider implementations. In most cases the simplest way is to use the Keyclopak Deployer
the Keycloak `deploy/` directory. Keycloak supports hot deployment as well in this scenario. This is also the best approach as this handles a number of dependencies automatically for you. It also supports hot deployment as well as re-deployment.
solution.
The alternative is not really recommended, but exists for legacy purposes as the Keycloak deployer didn't exist in The alternative approach is to deploy as a module.
previous versions of the project. Keycloak can load provider implementations from JBoss Modules or directly from the file-system.
Using Modules is recommended as you can control exactly what classes are available to your provider. If you are creating a custom SPI you will need to deploy it as a module, otherwise we recommend using the Keycloak Deployer approach.
Any providers loaded from the file-system uses a classloader with the Keycloak classloader as its parent.
==== Using the Keycloak Deployer ==== Using the Keycloak Deployer
@ -236,33 +234,6 @@ This is done by editing the keycloak-server subsystem section of
... ...
---- ----
==== Register a provider using file-system
To register your provider simply copy the JAR including the ProviderFactory and Provider classes and the service configuration file to server's root `providers` directory.
You can also define multiple provider class-path if you want to create isolated class-loaders.
To do this edit `standalone.xml`, `standalone-ha.xml`, or `domain.xml` and add more classpath entries to the providers element.
For example:
[source,xml]
----
<providers>
<provider>classpath:provider1.jar;lib-v1.jar</provider>
<provider>classpath:provider2.jar;lib-v2.jar</provider>
</providers>
----
The above example will create two separate class-loaders for providers.
The classpath entries follow the same syntax as Java classpath, with ';' separating multiple-entries.
Wildcard is also supported allowing loading all jars (files with .jar or .JAR extension) in a folder, for example:
[source,xml]
----
<providers>
<provider>classpath:/home/user/providers/*</provider>
</providers>
----
==== Configuring a provider ==== Configuring a provider
You can pass configuration options to your provider by setting them in `standalone.xml`, `standalone-ha.xml`, or `domain.xml`. You can pass configuration options to your provider by setting them in `standalone.xml`, `standalone-ha.xml`, or `domain.xml`.