Small note on the serialization issue before diving deeper: Part of the difficulty here is the assumption that the entire object could be serializable which would make it challenging when things start to cross reference each other in a non-trivial way. I suppose if the design separated the actual object model from the serialization model this problem would be reduced to some extent. Something like a serialization proxy might work well (which I believe is something Scott recently did with the CAS client) but it still lots of boilerplate code.
From: Jérôme LELEU [mailto:[email protected]] Sent: Thursday, December 11, 2014 6:24 AM To: [email protected] Subject: Re: [cas-dev] Reducing CASImpl's complexity: ArgExtractors and more Hi, Thanks for jumping into the discussion. All opinions are welcome, and not only from committers. You raise an interesting idea about the relationships between tickets. So far, real service tickets objects are hold inside TGTs instead of simple identifiers. We could use identifiers: it would certainly make things easier for Serialization but would require more steps to get the information. 2 steps to get all the service tickets of a TGT instead of one. 1) Inheritance is a fragile solution. I like the idea of factories returning the appropriate implementation. 2) I'm not sure to see the problem. Do you have a use case in mind? 3) I don't think tickets should know their ticket registry, the storage system should know where to store or retrieve their tickets (name mappings is the easy solution). 4) I have seen CAS systems with high traffic but never experienced this concurrent access issue, but I agree we must be protected against it. Best regards, Jérôme LELEU Founder of CAS in the cloud: www.casinthecloud.com <http://www.casinthecloud.com> | Twitter: @leleuj Chairman of CAS: www.jasig.org/cas <http://www.jasig.org/cas> | Creator of pac4j: www.pac4j.org <http://www.pac4j.org> 2014-12-10 21:16 GMT+01:00 Gilbert, Howard <[email protected] <mailto:[email protected]> >: Currently “storable objects” are both annotated JPA Entities (so they can be stored in a database) and Serializable (so they can be stored in any of the Cache systems). Currently we have Tickets, Authentications, Credentials, Principals, Services that fall in this general category. A TGT has a list of Services and Service logout URLs for Single SignOut (although since Services always have the same logout URL it might be better if they were separately tabulated and the TGT had an ID that you could look up in the shared SingleLogout map rather than replicating the same Service/URL in each TGT). A TGT also has one (or more in CAS4) Authentications, each Authentication having a Principal and maybe a Credential. A ST has a reference to its TGT (this is very, very bad. The ST should have the ID of the TGT, not a pointer to the TGT. This causes all sorts of trouble across replications). Now for the Wish List. 1) These types of objects should be generated by a Factory. If you want an ST you should ask an API to give you one, not as currently new an STImpl class. This is important when you need to add extra function to these types of objects. Generally, it should be a function of the storage system to create the objects. In current terms, it should be an API of the TicketRegistry to create a TGT or ST that the Registry can store. 2) I has to be possible to replicate one of these objects in code. Currently there are certain things that are set at construction time and then you can’t get to them. That makes it impossible to copy the old contents to a new object when you need to do it. Because Serialization under the covers can access all the fields that are not generally exposed you successfully copy the object when you use a Cache solution that does Serialization, but you cannot fix up problems when vanilla replication generates the wrong result. 3) Storable objects have to know their store. In current terms, Tickets do not know the TicketRegistry object and at the moment there is no way to find the TicketRegistry unless it is injected into your bean. This is hidden by the very bad practice of having STs reference their TGT directly. You cannot fix this by storing the TGT ID string in the ST unless you have a way to look up that ID string and get the TGT, which is a Registry function but if you don’t already have a reference to the Registry then you cannot get it from the ST. 4) If you are going to rely on Cache mechanisms knowing that they use Serialization under the covers to replicate objects, then you need to add the boilerplate method that locks the object before it gets serialized. Right now all the TicketRegistries are exposed to occasional ConcurrentAccessException problems because objects being serialized can be modified during serialization and we don’t handle it properly. While StorableObject might be a marker interface, or even a real interface, it cannot plausibly be a parent class. That brings nothing useful and creates unnecessary restrictions. From: Jérôme LELEU [mailto:[email protected] <mailto:[email protected]> ] Sent: Wednesday, December 10, 2014 10:37 AM To: [email protected] <mailto:[email protected]> Subject: Re: [cas-dev] Reducing CASImpl's complexity: ArgExtractors and more Hi, @Marvin: ah! you had the solution on your own ;-) Your diagram makes sense, I will add it. It will be a good starting point for asking questions and defining APIs and interactions. My first ones: Tokens, sessions and authentications are saved into and restored from the storage system: I guess that somehow there is a parent object StorableObject from which should inherit all these elements with a generic API? I guess it's meant to work even if I save my tickets in Memcached and my sessions in a DB: several storage systems can be plugged behind the storage generic API? In a previous discussion, you wanted to make things really easy with Serialization. Some more details to share with us? -- You are currently subscribed to [email protected] <mailto:[email protected]> as: [email protected] <mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to [email protected] <mailto:[email protected]> as: [email protected] <mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
