Resources should be Serializable

[thomasdarimont]

Just played a bit with the osiam docker image.

After a restart of the tomcat server I see some exceptions in the log indicating that scim Users or Resources in general cannot be serialized which makes tomcat bark when it tries to serialize HttpSession contents.

I'd suggest that you make Resources serializable to avoid such problems.

SEVERE: IOException while loading persisted sessions: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.osiam.resources.scim.User
java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.osiam.resources.scim.User

[wallner]

Hello Thomas,

we are aware of this problem but have so far refrained from implementing Serializable in our Resources because we are not yet sure if we are completely happy with them as they are, see for example the, well, problematic UpdateUser. We know that we have to make them serializable in the not so far future since we want to store them in a session, however implementing Serializable would add the binary representation to the public API of the classes. We had a few on and off discussions about that but never came to a final conclusion. Maybe now is the point to just go ahead and do it.

What do the others think?

[tkrille]

we are aware of this problem but have so far refrained from implementing Serializable in our Resources because we are not yet sure if we are completely happy with them as they are

IMHO the current implementations of the classes are fine, with one exception: org.osiam.client.oauth.AccessToken. At this time OSIAM's access tokens are quite simple, maybe too simple for more advanced use cases. Moreover we are still planning to sign tokens, which would at least add a new field (signature). I don't know whether adding a field is considered safe in respect of @Serializable or not.

see for example the, well, problematic UpdateUser

I think we can neglect org.osiam.resources.scim.UpdateUser and org.osiam.resources.scim.UpdateGroup, because there's no sense in storing them in session or other datastore. They're only used when updating the corresponding resources with HTTP PATCH.

We know that we have to make them serializable in the not so far future since we want to store them in a session

We are already doing this: see addon-administration.

Maybe now is the point to just go ahead and do it.

For org.osiam.resources.scim.User and org.osiam.resources.scim.Group: 👍 let's do it!

For org.osiam.client.oauth.AccessToken: Should be discussed in another issue? At least @thomasdarimont only mentioned User and Resource in this issue.

[tkrille]

@sputnik27 @dacrome ping

[tkrille]

@osiam/owners Anyone got an opinion about this?

[fwilhe]

For org.osiam.resources.scim.User and org.osiam.resources.scim.Group: 👍 let's do it!

Since no one objected to this, I will do it.

[fwilhe]

Shall we move the debate about org.osiam.client.oauth.AccessToken to another issue, merge #145 and close this one? Goes without saying that I'm in favor.

[tkrille]

We should definitely create an issue for making org.osiam.client.oauth.AccessToken serializable: osiam/connector4java#155

[tkrille]

For now, I don't see a consensus emerging. So let's wait until monday when @wallner is back and discuss this then.

[wallner]

I'm fine with makin the resources Serializable. I think they have proven stable by now. Please consider my comment on #145.