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:lel...@gmail.com] Sent: Wednesday, December 10, 2014 10:37 AM To: cas-dev@lists.jasig.org 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 cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
