Page Comparison

[07:49:43 CDT(-0500)] <fairwinds> wgthom: gmorning
[07:50:13 CDT(-0500)] <wgthom> hi
[07:52:23 CDT(-0500)] <fairwinds> wgthom: I have got my Auth Handler and Ticket Registry implementations pretty much finished. I was looking at DefaultTicketRegistry tests as I will begin writing my unit tests and found it was very sparse. Only test case was to instantiate it
[07:52:58 CDT(-0500)] <fairwinds> DistributedTicketRegistry tests look much better
[07:53:48 CDT(-0500)] <fairwinds> wgthom: have you got very much experience serializing/deserializing XML or JSON objects to Java and back?
[07:56:00 CDT(-0500)] <wgthom> doesn't the spring remoting taking care of that for you?
[07:56:05 CDT(-0500)] <fairwinds> wgthom: I decided to serialize/deserialize bytes to base64 encoded byteString for storage until I got a better handle on deserializing JSON. No trouble serializing tickets which look very beautiful in JSON, but deserializing is where the fun is
[07:56:53 CDT(-0500)] <wgthom> can couchdb do sync updates?
[07:56:55 CDT(-0500)] <fairwinds> wgthom: Am using gson for serialization to JSON
[07:59:41 CDT(-0500)] <fairwinds> wgthom: I believe that is what I am doing
[08:02:16 CDT(-0500)] <fairwinds> wgthom: currently I am storing JSON plus the byte data so that I can visualize data in the ticket store. Once I get the gson deserialization right for TGT and ST, I will drop the byte data and it will use purely JSON data
[08:05:14 CDT(-0500)] <fairwinds> wgthom: anyway, this thing was a bit more complicated than anticipated at start but I think results will be good
[08:05:55 CDT(-0500)] <wgthom> cool. i think ppl will be interested in couchdb possiblity for HA config
[08:06:23 CDT(-0500)] <fairwinds> wgthom: yeah it is HA for sure and highly scalable
[08:06:40 CDT(-0500)] <fairwinds> you get replication very easily
[08:07:55 CDT(-0500)] <fairwinds> wgthom: one thing that will be particularly cool about what I am doing is that I am creating real time apps with couch. I plan on making a dashboard work this way to display real time data about the authentication system
[08:08:38 CDT(-0500)] <wgthom> nice
[08:08:54 CDT(-0500)] <fairwinds> wgthom: when I mean real time I mean that as folks are logging in and creating service tickets etc, you will be able to see changes in real time
[08:09:36 CDT(-0500)] <fairwinds> in sort of an auth dashboard
[08:21:30 CDT(-0500)] <fairwinds> wgthom: on spring remoting, I am not really a java programmer so knowledge of libs for java is not great. I simply created a byteStringSerializer to serialize Ticket to byteString and back so I can transmit, store and reconstitute object in meantime. I will be dropping this once my gson deserializes the ticket objects properly
[09:17:55 CDT(-0500)] <fairwinds> serac: hey
[09:28:01 CDT(-0500)] <serac> howdy
[09:29:04 CDT(-0500)] <fairwinds> serac: I have a working implementation but had to go to bytes short term
[09:29:16 CDT(-0500)] <serac> go to bytes?
[09:30:16 CDT(-0500)] <fairwinds> serac: yeah. My goal was to serialize ticket objects to JSON and back. I have had some difficulty short term in deserializing JSON back to objects
[09:30:50 CDT(-0500)] <fairwinds> so I am including byteString with JSON to use in registry to reconstitute the object
[09:30:57 CDT(-0500)] <fairwinds> until I get this worked out
[09:31:58 CDT(-0500)] <serac> So it's XStream that's having trouble?
[09:32:27 CDT(-0500)] <fairwinds> serac: yeah
[09:32:53 CDT(-0500)] <fairwinds> serac: I am going to go with gson which is direct back and forth of java objects to JSON
[09:32:54 CDT(-0500)] <serac> Bummer.
[09:33:00 CDT(-0500)] <fairwinds> it is google code
[09:33:06 CDT(-0500)] <fairwinds> from google
[09:33:15 CDT(-0500)] <serac> Let me know how it fares.
[09:33:43 CDT(-0500)] <fairwinds> serac: here is what a TGT presently looks like https://gist.github.com/7515473a96717874ca81
[09:34:05 CDT(-0500)] <serac> looks fine.
[09:34:17 CDT(-0500)] <serac> Human readability is nice. But not really a requirement.
[09:34:28 CDT(-0500)] <fairwinds> serac: that byte data will disappear once I have a proper deserialization in JSON
[09:34:41 CDT(-0500)] <serac> Ah, that's the data field.
[09:34:45 CDT(-0500)] <fairwinds> yeah
[09:34:46 CDT(-0500)] <serac> base-64 encoded bytes?
[09:34:52 CDT(-0500)] <fairwinds> yup
[09:35:00 CDT(-0500)] <serac> makes sense
[09:35:26 CDT(-0500)] <fairwinds> I just created a byte code serializer to do the back and forth since Ticket is serializable
[09:35:47 CDT(-0500)] <serac> sure
[09:36:02 CDT(-0500)] <fairwinds> serac: the issue with the JSON serialization is the instantiation of classes within the Ticket object itself
[09:36:15 CDT(-0500)] <fairwinds> they require args and are not no args
[09:36:19 CDT(-0500)] <serac> Wonder if it's because you dropped class names.
[09:36:36 CDT(-0500)] <serac> oic
[09:36:45 CDT(-0500)] <serac> There are no no-arg constructors.
[09:37:05 CDT(-0500)] <fairwinds> serac: this serialization is from gson
[09:37:11 CDT(-0500)] <fairwinds> as opposed to xtream
[09:37:24 CDT(-0500)] <fairwinds> which omits some of these things
[09:38:05 CDT(-0500)] <fairwinds> it doesnt matter much with gson as I am going to have to create custom deserializer in any case
[09:38:29 CDT(-0500)] <fairwinds> so might as well have JSON readability
[09:38:43 CDT(-0500)] <serac> makes sense
[09:38:52 CDT(-0500)] <serac> readability really is nice
[09:39:57 CDT(-0500)] <fairwinds> serac: here is ST example https://gist.github.com/9a935a1d729769f59a82
[09:40:39 CDT(-0500)] <fairwinds> serac: imagine these without the data field
[09:40:44 CDT(-0500)] <fairwinds> nice huh
[09:40:44 CDT(-0500)] <serac> sure
[09:41:27 CDT(-0500)] <fairwinds> serac: so I have to brush up on gson to determine best way of reconstituting Ticket objects
[09:42:08 CDT(-0500)] <fairwinds> serac: what puzzles me is that if Ticket is serializable in first place, how is it that serialization/deserialization to bytes is so easy?
[09:42:40 CDT(-0500)] <fairwinds> why does it not complain about args for instantiating some of the classes there
[09:43:32 CDT(-0500)] <fairwinds> for example you have an ImmutableAuthentication object holding a Principal
[09:43:51 CDT(-0500)] <fairwinds> and that Class does not have a no args means of instantiation
[09:44:09 CDT(-0500)] <fairwinds> serac: this is where xstream was barking
[09:44:11 CDT(-0500)] <serac> I believe the Java serialization framework has special capabilities to instantiate classes.
[09:44:26 CDT(-0500)] <serac> I don't have a precise answer, though – it's a good question.
[09:44:37 CDT(-0500)] <fairwinds> serac: I need some of that magic
[09:44:52 CDT(-0500)] <serac> Yeah. But I have a question/concern that's more direct.
[09:45:06 CDT(-0500)] <serac> I see that your ST holds an explicit reference to the parent TGT.
[09:45:15 CDT(-0500)] <fairwinds> k
[09:45:18 CDT(-0500)] <serac> At least in the JSON data you shared.
[09:45:21 CDT(-0500)] <fairwinds> right
[09:45:42 CDT(-0500)] <serac> It actually holds the object,not a reference.
[09:45:53 CDT(-0500)] <serac> I would think you'd want to hold a reference to it by TGT ID.
[09:46:21 CDT(-0500)] <serac> Otherwise you might get in a situation where the parent changes and you either have to iterate over all the children to update their data, or, worse, you've got inconsistency.
[09:46:42 CDT(-0500)] <serac> You should give that use case some consideration.
[09:46:50 CDT(-0500)] <serac> It's not an issue under normal circumstances.
[09:47:16 CDT(-0500)] <serac> But when proxying comes into play, you have have complex graphs of tickets.
[09:47:23 CDT(-0500)] <fairwinds> serac: the JSON is only for visualization atm. This particular implementation is based on DefaultRegistry. I have another I am finishing based on distributed
[09:47:24 CDT(-0500)] <serac> TGT is self-referential for a reason.
[09:48:16 CDT(-0500)] <serac> The default in-memory registry uses Java object references to accomplish what I mentioned.
[09:49:22 CDT(-0500)] <fairwinds> serac: right, in this case the object is in byte data atm.
[09:49:53 CDT(-0500)] <serac> I'm assuming there is another entry in the DB that holds the parent TGT as well. Is that correct?
[09:50:02 CDT(-0500)] <fairwinds> yes
[09:50:42 CDT(-0500)] <serac> So you should make sure that when you deserialize, you replace the TGT referenced by the ST with that entry.
[09:51:08 CDT(-0500)] <serac> I suppose there could be other solutions to the issue.
[09:51:17 CDT(-0500)] <serac> But staleness is a concern if you don't address it somehow.
[09:53:01 CDT(-0500)] <fairwinds> serac: right. I am building this up a bit at a time. As soon as i have JSON serialization in proper way, am hoping for a code review
[09:53:08 CDT(-0500)] <serac> ack
[09:53:15 CDT(-0500)] <fairwinds> heh
[09:53:49 CDT(-0500)] <serac> So far what you've shared looks good.
[09:54:12 CDT(-0500)] <serac> The issue I pointed out is a higher-level logical concern – you can totally address it later, but thought it might be helpful to point out now.
[09:54:50 CDT(-0500)] <fairwinds> serac: k, cool. I will save this conversation for reference. the ticket clean up thing, on what sort of schedule does it run?
[09:55:01 CDT(-0500)] <fairwinds> it seems rather random
[09:55:22 CDT(-0500)] <serac> Whatever you configure. IIRC it's 30m by default.
[09:55:50 CDT(-0500)] <fairwinds> serac: it is likely looking random because of my starts and stops
[09:56:47 CDT(-0500)] <serac> Yeah, probably.
[09:57:03 CDT(-0500)] <serac> It does run on startup by default, so that's likely the cause.
[09:58:04 CDT(-0500)] <fairwinds> yeah, I noticed that part but following startup. I have debug going everywhere
[09:58:51 CDT(-0500)] <fairwinds> serac: I noticed that test for default registry are very scant. just one test for instantiation