...
[11:19:59 CST(-0600)] <athena> have CAS login working
[11:20:09 CST(-0600)] <athena> and local login, though that's only with spring's default login page
[11:20:14 CST(-0600)] <athena> so outstanding stuff includes
[11:20:23 CST(-0600)] <athena> 1. login portlet that can work w/ the local login stuff
[11:20:31 CST(-0600)] <athena> 2. recreating all the impersonation stuff
[11:20:37 CST(-0600)] <athena> 3. CAS clearpass
[11:20:48 CST(-0600)] <athena> 4. Proxy CAS and making sure CAS tickets get into the userinfomap
[11:20:53 CST(-0600)] <athena> 5. getting passwords into the userinfo map
[11:20:58 CST(-0600)] <athena> and probably some other stuff
[11:21:07 CST(-0600)] <athena> so certainly not done, but maybe working enough to be interesting
[11:22:30 CST(-0600)] <EricDalquist> very interesting
[11:22:37 CST(-0600)] <athena> yeah
[11:22:40 CST(-0600)] <athena> i mean, it does work
[11:22:43 CST(-0600)] <athena> reasonably clean
[11:22:52 CST(-0600)] <athena> not thrilled about the state of their documentation or their autowiring business
[11:23:01 CST(-0600)] <EricDalquist> :/
[11:23:05 CST(-0600)] <athena> and not thrilled that it seems the portal just silently fails to start up when things are misconfigured
[11:23:09 CST(-0600)] <athena> don't know what's going on there
[11:24:37 CST(-0600)] <EricDalquist> :/
[11:24:39 CST(-0600)] <EricDalquist> that is no fun
[11:24:41 CST(-0600)] <athena> yeah
[11:25:13 CST(-0600)] <athena> seems like what crashes it is usually a mismatch between the expected bean properties and what's misconfigured in the spring file
[11:25:22 CST(-0600)] <athena> but don't understand why that doesn't seem to produce more stack traces
[11:25:37 CST(-0600)] <EricDalquist> yeah
[12:00:10 CST(-0600)] <EricDalquist> so just discovered this: http://eggsylife.co.uk/2010/02/03/spring-annotation-based-aop-and-intercepting-the-ball/
[12:00:18 CST(-0600)] <EricDalquist> how to write a custom annotation
[12:00:25 CST(-0600)] <EricDalquist> and associate an interceptor with it
[12:00:30 CST(-0600)] <EricDalquist> in ~ 30 minutes
[12:57:17 CST(-0600)] <athena> ooo
[12:57:25 CST(-0600)] <athena> that sounds aawesome
[12:57:38 CST(-0600)] <EricDalquist> just finished uit
[12:57:51 CST(-0600)] <EricDalquist> there will be a @RequestCache annotation
[12:58:03 CST(-0600)] <EricDalquist> methods annotated with it will cache their result in the attributes of the current request
[12:58:16 CST(-0600)] <EricDalquist> and automatically re-use the cached result for the duration of the request
[12:58:35 CST(-0600)] <EricDalquist> Arvids had noticed that thigns like looking up the default tab nodeid ran for every url generation'
[12:58:44 CST(-0600)] <EricDalquist> even though that is the same for every urkl in the reuqest
[14:03:58 CST(-0600)] <EricDalquist> https://github.com/Jasig/uPortal/commit/68051fb9c9aa683f32d00a0fc8ac97fd900e8faa
[14:04:01 CST(-0600)] <EricDalquist> there we go
[14:05:33 CST(-0600)] <athena> oh nice
[14:05:41 CST(-0600)] <athena> is that the performance stuff he wanted to talk about before?
[14:05:54 CST(-0600)] <EricDalquist> well it is part of addressing it
[14:06:03 CST(-0600)] <EricDalquist> apparently xpath in the core JDK apis is terribly slow
[14:06:22 CST(-0600)] <athena> ah, interesting
[14:06:29 CST(-0600)] <EricDalquist> like 5-60ms to get the tabid for a random layout node id
[14:06:38 CST(-0600)] <EricDalquist> and that would run every time a url was generated
[14:06:41 CST(-0600)] <athena> oh wow
[14:06:47 CST(-0600)] <athena> yeah i guess that'd make a difference 
[14:07:19 CST(-0600)] <EricDalquist> he got a huge boost by just navigating the DOM manually
[14:07:25 CST(-0600)] <EricDalquist> his patch just did it in the wrong place
[14:07:43 CST(-0600)] <EricDalquist> the other patch that helped a lot was not looking up portlet entities directly by user+layout+node
[14:07:51 CST(-0600)] <EricDalquist> instead getting all entities for user+layout
[14:07:59 CST(-0600)] <EricDalquist> then iterate on them comparing the nodes
[14:08:04 CST(-0600)] <athena> sounds like really good stuff
[14:08:06 CST(-0600)] <EricDalquist> yeah
[14:08:16 CST(-0600)] <athena> really glad he's involved
[14:08:21 CST(-0600)] <EricDalquist> a lot of this stuff is a result of only being part way to hibernate/jpa
[14:08:30 CST(-0600)] <athena> ah, yeah
[14:08:39 CST(-0600)] <EricDalquist> if everything was actually part of our JPA model we could essentially load it all when the user logs in
[14:08:49 CST(-0600)] <EricDalquist> or load it in reasonable chunks
[14:09:01 CST(-0600)] <EricDalquist> getting users + layouts moved over will be huge for reducing DB io
[14:09:05 CST(-0600)] <athena> yeah
[14:09:09 CST(-0600)] <EricDalquist> since then we can really have one object graph per user
[14:09:11 CST(-0600)] <athena> would love to get that work done
[14:09:18 CST(-0600)] <athena> maybe after stats?
[14:09:20 CST(-0600)] <EricDalquist> and load the whole graph at login with a minimal number of calls
[14:09:21 CST(-0600)] <EricDalquist> yeah
[14:09:24 CST(-0600)] <EricDalquist> after stats
[14:09:28 CST(-0600)] <athena> how's the stats stuff going, by the way?
[14:09:32 CST(-0600)] <EricDalquist> and after I get 4.0 deployed here
[14:09:33 CST(-0600)] <EricDalquist> good
[14:09:40 CST(-0600)] <EricDalquist> the branch is making good progress
[14:09:48 CST(-0600)] <EricDalquist> I just keep realizing more gotchas 
[14:09:50 CST(-0600)] <athena> lol
[14:09:55 CST(-0600)] <EricDalquist> I had forgotten how complex that aggregator was
[14:10:01 CST(-0600)] <EricDalquist> its translating over just fine
[14:10:11 CST(-0600)] <EricDalquist> it is just A LOT of daos/entities
[14:10:23 CST(-0600)] <athena> yeahi 'm sure
[14:12:21 CST(-0600)] <EricDalquist> here is the work so far: https://github.com/edalquist/uPortal/compare/master...event-aggr
[14:14:16 CST(-0600)] <EricDalquist> most important stuff that you'll be interested in is:
[14:14:16 CST(-0600)] <EricDalquist> https://github.com/edalquist/uPortal/compare/master...event-aggr#diff-44
[14:14:16 CST(-0600)] <EricDalquist> https://github.com/edalquist/uPortal/compare/master...event-aggr#diff-42
[14:20:46 CST(-0600)] <athena> awesome
[14:21:05 CST(-0600)] <athena> i'll take a look
[14:21:57 CST(-0600)] <EricDalquist> the api is still going to change a little bit
[14:22:03 CST(-0600)] <EricDalquist> that is what I just realized
[14:22:07 CST(-0600)] <EricDalquist> but its getting closer
[14:22:39 CST(-0600)] <EricDalquist> the other thing I need to do (in addition to the term/quarter config) is allow configuration of what groups and intervals each aggregator sees
[14:22:57 CST(-0600)] <EricDalquist> I have a feeling I'm just going to have to write an even aggregation admin flow :/
[14:25:46 CST(-0600)] <athena> ahhh
[14:25:47 CST(-0600)] <athena> hmm.
[14:25:52 CST(-0600)] <athena> yeah