[07:49:02 CST(-0600)] <dd> hello
[07:52:53 CST(-0600)] <Arvids> hi
[07:59:00 CST(-0600)] <dd> currently, if a user's browser session expires, they are redirected to the guest layout screen
[07:59:11 CST(-0600)] <dd> is there a way to redirect them to the portal?
[07:59:53 CST(-0600)] <dd> i've been googling and have seen people use a "Redirect channel"
[08:00:01 CST(-0600)] <dd> is that still a thing in uportal 3.2.4?
[08:00:54 CST(-0600)] <Arvids> haven't heard of such channel
[08:01:20 CST(-0600)] <dd> ok
[08:02:01 CST(-0600)] <Arvids> ... but i didn't quite get the point of your question - do you want to login users even if their session has expired?
[08:02:02 CST(-0600)] <dd> because they are still logged in at that point. going to http://portal.edu brings them back to their portal
[08:02:51 CST(-0600)] <dd> yeah, their CAS "session" must still be good
[08:03:23 CST(-0600)] <Arvids> ahh... now I get it - SSO session hasn't been expired yet, while portal's session has been expired
[08:03:29 CST(-0600)] <dd> yeah
[08:03:45 CST(-0600)] <dd> what are the default lengths of both?
[08:04:21 CST(-0600)] <dd> i guess an easy way would be to make them both the same length?
[08:04:25 CST(-0600)] <Arvids> length of portal session can be configured in web.xml (under uPortal/WEB-INF/web.xml or server-scope at <tomcat>/conf/web.xml
[08:04:53 CST(-0600)] <Arvids> but i'm not familiar with configuring CAS (we're using OpenAM)
[08:06:42 CST(-0600)] <dd> ok, uportal looks to be 30 minutes. that sound right?
[10:06:40 CST(-0600)] <Arvids> anyone knows why property placeholder config in portlet context isn't inherited from application context?
[10:07:28 CST(-0600)] <EricDalquist> so you have a placeholder set in appCtx but not in portletCtx
[10:07:37 CST(-0600)] <EricDalquist> and there is no placeholder resolution happening in portletCtx?
[10:08:00 CST(-0600)] <Arvids> i'm working with sitemap currently
[10:08:55 CST(-0600)] <Arvids> ... and @Value annotation caused sitemap to be unaccessible
[10:09:14 CST(-0600)] <EricDalquist> and you have the property set?
[10:09:33 CST(-0600)] <Arvids> of course
[10:09:58 CST(-0600)] <EricDalquist> try doing @Value("$ ")
[10:10:10 CST(-0600)] <Arvids> adding explicit "<context:property-placeholder location="classpath:/properties/portal.properties"/>" in portlet context fixes the problem
[10:10:12 CST(-0600)] <EricDalquist> just to see if that gets resolved correctly and the default value gets set
[10:11:49 CST(-0600)] <Arvids> ... strange... I've had the same issue while working with our local portlets and I resolved it by redeclaring property placeholder in portlet context (just like now)
[10:11:59 CST(-0600)] <EricDalquist> huh
[10:12:03 CST(-0600)] <EricDalquist> maybe it doesn't get inherited
[10:12:28 CST(-0600)] <Arvids> well... the strangest thing is that it gets inherited... but not always
[10:12:38 CST(-0600)] <Arvids> i'm not aware of the details why, though 
[10:14:36 CST(-0600)] <EricDalquist> yeah, weird
[10:17:10 CST(-0600)] <Arvids> but now it seems that sitemap will be fixed - consistent URL generation, translatable element titles, working tab groups (this is why i needed property from portal.properties)... and no sign of missing portlets
[10:17:48 CST(-0600)] <EricDalquist> woot!
[10:17:52 CST(-0600)] <EricDalquist> very cool
[10:18:04 CST(-0600)] <Arvids> have to run, though. Will create patch, apply to github and issue pull request tomorrow
[10:18:05 CST(-0600)] <EricDalquist> oh, any thoughts on the hibernate 4.0 upgrade for 4.0.3?
[10:18:11 CST(-0600)] <Arvids> +1
[12:08:33 CST(-0600)] <EricDalquist> so apparently the SQL DATE type doesn't include TZ
[12:08:39 CST(-0600)] <EricDalquist> which is kinda ridiculous
[12:10:53 CST(-0600)] <EricDalquist> hrm ... apparently the sql standard doesn't address tz at all ;p
[12:14:44 CST(-0600)] <athena> ummm . . . wow, really?
[12:14:48 CST(-0600)] <EricDalquist> yeah
[12:15:23 CST(-0600)] <EricDalquist> looks like sql dates/times are all millis from epoch in utc
[12:15:40 CST(-0600)] <athena> fun 
[12:15:40 CST(-0600)] <EricDalquist> and you have to apply the TZ you want when you pull it back out
[12:15:59 CST(-0600)] <EricDalquist> this hibernate support library for jodatime has a bunch of "WithTZ" mapping types
[12:16:03 CST(-0600)] <EricDalquist> that all end up using 2 columns
[12:16:09 CST(-0600)] <EricDalquist> one for the date/time and one for the TZ offset
[12:17:06 CST(-0600)] <athena> lol
[12:17:14 CST(-0600)] <athena> that's irritating
[12:17:15 CST(-0600)] <EricDalquist> yeah
[12:17:41 CST(-0600)] <EricDalquist> yeah
[12:17:54 CST(-0600)] <EricDalquist> I'm trying to figure out how best to persist the various stuff related to events
[12:18:02 CST(-0600)] <EricDalquist> any thoughts on the hibernate/spring updates for 4.0.3?
[12:22:31 CST(-0600)] <athena> dunno
[12:22:41 CST(-0600)] <athena> is the next spring-sec actually out yet?
[12:23:00 CST(-0600)] <EricDalquist> 3.1 is out
[12:26:08 CST(-0600)] <athena> ah ok
[12:26:21 CST(-0600)] <athena> i guess as long as it seems like everything works ok i don't have a problem with it
[12:26:39 CST(-0600)] <EricDalquist> the only slightly annoying thing I ran into with it is that the auto-proxy-class default changed from falst to true
[12:26:42 CST(-0600)] <athena> imagine we don't have a lot of people writing code directly in uportal, much less code that's version-dependent
[12:26:46 CST(-0600)] <EricDalquist> and I had to go set that in a few places
[12:26:50 CST(-0600)] <athena> ah
[12:26:54 CST(-0600)] <EricDalquist> since we don't bundle cglib
[12:26:56 CST(-0600)] <EricDalquist> yeah
[12:27:05 CST(-0600)] <EricDalquist> I have it working and haven't seen any other problems
[12:27:18 CST(-0600)] <EricDalquist> and it will make our long term support of the event aggregation schema better
[12:33:18 CST(-0600)] <athena> that's good 
[12:33:42 CST(-0600)] <EricDalquist> oh and google data vis apis ...
[12:33:51 CST(-0600)] <EricDalquist> should I return a datatable object?
[12:33:55 CST(-0600)] <athena> no, i don't think so
[12:34:04 CST(-0600)] <EricDalquist> I think I have a spring View object that handles those nicely
[12:34:23 CST(-0600)] <EricDalquist> ok, so if not that, how should the data be structured?
[12:34:38 CST(-0600)] <athena> seems like just the aggregation objects have the right info?
[12:34:45 CST(-0600)] <EricDalquist> they do
[12:34:48 CST(-0600)] <EricDalquist> so a list of those is fine?
[12:34:52 CST(-0600)] <athena> yeah, i think that'd be best
[12:34:55 CST(-0600)] <EricDalquist> ok
[12:34:57 CST(-0600)] <EricDalquist> easy enough
[12:35:02 CST(-0600)] <athena> i hate to put the google datatables down quite so deep in the APIs
[12:35:12 CST(-0600)] <EricDalquist> yeah
[12:35:19 CST(-0600)] <athena> especially given the way they've treated their APIs
[12:35:25 CST(-0600)] <EricDalquist> yeah
[12:35:36 CST(-0600)] <athena> don't want to make our code not compile if they change everything (which they probably will . . . )
[12:35:49 CST(-0600)] <EricDalquist> I had an argument with them via an issue tracker over some changes in guava
[12:36:27 CST(-0600)] <athena> how'd that go?
[12:36:40 CST(-0600)] <EricDalquist> no where
[12:37:13 CST(-0600)] <EricDalquist> http://code.google.com/p/guava-libraries/issues/detail?id=881
[12:37:19 CST(-0600)] <EricDalquist> essentially they deprecated an API in r10
[12:37:23 CST(-0600)] <EricDalquist> and replaced it in R11
[12:37:28 CST(-0600)] <EricDalquist> but there is no release that has both old and new
[12:37:39 CST(-0600)] <EricDalquist> which makes upgrading hard since some other libraries use the old API
[12:37:43 CST(-0600)] <EricDalquist> everything has to move together
[12:37:52 CST(-0600)] <athena> lol
[12:37:53 CST(-0600)] <athena> no kidding.
[13:31:48 CST(-0600)] <EricDalquist> athena: should new guest sessions create LoginEvents?
[14:02:18 CST(-0600)] <athena> hmmm.
[14:02:39 CST(-0600)] <athena> my instinct is to want to record session creation events for them but not login events
[14:02:43 CST(-0600)] <athena> do we have such a distinction?
[14:02:49 CST(-0600)] <EricDalquist> we don't right now
[14:03:20 CST(-0600)] <EricDalquist> I've thought about splitting them out but I'm not really sure the best way
[14:03:30 CST(-0600)] <EricDalquist> for guest users you'd just have a SessionCreated event
[14:03:42 CST(-0600)] <EricDalquist> for authd you'd have SessionCreated and Login
[14:03:45 CST(-0600)] <athena> yeah
[14:03:54 CST(-0600)] <athena> i mean i guess if we didn't have that then yes, we'd want a login event
[14:04:05 CST(-0600)] <EricDalquist> though if we want to capture the groups the user is in we should probably do that in the SessionCreated event
[14:04:13 CST(-0600)] <EricDalquist> since even guests can have interesting groups
[14:05:58 CST(-0600)] <EricDalquist> so I guess that is where I get stuck
[14:06:14 CST(-0600)] <EricDalquist> what is the real difference between session creation and login
[14:06:24 CST(-0600)] <EricDalquist> I guess login is the explicit auth request
[14:19:07 CST(-0600)] <athena> yeah
[14:19:09 CST(-0600)] <athena> i think so
[14:19:23 CST(-0600)] <athena> hmm.
[14:19:39 CST(-0600)] <athena> heh, not even quite sure how to get data for my most simple use case here
[14:19:47 CST(-0600)] <EricDalquist> ?
[14:19:56 CST(-0600)] <athena> was thinking i'd start small and just do a pie chart of login groups
[14:20:19 CST(-0600)] <EricDalquist> ah, like logins per groups for a time period?
[14:20:23 CST(-0600)] <athena> yeah
[14:20:31 CST(-0600)] <athena> what do you think the best way to select a time period would be though?
[14:20:43 CST(-0600)] <athena> especially for testing, not necessarily a lot of data
[14:20:46 CST(-0600)] <EricDalquist> well, what sort of time period do you want to display?
[14:20:57 CST(-0600)] <athena> does the aggregator aggregate times before the time period is up?
[14:21:00 CST(-0600)] <EricDalquist> like logins per group for a specific week?
[14:21:01 CST(-0600)] <EricDalquist> yes
[14:21:06 CST(-0600)] <athena> like if i asked for data for the last month, would it give it to me?
[14:21:09 CST(-0600)] <EricDalquist> it updates them as it goes
[14:21:11 CST(-0600)] <EricDalquist> yup
[14:21:14 CST(-0600)] <athena> oh awesome
[14:21:15 CST(-0600)] <athena> ok.
[14:21:27 CST(-0600)] <athena> so would it give it to me even if the aggregation hadn't been running for a month?
[14:21:38 CST(-0600)] <athena> so i could say a month from right now, or whatever?
[14:22:13 CST(-0600)] <EricDalquist> right
[14:22:19 CST(-0600)] <EricDalquist> so if you started running your portal today
[14:22:34 CST(-0600)] <EricDalquist> there will be an aggregation with a DateDimension of Jan 1 2012
[14:22:42 CST(-0600)] <EricDalquist> for the MONTH interval
[14:23:09 CST(-0600)] <EricDalquist> which would have the total and unique login counts for this month
[14:23:34 CST(-0600)] <athena> awesome
[14:23:39 CST(-0600)] <athena> so something like:
[14:23:40 CST(-0600)] <athena> DateDimension date = dateDimensionDao.getDateDimensionByDate(new DateMidnight());
[14:23:40 CST(-0600)] <athena> TimeDimension time = timeDimensionDao.getTimeDimensionByTime(new LocalTime());
[14:23:40 CST(-0600)] <athena> Set<? extends LoginAggregation> aggrs = loginDao.getLoginAggregationsForInterval(date, time, Interval.MONTH);
[14:23:44 CST(-0600)] <athena> does that seem plausible?
[14:23:55 CST(-0600)] <EricDalquist> ah yeah
[14:24:22 CST(-0600)] <EricDalquist> I think there may end up being either sub-selects or utility methods on the dimension daos
[14:24:45 CST(-0600)] <EricDalquist> since you need to answer they "give me the first DateDimension in interval X for DateMidnight Y"
[14:24:59 CST(-0600)] <EricDalquist> since that is the DateDimension you need to actually query with
[14:25:38 CST(-0600)] <athena> not sure i'm following
[14:26:08 CST(-0600)] <EricDalquist> so in the DB each LoginAggregation row has a reference to a DateDimension and a TimeDimension
[14:26:39 CST(-0600)] <EricDalquist> there is no MONTH aggregate for the DateDimension(JAn 23, 2012)
[14:26:43 CST(-0600)] <EricDalquist> oh ... dug
[14:26:45 CST(-0600)] <EricDalquist> duh
[14:26:47 CST(-0600)] <EricDalquist> just a sec
[14:26:58 CST(-0600)] <athena> oh oops.
[14:27:06 CST(-0600)] <EricDalquist> I have an easy solution
[14:27:10 CST(-0600)] <athena> meant to do datemidnight - one month, or whatever jodatime does for that
[14:27:12 CST(-0600)] <EricDalquist> just need to smack eclipse a few times first
[14:27:12 CST(-0600)] <athena> would that work?
[14:27:20 CST(-0600)] <EricDalquist> it does, for months
[14:27:24 CST(-0600)] <athena> clearly i need to eat lunch
[14:27:24 CST(-0600)] <EricDalquist> but there is a helper class
[14:27:26 CST(-0600)] <athena> ooh
[14:27:27 CST(-0600)] <EricDalquist> that does this all for you
[14:27:39 CST(-0600)] <EricDalquist> since for things like weeks, quarters and terms it isn't so simple
[14:28:03 CST(-0600)] <EricDalquist> Inject IntervalHelper
[14:28:07 CST(-0600)] <EricDalquist> IntervalInfo getIntervalInfo(Interval interval, DateTime date)
[14:28:33 CST(-0600)] <EricDalquist> so you do: IntervalInfo info = intervalHelper.getIntervalInfo(Interval.MONTH, new DateTime());
[14:28:35 CST(-0600)] <athena> ahh, excellent
[14:28:44 CST(-0600)] <athena> yes that sounds much cleaner
[14:28:45 CST(-0600)] <athena> thanks!
[14:29:09 CST(-0600)] <EricDalquist> IntervalInfo is a simple pojo that consists of the start DateTime (inclusive), end DateTime (exclusive), start DateDimension, and start TimeDimension
[14:29:33 CST(-0600)] <EricDalquist> use those date/time dimensions objects in your query against the login aggregates
[14:30:01 CST(-0600)] <athena> excellent
[14:30:17 CST(-0600)] <EricDalquist> and that will work correctly for all intervals
[14:30:41 CST(-0600)] <EricDalquist> note that info requests for ACADEMIC_TERM will return null if no term configuration has been done
[14:31:05 CST(-0600)] <EricDalquist> eclipse is NOT cooporating today
[14:32:05 CST(-0600)] <EricDalquist> also in the login aggregation model the duration property is the number of minutes in the aggregated interval
[14:32:10 CST(-0600)] <EricDalquist> that field is updated as aggregation is done
[14:32:37 CST(-0600)] <EricDalquist> so for things like the current month it tells you the number of minutes from the start of the month to the most recently aggregated event
[14:32:50 CST(-0600)] <athena> i hate when eclipse misbehaves
[14:33:13 CST(-0600)] <EricDalquist> my work machine in general is getting bad
[14:33:45 CST(-0600)] <EricDalquist> and I'm loathe to upgrade to the latest ubuntu ... need to find a new linux distro I guess
[14:43:34 CST(-0600)] <athena> oh ubuntu not working out well right now?
[14:43:56 CST(-0600)] <EricDalquist> well my current install seems to be getting flakier
[14:44:05 CST(-0600)] <EricDalquist> and upgrading would mean the unity interface
[14:44:07 CST(-0600)] <EricDalquist> which I've tried
[14:44:11 CST(-0600)] <EricDalquist> and don't want any part of
[14:44:25 CST(-0600)] <athena> ahh
[14:44:29 CST(-0600)] <athena> ooh the chart works!
[14:44:36 CST(-0600)] <athena> of course, actually this chart makes no sense whatsoever
[14:44:39 CST(-0600)] <EricDalquist> lol
[14:44:43 CST(-0600)] <athena> since groups aren't mutually exclusive
[14:44:45 CST(-0600)] <athena> but hey, a graph!
[14:44:47 CST(-0600)] <EricDalquist> yup
[14:44:52 CST(-0600)] <athena> mmmm shiny colors
[14:44:53 CST(-0600)] <athena> ok.
[14:44:55 CST(-0600)] <EricDalquist> are you just doing straight sql?
[14:44:57 CST(-0600)] <athena> no
[14:45:08 CST(-0600)] <EricDalquist> oh even better
[14:45:16 CST(-0600)] <athena> yes, except for the uselessness
[14:45:23 CST(-0600)] <EricDalquist> lol
[14:45:26 CST(-0600)] <athena> so i guess now what i really need to do is go use JPA to add some new methods to the DAO so we can make charts that make sense?
[14:45:34 CST(-0600)] <EricDalquist> well maybe a nice line chart of logins/unique logins over time
[14:45:47 CST(-0600)] <athena> yeah, that's exactly my thought
[14:45:57 CST(-0600)] <athena> actually this current chart would be ok as a bar chart
[14:46:04 CST(-0600)] <EricDalquist> yeah
[14:46:07 CST(-0600)] <athena> but yeah, graphing logins/time period would be good
[14:46:39 CST(-0600)] <EricDalquist> https://my-reports.doit.wisc.edu/StatsReporter/reports/loginReport.html
[14:46:42 CST(-0600)] <EricDalquist> that is what we have right now
[14:46:44 CST(-0600)] <EricDalquist> agaisnt our old tool
[14:46:52 CST(-0600)] <EricDalquist> my only gripe is I want one more option
[14:46:58 CST(-0600)] <athena> so i probably need a DAO that returns something like what we have now, but returns a list of aggregation objects across some time period
[14:47:01 CST(-0600)] <EricDalquist> to say if I want total, unique or both
[14:47:07 CST(-0600)] <athena> yeah
[14:47:07 CST(-0600)] <EricDalquist> yeah
[14:47:12 CST(-0600)] <athena> this is exactly the kidn of thing i was thinking
[14:47:27 CST(-0600)] <athena> thinking we might want it to get data via ajax so it auto-updates when you select different options?
[14:47:43 CST(-0600)] <EricDalquist> yup