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 | Twitter: @leleuj Chairman of CAS: www.jasig.org/cas | Creator of pac4j: www.pac4j.org 2014-12-10 21:16 GMT+01:00 Gilbert, Howard <howard.gilb...@yale.edu>: > 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: lel...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- 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
