[12:09:59 CDT(-0500)] <b-sure> Hello uPortal Devs: were using remote_user authentication at our campus and Im' having an issue w/ it working in the 4.0.4 build of uPortal. I see there is a RemoteUserSettingFilter to help debug issues. do you know what I should put in remoteUserFIle?
[12:10:23 CDT(-0500)] <EricDalquist> the username
[12:10:29 CDT(-0500)] <EricDalquist> it reads that file on every request
[12:10:40 CDT(-0500)] <EricDalquist> it sets the contents as the REMOTE_USER header
[12:10:45 CDT(-0500)] <EricDalquist> if the file is empty no remote user is set
[12:11:27 CDT(-0500)] <b-sure> ok that sounds like its forcing the remot user to be set and then if that is the case, the rest of the authentication should work?
[12:11:43 CDT(-0500)] <EricDalquist> well its useful for testing on like a desktop
[12:11:55 CDT(-0500)] <EricDalquist> where you may not have something in front of tomcat setting the remote user header
[12:12:07 CDT(-0500)] <b-sure> I do actually. its coming from shibb.
[12:12:35 CDT(-0500)] <EricDalquist> then the filter isn't much use for you
[12:12:39 CDT(-0500)] <b-sure> I added some debug to POrtalPReAuthenticatedProccessingFilter that shows remote use is set
[12:12:54 CDT(-0500)] <b-sure> I'm just not sure where its being wiped away
[12:13:26 CDT(-0500)] <b-sure> in that file is is set before and after the SecurityContextHolder.clearContext(); and also after the filter chain
[12:15:00 CDT(-0500)] <b-sure> maybe there is a package or two I can turn up the logs for to see if I can take a closer look at where its getting lost?
[12:17:42 CDT(-0500)] <b-sure> Hi EricDalquist. I also see these spitting out in the logs now http://pastebin.com/raw.php?i=EituRLh6. could that be causing the authentication to fail? I'm guessing no.
[12:19:26 CDT(-0500)] <EricDalquist> no
[12:19:29 CDT(-0500)] <EricDalquist> that would be unrelated
[12:20:18 CDT(-0500)] <b-sure> ok. thanks. do you have an idea of what packages I could sprinke w/ some more debug statements to maybe see where its getting lost? I know you did some work for this on a releated issue.
[12:20:30 CDT(-0500)] <EricDalquist> not off the top of my head
[12:20:42 CDT(-0500)] <EricDalquist> I can give more coherent help middle of next week
[12:20:52 CDT(-0500)] <EricDalquist> we're scheduled to upgrade to up4 on Tuesday
[12:20:56 CDT(-0500)] <EricDalquist> so I'm pretty swamped
[12:21:02 CDT(-0500)] <b-sure> oh ok. you're swamped np
[12:21:19 CDT(-0500)] <b-sure> are you using shibb for authentication now?
[12:21:23 CDT(-0500)] <EricDalquist> yes
[12:21:33 CDT(-0500)] <EricDalquist> we have shib working against uP4
[12:21:39 CDT(-0500)] <b-sure> great. I"ll probably be buggin you a lot more now 
[12:21:41 CDT(-0500)] <EricDalquist> I don't think we're that far off 4.0.4
[12:21:53 CDT(-0500)] <EricDalquist> but that is what I'll be working on post-upgrade
[12:21:55 CDT(-0500)] <b-sure> are you deploy ing 4.0.4
[12:22:05 CDT(-0500)] <EricDalquist> making sure all the changes in our vendor branch make it into 4.0.5
[12:22:06 CDT(-0500)] <EricDalquist> yes
[12:22:13 CDT(-0500)] <EricDalquist> 4.0.4 + a bunch of little fixes/mods
[12:22:15 CDT(-0500)] <b-sure> ok thats promising.
[12:22:45 CDT(-0500)] <b-sure> I"ve been having issue getting 4.0.4 working where 4.0.3 was working well with exception of groups/categories
[12:36:41 CDT(-0500)] <drewwills> EricDalquist – I'm hearing this is a pretty busy period for you and WI, but I wonder if you looked any further at that patch
[12:36:52 CDT(-0500)] <EricDalquist> I have not
[12:36:58 CDT(-0500)] <EricDalquist> I'll see if I can give it a second read through today
[12:37:06 CDT(-0500)] <EricDalquist> but it really did look good on my first review
[12:37:08 CDT(-0500)] <EricDalquist> question for you
[12:37:17 CDT(-0500)] <EricDalquist> what was your impression of the up4 portlet execution framework?
[12:37:36 CDT(-0500)] <EricDalquist> and on an unrelated note
[12:37:51 CDT(-0500)] <EricDalquist> do you think you could cut a cernunnous 1.2.2 release by mid next week?
[12:37:53 CDT(-0500)] <drewwills> yeah I don't want to make it tough on you, so it can wait if it has to... the concern is merely how it might get harder to circle back over time
[12:38:12 CDT(-0500)] <EricDalquist> I have a bunch of improvements to 3.2 layout export I want to get back into jasig next week
[12:38:19 CDT(-0500)] <drewwills> i can cut that – did you get your bits in?
[12:38:23 CDT(-0500)] <EricDalquist> yup
[12:38:34 CDT(-0500)] <EricDalquist> got it so that I was able to export 65k layouts from 240k users in 30 minutes
[12:38:48 CDT(-0500)] <EricDalquist> and then import those 65k layouts in 30 minutes into up4
[12:40:35 CDT(-0500)] <drewwills> holy %^$#
[12:40:53 CDT(-0500)] <drewwills> that's very impressive... did you use multiple import/export threads?
[12:40:54 CDT(-0500)] <EricDalquist> yeah
[12:40:57 CDT(-0500)] <EricDalquist> yup
[12:41:02 CDT(-0500)] <EricDalquist> 10 export
[12:41:04 CDT(-0500)] <EricDalquist> 20 import
[12:41:14 CDT(-0500)] <EricDalquist> there were some serious sync bottleneck in crn
[12:41:20 CDT(-0500)] <EricDalquist> and some thread saftey issues in crn and uPortal
[12:41:28 CDT(-0500)] <EricDalquist> also found a few DB tables missing crucial indexes
[12:41:29 CDT(-0500)] <drewwills> not entirely surprised
[12:41:55 CDT(-0500)] <EricDalquist> the javadoc for that scriptengine API changed from jdk5 to 6
[12:42:00 CDT(-0500)] <drewwills> it's tough to hit that evel of polish when you're normally working with very small data sets
[12:42:14 CDT(-0500)] <EricDalquist> and what we assumed was thread safe WRT groovy was not
[12:42:21 CDT(-0500)] <EricDalquist> variables were being shared across script executions
[12:42:26 CDT(-0500)] <EricDalquist> even within method
[12:42:29 CDT(-0500)] <drewwills> oh great
[12:42:31 CDT(-0500)] <EricDalquist> methods*
[12:42:35 CDT(-0500)] <EricDalquist> that was one of the fixes
[12:43:27 CDT(-0500)] <EricDalquist> so in JDK5 they just said if the threading param returned multithreaded it was thread safe
[12:43:31 CDT(-0500)] <EricDalquist> but that isn't exactly true
[12:43:37 CDT(-0500)] <EricDalquist> http://docs.oracle.com/javase/6/docs/api/javax/script/ScriptEngineFactory.html#getParameter(java.lang.String)
[12:43:47 CDT(-0500)] <EricDalquist> "MULTITHREADED"Â - The engine implementation is internally thread-safe and scripts may execute concurrently although effects of script execution on one thread may be visible to scripts on other threads.
[12:43:57 CDT(-0500)] <EricDalquist> that's a kind of important clarification at the end of that line
[12:45:34 CDT(-0500)] <EricDalquist> so the crn mod was to only treat scripts as thread safe if they are thread-isolated or stateless
[12:45:59 CDT(-0500)] <drewwills> I did like the "portlet execution framework" btw... the classes/methods/interations defined therein seemed much more tightly in tune with the actual work being performed... as compared with what I know of the previous setup, which likely feel out-of-tune with its design as more was added/edited
[13:31:46 CDT(-0500)] <drewwills> Hey athena if you're there – is there a 286 version of the Jasig portlet maven archetype by chance?
[13:32:00 CDT(-0500)] <athena> yes, the main documented version is 286
[13:32:21 CDT(-0500)] <athena> https://wiki.jasig.org/display/UMM/Using+the+uMobile+Portlet+Archetype
[13:32:23 CDT(-0500)] <drewwills> hmm... i tried it last week based on docs i found somewhere... ended up with a 168 version
[13:32:32 CDT(-0500)] <athena> take a look that that documentation
[13:32:41 CDT(-0500)] <athena> i'll be publishing a new version of that within the next week or so too, actually