[10:52:07 CDT(-0500)] <athena1> hey EricDalquist - did the portlet caching stuff ever get done?
[10:52:18 CDT(-0500)] <EricDalquist> nope, haven't gotten to that yet
[10:52:26 CDT(-0500)] <athena1> ah ok
[10:52:31 CDT(-0500)] <EricDalquist> though we technically can just ignore it since it is optional in the spec
[10:52:34 CDT(-0500)] <athena1> ahh
[10:52:35 CDT(-0500)] <athena1> ok
[10:52:37 CDT(-0500)] <EricDalquist> though realisticly it shouldn't be that hard
[10:52:41 CDT(-0500)] <athena1> cool 
[10:52:49 CDT(-0500)] <athena1> seems like it might help ajax performance?
[10:52:57 CDT(-0500)] <EricDalquist> um
[10:52:58 CDT(-0500)] <EricDalquist> yeah
[10:53:05 CDT(-0500)] <EricDalquist> resource URLs have caching built in
[10:53:15 CDT(-0500)] <EricDalquist> you can even specify cache scope (public vs private)
[10:53:30 CDT(-0500)] <EricDalquist> so things like an ajax news reader could cache the URLs publicly
[11:00:50 CDT(-0500)] <athena1> trying to remember what we ran into when we tested that in the fall
[11:01:21 CDT(-0500)] <athena1> seems like something wasn't implemented yet
[11:01:35 CDT(-0500)] <EricDalquist> with the resource urls?
[12:44:17 CDT(-0500)] <EricDalquist> this setContentType bug is driving me insane
[12:44:35 CDT(-0500)] <EricDalquist> I can't see anything different about the first request to a tab than other requests that would cause the content type to be null
[12:54:25 CDT(-0500)] <EricDalquist> if I have a break point in setContentType it works
[12:54:32 CDT(-0500)] <EricDalquist> without the break point it fails
[12:54:35 CDT(-0500)] <EricDalquist> wtf
[13:07:57 CDT(-0500)] <athena> yes
[13:08:06 CDT(-0500)] <athena> you know, i actually thought i was seeing the same thing
[13:08:10 CDT(-0500)] <EricDalquist> just downloaded the tomcat source
[13:08:13 CDT(-0500)] <athena> so that made me wonder if there's some kind of timing issue going on
[13:08:19 CDT(-0500)] <EricDalquist> setting break points down the whole call stack
[13:08:23 CDT(-0500)] <EricDalquist> going to see where it is missing
[13:08:25 CDT(-0500)] <EricDalquist> yeah
[13:08:25 CDT(-0500)] <athena> like maybe our code is somehow finishing up before something else
[13:08:29 CDT(-0500)] <EricDalquist> it sure looks like a race condition
[13:08:31 CDT(-0500)] <athena> yeah
[13:11:17 CDT(-0500)] <EricDalquist> found it
[13:12:32 CDT(-0500)] <athena> oooh really?
[13:12:37 CDT(-0500)] <EricDalquist> yes
[13:12:40 CDT(-0500)] <EricDalquist> $%!#$%
[13:12:47 CDT(-0500)] <athena> uhoh?
[13:12:55 CDT(-0500)] <EricDalquist> so according to the servlet spec multithreaded access to a request is iffy at best
[13:13:08 CDT(-0500)] <athena> eep
[13:13:17 CDT(-0500)] <athena> i assume we're counting on multithreaded access?
[13:13:20 CDT(-0500)] <EricDalquist> we have a bunch of stuff in uPortal that smooths that out for the most part
[13:13:32 CDT(-0500)] <EricDalquist> right that is the basis of our "portlets render in their own threads" architecture
[13:14:00 CDT(-0500)] <EricDalquist> AND you're supposed only every use the provded req/res wrapper classes
[13:14:32 CDT(-0500)] <EricDalquist> during the pluto cross-context dispatch tomcat is getting to its original request object and switching the request object out from under the portal 
[13:14:32 CDT(-0500)] <athena> ugh
[13:14:46 CDT(-0500)] <EricDalquist> time to dig a little more :/
[13:14:56 CDT(-0500)] <athena> 
[13:15:39 CDT(-0500)] <EricDalquist> oh ok
[13:15:42 CDT(-0500)] <EricDalquist> I think I have a solution
[13:15:50 CDT(-0500)] <EricDalquist> we already fix this for requests
[13:15:59 CDT(-0500)] <EricDalquist> by breaking the servelt spec rules a little bit
[13:16:14 CDT(-0500)] <EricDalquist> we have a PortletHttpServletRequestWrapper that implements HttpServletRequest directly
[13:16:19 CDT(-0500)] <EricDalquist> and doesn't use the provided wrapper
[13:16:47 CDT(-0500)] <EricDalquist> tomcat deals with this just fine and doesn't unwrap the request passed our portlet specific wrapper
[13:16:56 CDT(-0500)] <EricDalquist> which protects the portal's request object
[13:17:02 CDT(-0500)] <EricDalquist> just need to do the same thing for the response
[13:17:07 CDT(-0500)] <EricDalquist> :/
[13:22:48 CDT(-0500)] <athena> sounds fixable at least?
[13:28:50 CDT(-0500)] <EricDalquist> yes
[13:28:57 CDT(-0500)] <EricDalquist> should have a fix in 30 minutes or so
[13:30:32 CDT(-0500)] <athena> nice!
[13:32:50 CDT(-0500)] <EricDalquist> athena: if you log into https://developer.jasig.org/bamboo/allPlans.action do you now have the ability to run the uPortal plans?
[13:33:42 CDT(-0500)] <athena> hmm, forgot my password
[13:33:52 CDT(-0500)] <EricDalquist> should be the same as jira, confluence and svn
[13:34:10 CDT(-0500)] <athena> huh.
[13:34:27 CDT(-0500)] <athena> there we go
[13:34:42 CDT(-0500)] <athena> yep, looks like i can
[13:34:47 CDT(-0500)] <EricDalquist> great
[13:35:00 CDT(-0500)] <EricDalquist> I gave the steering committee access to admin all of the uportal related build plans
[13:40:06 CDT(-0500)] <b-rock> Greetings uPortal devs: I submitted an issue / patch https://issues.jasig.org/browse/UP-2994 for the 3.2.4 branch that may affect the upcoming 4.0 release as well. I just wanted to call it to your attention.
[13:40:19 CDT(-0500)] <b-rock> its regarding the new grouper functionality
[13:40:29 CDT(-0500)] <EricDalquist> thanks
[13:40:49 CDT(-0500)] <EricDalquist> got it updated with fix-for versions
[13:40:53 CDT(-0500)] <EricDalquist> so we don't lose track of it
[13:41:06 CDT(-0500)] <b-rock> np. I'm not sure if its been seen in your testing or not. and one of my co-workers is supposed to present our portal at the conference . dough
[13:41:21 CDT(-0500)] <b-rock> cool.
[13:42:05 CDT(-0500)] <b-rock> I've got the fix running / tested in our dev environment but it will go live either tomorrow or thursday.
[13:43:00 CDT(-0500)] <EricDalquist> I don't have access to a group integrated uPortal so I haven't seen it
[13:43:11 CDT(-0500)] <EricDalquist> but thanks for finding it and adding a patch
[13:43:16 CDT(-0500)] <EricDalquist> I like those bugts
[13:43:20 CDT(-0500)] <EricDalquist> they're easy to fix
[13:54:00 CDT(-0500)] <athena> ah - thanks b-rock
[14:02:07 CDT(-0500)] <b-rock> np.take care.
[14:59:44 CDT(-0500)] <EricDalquist> athena: was there a jira issue for that content type bug?
[15:00:03 CDT(-0500)] <athena> no, don't think so
[15:00:20 CDT(-0500)] <athena> you checking something in for it?
[15:00:32 CDT(-0500)] <EricDalquist> yeah
[15:00:34 CDT(-0500)] <EricDalquist> I have a fix for it
[15:00:37 CDT(-0500)] <athena> awesome
[15:00:38 CDT(-0500)] <EricDalquist> I'll create one
[15:00:54 CDT(-0500)] <athena> let me know when you check in - was about to update our umobile server anyway
[15:00:57 CDT(-0500)] <athena> might as well pick that up!
[15:01:06 CDT(-0500)] <EricDalquist> will do ... it will be about 5 minutes
[15:01:18 CDT(-0500)] <athena> no problem
[15:01:19 CDT(-0500)] <athena>
[15:01:26 CDT(-0500)] <athena> really glad you figured that out
[15:02:57 CDT(-0500)] <EricDalquist> yeah
[15:02:58 CDT(-0500)] <EricDalquist> me too
[15:03:00 CDT(-0500)] <EricDalquist> also
[15:03:03 CDT(-0500)] <EricDalquist> race conditions suck
[15:03:07 CDT(-0500)] <athena> totally.
[15:03:09 CDT(-0500)] <athena> so evil
[15:10:55 CDT(-0500)] <EricDalquist> has SVN seemed really slow for anyone else?
[15:15:46 CDT(-0500)] <athena> yeah, actually
[15:15:54 CDT(-0500)] <athena> thought it was just me - had some internet issues this morning
[15:15:57 CDT(-0500)] <EricDalquist> no
[15:16:02 CDT(-0500)] <EricDalquist> it was really slow from home last night
[15:16:06 CDT(-0500)] <EricDalquist> and slow from work today
[15:16:09 CDT(-0500)] <athena> huh
[15:16:26 CDT(-0500)] <EricDalquist> ok, I'll make a note to email contegix
[15:16:44 CDT(-0500)] <EricDalquist> and the content type issue is fixed
[15:18:11 CDT(-0500)] <athena> awesome
[15:21:12 CDT(-0500)] <athena> my poor phone apparently spends most of it's time spitting out memory warnings
[15:36:37 CDT(-0500)] <athena> ok, this is so completely bizarre
[15:36:56 CDT(-0500)] <athena> from the native app the first request to the login page redirects to /uPortal/%3Bjsessionid=4A85CB7C6E88A9C804162D3646D58246 and returns an error
[15:37:02 CDT(-0500)] <athena> i just have no idea what's causing that
[15:37:23 CDT(-0500)] <EricDalquist> uhg
[15:37:24 CDT(-0500)] <EricDalquist> that is tomcat
[15:37:30 CDT(-0500)] <athena> it is?
[15:37:33 CDT(-0500)] <EricDalquist> I can';t remember how to turn it off
[15:37:34 CDT(-0500)] <EricDalquist> yeah
[15:37:40 CDT(-0500)] <athena> huh
[15:37:42 CDT(-0500)] <EricDalquist> that is what tomcat does on the first request
[15:37:48 CDT(-0500)] <athena> so weird - i didnt' see this until yesterday
[15:37:53 CDT(-0500)] <EricDalquist> since it doesn't know until request 2 if your browser supports cookies or not
[15:38:01 CDT(-0500)] <athena> huh.
[15:38:12 CDT(-0500)] <athena> how come i can't reproduce that in my browser?
[15:38:15 CDT(-0500)] <EricDalquist> at least that's my recolection
[15:38:37 CDT(-0500)] <EricDalquist> what happens if you clear all cookies for the domain first?
[15:40:03 CDT(-0500)] <athena> hm, lets see
[15:40:57 CDT(-0500)] <athena> works just fine
[15:41:07 CDT(-0500)] <EricDalquist> uh weird
[15:41:11 CDT(-0500)] <athena> yeah
Manage space
Manage content
Integrations