On Wed, Apr 6, 2016 at 12:57 PM, Stian Thorgersen <sthorger(a)redhat.com>
On 6 April 2016 at 11:52, Thomas Raehalme <
> On Wed, Apr 6, 2016 at 12:47 PM, Stian Thorgersen <sthorger(a)redhat.com>
>> Problem with a built-in JMS event listener provider is that it should
>> send messages to an external JMS server. Keycloak itself should not act as
>> a JMS server. Further, there's no standard way to connect to JMS providers,
>> so best we could do is one that connects to WildFly/EAP and make it easy
>> for users to extend it to connect to different providers (maybe an
>> getDestination() method).
> I understand that the configuration cannot (and should not) be enabled by
> default, but it would be great if it was enough for the user to just modify
> the Wildfly/Keycloak configuration instead of having to add modules, jars
> and whatever to the installation. Examples of the configuration can be
> provided separately.
User would at the very least be required to have a separate WildFly
installation to use as a JMS server. We will not document how to make
Keycloak (underlying WildFly) itself act as JMS server. However, I'm happy
to include a provider that can connect to the external JMS server, allow
extending to connect to other providers. Documentation only needs to cover
how to configure it to connect to an external JMS server (on WildFly/EAP).
It doesn't need to cover setup of the JMS server itself, but can link to
relevant WildFly documentation.
Including the provider is what I meant. No need to document on how to do
some external stuff.