Interesting issue. Not sure if we're going to change something in the
UserRepresentation class just because JSF limitations. Maybe the
possibility is:
- Create some custom JSF renderer/handler/component (not sure what
exactly, didn't work with the JSF in last few years) to be able to deal
with it
- Create some wrapper/delegate object around Keycloak UserRepresentation
and pass that one to JSF. For example something like:
public class MyUser {
private final UserRepresentation delegate;
public MyUser(UserRepresentation kcUser) {
delegate = kcUser;
}
public String getFirstName() {
// Just delegate to the underlying object
return delegate.getFirstName();
}
// Convert "is" to "get"
public Boolean getEnabled() {
return deelgate.isEnabled();
}
// All the others...
}
Marek
On 14/11/17 13:05, Matthew Broadhead wrote:
org.keycloak.representations.idm.UserRepresentation
(
https://github.com/keycloak/keycloak/blob/master/core/src/main/java/org/k...)
has a property enabled which is of type java.lang.Boolean. Technically
this should have getters and setters of getEnabled and setEnabled. A
type boolean would have isEnabled and setEnabled. This stops it from
working with JSF
(
https://stackoverflow.com/questions/14400222/boolean-properties-starting-...)
This also applies to totp and emailVerified in the same class.
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user