uPortal IRC Logs-2009-02-04

Owned by Apereo Infrastructure
Last updated: Feb 04, 2009Version comment
8 min read

[02:09:18 EST(-0500)] * lennard1 (n=sparhk@ip68-98-56-21.ph.ph.cox.net) has joined ##uportal
[07:32:39 EST(-0500)] * bszabo (n=bszabo@ip72-208-41-138.ph.ph.cox.net) has joined ##uportal
[08:17:12 EST(-0500)] * michelled (n=michelle@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has joined ##uportal
[08:42:32 EST(-0500)] * colinclark (n=colin@bas2-toronto09-1176131623.dsl.bell.ca) has joined ##uportal
[10:04:05 EST(-0500)] * awills (n=awills@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[10:10:11 EST(-0500)] * colinclark (n=colin@bas2-toronto09-1176131623.dsl.bell.ca) has joined ##uportal
[10:24:52 EST(-0500)] * holdorph (n=holdorph@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[10:27:58 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[10:31:43 EST(-0500)] * athena7 (n=athena7@12.164.139.7) has joined ##uportal
[10:41:28 EST(-0500)] * jessm (n=Jess@c-24-34-214-137.hsd1.ma.comcast.net) has joined ##uportal
[10:47:47 EST(-0500)] * bszabo (n=bszabo@ip72-208-41-138.ph.ph.cox.net) has joined ##uportal
[11:02:47 EST(-0500)] * lennard1 (n=sparhk@ip68-98-56-21.ph.ph.cox.net) has left ##uportal
[11:29:18 EST(-0500)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[11:30:02 EST(-0500)] <awills> morning folks...EricDalquist are you listening?
[11:30:08 EST(-0500)] <EricDalquist> yup
[11:31:39 EST(-0500)] * apetro (n=apetro@12.164.139.7) has joined ##uportal
[11:31:46 EST(-0500)] <awills> awesome... so before I start letting my imagination get the better of me, I'd love to get a bit of insight on the behavior of aop: (sessio) scoped proxy on the /Login click
[11:32:07 EST(-0500)] <awills> the LoginServlet invalidtes the HttpSession
[11:32:22 EST(-0500)] <EricDalquist> honestly I'm not 100% sure
[11:32:33 EST(-0500)] <EricDalquist> but remember that the real object gets resolved on every API call
[11:32:39 EST(-0500)] <EricDalquist> so you could very well have:
[11:33:01 EST(-0500)] <EricDalquist> proxiedBean.apiCall(); <- resolved to real object A by proxy
[11:33:09 EST(-0500)] <EricDalquist> session.invalidate();
[11:33:14 EST(-0500)] <EricDalquist> request.getSession();
[11:33:22 EST(-0500)] <EricDalquist> proxiedBean.apiCall(); <- resolved to real object B by proxy
[11:33:26 EST(-0500)] <EricDalquist> that would be my guess
[11:33:41 EST(-0500)] <awills> ah, I would think that would be workable
[11:34:07 EST(-0500)] <EricDalquist> so aop proxies add a bit of overhead that way because every API call they have to resolve the appropriate real object to delegate to
[11:34:15 EST(-0500)] <awills> so long as the 2nd 'proxiedBean.apiCall();' didn't resolve to real object A
[11:34:27 EST(-0500)] <EricDalquist> I'm pretty sure it wouldn't
[11:34:36 EST(-0500)] <EricDalquist> since that would have been part of the previous session
[11:34:44 EST(-0500)] <awills> yep
[11:42:08 EST(-0500)] * jessm (n=Jess@c-24-34-214-137.hsd1.ma.comcast.net) has joined ##uportal
[12:02:47 EST(-0500)] * athena7 (n=athena7@12.164.139.7) has joined ##uportal
[12:22:29 EST(-0500)] <awills> what is important in constructing an instance of IPersonAttributes for getPeopleWithMultivaluedAttributes()... just the attributes? or implementing getName() as well?
[12:38:10 EST(-0500)] * bszabo (n=bszabo@ip72-208-41-138.ph.ph.cox.net) has joined ##uportal
[13:02:03 EST(-0500)] * athena7 (n=athena7@12.164.139.7) has joined ##uportal
[13:15:08 EST(-0500)] * bszabo (n=bszabo@ip72-208-41-138.ph.ph.cox.net) has joined ##uportal
[13:20:53 EST(-0500)] * holdorph (n=holdorph@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[13:37:14 EST(-0500)] * athena7 (n=athena7@12.164.139.7) has joined ##uportal
[13:46:54 EST(-0500)] * athena7 (n=athena7@12.164.139.7) has joined ##uportal
[14:41:40 EST(-0500)] * michelled (n=michelle@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has joined ##uportal
[15:05:03 EST(-0500)] * apetro (n=apetro@63.133.148.66) has joined ##uportal
[15:12:32 EST(-0500)] <EricDalquist> awills: just got back
[15:12:40 EST(-0500)] <EricDalquist> you still wondering about: awills: what is important in constructing an instance of IPersonAttributes for getPeopleWithMultivaluedAttributes()... just the attributes? or implementing getName() as well?
[15:15:45 EST(-0500)] <awills> sure i'm wondering... but i'm not focused on that possibility atm... looking at this from spring docs: "global session: Scopes a single bean definition to the lifecycle of a global HTTP Session. Typically only valid when used in a portlet context."
[15:17:34 EST(-0500)] <EricDalquist> so the point of IPersonAttributes in Person Directory 1.5 is that name property, PD 1.5 added search functionality
[15:17:37 EST(-0500)] <awills> looks like i'm loosing my Map on subsequent clicks... it's empty later, when I expect it to be full
[15:18:08 EST(-0500)] <EricDalquist> IPersonAttributes and the corresponding name let the framework collate results for a single user from multiple sources
[15:18:28 EST(-0500)] <EricDalquist> hrm, and you're using the same scope that the overrides Map is using?
[15:19:31 EST(-0500)] <awills> yep, i was... until i tried just "session" with the same result
[15:21:22 EST(-0500)] <EricDalquist> hrm, strange
[15:21:43 EST(-0500)] <EricDalquist> yeah you need to have globalSession there or things get weird when a request to a portlet needs access to the object
[15:22:14 EST(-0500)] <awills> http://upportal.pastebin.com/m18f9f5e2
[15:22:31 EST(-0500)] <EricDalquist> I'd perhaps turn logging on org.springframework.aop up to DEBUG and see if there is anything helpful ...
[15:23:07 EST(-0500)] <EricDalquist> yeah, so the only thing I see there is you need to change the scope to globalSession
[15:28:23 EST(-0500)] * bszabo (n=bszabo@ip72-208-41-138.ph.ph.cox.net) has joined ##uportal
[15:51:22 EST(-0500)] * bszabo (n=bszabo@ip72-208-41-138.ph.ph.cox.net) has joined ##uportal
[16:02:38 EST(-0500)] <awills> EricDalquist (if you're still listening) do you suppose it could be a thread issue? since the operation is likely happening w/in a thread that's NOT the tomcat worker for which the HttpSession is meant to be valid
[16:02:56 EST(-0500)] <awills> it's probably happening in a channel rendering thread
[16:03:20 EST(-0500)] <EricDalquist> it could ... but if you're using the global session scope things should be available for channel rendering thread
[16:03:23 EST(-0500)] <EricDalquist> threads*
[16:03:32 EST(-0500)] <EricDalquist> there is some extra support in channel manager for that
[16:04:20 EST(-0500)] <EricDalquist> if you want to follow in a debugger
[16:04:35 EST(-0500)] <EricDalquist> org.jasig.portal.spring.web.context.support.PortalSessionScope is the scope implementation being used for globalSession
[16:04:39 EST(-0500)] <awills> yeah it makes sense... but I am considering that your example (overrides, which is working) is actually happening w/in a portlet (for which globalSession is designed), where mine is in CPersonAttributes
[16:05:04 EST(-0500)] <EricDalquist> hrm
[16:05:14 EST(-0500)] <EricDalquist> well it should work for a channel too ... but I;m not positive
[16:06:25 EST(-0500)] <EricDalquist> just a minute and I'll look at this a little more closely
[16:07:30 EST(-0500)] <awills> you're a superstar
[16:08:32 EST(-0500)] <EricDalquist> I'm thinking some ThreadLocal just isn't getting copied like it should
[16:08:57 EST(-0500)] <EricDalquist> while you're here ... you read the line-ending thread in the cernunnos list?
[16:10:22 EST(-0500)] <awills> yes, of course
[16:10:33 EST(-0500)] <awills> one sec
[16:13:40 EST(-0500)] <awills> "I'd also like to propose switching the expected type of the content of an echo or echo-line from String to Object" this sounds great
[16:14:17 EST(-0500)] <EricDalquist> yeah, functionally that's how it works now, it just yells at you for non-string data
[16:14:22 EST(-0500)] <awills> can you think of any downsides to System.getProperty("line.separator")?
[16:14:41 EST(-0500)] <awills> yeah that makes sense... to get rid of those warnings
[16:14:47 EST(-0500)] <EricDalquist> no, but I'm not a big "OS specific line seperator nerd"
[16:15:14 EST(-0500)] <EricDalquist> I think it would help more than hurt though
[16:15:22 EST(-0500)] <EricDalquist> since I think most tools work in the OS's native line ending format
[16:15:32 EST(-0500)] <EricDalquist> I know CVS and SVN check out files appropriately
[16:17:10 EST(-0500)] <awills> yeah... or it might make sense just to go w/ the *nix version, since (decent) windows tools seem to handle it well enough
[16:17:41 EST(-0500)] <awills> no that probably wouldn't work
[16:18:06 EST(-0500)] <awills> <echo-ln> is commonly used for the command shell
[16:18:22 EST(-0500)] <awills> i doubt the DOS prompt would deal w/ that gracefully
[16:18:56 EST(-0500)] <EricDalquist> yeah
[16:19:05 EST(-0500)] <EricDalquist> maybe we have echo-ln use the current OS version
[16:19:14 EST(-0500)] <EricDalquist> and the line iterator can handle both?
[16:19:35 EST(-0500)] <EricDalquist> *nix uses \n and windows uses \r\n right?
[16:19:47 EST(-0500)] <awills> that sounds worth a shot... that's right
[16:20:01 EST(-0500)] <EricDalquist> so you could split on \n
[16:20:01 EST(-0500)] <athena7> svn only checks out files appropriately if the proper svn:property for eol is set
[16:20:13 EST(-0500)] <athena7> i know we're missing some of that in uportal in some files
[16:20:17 EST(-0500)] <EricDalquist> and then check if the last char is \r and trim in
[16:20:29 EST(-0500)] <EricDalquist> I bet commons-lang StringUtils has an API for that
[16:20:41 EST(-0500)] <EricDalquist> I hate line endings (sad)
[16:20:55 EST(-0500)] <awills> heh... the first time I saw \r\n it was vbCrLf... boy I'm glad those days are gone
[16:25:08 EST(-0500)] <EricDalquist> grr, eclipse isn't cooperating today
[16:27:32 EST(-0500)] <athena7> my mac's been freezing today
[16:27:33 EST(-0500)] <athena7> no idea why
[16:28:57 EST(-0500)] <holdorph> i blame petro
[16:29:11 EST(-0500)] <athena7> yeah i bet it is his fault
[16:31:38 EST(-0500)] <EricDalquist> hrm ok
[16:31:43 EST(-0500)] <EricDalquist> awills: so I think data is missing for channels
[16:31:52 EST(-0500)] <EricDalquist> and it happens to work for portlets that use the Spring MVC
[16:32:22 EST(-0500)] <awills> ah gotcha
[16:32:29 EST(-0500)] <awills> that adds up
[16:32:31 EST(-0500)] <EricDalquist> doing a little more digging ...
[16:33:12 EST(-0500)] <EricDalquist> so uPortal has Spring's RequestContextListener configured in web.xml
[16:33:29 EST(-0500)] <EricDalquist> and that binds a bunch of request data into some threadlocals
[16:33:30 EST(-0500)] <awills> yep
[16:33:41 EST(-0500)] <EricDalquist> you know why I thought this would work ...
[16:33:49 EST(-0500)] <EricDalquist> we solved this in the sandboxed uP3 code
[16:33:53 EST(-0500)] <EricDalquist> and it just never made it over
[16:34:12 EST(-0500)] <EricDalquist> it should be an easy fix .... I just need to read the spring apis ...
[16:35:38 EST(-0500)] * michelled (n=michelle@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has left ##uportal
[16:35:42 EST(-0500)] <awills> so did you see the name of my class was AditionalDescriptorPersonAttributeDao?
[16:36:19 EST(-0500)] <EricDalquist> yup
[16:36:28 EST(-0500)] <EricDalquist> this for things like shib?
[16:36:34 EST(-0500)] <EricDalquist> attributes provided at auth time?
[16:36:48 EST(-0500)] <awills> i need it for an assignment, but i figure securityContext impls can use it, if they're so inclined, to inject person attributes into the real IPersonAttributeDao API
[16:37:35 EST(-0500)] <awills> the ones I'm after aren't precisely authN related... they need to be evaluated based on the hostname and/or part of the path info of the request URL
[16:37:51 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[16:37:57 EST(-0500)] <awills> but i figure the requirement can be generalized
[16:38:31 EST(-0500)] <EricDalquist> very much so
[16:48:38 EST(-0500)] <EricDalquist> awills: http://uportal.pastebin.com/d3e25eba1
[16:48:45 EST(-0500)] <EricDalquist> can you try applying that patch to uPortal
[16:48:47 EST(-0500)] <EricDalquist> and then testing?
[16:48:52 EST(-0500)] <awills> yep
[16:49:02 EST(-0500)] <awills> i think... how many files?
[16:49:02 EST(-0500)] <EricDalquist> I copies the contents of the Spring holder utils into the renderer thread
[16:49:05 EST(-0500)] <EricDalquist> just one
[16:49:11 EST(-0500)] <awills> ah np
[17:00:37 EST(-0500)] <EricDalquist> let me know if it works and I'll commit it
[17:00:48 EST(-0500)] <awills> yep – cleared it up perfectly... nice catch
[17:00:53 EST(-0500)] <awills> just finished
[17:00:53 EST(-0500)] <EricDalquist> great
[17:02:05 EST(-0500)] <awills> ok, i have this item, and a UrlRequestParameterProcessor to write up for contribution
[17:02:39 EST(-0500)] <EricDalquist> great
[17:02:45 EST(-0500)] <awills> the UrlRequestParameterProcessor pulls theme/structure parameters from arbitrary parts of the url
[17:03:00 EST(-0500)] <EricDalquist> are you going to push the PD related code back into that project?
[17:03:08 EST(-0500)] <EricDalquist> seems like something we could include in the 1.5 final release
[17:03:17 EST(-0500)] <awills> useful for linking to a tab like /uPortal/News
[17:03:59 EST(-0500)] <EricDalquist> cool
[17:04:13 EST(-0500)] <EricDalquist> sounds like a good base for some upcoming URL related work we have planned
[17:04:28 EST(-0500)] <awills> i had written the PD impl as org.jasig.portal.security, b/c i saw it as a (portal-specific) evolution of the previous additional descriptor features
[17:04:44 EST(-0500)] <awills> but i could to it the other way too
[17:05:01 EST(-0500)] <EricDalquist> I think it could be generic enough to include there
[17:05:16 EST(-0500)] <awills> there=PD 1.5?
[17:05:19 EST(-0500)] <EricDalquist> yes
[17:05:24 EST(-0500)] <awills> sure
[17:06:31 EST(-0500)] <awills> i'm missing only 1 little part i think... have to do something similar to what you did w/ the overrides... make sure to add the Map elements only to my own attributes (wink)
[17:07:39 EST(-0500)] <EricDalquist> (smile)
[17:07:41 EST(-0500)] <EricDalquist> yup
[17:07:58 EST(-0500)] <awills> config for the processor: http://upportal.pastebin.com/m185c7554
[17:08:06 EST(-0500)] <EricDalquist> something you don't think about when its just one user testing it
[17:08:19 EST(-0500)] <EricDalquist> nice
[17:08:20 EST(-0500)] <awills> heh. no doubt
[17:08:26 EST(-0500)] <EricDalquist> so regex to select attribute values
[17:08:29 EST(-0500)] * apetro (n=apetro@63.133.148.66) has joined ##uportal
[17:08:31 EST(-0500)] <EricDalquist> that is a very nice approach
[17:08:37 EST(-0500)] <awills> yes, using capturing groups
[17:08:51 EST(-0500)] <awills> tyvm
[17:08:51 EST(-0500)] <EricDalquist> does the URL stay at /foo/bar or does it redirect after handling?
[17:09:45 EST(-0500)] <awills> i wish it stayed (where appropriate)... perhaps we can get there... but uP generates a new URL from a file spec thingee
[17:10:10 EST(-0500)] <EricDalquist> oh yeah
[17:10:16 EST(-0500)] <EricDalquist> yeah that is probably what I'm going to tackle
[17:10:26 EST(-0500)] <EricDalquist> move to an API like we created for portlet URL generation
[17:10:35 EST(-0500)] <EricDalquist> where you have a URL syntax provider interface
[17:10:43 EST(-0500)] <awills> yes that would be nice
[17:10:45 EST(-0500)] <EricDalquist> that can contribute to URL parameters and request parsing
[17:10:58 EST(-0500)] <EricDalquist> and then a single class to take those providers and build the final URL
[17:11:20 EST(-0500)] <EricDalquist> the problem is it is hard for channels because that file spec API doesn't follow that pattern at all
[17:11:39 EST(-0500)] <EricDalquist> so I'm thinking we'd just have to figure out some legacy channel URL handler for the remaining channels
[17:11:52 EST(-0500)] <EricDalquist> but theme and portlet URLs could be made pretty
[17:12:35 EST(-0500)] <awills> yeah... perhaps the portal could support both "styles" of URL... there are fewer channels all the time anyway
[17:12:42 EST(-0500)] <EricDalquist> yup
[17:21:26 EST(-0500)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has left ##uportal
[17:33:20 EST(-0500)] * bszabo (n=bszabo@ip72-208-41-138.ph.ph.cox.net) has joined ##uportal
[18:26:09 EST(-0500)] * bszabo (n=bszabo@ip72-208-41-138.ph.ph.cox.net) has joined ##uportal
[19:42:25 EST(-0500)] * athena7 (n=athena7@ip68-230-77-209.ph.ph.cox.net) has joined ##uportal
[20:10:54 EST(-0500)] * bszabo (n=bszabo@ip72-208-41-138.ph.ph.cox.net) has joined ##uportal
[20:11:02 EST(-0500)] * awills (n=awills@wsip-98-174-242-39.ph.ph.cox.net) has left ##uportal
[20:42:22 EST(-0500)] * bszabo (n=bszabo@ip72-208-41-138.ph.ph.cox.net) has joined ##uportal
[21:01:40 EST(-0500)] * bszabo (n=bszabo@ip72-208-41-138.ph.ph.cox.net) has joined ##uportal
[21:14:40 EST(-0500)] * apetro (n=apetro@63.133.148.66) has joined ##uportal
[22:20:57 EST(-0500)] * bszabo (n=bszabo@ip72-208-41-138.ph.ph.cox.net) has joined ##uportal
[22:33:37 EST(-0500)] * apetro (n=apetro@ip68-3-207-51.ph.ph.cox.net) has joined ##uportal