[09:58:33 CDT(-0500)] <b-rock> Greetings uPortal: I think from uportal 3.1.1 to the 3.2.x series of portal, the way multi-valued user attributes are handled changed so that instead of using PortletRequest.USER_INFO to get a list of ; separated values, you now use org.jasig.portlet.USER_INFO_MULTIVALUED which gives you a list.
[09:59:24 CDT(-0500)] <EricDalquist> that depends on your person directory config, as far as I know uportal has never concatenated multi-valued parameters together to provide via user_info
[09:59:37 CDT(-0500)] <EricDalquist> did how you get the attributes in question into person directory change at all?
[10:00:33 CDT(-0500)] <b-rock> no it didn't change.
[10:00:54 CDT(-0500)] <b-rock> I'm thinking about how we are using the pags tester classes for a multi-valued attribute.
[10:01:39 CDT(-0500)] <EricDalquist> so your person directory config is exactly the same?
[10:01:45 CDT(-0500)] <b-rock> yes.
[10:01:49 CDT(-0500)] <EricDalquist> huh
[10:01:53 CDT(-0500)] <EricDalquist> I'm at a loss then
[10:03:43 CDT(-0500)] <b-rock> my question is about if in my custom Pags Tester, that reads the attribute field from the PagsGroupStoreConfig.xml file is a multi valued attribute, will I get the attribute in the tester as a List from the the IPerson object?
[10:04:08 CDT(-0500)] <EricDalquist> I think so
[10:04:35 CDT(-0500)] <b-rock> ok. thanks EricDalquist.
[10:05:13 CDT(-0500)] <b-rock> I think we may need to rewrite some of our custom pags testers to take into an account that the value we get from the IPerson attribute is a list instead of a string.
[10:05:34 CDT(-0500)] <EricDalquist> so where is this attribute coming from?
[10:05:35 CDT(-0500)] <EricDalquist> ldap?
[10:05:54 CDT(-0500)] <EricDalquist> I'm just really confused about the ; delemited string versus a list of values
[10:05:56 CDT(-0500)] <b-rock> shibb
[10:06:06 CDT(-0500)] <EricDalquist> and your shib config is exactly the same as well?
[10:06:13 CDT(-0500)] <b-rock> through a Request Attribute Header
[10:06:27 CDT(-0500)] <b-rock> yeah our shibb config is the same.
[10:07:21 CDT(-0500)] <EricDalquist> very weird
[10:07:54 CDT(-0500)] <b-rock> I'm gonna do a paste bin to show you (hopefully more clearly) what I'm talking about.
[10:14:21 CDT(-0500)] <b-rock> ok. http://pastebin.com/vDzLjaht just shows how we had to change the way we get a multi-valued attribute from the person in a portlet. I'm wondering if this same change takes place in the custom pags tester for the test(IPerson person) method where we try to get an attribute from the person object.
[10:14:41 CDT(-0500)] <EricDalquist> pags talks to person directory directly
[10:14:51 CDT(-0500)] <b-rock> oh.
[10:15:00 CDT(-0500)] <EricDalquist> I don't know the code well enough to know how pags testers deal with multi-valued attributes
[10:15:11 CDT(-0500)] <EricDalquist> but person directory natively supports multi-valued attributes
[10:15:59 CDT(-0500)] <b-rock> ok . thanks. I will try digging a little more in the code to see if I can get it answered with some debugging. thanks.
[10:16:28 CDT(-0500)] <EricDalquist> yup
[15:20:27 CDT(-0500)] <holdorph> i haven't built uportal in longer then i'd like to admit
[15:20:50 CDT(-0500)] <holdorph> i just tried building trunk, fresh checkout from this morning, and get a dependency error
[15:21:02 CDT(-0500)] <holdorph> artifact:mvn] [ERROR] Failed to execute goal on project cas: Could not resolve dependencies for project org.jasig.portal.portlets-overlay:cas:war:3.3.0-SNAPSHOT: Failed to collect dependencies for.....
[15:21:02 CDT(-0500)] <EricDalquist> was it on a hibernate dependency?
[15:21:13 CDT(-0500)] <holdorph> might be, i'll post more in a pastebin
[15:21:55 CDT(-0500)] <holdorph> http://pastebin.com/myah1saq
[15:22:28 CDT(-0500)] <EricDalquist> uhg @#$#$ jboss
[15:22:33 CDT(-0500)] <EricDalquist> just re-run it until it works
[15:22:42 CDT(-0500)] <EricDalquist> the jboss maven repo appears to have problems
[15:22:48 CDT(-0500)] <EricDalquist> and randomly fails with connection refused errros
[15:22:52 CDT(-0500)] <EricDalquist> which causes maven to fail
[15:22:56 CDT(-0500)] <EricDalquist> I'm not sure what to do about it
[15:23:07 CDT(-0500)] <holdorph> do we have a jasig mvn repo?
[15:23:08 CDT(-0500)] <EricDalquist> since I don't want to try and figure out how to mirror all the jpa/hibernate dependencies
[15:23:13 CDT(-0500)] <holdorph> can't we mirror them there?
[15:23:16 CDT(-0500)] <EricDalquist> we do not
[15:23:30 CDT(-0500)] <EricDalquist> we use oss.sonatype.org to publish org.jasig.* artifacts into central
[15:23:42 CDT(-0500)] <EricDalquist> but we have no facilities to mirror or host 3rd party libraries
[15:23:59 CDT(-0500)] <holdorph> what a pain in the bottom...
[15:24:55 CDT(-0500)] <EricDalquist> yes
[15:25:14 CDT(-0500)] <EricDalquist> I'm going to see if I can bug the guys from jboss that are on the jsr107 spec
[15:25:21 CDT(-0500)] <EricDalquist> maybe they can point me to someone that can fix it
[15:25:47 CDT(-0500)] <holdorph> they're probably busy working on a replacement for maven
[15:25:57 CDT(-0500)] <EricDalquist> I'm sure
[15:26:04 CDT(-0500)] * holdorph might be a bit cycnical or bitter.
[15:26:11 CDT(-0500)] <EricDalquist> why they don't just publish them to central ....
[15:28:46 CDT(-0500)] <holdorph> how big do you think all the jboss dependecies we use are? is it small enough that we could zip up that part of a local-personal maven repo and put the archive somewhere for people to download, if they hit this problem?
[15:29:09 CDT(-0500)] <EricDalquist> not sure
[15:29:18 CDT(-0500)] <athena> betting that might still interfere w/ the working of some of the release plugins
[15:29:44 CDT(-0500)] <holdorph> only as an alternative for someone who wants to build
[15:29:57 CDT(-0500)] <holdorph> and doesn't want to wait for jboss's repo to fix itself
[15:30:22 CDT(-0500)] <holdorph> (fwiw, it did build successfully the second time)
[15:31:19 CDT(-0500)] <EricDalquist> https://forum.hibernate.org/viewtopic.php?f=1&t=1005998&p=2445168#p2445168
[15:32:15 CDT(-0500)] <holdorph> haha, they don't even have a valid ssl cert
[15:33:09 CDT(-0500)] <EricDalquist> it just expired yesterday
[15:33:11 CDT(-0500)] <holdorph> wow, that's a much slower startup time then previously
[15:33:18 CDT(-0500)] <holdorph> INFO: Server startup in 107602 ms
[15:33:50 CDT(-0500)] <EricDalquist> more included webapps
[15:39:10 CDT(-0500)] <holdorph> wow that's a long stack
[15:39:49 CDT(-0500)] <holdorph> known issue? java.lang.NumberFormatException: For input string: ""
[15:40:18 CDT(-0500)] <EricDalquist> what were you doing that caused it?
[15:40:38 CDT(-0500)] <holdorph> i logged in as student/student
[15:41:14 CDT(-0500)] <holdorph> did nothing else before/after that. (so, guest page layout, the cas screen, student/student, default layout for student)
[15:41:45 CDT(-0500)] <EricDalquist> neat
[15:42:00 CDT(-0500)] <EricDalquist> can you create a jira issue with the stack trace and the action that triggered it
[15:42:20 CDT(-0500)] <holdorph> at YahooWeatherParsingServiceImpl.parseWeather(YahooWeatherParsingServiceImpl:38)
[15:42:42 CDT(-0500)] <holdorph> is in the stack. so not sure if I should create the issue against weather portlet or against uportal
[15:44:46 CDT(-0500)] <athena> wonder if that's missing info from the weather service or something
[15:46:14 CDT(-0500)] <EricDalquist> just create it against uPortal for now
[15:46:20 CDT(-0500)] <EricDalquist> if nothing else uportal should handle it better
[15:46:24 CDT(-0500)] <holdorph> you can call me out on my non-scripting-bias, but.... why is groovy in that stack?
[15:46:28 CDT(-0500)] <EricDalquist> and not fail with a giant stack trace
[15:46:50 CDT(-0500)] <holdorph> sorry, if i wasn't clear. the page renders. this is just an ugly mess in the catalina.out
[15:47:13 CDT(-0500)] <EricDalquist> ah ok
[15:47:33 CDT(-0500)] <athena> some crn portlet? do we still have any of those left?
[15:47:41 CDT(-0500)] <holdorph> this is the weather portlet
[15:47:48 CDT(-0500)] <athena> oh
[15:48:03 CDT(-0500)] <EricDalquist> I think the XML parsing is done in groovy right?
[15:48:06 CDT(-0500)] <athena> yeah the weather portlet's yahoo service uses groovy because the schema is really hard to parse w/ JAXB
[15:48:16 CDT(-0500)] <EricDalquist> because they don't provide an actual XSD for their service?
[15:48:21 CDT(-0500)] <EricDalquist> if I recall correctly
[15:48:23 CDT(-0500)] <athena> and because we wrote it as an emergency in like a day and didn't have time to sort everything out
[15:48:35 CDT(-0500)] <athena> well . . . they add some custom namespace stuff into RSS
[15:48:41 CDT(-0500)] <athena> but i still can't make JAXB play nicely with it
[15:49:10 CDT(-0500)] <athena> holdorph: i'd much prefer not to use groovy for that, and if anyone has time, i'd be all for figuring out how to transition that back to something more standard
[15:49:21 CDT(-0500)] <athena> but we wanted to provide a quick solution for accuweather dropping our feed
[15:50:30 CDT(-0500)] <holdorph> how 'big' is the xml that it returns? would it be that hard to just skip jaxb and parse it manually with something like jdom or the other one dom4j (? always forget the name)
[15:51:17 CDT(-0500)] <athena> we could, but that's always a pain and leads to dependency issues
[15:51:24 CDT(-0500)] <athena> so not sure that we'd actually be gaining anything there
[15:51:34 CDT(-0500)] <athena> not sure that's really an improvement on groovy
[15:52:33 CDT(-0500)] <holdorph> i'd have to run some perf tests, but i suspect, there'd at least be a perf improvement.
[15:54:32 CDT(-0500)] <athena> would be interesting to see
[15:54:58 CDT(-0500)] <athena> i suspect the network download time may be more of a factor than parsing, but guess it'd be interesting to see
[15:55:16 CDT(-0500)] <athena> it's possible we could also parse that with rome and a custom modules impl
[15:56:14 CDT(-0500)] <holdorph> what's the default cache time for the weather data?
[15:56:41 CDT(-0500)] <EricDalquist> close to an hour I think
[15:56:50 CDT(-0500)] <holdorph> hmm....
[15:57:08 CDT(-0500)] <holdorph> i left the tab, came back and got the stack(s) again. but just did that again, and didn't
[15:57:14 CDT(-0500)] <EricDalquist> hrm only 15 minutes
[15:57:17 CDT(-0500)] <holdorph> so it seemed like it might have been shorter
[15:57:22 CDT(-0500)] <holdorph> ok, that makes sense.
[15:57:25 CDT(-0500)] <EricDalquist> exceptions are cached for 30 seconds
[15:57:31 CDT(-0500)] <EricDalquist> searches are cached for 6 hours
[15:57:36 CDT(-0500)] <athena> we probably want to turn that up, i'd think
[15:57:39 CDT(-0500)] <EricDalquist> though I think we can increase the weather cache time
[15:57:41 CDT(-0500)] <holdorph> there seem to be 4 preconfigured locations
[15:57:46 CDT(-0500)] <athena> yes, there are
[15:57:50 CDT(-0500)] <holdorph> but I don't get any data in the weather portlet
[15:57:59 CDT(-0500)] <EricDalquist> I know WWO only updates their feed data every hour
[15:58:01 CDT(-0500)] <holdorph> i'm getting "Currently there is no weather location(s) set, please set a location(s) using the edit link."
[15:58:29 CDT(-0500)] <athena> looks like i need to check in an update
[15:58:32 CDT(-0500)] <athena> i've fixed that locally
[15:58:57 CDT(-0500)] <holdorph> what was the fix? will it get rid of my stack ? i hope?
[15:59:02 CDT(-0500)] * holdorph hates messy log files.
[15:59:18 CDT(-0500)] <athena> yes, it will
[15:59:20 CDT(-0500)] <EricDalquist> oh
[15:59:23 CDT(-0500)] <EricDalquist> speaking of messy logs
[15:59:24 CDT(-0500)] <athena> it sets the locations to ones that are actually compatible w/ yahoo's weather service
[15:59:35 CDT(-0500)] <athena> yeah we need to turn the news reader hibernate logging down
[15:59:37 CDT(-0500)] <EricDalquist> what are peoples opinions on logging non-fatal stack traces
[15:59:39 CDT(-0500)] <athena> as well as the portlet cookie dao
[15:59:47 CDT(-0500)] <EricDalquist> like there are a lot of places in the portal where it catches an exception
[15:59:49 CDT(-0500)] <EricDalquist> logs a warning
[15:59:53 CDT(-0500)] <EricDalquist> and gracefully recovers
[16:00:01 CDT(-0500)] <EricDalquist> I HATE throwing away stack traces
[16:00:10 CDT(-0500)] <EricDalquist> but seeing a stack makes people think something is broken
[16:00:18 CDT(-0500)] <EricDalquist> when really it could just be a user entering bad data
[16:00:34 CDT(-0500)] <EricDalquist> I've seen some libraries do stuff where warn level has no stack
[16:00:41 CDT(-0500)] <EricDalquist> but if you turn on debug you get the stack
[16:00:47 CDT(-0500)] <athena> yeah was just about to suggest that
[16:00:54 CDT(-0500)] <athena> seems reasonable
[16:02:00 CDT(-0500)] <holdorph> there's probably some way to get creative, but at the same time probably not worth the effort, that solution seems simple and like it would work.
[16:02:13 CDT(-0500)] <athena> checked in a fix for you holdorph
[16:02:37 CDT(-0500)] <holdorph> will i get it, if I just update uportal-trunk ?
[16:02:48 CDT(-0500)] <EricDalquist> I might create a little Logger wrapper that has a warnWithDebugEx(str, ex)
[16:02:54 CDT(-0500)] <EricDalquist> and encapsulates that logic
[16:03:01 CDT(-0500)] <athena> update, then run ant crn-import on the weather portlet file
[16:03:31 CDT(-0500)] <EricDalquist> I did find a jboss contact person for their maven repo
[16:03:34 CDT(-0500)] <EricDalquist> and emailed them
[16:03:41 CDT(-0500)] <EricDalquist> maybe we can get that fixed in the next day or two
[16:03:45 CDT(-0500)] <athena> that'd be nice
[16:04:52 CDT(-0500)] <holdorph> hmm.... what happened to the log back in link on the cas screen?
[16:05:13 CDT(-0500)] <athena> log back in?
[16:05:15 CDT(-0500)] <holdorph> i clicked 'sign out' at the top of the uportal page, got the cas signout success page. but no link to log back in
[16:05:24 CDT(-0500)] <athena> don't think we've ever actually had that
[16:05:28 CDT(-0500)] <athena> forget what setting that is in cas
[16:05:55 CDT(-0500)] <holdorph> hmm... I thought it was there in 3.2.2'ish (can't remember the last time I tested this thoroughly)
[16:06:00 CDT(-0500)] <EricDalquist> yeah
[16:06:02 CDT(-0500)] <EricDalquist> we did have it
[16:06:04 CDT(-0500)] <athena> ah
[16:06:10 CDT(-0500)] <EricDalquist> I noticed as well just enver thought about it really
[16:06:10 CDT(-0500)] <athena> might have lost a setting when we upgraded
[16:06:13 CDT(-0500)] <EricDalquist> yeah
[16:06:26 CDT(-0500)] <athena> think adam got us up to a much more recent CAS version during the unconference
[16:06:41 CDT(-0500)] <holdorph> as a uportal instructor, it's a pain. probably not to the average user though.
[16:06:59 CDT(-0500)] <athena> it would be nice to have, if you want to fix it
[16:07:12 CDT(-0500)] <EricDalquist> 
[16:07:25 CDT(-0500)] <holdorph> if it's a cas setting, i'm not going to be the one to find that needle before the conference
[16:07:45 CDT(-0500)] <holdorph> maybe our new cas expert bill thompson knows what it is
[16:07:54 CDT(-0500)] <athena> sounds good to me!
[16:10:03 CDT(-0500)] <holdorph> athena: do you have the ant crn-import command line still in your history?
[16:10:15 CDT(-0500)] * holdorph is lazy and doesn't want to look up the parameter names
[16:10:25 CDT(-0500)] <athena> ant crn-import -Ddir=directory -Dpattern=filename
[16:11:26 CDT(-0500)] <holdorph> sorry, i thought you had run the command, i didn't mean for you to look in the build.xml.
[16:12:17 CDT(-0500)] <holdorph> odd, wonder why it's recompiling just to run that crn-import
[16:12:47 CDT(-0500)] <EricDalquist> the build is naïve
[16:13:04 CDT(-0500)] <EricDalquist> if any file changes under uportal-war (which also contains the code to run the tool) it rebuilds
[16:18:28 CDT(-0500)] <holdorph> that cleaned up my logs athena, and also helped the weather portlet display real data
[16:18:53 CDT(-0500)] <athena> awesome, i'm glad
[16:19:03 CDT(-0500)] <athena> it was feeding the portlet strings, and yahoo uses numerical codes
[16:20:24 CDT(-0500)] <holdorph> i saw something (email or irc chatter) about needing a minimize icon, right?
[16:20:46 CDT(-0500)] <holdorph> using the same one as maximized, feels a bit odd
[16:20:55 CDT(-0500)] <athena> gary's working on that right now
[16:21:20 CDT(-0500)] <holdorph> ok, i thought it had already come up, just checking
[16:22:08 CDT(-0500)] <athena>
[16:22:12 CDT(-0500)] <athena> good to make sure we have stuff covered
[16:38:39 CDT(-0500)] <EricDalquist> got the word back that the jboss infra group is aware of the maven repo isseu and is working on it
[16:38:47 CDT(-0500)] <EricDalquist> increased load recently I guess
[16:38:57 CDT(-0500)] <EricDalquist> also they say they are working ongetting synced to central
[16:39:02 CDT(-0500)] <EricDalquist> which really would be the best option
[16:39:19 CDT(-0500)] <athena> ah that'd be terrific
[16:39:20 CDT(-0500)] <EricDalquist> it would be great if we could get to the point where uportal only needs central to build
[16:39:26 CDT(-0500)] <EricDalquist> would make builds MUCH faster
[16:39:30 CDT(-0500)] <EricDalquist> well new builds
[16:39:31 CDT(-0500)] <athena> no kidding!
Manage space
Manage content
Integrations