<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Stan,<br>
<br>
did you already tried to test with more auth-servers per Wildfly
instance? I am seeing some potential issue in the fact that some
stuff is static (at least KeycloakApplication.loadConfig() is
static method and configProvider field in org.keycloak.Config is
static too). It looks that this might need some refactoring
(unless we want to share the same config among all auth-servers,
which seems as bad solution to me)<br>
<br>
I did not try myself yet to test with more auth-servers, just
raising potential issue<span class="moz-smiley-s3"><span> ;-) </span></span><br>
<br>
Marek<br>
<br>
On 29.10.2014 14:28, Stan Silvert wrote:<br>
</div>
<blockquote cite="mid:5450EB94.9090404@redhat.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
I've sent a PR for this:<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://github.com/keycloak/keycloak/pull/811">https://github.com/keycloak/keycloak/pull/811</a><br>
<br>
It's a pretty big change in the way the Auth Server is started
when the KeyCloak subsystem is used. The WAR is no longer dropped
into the standalone/deployments directory. This is especially
helpful for domain deployments, but it makes standalone cleaner as
well. It will also be important for Feature Pack installation.<br>
<br>
The main difference you will see right away with this PR is that
the appliance dist now uses the subsystem to launch the Auth
Server.<br>
<br>
Here are some notes about how everything turned out. Next, I'll
update the documentation if there is no major rework that needs to
be done after the PR is reviewed.<br>
<br>
<ul>
<li>The WAR for the auth server now lives in
modules/.../keycloak-wildfly-subsystem/main/auth-server. By
default, it is unexploded. If you want it to be exploded you
can unzip it into that same directory and set the
"auth-server-exploded" property in module.xml.</li>
<li>A new Auth Server is declared in standalone.xml/domain.xml.
You can have more than one Auth Server in the same WildFly
instance. </li>
<li><subsystem xmlns="urn:jboss:domain:keycloak:1.0"><br>
<auth-server name="main-auth-server"><br>
<enabled>true</enabled><br>
<web-context>auth</web-context><br>
</auth-server><br>
<br>
</li>
<li>The "enabled" attribute can be toggled at runtime to make
the auth server undeploy/redeploy.</li>
<li>If you have more than one auth-server, the web-context must
be unique.</li>
<li>In a domain environment, all specified Auth Server
deployments are propagated to all servers using that profile.
The same is true for overlays uploaded through the new CLI
operations.<br>
</li>
<li>There are two new CLI operations that act on an
auth-server. They are "add-provider" and
"update-server-config". Currently, you can only execute these
operations in the latest version of CLI GUI. We should
discuss if we need to add support in plain CLI. The long term
goal would be to add this functionality to the Keycloak Admin
Console.</li>
<li>"add-provider" adds a provider jar to an auth-server</li>
<li>"update-server-config" overlays the keycloak-server.json for
an auth-server.</li>
<li>If a keycloak-server.json file is found in
standalone/configuration directory, all auth-server instances
will still use it regardless of any update-server-config
operations.<br>
</li>
<li>EAP6 does not yet support all this. We should discuss
whether or not this functionality should be backported.<br>
</li>
</ul>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
keycloak-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</blockquote>
<br>
</body>
</html>