<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 12/12/15 16:17, Niko Köbler wrote:<br>
</div>
<blockquote cite="mid:4B40CDCA-C131-4810-A1CB-4321062657EC@n-k.de"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
Ok, I understand.
<div class=""><br class="">
</div>
<div class="">But then I suggest, if I was right with my
assumption about the SPIs, that you should remove the lines from
the documentation. </div>
</blockquote>
Could you please create JIRA pointing to incorrect part in the
documentation?<br>
<blockquote cite="mid:4B40CDCA-C131-4810-A1CB-4321062657EC@n-k.de"
type="cite">
<div class="">Also, there seems to be some relicts of classes in
the code (if I’m not completely wrong).</div>
</blockquote>
Yes, in code we still have MemUserSessionProvider, which is
userSession implementation based on pure memory. Did you mean this?
This is used just for backwards compatibility in EAP 6.4 (because
infinispan local mode doesn't work correctly here and doesn't
support all the stuff we need) and will be removed.<br>
<br>
Btv. what's your motivation to not use infinispan? If you afraid of
cluster communication, you don't need to worry much about it,
because if you run single keycloak through standalone.xml, the
infinispan automatically works in LOCAL mode and there is no any
cluster communication at all. <br>
<br>
Or do you want persistent userSession/clientSessions, which will
survive server restart? We already have userSessionPersister SPI,
which is used to persist just "offline" userSessions (those used for
retrieve offline token) but possibly we will extend it with the
optional possibility to persist all user sessions.<br>
<br>
Marek<br>
<blockquote cite="mid:4B40CDCA-C131-4810-A1CB-4321062657EC@n-k.de"
type="cite">
<div class=""><br class="">
</div>
<div class="">
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">Am 12.12.2015 um 02:55 schrieb Scott Rossillo
<<a moz-do-not-send="true"
href="mailto:srossillo@smartling.com" class="">srossillo@smartling.com</a>>:</div>
<br class="Apple-interchange-newline">
<div class="">I highly suggest, from production experience,
that you stick with Infinispan. <br class="">
<div class="gmail_quote">
<div dir="ltr" class="">On Fri, Dec 11, 2015 at 1:56 PM
Bill Burke <<a moz-do-not-send="true"
href="mailto:bburke@redhat.com" class="">bburke@redhat.com</a>>
wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Yes,
you can replace Infinispan... No, we will not support
you :) We<br class="">
had to reduce the scope of Keycloak. Same reason why
we only support<br class="">
running the server on Wildfly/EAP now. Its just too
much extra work.<br class="">
<br class="">
On 12/11/2015 8:14 AM, Niko Köbler wrote:<br class="">
> Hi,<br class="">
><br class="">
> in my current project, it’s not wanted to use
Infinispan as cache in a cluster.<br class="">
> However, I have to deal with the user session and
token information.<br class="">
> And as I can remember, in early versions of
Keycloak was an option, to store this information via
JPA or MongoDB instead of Infinispan.<br class="">
> Also, I saw there is a User Sessions SPI, and
also a User Cache SPI and Realm Cache SPI.<br class="">
> If I implement those SPIs, can I get rid of
Infinispan replication in a cluster?<br class="">
> And are there some examples or good starting
points? (documentation?)<br class="">
><br class="">
> Regards,<br class="">
> - Niko<br class="">
><br class="">
><br class="">
> _______________________________________________<br
class="">
> keycloak-user mailing list<br class="">
> <a moz-do-not-send="true"
href="mailto:keycloak-user@lists.jboss.org"
target="_blank" class="">keycloak-user@lists.jboss.org</a><br
class="">
> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/keycloak-user"
rel="noreferrer" target="_blank" class="">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br
class="">
><br class="">
<br class="">
--<br class="">
Bill Burke<br class="">
JBoss, a division of Red Hat<br class="">
<a moz-do-not-send="true"
href="http://bill.burkecentral.com/"
rel="noreferrer" target="_blank" class="">http://bill.burkecentral.com</a><br
class="">
_______________________________________________<br
class="">
keycloak-user mailing list<br class="">
<a moz-do-not-send="true"
href="mailto:keycloak-user@lists.jboss.org"
target="_blank" class="">keycloak-user@lists.jboss.org</a><br
class="">
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/keycloak-user"
rel="noreferrer" target="_blank" class="">https://lists.jboss.org/mailman/listinfo/keycloak-user</a></blockquote>
</div>
_______________________________________________<br
class="">
keycloak-user mailing list<br class="">
<a moz-do-not-send="true"
href="mailto:keycloak-user@lists.jboss.org" class="">keycloak-user@lists.jboss.org</a><br
class="">
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-user">https://lists.jboss.org/mailman/listinfo/keycloak-user</a></div>
</blockquote>
</div>
<br class="">
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
keycloak-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-user">https://lists.jboss.org/mailman/listinfo/keycloak-user</a></pre>
</blockquote>
<br>
</body>
</html>