Page Comparison

[08:46:28 EDT(-0400)] * michelled (n=team@142.150.154.197) has joined ##uportal
[09:19:54 EDT(-0400)] * anastasiac (n=team@142.150.154.105) has joined ##uportal
[09:32:22 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[09:59:50 EDT(-0400)] * anastasiac (n=team@142.150.154.105) has joined ##uportal
[10:01:25 EDT(-0400)] * theclown (n=theclown@142.150.154.101) has joined ##uportal
[11:00:58 EDT(-0400)] * athena7 (n=athena7@lumina.its.yale.edu) has joined ##uportal
[11:01:19 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[11:02:41 EDT(-0400)] * anastasiac (n=team@142.150.154.105) has joined ##uportal
[11:19:00 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[11:23:28 EDT(-0400)] * anastasiac (n=team@142.150.154.105) has joined ##uportal
[11:26:53 EDT(-0400)] <athena7> oh ugh
[11:27:02 EDT(-0400)] <athena7> the z-index fix i'd used is really broken in IE
[11:53:32 EDT(-0400)] * holdorph (n=holdorph@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[11:53:43 EDT(-0400)] <KWhat_Work> ahhh the new version of uportal out yet?
[12:00:51 EDT(-0400)] <KWhat_Work> anyone her e?
[12:01:16 EDT(-0400)] <EricDalquist> hey, no 3.0 is not out yet
[12:01:26 EDT(-0400)] <EricDalquist> we're working on lots of testing right now
[12:01:28 EDT(-0400)] <KWhat_Work> 2.6.1 java 1.5 ?
[12:01:38 EDT(-0400)] <EricDalquist> and plan on releasing this week
[12:01:43 EDT(-0400)] <EricDalquist> ?
[12:01:43 EDT(-0400)] <KWhat_Work> ohh
[12:01:44 EDT(-0400)] <KWhat_Work> no kidding
[12:01:57 EDT(-0400)] <KWhat_Work> maybe i will hold off for a week =)
[12:02:09 EDT(-0400)] <KWhat_Work> i was wondering if 2.6 was java 1.5 compatible
[12:02:12 EDT(-0400)] <KWhat_Work> i dont remmber
[12:02:51 EDT(-0400)] <EricDalquist> I believe it requires 1.5
[12:03:00 EDT(-0400)] <KWhat_Work> cool
[12:03:04 EDT(-0400)] <EricDalquist> or above
[12:05:25 EDT(-0400)] <holdorph> uPortal 2.6.x definitely requires 1.5 as a minimum, and will compile/run against 1.6 as well.
[12:06:20 EDT(-0400)] <EricDalquist> thanks holdorph
[12:08:18 EDT(-0400)] <holdorph> what's sad is I probably know the answer for uPortal 2.4 and 2.5 as well. so much useless knowlege stuck in my head.
[12:19:39 EDT(-0400)] <dstn> lol
[12:19:55 EDT(-0400)] <dstn> at least your marketable
[12:20:16 EDT(-0400)] <dstn> with all your "useless knowledge"
[12:22:28 EDT(-0400)] <holdorph> whats the going rate for "useless knowledge" pennies?
[12:30:02 EDT(-0400)] <athena7> dunno
[12:47:09 EDT(-0400)] <EricDalquist> ok ... this is really weird ....
[12:47:37 EDT(-0400)] <EricDalquist> trying to get a load test script setup to do some memory profiling of up3 today
[12:48:05 EDT(-0400)] <EricDalquist> whenever the script tries to render the admin tests tab the first pluto portlet fails with: http://uportal.pastebin.com/d5fdcd89b
[12:48:11 EDT(-0400)] <EricDalquist> rendering in my browser is just fine
[12:49:35 EDT(-0400)] <athena7> hmmmm
[12:49:42 EDT(-0400)] <athena7> that's weird
[12:49:52 EDT(-0400)] * theclown_ (n=theclown@142.150.154.101) has joined ##uportal
[12:49:52 EDT(-0400)] <EricDalquist> and this isn't load or anything
[12:50:00 EDT(-0400)] <EricDalquist> just a single jmeter thread stepping through the script
[12:50:20 EDT(-0400)] <athena7> weird
[12:50:32 EDT(-0400)] <EricDalquist> yeah
[12:53:47 EDT(-0400)] <athena7> i really need some jquery help
[12:53:48 EDT(-0400)] <athena7> ugh
[12:59:34 EDT(-0400)] <athena7> ok, tickets filed
[12:59:44 EDT(-0400)] <EricDalquist> great
[13:00:38 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[13:01:17 EDT(-0400)] <athena7> colin, i have a jquery question for you
[13:14:13 EDT(-0400)] * awills (n=awills@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[13:15:10 EDT(-0400)] * anastasiac (n=team@142.150.154.105) has joined ##uportal
[13:15:59 EDT(-0400)] <awills> EricDalquist – you there?
[13:16:19 EDT(-0400)] <EricDalquist> anyone know if javac/jit would optimize the following method local assignment out?
[13:16:20 EDT(-0400)] <EricDalquist> static Object o;
[13:16:20 EDT(-0400)] <EricDalquist> public static void do() {
[13:16:20 EDT(-0400)] <EricDalquist> Object l = o;
[13:16:20 EDT(-0400)] <EricDalquist> //do something with l
[13:16:20 EDT(-0400)] <EricDalquist> }
[13:16:23 EDT(-0400)] <EricDalquist> awills: yes
[13:16:50 EDT(-0400)] <michelled> athena7: can I help?
[13:16:55 EDT(-0400)] <EricDalquist> and I got the outline, I'll try to fire back with some questions as soon as the up3 testing is done
[13:17:08 EDT(-0400)] <athena7> michelled, yes! i didn't realize you were around
[13:17:15 EDT(-0400)] <awills> ah cool, np
[13:17:17 EDT(-0400)] <michelled> Just got back from lunch
[13:17:23 EDT(-0400)] <athena7> so what i'd like to do is be able to get the enclosing div for an element
[13:17:24 EDT(-0400)] <awills> eric i'm looking at this: http://pastebin.com/m3eae2cb4
[13:17:39 EDT(-0400)] <athena7> the jquery parent() method seems to return the right thing in firefox but not ie
[13:18:05 EDT(-0400)] <awills> as we discussed yesterday, i agree the top lines are important, but i believe the highlighted lines are unnecessary
[13:18:22 EDT(-0400)] <michelled> interesting. I did something similar but I can't remember the details one sec while I look ...
[13:18:24 EDT(-0400)] <athena7> in IE i think it just returns the body element or something
[13:18:24 EDT(-0400)] <EricDalquist> ah
[13:18:28 EDT(-0400)] <awills> b/c the crn runtime does exactly that on its own
[13:18:30 EDT(-0400)] <EricDalquist> yeah, they probably are
[13:18:42 EDT(-0400)] <athena7> which i assume is because the element has position: relative
[13:18:44 EDT(-0400)] <athena7> thanks
[13:18:44 EDT(-0400)] <EricDalquist> I had forgotten about that
[13:20:27 EDT(-0400)] <awills> and removing those 2 lines means: (1) no need for an API change, and (2) no "lateral" imports (which I have a strange allergy to)
[13:20:37 EDT(-0400)] <EricDalquist> yup
[13:23:13 EDT(-0400)] <michelled> athena7: are you looking at the first thing in the resulting set? I wouldn't be surprised if the order the parents are returned in is different - I guess it's not something I would ever want to depend on.
[13:23:36 EDT(-0400)] <athena7> yeah, i am
[13:23:39 EDT(-0400)] <athena7> thanks, that's a good point
[13:24:01 EDT(-0400)] <athena7> maybe i can try grabbing the element out of the set by the css class or something?
[13:24:07 EDT(-0400)] <michelled> We used the jquery 'grep' to find the actual parent we were interested in.
[13:26:20 EDT(-0400)] <michelled> the parent css selector doesn't seem to do exactly what you want. Perhaps when used in conjunction with something else. You require the immediate parent of the element?
[13:26:41 EDT(-0400)] <athena7> yeah
[13:26:48 EDT(-0400)] <athena7> it doesn't have an ID
[13:27:00 EDT(-0400)] <athena7> although it does have a predictable css class
[13:27:01 EDT(-0400)] <athena7> hm
[13:27:14 EDT(-0400)] <athena7> at least looking at this in firebug it looks like parent() only returns one element
[13:27:45 EDT(-0400)] <michelled> interesting - the docs say a set.
[13:27:59 EDT(-0400)] <athena7> sorry, i mean a set with just one element
[13:28:18 EDT(-0400)] <michelled> and in IE it's the body?
[13:28:28 EDT(-0400)] <athena7> i think so, need to double check
[13:28:51 EDT(-0400)] <athena7> i need an IE debugging console, argh
[13:29:06 EDT(-0400)] <michelled> I use firebug lite not ideal but does the trick
[13:29:11 EDT(-0400)] <colinclark> ie 8 has a firebug clone. don't know what state it's in.
[13:29:26 EDT(-0400)] <colinclark> (i'm on a conference call at the moment; sorry I haven't been able to follow this thread more closely)
[13:29:27 EDT(-0400)] <athena7> i think i have something set up on my home desktop, but not on this vmware install
[13:29:31 EDT(-0400)] <colinclark>
[13:29:33 EDT(-0400)] <athena7> no worries colin
[13:31:37 EDT(-0400)] <athena7> ok
[13:31:43 EDT(-0400)] <athena7> looks like maybe i am getting the right element
[13:33:44 EDT(-0400)] <michelled> cool!
[13:33:50 EDT(-0400)] <athena7> so it looks like my problem is actually the differing results of clientheight in IE and Firefox
[13:33:59 EDT(-0400)] <athena7> i'd been hoping previously that that wouldn't actually be the problem
[13:34:07 EDT(-0400)] <athena7> ugh
[13:34:11 EDT(-0400)] <colinclark> really? woah.
[13:35:43 EDT(-0400)] <athena7> wait, how did i miss that there's actually a height() function in jquery??
[13:35:55 EDT(-0400)] <colinclark>
[13:36:04 EDT(-0400)] <colinclark> jQuery is great.
[13:36:08 EDT(-0400)] <athena7> that's like, way better, anyway
[13:36:11 EDT(-0400)] <athena7> yes, it really is
[13:36:15 EDT(-0400)] <athena7> oh this will make so much more sense
[13:36:42 EDT(-0400)] <colinclark> I find my thinking is now the reverse. I generally assume whatever I need is in jQuery, and am surprised when it's not.
[13:36:49 EDT(-0400)] <athena7> yeah me too
[13:36:55 EDT(-0400)] <athena7> i really don't know how it missed that method
[13:37:00 EDT(-0400)] <athena7> of course they'd have something useful like that!
[13:38:41 EDT(-0400)] <athena7> the flyout menus script should probably be using that method too
[13:38:54 EDT(-0400)] <athena7> thanks for the help michelle
[13:45:03 EDT(-0400)] <michelled> no problem athena7!
[13:45:26 EDT(-0400)] <athena7> i'm glad someone noticed that bug
[13:45:45 EDT(-0400)] <athena7> made all the dialog boxes unusable in IE
[14:25:26 EDT(-0400)] <athena7> yea, that awful bug really is fixed now
[14:26:07 EDT(-0400)] <EricDalquist> yay
[14:26:13 EDT(-0400)] <athena7> yeah
[14:26:28 EDT(-0400)] <athena7> turns out there were some artifacts appearing in the ivy skin too, so i think that's all fixed now
[14:26:46 EDT(-0400)] <EricDalquist> cool
[14:34:39 EDT(-0400)] * anastasiac (n=team@142.150.154.105) has joined ##uportal
[14:55:45 EDT(-0400)] <athena7> great, i've confirmed that the CAS proxy portlet stuff does work in the trunk
[14:56:11 EDT(-0400)] <athena7> i'll check in the configuration change for the portlet container context
[14:56:22 EDT(-0400)] <athena7> hm
[14:56:24 EDT(-0400)] <EricDalquist> cool
[14:56:47 EDT(-0400)] <EricDalquist> with my little bit of load testing so far I found a regression I'm going to have to figure out how to fix today
[14:57:03 EDT(-0400)] <EricDalquist> in 2.6 portlet session invalidation was added
[14:57:03 EDT(-0400)] <athena7> what's happening?
[14:57:11 EDT(-0400)] <EricDalquist> and I never added it back in with the container switch
[14:57:16 EDT(-0400)] <athena7> ahh
[14:57:29 EDT(-0400)] <EricDalquist> so the portlet app sessions are just left to timeout
[14:57:33 EDT(-0400)] <athena7> ahh
[14:57:35 EDT(-0400)] <athena7> gotcha
[14:57:37 EDT(-0400)] <EricDalquist> not horrible but not optimal either
[14:57:40 EDT(-0400)] <athena7> yeah
[14:57:45 EDT(-0400)] <athena7> good if we could get that working again
[14:57:52 EDT(-0400)] <athena7> probably not the end of the world if it's not feasible
[14:58:19 EDT(-0400)] <EricDalquist> it should be
[14:58:38 EDT(-0400)] <athena7> i want to try and test the calendar portlet with the older postgres driver today
[14:58:55 EDT(-0400)] <athena7> since i've yet to replicate it, i'm sort of guessing it might be a bug in the driver or something
[14:59:30 EDT(-0400)] <athena7> hm i'm getting a build test failure after the cas fix
[14:59:51 EDT(-0400)] <EricDalquist> cool
[14:59:56 EDT(-0400)] <EricDalquist> oh and the cas login fix is in
[15:00:19 EDT(-0400)] <athena7> i saw the jira ticket got resolved so i was trying to see it
[15:00:47 EDT(-0400)] <athena7> i guess probably one of the tests isn't updated yet to match?
[15:01:08 EDT(-0400)] <EricDalquist> ?
[15:01:15 EDT(-0400)] <EricDalquist> is something else failing now?
[15:01:25 EDT(-0400)] <athena7> yeah
[15:01:33 EDT(-0400)] <EricDalquist> that's what I get for not testing it well
[15:01:36 EDT(-0400)] <athena7> the build fails tests
[15:01:39 EDT(-0400)] <athena7> specfically
[15:01:41 EDT(-0400)] <athena7> [exec] Tests in error:
[15:01:41 EDT(-0400)] <athena7> [exec] testNonExistantUser(org.jasig.portal.cas.authentication.handler.support.PortalPersonDirUserPasswordDaoTest)
[15:01:41 EDT(-0400)] <EricDalquist> ok
[15:01:41 EDT(-0400)] <athena7> [exec] testSingleUser(org.jasig.portal.cas.authentication.handler.support.PortalPersonDirUserPasswordDaoTest)
[15:01:41 EDT(-0400)] <athena7> [exec] testDuplicateUser(org.jasig.portal.cas.authentication.handler.support.PortalPersonDirUserPasswordDaoTest)
[15:01:54 EDT(-0400)] <EricDalquist> oh .... duh
[15:01:56 EDT(-0400)] <EricDalquist> sorry
[15:02:01 EDT(-0400)] <EricDalquist> trying to do things too fast
[15:02:01 EDT(-0400)] <athena7> no problem
[15:02:11 EDT(-0400)] <athena7> yeah me too, apparently
[15:02:56 EDT(-0400)] <EricDalquist> I ran the tests in eclipse
[15:02:59 EDT(-0400)] <EricDalquist> which has hsql in the classpath
[15:03:05 EDT(-0400)] <EricDalquist> I forgot to add it to the cas pom
[15:03:18 EDT(-0400)] <athena7> ah
[15:03:22 EDT(-0400)] <athena7> totally not a big deal
[15:03:28 EDT(-0400)] <athena7> oooh it's my yale email in the duke mail portlet
[15:03:30 EDT(-0400)] <athena7> yea
[15:03:43 EDT(-0400)] <EricDalquist> lol
[15:04:09 EDT(-0400)] <athena7> well the yale imap servers use pam cas
[15:04:21 EDT(-0400)] <athena7> so for the portal, we log users in with their netid and a cas proxy ticket
[15:04:49 EDT(-0400)] <athena7> so i was testing being able to get a ticket from the portal for the portlet itself, then have the portlet request one for the imap service
[15:05:05 EDT(-0400)] <EricDalquist> ok, the updated pom is comitted
[15:05:08 EDT(-0400)] <athena7> then use that last ticket in combination with the user id provided by the userinfo service to log into the imap server
[15:05:21 EDT(-0400)] <athena7> pleased that all this seems to work flawlessly with up3
[15:05:38 EDT(-0400)] <EricDalquist> very cool
[15:05:59 EDT(-0400)] <EricDalquist> I think this will be one of the big joys with portlets going forward
[15:06:08 EDT(-0400)] <EricDalquist> we can do more fun things in the framework
[15:06:14 EDT(-0400)] <athena7> up3 is making me really happy development wise
[15:06:15 EDT(-0400)] <EricDalquist> with fewer concerns about breaking people's apps
[15:06:20 EDT(-0400)] <EricDalquist> good
[15:06:21 EDT(-0400)] <athena7> i have that guest stuff working now
[15:06:23 EDT(-0400)] <EricDalquist> same here
[15:06:31 EDT(-0400)] <athena7> although i'll still have to sort out the user layout caching issue
[15:06:35 EDT(-0400)] <EricDalquist> I cringe more and more every time I have to go fix stuff in our 2.5 codebase
[15:06:44 EDT(-0400)] <athena7> yeah i bet!
[15:06:50 EDT(-0400)] <athena7> this is just so fun to develop for though
[15:07:04 EDT(-0400)] <athena7> because rather than just modifying the source code i was able to add and reconfigure
[15:07:14 EDT(-0400)] <EricDalquist> so if you're working on the caching issue in 3.0 you should just look at using the new caching framework
[15:07:23 EDT(-0400)] <EricDalquist> yup
[15:07:35 EDT(-0400)] <athena7> yeah that'd be great
[15:07:37 EDT(-0400)] <EricDalquist> uhg
[15:07:42 EDT(-0400)] <EricDalquist> I messed something up again
[15:07:46 EDT(-0400)] <EricDalquist> hold on ...
[15:08:26 EDT(-0400)] <EricDalquist> I tested it then accidentally deleted a char then committed
[15:08:30 EDT(-0400)] <EricDalquist> all fixed for real now
[15:08:38 EDT(-0400)] <athena7>
[15:09:15 EDT(-0400)] <athena7> so for the new behavior, i just made a new user instance manager implementation
[15:09:21 EDT(-0400)] <athena7> and created a union one that chains them together
[15:09:38 EDT(-0400)] <athena7> so it tries out the cookie behavior, then falls back to the simple version if no cookie exists
[15:09:56 EDT(-0400)] <athena7> and it'd be really easy to create new ones to assign guests based on IP addresses, like yale's done in the past
[15:09:56 EDT(-0400)] <EricDalquist> nice
[15:09:59 EDT(-0400)] <athena7> or whatever else you want
[15:10:13 EDT(-0400)] <EricDalquist> the joys of interface/service based design
[15:11:07 EDT(-0400)] <athena7> yeah definitely
[15:11:44 EDT(-0400)] <athena7> i'm hoping maybe we can contribute that code after up3 is released
[15:11:55 EDT(-0400)] <EricDalquist> that would be neat
[15:12:08 EDT(-0400)] <athena7> yeah
[15:12:11 EDT(-0400)] <EricDalquist> I'm hoping once we release and branch people will start hacking interesting things into the trunk for 3.1
[15:12:29 EDT(-0400)] <athena7> it looks like the stuff that allows you to use the local connection contexts in CWebProxy and CSyndFeed are local yale customizations too
[15:12:33 EDT(-0400)] <athena7> yeah that'd be great
[15:14:17 EDT(-0400)] <athena7> i'd really been hoping that we could take pretty much all the yale mods and contribute them or drop them
[15:15:05 EDT(-0400)] <EricDalquist> yeah, same here
[15:15:19 EDT(-0400)] <EricDalquist> though we probably won't really get to the meat of doing that until after we're on 3
[15:15:22 EDT(-0400)] <EricDalquist> just not enough time
[15:15:25 EDT(-0400)] <athena7> spring really helps, since you can just change the configuration, instead of making changes in the source
[15:15:26 EDT(-0400)] <athena7> yeah
[15:15:40 EDT(-0400)] <EricDalquist> yup
[15:19:39 EDT(-0400)] <athena7> hmmm
[15:19:50 EDT(-0400)] <athena7> i'm still getting an error when i put in a bad username
[15:20:03 EDT(-0400)] <EricDalquist> still a stack trace?
[15:20:08 EDT(-0400)] <athena7> yeah
[15:20:13 EDT(-0400)] <EricDalquist> can you pastebin it for me?
[15:20:18 EDT(-0400)] <athena7> sure
[15:20:51 EDT(-0400)] <athena7> http://uportal.pastebin.com/m76e24162
[15:20:55 EDT(-0400)] <athena7> i did an ant clean initportal
[15:21:11 EDT(-0400)] <EricDalquist> heh
[15:21:24 EDT(-0400)] <athena7> assuming that should have been enough
[15:21:24 EDT(-0400)] <EricDalquist> I really need to slow down and really test these
[15:21:28 EDT(-0400)] <EricDalquist> yeah
[15:21:33 EDT(-0400)] <EricDalquist> different stack than before
[15:21:37 EDT(-0400)] <athena7> ah ok
[15:21:43 EDT(-0400)] <athena7> well at least it's a new and different error?
[15:21:45 EDT(-0400)] <athena7>
[15:22:15 EDT(-0400)] <EricDalquist> yup
[15:22:17 EDT(-0400)] <EricDalquist> and easy to fix
[15:23:46 EDT(-0400)] <EricDalquist> ok ... committed fix ... I can test it here in about 10 minutes or if you want to continue to play guinea pig ...
[15:25:16 EDT(-0400)] <athena7> sure
[15:25:18 EDT(-0400)] <athena7> i'll do it now
[15:25:23 EDT(-0400)] <athena7> just need to switch to wireless
[15:25:23 EDT(-0400)] <athena7> brb
[15:30:24 EDT(-0400)] * athena7 (n=athena7@tp-wireless.its.yale.edu) has joined ##uportal
[15:34:21 EDT(-0400)] <EricDalquist> so ... anyone in here know if a HttpSession reference can be held on to and used across multiple requests?
[15:34:28 EDT(-0400)] <athena7> ok eric, i think that's all fixed
[15:34:53 EDT(-0400)] <EricDalquist> yay! (sorry it took so many iterations)
[15:35:44 EDT(-0400)] <EricDalquist> actually the better question is: Is it OK to only do portlet session invalidation when the Portal's LogoutServlet is invoked or should it be done when the portal user's session is invalidated for any reason (expiration or logout)
[15:36:35 EDT(-0400)] <athena7> kind of seems like it should be invalidated when the portal session expires too?
[15:37:01 EDT(-0400)] <EricDalquist> yeah, that's what I'm thinking too ... that is the harder perhaps even iffy on the servlet spec one to do though
[15:37:08 EDT(-0400)] <EricDalquist> since invalidating a portlet's session requires a reference to it
[15:37:28 EDT(-0400)] <EricDalquist> if it is being initiated from the LogoutServlet there is a request/response that can be used for a cross-context call to do the invalidation
[15:37:42 EDT(-0400)] <EricDalquist> if it is just a session invalidation event ... there may or may not be a request/response
[15:37:50 EDT(-0400)] <EricDalquist> so a direct reference to each portlet app session would be needed
[15:38:07 EDT(-0400)] <EricDalquist> awills ... holdorph ... any ideas?
[15:39:09 EDT(-0400)] <athena7> well, if all we can reasonably do is invalidate at logout, that's better than nothing
[15:39:25 EDT(-0400)] <EricDalquist> true
[15:39:37 EDT(-0400)] <EricDalquist> I'm trying to find the 2.6 code that does this ...
[15:41:11 EDT(-0400)] <EricDalquist> hrm ... yeah I'm not sure I'm a huge fan of how 2.6 does it but it apparently works ...
[15:41:30 EDT(-0400)] <EricDalquist> the code there grabs a reference to each portlet's session object at each request to the portlet
[15:41:56 EDT(-0400)] <EricDalquist> and when the SESSION_DONE channel event comes through the portlet adaptor invalidates it
[16:06:14 EDT(-0400)] <holdorph> sorry, i was at lunch
[16:06:17 EDT(-0400)] * holdorph reads back
[16:08:30 EDT(-0400)] <holdorph> you definitely can not rely only the LogoutServlet, because the user may never use the logout servlet.
[16:08:32 EDT(-0400)] <EricDalquist> well ... I just skimmed through the servlet spec and didn't see anything explicitly saying a session couldn't be referenced outside of the request scope ... still seems rather ugly
[16:09:37 EDT(-0400)] <holdorph> i s'pose if all the sessions had the same timeout, there wouldn't be a huge difference to the portlet session 'timing out' with the portal session at the same time though.
[16:09:56 EDT(-0400)] <EricDalquist> yeah
[16:10:06 EDT(-0400)] <EricDalquist> one thing I'm also going to look at with this is portlet app context 'pings'
[16:10:29 EDT(-0400)] <EricDalquist> since another case we don't address is not interacting with a portlet for a while even though you're interacting with the portal
[16:10:43 EDT(-0400)] <EricDalquist> it could be possible for your portlet session to timeout even though your portal session has not
[16:11:28 EDT(-0400)] <holdorph> nod
[16:18:10 EDT(-0400)] * apetro_LD830_ubu (n=apetro_L@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[16:18:20 EDT(-0400)] <EricDalquist> brb
[16:29:40 EDT(-0400)] <EricDalquist> ok ... so I guess the holding onto session references is perhaps the way to go
[16:30:43 EDT(-0400)] <apetro_LD830_ubu> oh?
[16:31:11 EDT(-0400)] <apetro_LD830_ubu> portlet sessions don't time out?
[16:31:41 EDT(-0400)] <EricDalquist> they do
[16:31:59 EDT(-0400)] <EricDalquist> so a patch was added in 2.6 so that when a users portal session is invalidated the portlet adapter would call .invalidate on the portlet sessions too
[16:32:22 EDT(-0400)] <EricDalquist> it did this by grabbing a reference to the portlet session each time it dispatched to the portlet
[16:32:39 EDT(-0400)] <EricDalquist> without that patch when the users portal session is invalidated the portlet sessions are left to timeout
[16:32:50 EDT(-0400)] <EricDalquist> which may be some significant time in the future
[16:33:14 EDT(-0400)] <EricDalquist> so not doing anything isn't a memory leak
[16:33:21 EDT(-0400)] <EricDalquist> just higher memory usage than needed
[16:36:35 EDT(-0400)] <EricDalquist> any thoughts on this apetro_LD830_ubu?
[16:43:41 EDT(-0400)] <apetro_LD830_ubu> thinking
[16:44:20 EDT(-0400)] <apetro_LD830_ubu> seldom are uP sessions invalidated other than by their timing out
[16:44:21 EDT(-0400)] <EricDalquist>
[16:44:28 EDT(-0400)] <EricDalquist> yup
[16:44:47 EDT(-0400)] <apetro_LD830_ubu> so isn't it simplest to recommend that portlet session timeouts be configured akin to portal session timeouts?
[16:45:21 EDT(-0400)] <EricDalquist> probably
[16:45:28 EDT(-0400)] <apetro_LD830_ubu> less so with the patch for fancy flexible portal session timeouts based on group membership
[16:46:17 EDT(-0400)] <apetro_LD830_ubu> I guess I'm suggesting that this be a "known behavior" for the 3.0 release, that uPortal rely on the primitive timeout mechanism
[16:46:27 EDT(-0400)] <apetro_LD830_ubu> and then see what schools really do about this
[16:46:46 EDT(-0400)] <apetro_LD830_ubu> if Yale / Rutgers / Wisconsin / whoever finds they in practice need to do something more sophisticated
[16:46:54 EDT(-0400)] <apetro_LD830_ubu> then pull that in for a next release
[16:47:05 EDT(-0400)] <EricDalquist> yeah, and we don't do anything right now here
[16:47:19 EDT(-0400)] <EricDalquist> we just let them time out
[16:47:27 EDT(-0400)] <apetro_LD830_ubu> which suggests that that's a viable strategy
[16:47:30 EDT(-0400)] <EricDalquist> yup
[16:47:51 EDT(-0400)] <apetro_LD830_ubu> and it seems like the low hanging fruit is tuning those timeouts and/or getting more careful about what's shoved into the session
[16:48:01 EDT(-0400)] <apetro_LD830_ubu> before going after the keeping references to the sessions solution
[16:48:15 EDT(-0400)] <apetro_LD830_ubu> I dunno why I'm disliking that keep references solution so much
[16:48:23 EDT(-0400)] <apetro_LD830_ubu> it probably in practice works fine
[16:48:31 EDT(-0400)] <apetro_LD830_ubu> but then some clever servlet container is going to come along
[16:48:40 EDT(-0400)] <apetro_LD830_ubu> and do something dynamic with session objects
[16:49:00 EDT(-0400)] <EricDalquist> yeah, that is my concern
[16:49:00 EDT(-0400)] <apetro_LD830_ubu> or there's the Terracotta stuff to do session clustering
[16:49:27 EDT(-0400)] <apetro_LD830_ubu> I know dmccallum is having fun times looking at the complexity of that in the context of Sakai
[16:49:46 EDT(-0400)] <apetro_LD830_ubu> and it's a similar kind of story, where Sakai's keeping around references to these sessions / doing advanced tricks with the session
[16:50:07 EDT(-0400)] <holdorph> sakai doesn't use the servlet container for sessions
[16:50:30 EDT(-0400)] <apetro_LD830_ubu> yes. loosely similar. Similar metaphorically.
[16:51:07 EDT(-0400)] <holdorph> well, what I mean, is you take that approach, the problem is actually easier then what you describe
[16:51:31 EDT(-0400)] <holdorph> you're not dependent on the container, behaving a certain way, or risk changing in the future.
[16:51:50 EDT(-0400)] <apetro_LD830_ubu> I think uPortal keeping those servlet session references is likely to eventually bite. I'm not sure it's worth heroics to avoid keeping those references, but I do think it's worth not doing those heroics at this juncture before the up3.0.0 release if they're not already there in 3.0.0 RCx
[16:51:52 EDT(-0400)] <holdorph> but the flip side, is, Sakai's not very portable to other containers.
[16:52:08 EDT(-0400)] <holdorph> it was done in 2.6, who did the work to do it there?
[16:52:30 EDT(-0400)] <holdorph> that person was probably trying to solve a problem they had, which I would guess was worse then a little extra memory for a short time.
[16:52:35 EDT(-0400)] <EricDalquist> it is very easy to add
[16:52:41 EDT(-0400)] <EricDalquist> I'll check on the 2.6 version
[16:53:01 EDT(-0400)] <EricDalquist> but with pluto 1.1 the API the code to track portlet sessions would be less than 100 lines
[16:53:59 EDT(-0400)] <EricDalquist> Stephane Bond
[16:54:22 EDT(-0400)] <EricDalquist> did it for 2.6
[16:54:24 EDT(-0400)] <EricDalquist> but the 2.6 approach is not what would be done for 3.0
[16:54:28 EDT(-0400)] <EricDalquist> if we did it
[16:54:39 EDT(-0400)] <holdorph> but 'why' did he do it for 2.6?
[16:55:19 EDT(-0400)] * michelled (n=team@142.150.154.197) has left ##uportal
[16:56:15 EDT(-0400)] <EricDalquist> http://www.ja-sig.org/issues/browse/UP-1590
[16:56:33 EDT(-0400)] <EricDalquist> ahhhh
[16:56:38 EDT(-0400)] <EricDalquist> it can be a security issue
[16:56:41 EDT(-0400)] <EricDalquist> I hadn't thought about that
[16:58:25 EDT(-0400)] <holdorph> yeah, sounds like from that description, it's not optional.
[16:58:48 EDT(-0400)] <holdorph> you could potentially punt for 3.0.0 GA, if you expect a 3.0.1 sometime this summer.
[16:59:03 EDT(-0400)] <holdorph> but you'd have top create a new jira issue, or reopen this one
[16:59:14 EDT(-0400)] <EricDalquist> yeah
[16:59:36 EDT(-0400)] <EricDalquist> I'll look into the work and complexity involved and if it something that would be comfortable adding as a bug-fix right now
[17:00:00 EDT(-0400)] <EricDalquist> I think we can implement this such that the worst case of calling session.invalidate is that the target session does not actually get invalidated
[17:00:11 EDT(-0400)] <EricDalquist> which isn't any worse than not doing anything