Not sure why this is turning into a lengthy discussion, but null in
the representation has a meaning. If you look at how it's implemented
the lack of a value (it's set to null) results in setting the default
value only if creating a new entity. If updating an existing entity a
null value is simply ignored. If you initialize these in the
representation you will end up overriding existing values. The idea is
that someone can update a single value without having to include all
existing values.
So at the beginning I said it would be rare for us to want the
default
to be null. That's where I was mistaken. It's good that we had the
discussion because I needed to know that null has that meaning.
Part of this is Java's fault. A Boolean with three values isn't really
Boolean. George Boole is probably rolling over in his grave.
On 12 November 2015 at 14:45, Stan Silvert <ssilvert(a)redhat.com
<mailto:ssilvert@redhat.com>> wrote:
On 11/12/2015 8:41 AM, Stian Thorgersen wrote:
> The bug is simply caused by not checking for null
Seriously? So every time you call a getter on a Representation
you have to check for null?
If a Boolean should not be null then initialize it properly or use
boolean.
>
> On 12 November 2015 at 14:40, Stan Silvert <ssilvert(a)redhat.com
> <mailto:ssilvert@redhat.com>> wrote:
>
> On 11/12/2015 8:33 AM, Stian Thorgersen wrote:
>> RepresentationToModel
> The bug happened before RepresentationToModel could be
> called. That's why we need to initialize variables properly.
>
>>
>> On 12 November 2015 at 14:20, Stan Silvert
>> <ssilvert(a)redhat.com <mailto:ssilvert@redhat.com>> wrote:
>>
>> On 11/12/2015 7:39 AM, Stian Thorgersen wrote:
>>>
>>>
>>> On 12 November 2015 at 13:12, Stan Silvert
>>> <ssilvert(a)redhat.com <mailto:ssilvert@redhat.com>>
wrote:
>>>
>>> Funny. I just ran into that exact NPE yesterday
>>> but I thought it was a state that was caused by my
>>> new code. So I only fixed it in that one
>>> representation class. But I'm not ready to merge
>>> that yet.
>>>
>>> We really need to go through all the
>>> representations and set defaults for all instance
>>> variables of type Boolean. It's probably rare that
>>> we would want that default to be null. Even if it
>>> should be null we should say so explicitly.
>>>
>>>
>>> -1 We want them to be null. We set defaults elsewhere
>> Where?
>>
>>>
>>>
>>> Stan
>>>
>>>
>>> On 11/12/2015 5:42 AM, Stian Thorgersen wrote:
>>>> That's a bug. It's failing on "if
>>>> (rep.isServiceAccountsEnabled() ..)",
>>>> but serviceAccountsEnabled in the representation
>>>> can be null, which would result in this NPE.
>>>>
>>>> Can you create a JIRA please? If you did a PR as
>>>> well that'd be even better :)
>>>>
>>>> On 12 November 2015 at 10:58, Juraj Janosik
>>>> <juraj.janosik77(a)gmail.com
>>>> <mailto:juraj.janosik77@gmail.com>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I want to announce an issue with "Update the
>>>> client
>>>>
<
http://keycloak.github.io/docs/rest-api/index.html#_update_the_client>...
>>>> via Admin REST API.
>>>>
>>>> _Description:_ I want to change the
>>>> description for existing client #3.
>>>>
>>>> _Note:_ From the documentation ("Update the
>>>> client
>>>>
<
http://keycloak.github.io/docs/rest-api/index.html#_update_the_client>...),
>>>> body parameter attributes
>>>> are required in schema
"ClientRepresentation".
>>>> Description of schema
"ClientRepresentation"
>>>> notes for any mandatory attribute.
>>>>
>>>> Are some parameters mandatory for successfuly
>>>> running of this scenario ?
>>>>
>>>> _Tested scenario:_
>>>> _Tested data:_
>>>> "Update Client":
>>>>
"method":"PUT","url":"<URL>:<PORT>/auth/admin/realms/<REALM>/clients/3"
>>>> "headers":
>>>>
[["Content-Type","application/json"],
>>>> ["Authorization","Bearer
<ACCESS_TOKEN>]]
>>>> "body":
>>>> "{
>>>> "id":"3",
>>>> "clientId":"testclient-3",
>>>> "name": "testclient-3",
>>>> "description": "TESTCLIENT-3
v.2"
>>>> }"
>>>>
>>>> _Test Result:_ Status Code: 500 Internal
>>>> Server Error
>>>>
>>>> _Some parts from console logs:_
>>>> 10:35:31,591 ERROR [io.undertow.request]
>>>> (default task-18) UT005023: Exception handling
>>>> request to
>>>> /auth/admin/realms/universities/clients/3:
>>>> java.lang.RuntimeException: request path:
>>>> /auth/admin/realms/universities/clients/3
>>>> ...
>>>> at
>>>>
org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61)
>>>> ... 29 more
>>>> *Caused by: java.lang.NullPointerException*
>>>> at
>>>>
org.keycloak.services.resources.admin.ClientResource.update(ClientResource.java:106)
>>>>
>>>>
>>>> Thanks a lot.
>>>>
>>>> Best Regards,
>>>> Juraj
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user(a)lists.jboss.org
>>>> <mailto:keycloak-user@lists.jboss.org>
>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user(a)lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>
>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user(a)lists.jboss.org
>>> <mailto:keycloak-user@lists.jboss.org>
>>>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>>
>>
>>
>
>