Page Comparison

[10:25:55 CDT(-0500)] <fairwinds> apetro: have you done any complex serializing deserializing using xstream for xml?
[10:27:15 CDT(-0500)] <fairwinds> apetro: my concern is around the fact that tickets have various implementations
[10:27:45 CDT(-0500)] <fairwinds> serializing is not much a problem, it is going the other way that is
[10:29:07 CDT(-0500)] <fairwinds> I am currently looking at gson as well
[11:55:53 CDT(-0500)] <fairwinds> apetro: gson json serialization looks very nice
[11:56:49 CDT(-0500)] <fairwinds> I think I will try a bit harder with gson on deserialization as it is a much better supported lib than either xstream or flexjson
[11:57:53 CDT(-0500)] <fairwinds> apetro: it is mean specifically for json to java and back as well where json is sort of an add on to xstream.
[15:40:44 CDT(-0500)] <fairwinds> apetro: ping
[15:41:08 CDT(-0500)] <apetro> pong
[15:41:37 CDT(-0500)] <apetro> I don't know much about serializing and deserializing json, but it all sounds like interesting stuff to be looking at?
[15:41:43 CDT(-0500)] <apetro> don't have much to offer on those fronts
[15:42:12 CDT(-0500)] <fairwinds> sure, I was wondering about the serializability of Tickets for byte arrays also
[15:42:52 CDT(-0500)] <fairwinds> apetro: so if I wanted to serialize to byte array, base64 encode that and store in couchdb that would be fine?
[15:43:17 CDT(-0500)] <fairwinds> and do reverse to get it back
[15:43:57 CDT(-0500)] <fairwinds> apetro: Ticket extends Serializable
[15:44:08 CDT(-0500)] <fairwinds> so this should be possible, correct?
[15:45:05 CDT(-0500)] <apetro> yes, Tickets should be serializable and deserializable
[15:45:14 CDT(-0500)] <fairwinds> apetro: until I get the deserialization right back and forth in JSON, I was thinking short term will set up an implementation that can do with bytes
[15:45:53 CDT(-0500)] <apetro> sounds a fine incremental approach
[15:46:11 CDT(-0500)] <fairwinds> apetro: the gson lib is very nice, but I am going to need a bit more time to get a handle on deserialization bit
[15:47:11 CDT(-0500)] <fairwinds> apetro: will end up with a couple of implementations but in end only want the JSON since I can create a dashboard easily with data stored in the db
[15:48:57 CDT(-0500)] <apetro> dashboard's a fine idea. Something that's come up off and on as enhancements to the current statistics / monitoring panel in the services registry
[15:49:21 CDT(-0500)] <fairwinds> apetro: at least in short term the bytes things should be good. I should finish this today and afterwards will need to work on custom deserializer for TicketGrantingTickets and ServiceTickets
[15:49:54 CDT(-0500)] <fairwinds> apetro: having ticket data in json makes the dashboard very doable
[15:50:52 CDT(-0500)] <apetro> that all sounds fine to me.
[15:54:26 CDT(-0500)] <fairwinds> apetro: I wonder if there is a core CAS dev that knows gson well. I am learning it but could benefit from someone that knows more than I. I am pretty green. The biggest issue is handling class instances withing the object and ensuring there is a way to instantiate those properly with the data
[15:56:07 CDT(-0500)] <fairwinds> apetro: Perhaps I should write a note on mailing list. Having an ability to serialize/deserialize the tickets in JSON generally would not be a bad thing for CAS
[15:57:26 CDT(-0500)] <apetro> sounds like a lovely thing
[15:57:42 CDT(-0500)] <apetro> and entirely suitable for cas email list discussion
[15:57:55 CDT(-0500)] <apetro> cas-dev if you're serious about building the enhancment for CAS server, that is, enhancing the CAS software product
[15:58:12 CDT(-0500)] <apetro> cas-user if you're thinking of yourself as a consumer of the CAS software rather than looking to make a contribution to it
[15:58:13 CDT(-0500)] <fairwinds> apetro: k, yeah that would be the right list