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/keycloak/representations/idm/UserRepresentation.java)
> 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-with-is-does-not-work)
>>> This also applies to totp and emailVerified in the same class.
> _______________________________________________
> keycloak-user mailing list
>keycloak-user at lists.jboss.org>https://lists.jboss.org/mailman/listinfo/keycloak-user