Looking at global settings for Surefire plugin in keycloak/pom.xml:
<argLine>-Xms512m -Xmx2048m -XX:MaxMetaspaceSize=512m</argLine>
1) The heap space settings seems quite high. Is there some reason for 2g heap? If not, can we lower it say to 1g?
2) In JDK 8 permspace was replaced by metaspace which we might want to limit instead.
"backends" (jpa, mongo, infinispan) were consolidated under
keycloak-model-(jpa, mongo, infinispan).
Integration module was moved around into:
connections, broker, social, events etc. were consolidated.
Modules I did not consolidate:
I kept federation separate as I'm wondering what will happen with
kerberos and IBM JDK. LDAP module depends on kerberos, so I kept that
Not sure if this is something we was removable or not as it depends on a
I don't know much about these modules so I kept them separate.
Stian/Marko can decide what they want to do here.
JBoss, a division of Red Hat
Keycloak SAML Client Adapter Reference Guide section 2.7 wrongly saying
"IDP SingleSignOnService sub element" instead of "IDP SignleLogoutService"
is it possible to correct this in 1.8 Release .
From yesterday's discussion, it was clear that as a group, we consider
debug/trace logging to be fundamentally different from other logging.
The loggers I've been concerned with will be logged through a limited
number of keycloak loggers using broad categories such as User, Realm,
But for debug/trace logging, we want the category to be based upon the
class it was logged from. That way, you can turn logging on for a
particular class, package, or sub-package to do your trace.
There is no good way to do both kinds of logging using the same logger
instance. Therefore, I propose that debug/trace logging be done the
same way we've always done it. Declare a debug/trace logger in your
class and use that. Other logging will be done through the keycloak logger.
So, to do both kinds of logging in the same class, you declare two loggers:
private static final KeycloakLogger kcLogger = KeycloakLogger.ROOT_LOGGER;
private static final Logger debugLogger = Logger.getLogger(MyClass.class);
kcLogger.CONFIG.localizedMessage("My localized message"); // logged to
debugLogger.debug("My debug message"); // logged to
If a required or auth action was successful, the flow redirects to the
appropriate path (just like in 1.6). This time though, there should not
be multiple redirects at once. I'll work on backbutton soon.
JBoss, a division of Red Hat
I'm wasn't planing on having a lengthy discussion about code style. It's
usually just a matter of personal preference and folks do get used to most
* Should we have a code style?
* What IDEs are Keycloak devs using (I'm crossing my fingers everyone says
* Should we enable the checkstyle plugin?
With regards to the actual style my first thought was to base it on WildFly
code style (we do build on top of it after all). However, they do not have
one for IntelliJ, which makes it a no go IMO. Further I don't particularly
want to craft one (and try to get configs for IntelliJ match Eclipse, which
also passes the checkstyle). So do anyone have suggestions of other
projects we can borrow from?
If we're going to incorporate a code style and re-format the current code
case now is a very good time.
It would be great if one could configure concrete event-listener via the
In my case I have an EventListenerProvider that asynchronously forwards
a set of configured event types to a REST endpoint via HTTP POST which has
configurable options like:
- forwardingEndpoint - Address of the rest endpoint
- authHeader - Authroization Basic: ... / Bearer: ...
- includeEventPattern - Regex for matching included event type names
- excludeEventPattern - Regex for exluding event type names (that were
- postAsync - use background thread for sending (true/false)
- retryStrategy - (max retries, backoff etc.)
- postTimeout - max time for the post request to complete
- queuePath - file backed FIFO queue
Currently I have to configure this listener via keycloak-server.json.
What do you think - shall I create a JIRA for this (allow for event