yes i am already using a wrapper but i thought you might want to address
the problem?
technically it is incorrect coding.
a boolean can be true or false, defaulting to false. therefore
isEnabled must be true or false
a Boolean can be true, false or null, defaulting to null. therefore
isEnabled can blow up with an NPE and doesn't truly represent an "is"
statement.
how did it get coded as isEnabled and setEnabled in the first place? is
there something wrong with the IDE you are using?
On 15/11/2017 15:57, Marek Posolda wrote:
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