uPortal IRC Logs-2012-02-15

Owned by Apereo Infrastructure
Last updated: Feb 15, 2012Version comment

[10:13:54 CST(-0600)] <b-sure> Hello uPortal devs. hello EricDalquist. I'm happy to report the error I saw yesterday afternoon http://stackoverflow.com/questions/5891032/in-a-spring-bean-is-it-possible-to-have-a-shutdown-method-which-can-use-transact was a false positive. A fresh clean and deploy resolved it after reverting my changes.

[10:14:06 CST(-0600)] <EricDalquist> that's good (smile)

[10:14:58 CST(-0600)] <b-sure> yeah. I'm hoping to do the full data export from 3.2.5 and import from the 4.0.3 build today. I think you may have fixed the issue we were having so I can try to confirm today.

[10:15:15 CST(-0600)] <EricDalquist> hopefully (smile)

[11:10:59 CST(-0600)] <EricDalquist> drewwills: oracle has no concept of null vs ""

[11:11:05 CST(-0600)] <EricDalquist> they are one in the same

[11:11:22 CST(-0600)] <EricDalquist> which is why a various JPA entities in uPortal use a nullSafeString custom type

[11:11:32 CST(-0600)] <EricDalquist> that prefixes all non-null strings with _ when sticking them into the DB

[11:15:27 CST(-0600)] <b-sure> Hello EricDalquist. I can confirm that UP-3345 affects the Group Manager in the 4.0.3 build as well.

[11:16:41 CST(-0600)] <athena> is this the authentication stack trace one?

[11:16:41 CST(-0600)] <b-sure> from discussion btwn drewwills and EricDalquist, I'm not sure if I should attempt an export of 3.2.5 to an import of 4.0.3

[11:17:12 CST(-0600)] <b-sure> yes athena I think so. I'll verify now...

[11:17:21 CST(-0600)] <athena> i remember that from yesterday

[11:17:27 CST(-0600)] <athena> guessing it may affect several admin portlets

[11:17:32 CST(-0600)] <athena> will take a look today

[11:19:46 CST(-0600)] <b-sure> hello athena is this a good forum to discuss uMobile or do you have another IRC channel set for that?

[11:21:06 CST(-0600)] <drewwills> yeah EricDalquist i figured that must be the case... the change I just committed should plug that particular hole though

[11:21:07 CST(-0600)] <b-sure> or maybe I should just send to the mailing list for questings. not sure

[11:23:34 CST(-0600)] <athena> b-sure: that's fine (smile)

[11:23:51 CST(-0600)] <b-sure> fine to the list or fine here? not sure

[11:23:54 CST(-0600)] <athena> since umobile is mostly uportal components i think it makes sense to discuss here

[11:24:02 CST(-0600)] <b-sure> oh ok. awesome

[11:24:03 CST(-0600)] <athena> just whatever's easiest for you

[11:25:19 CST(-0600)] <b-sure> hello drewwills is the change you committed for the ticket from earlier today is that in the 3.2-patches branch of the portal or maybe it is in git somewhere that I can try to apply?

[11:29:01 CST(-0600)] <drewwills> b-sure it doesn't impact 3-2-patches actually... if we're talking about the same thing

[11:30:34 CST(-0600)] <drewwills> 3-2 had different logic... sort of... would use the bad input as long as it wasn't > 35 chars

[11:31:01 CST(-0600)] <drewwills> but that's import side anyway... are you importing into 3-2? (wink)

[11:34:39 CST(-0600)] <b-sure> opps no I've got a dump or 3-2 data and want to import it into 4.0.3. I"ve had to make mods to some of the xml in the 3-2 data files like removing lines from the .layout files in order to import into 4.x builds. I'm thinking I should try a fresh export of 3.2 data and import to the 4.0.3 release.

[11:35:22 CST(-0600)] <b-sure> and see if I need to modify anything in the xml produced from the 3.2-patches build

[11:35:37 CST(-0600)] <drewwills> yeah you will need to

[11:36:21 CST(-0600)] <b-sure> ok so I'll still need to remove some things from user's layout files in order to load it into the 4.0.3 build?

[11:36:29 CST(-0600)] <drewwills> for the most part the tools faithfully disgorge data, then faithfully reproduce it from the XML

[11:36:41 CST(-0600)] <b-sure> understood

[11:37:07 CST(-0600)] <drewwills> when you're migrating versions, sometimes 100% faithful reproduction is not what you want

[11:37:32 CST(-0600)] <b-sure> yeah I think so too

[11:37:52 CST(-0600)] <drewwills> we try to catch some of the clear cases where things should be changed on migration... bake those changes into the process

[11:38:04 CST(-0600)] <drewwills> but not everything is clear like that

[11:38:27 CST(-0600)] <b-sure> yes so from 3.2 to 4.x builds there were these header and footer xml in the layouts that needed to be removed

[11:39:41 CST(-0600)] <drewwills> yeah removing header/footer <folder> elements from regular users is a good call... you might want to put stuff in there for fragment layouts... like we did with the all-lo for the tips and emergency notifications

[11:40:07 CST(-0600)] <EricDalquist> drewwills: that might be a worth-while tweak to the import-layout scripts for 4.0

[11:40:21 CST(-0600)] <EricDalquist> add a flag to ignore header/footer data for non layout owners

[11:40:45 CST(-0600)] <b-sure> that would be helpful for our data I think

[11:40:52 CST(-0600)] <drewwills> it might... you could put a toggle in import.props to enable the behavior... like the theme override behavior

[11:41:04 CST(-0600)] <drewwills> er yeah exactly

[11:42:20 CST(-0600)] <drewwills> also: if you have layout owners that have header/footer folders that should not percolate to their audiences, just make hidden=true

[11:42:50 CST(-0600)] <drewwills> that will cause them not to be applied to the fragment audience members

[11:43:08 CST(-0600)] <b-sure> um aside from the manual layout file adjustments, all of the data imported cleanly from the 3.2 builds into the 4.x builds. except we have had to use the 4.0.1 build to do the import and not the 4.0.2 build

[11:43:29 CST(-0600)] <b-sure> base on the wiki page EricDalquist put in place for the 3.2 upgrade to 4.0

[11:44:02 CST(-0600)] <drewwills> could maybe use the tip of master for the import, if you think there are fixes there you want to use in the process

[11:45:01 CST(-0600)] <drewwills> also: i would take all the data EXCEPT user/layout/profile files for real users and put it in SCM

[11:45:40 CST(-0600)] <drewwills> so i can make tweaks, share/audit my changes, etc

[11:45:58 CST(-0600)] <b-sure> this page is very helpful https://wiki.jasig.org/display/UPM40/Upgrade+Data+Import

[11:45:59 CST(-0600)] <drewwills> then i'd use my massaged versions of those files at the zero hour

[11:56:33 CST(-0600)] <b-sure> drewwills maybe your tip " removing header/footer <folder> elements from regular users .layout files" should be added to the wiki page in the .layout .profile section?

[11:57:52 CST(-0600)] <athena> hey EricDalquist - you still have time to talk about the JSON theme today?

[11:57:55 CST(-0600)] <b-sure> I"m not familiar with the all-lo fragment usr tip

[11:58:15 CST(-0600)] <EricDalquist> ah ... yeah I think so athena, I'll be back from a meeting around 1:30c and I'll ping you then

[11:58:44 CST(-0600)] <athena> cool

[11:59:02 CST(-0600)] <athena> i have a noon-o-clock appointment, but if i don't catch you before then we can talk after

[11:59:40 CST(-0600)] <EricDalquist> ok

[12:06:03 CST(-0600)] <b-sure> ok athena here is a uMobile question. with our pre educause build of uMobile native app, I see that I can add any portlet in our system to our guest layout and, if it shows up in the portalURL/layout.json file in the browser, it will show up in the emulator device in the unauthenticated view.

[12:06:26 CST(-0600)] <athena> yes, that sounds right

[12:08:48 CST(-0600)] <b-sure> I've seen that if I add another portelt to the quest view while the emulator is running, I need to restart the emulator for the new portlet to show in view. It does show immeadiatly in /layout.json. So I'm thinking, is it a feature of umobile native to do some kind of polling of the uPortal server so that it can render new portlets added to the guest layout on the fly (maybe in the authenticated view as well)? Or maybe it sh

[12:09:05 CST(-0600)] <b-sure> to restart their native app on the device to see new information?

[12:12:57 CST(-0600)] <athena> right now it's session-based

[12:13:04 CST(-0600)] <b-sure> It does look like in the console output of TA while the emulator is running that something is hapening

[12:13:10 CST(-0600)] <b-sure> oh ok it is session based

[12:13:12 CST(-0600)] <athena> so it's basically the same experience that a user would get in a browser

[12:13:13 CST(-0600)] <athena> yeah

[12:13:23 CST(-0600)] <athena> so the next time you open the app up you'll get the new layout

[12:13:24 CST(-0600)] <b-sure> that is probably fine

[12:13:35 CST(-0600)] <b-sure> yeah thats what Im' seeing when I restart the emulator

[12:13:38 CST(-0600)] <athena> yeah, we'd need to actually establish a new session w/ uportal to get the new layout

[12:13:45 CST(-0600)] <b-sure> ok

[12:13:50 CST(-0600)] <athena> just like users don't get the new layout in the browser until their session is renewed

[12:14:25 CST(-0600)] <b-sure> yep. I also note that I needed to clear the cache in uPortal for my new portlet to show in the guest view

[12:14:43 CST(-0600)] <b-sure> or maybe I just need to close / open the browser

[12:18:17 CST(-0600)] <b-sure> another question if you have time athena, some of the portlets loaded from uPortal server on the native app look nicely styled for a mobile device, can the styling for these portlets reside in the portlet itself or do we have to add something extra to the native uMobile app to get the portlets to display nicely? The test portlets I added to the guest view look like mini portlets in the emulator when I click on them.

[12:19:06 CST(-0600)] <athena> that's all on the portal side

[12:19:13 CST(-0600)] <b-sure> oh good.

[12:19:20 CST(-0600)] <athena> the native app is using something called a web view that's basically an embedded web browser

[12:19:23 CST(-0600)] <athena> it's sort of like an iframe

[12:19:51 CST(-0600)] <athena> so typically the portlets you're looking at have shared model and controllers, but then have one JSP file for desktop views, and one for mobile

[12:20:02 CST(-0600)] <athena> that's certainly not how you have to implement it, but we've had good luck with that strategy

[12:20:13 CST(-0600)] <athena> for the mobile view, the portlets are using jQuery Mobile

[12:20:35 CST(-0600)] <b-sure> ok.

[12:20:41 CST(-0600)] <athena> it's pretty easy to create content with, and if you use the standard elements and classes, most simple views should have pretty nice styling without you having to put in much custom CSS

[12:20:55 CST(-0600)] <b-sure> and the portlet is just detecting the user agent and serving the mobile view?

[12:21:24 CST(-0600)] <athena> here's an example: https://source.jasig.org/sandbox/CampusLifePortlets/trunk/src/main/webapp/WEB-INF/jsp/laundry/main-jQM.jsp

[12:21:41 CST(-0600)] <athena> it's actually detecting a parameter coming from the portal that represents the theme name

[12:21:46 CST(-0600)] <athena> you could instead detect the user agent

[12:22:05 CST(-0600)] <athena> but the advantage of using the theme name, is that then if we start letting users choose which view they want, the portlets and the portal will match

[12:22:29 CST(-0600)] <athena> here's a sample view helper implementation: https://source.jasig.org/sandbox/CampusLifePortlets/trunk/src/main/java/org/jasig/portlet/campuslife/mvc/ThemeNameViewSelectorImpl.java

[12:25:16 CST(-0600)] <b-sure> oh ok nice. so where do you set the theme name? in the portlet configuration

[12:41:32 CST(-0600)] <athena> the theme name comes in from the portal automatically

[12:44:40 CST(-0600)] <b-sure> I see now. thanks.

[12:44:44 CST(-0600)] <b-sure> this is really helpful.

[12:45:45 CST(-0600)] <b-sure> we've got some authentication questions were trying to figure out yet but I think we're making good progress with the evaluation. I'll try to update you with them as they come in.

[12:52:15 CST(-0600)] <athena> terrific, glad things are off to a good start (smile)

[14:00:52 CST(-0600)] <EricDalquist> hey athena

[14:00:56 CST(-0600)] <EricDalquist> json issue

[15:12:49 CST(-0600)] <athena> hi EricDalquist

[15:12:54 CST(-0600)] <athena> you still have time to talk?

[15:12:55 CST(-0600)] <EricDalquist> hi athena

[15:12:56 CST(-0600)] <EricDalquist> yup

[15:13:11 CST(-0600)] <athena> awesome.

[15:13:27 CST(-0600)] <athena> so . . . i think at this point i'm actually not even quite sure what we intend the code to do

[15:14:05 CST(-0600)] <EricDalquist> do you have that stack trace handy again?

[15:14:29 CST(-0600)] <athena> not offhand, though i can generate a new one

[15:14:35 CST(-0600)] <athena> maybe i can find it in the logs though

[15:15:33 CST(-0600)] <athena> ah, found it: https://gist.github.com/1819876

[15:15:52 CST(-0600)] <athena> it seems kind of random now

[15:15:58 CST(-0600)] <EricDalquist> sec ... someone walked in

[15:16:10 CST(-0600)] <athena> like half the time we get an error, and half the time it renders, but some of hte portlets don't render content

[15:16:42 CST(-0600)] <EricDalquist> so ... first thought

[15:17:03 CST(-0600)] <EricDalquist> something changed in spring in how minimized portlets "render"

[15:17:12 CST(-0600)] <EricDalquist> and null is being returned instead of ""

[15:17:35 CST(-0600)] <athena> ah

[15:17:38 CST(-0600)] <athena> sounds possible

[15:17:43 CST(-0600)] <athena> so what's our strategy right now?

[15:17:45 CST(-0600)] <EricDalquist> in which case the PortletRendererImpl needs to be updated to handle null being a valud return value from doRender

[15:17:50 CST(-0600)] <EricDalquist> and convert it to ""

[15:17:54 CST(-0600)] <athena> i wasn't sure what was changed last week

[15:18:03 CST(-0600)] <EricDalquist> not much

[15:18:23 CST(-0600)] <EricDalquist> the only things I can think of are the spring 3.1 update

[15:18:31 CST(-0600)] <EricDalquist> and the filter that minimizes all portlets in the mobile views

[15:19:47 CST(-0600)] <EricDalquist> that is all just a big guess

[15:20:02 CST(-0600)] <EricDalquist> to know for sure you'd either need a break point or logging in PortletRenderingIncorporationComponent to see what the portlet renderer returned

[15:20:06 CST(-0600)] <EricDalquist> and potentially trace back from there

[15:20:15 CST(-0600)] <EricDalquist> can you reproduce this consistently?

[15:20:37 CST(-0600)] <athena> no, unfortunately

[15:21:43 CST(-0600)] <EricDalquist> then I'd start at PortletRenderingIncorporationComponent.java:133

[15:21:56 CST(-0600)] <EricDalquist> and trace the call path back that gets the portlet content string

[15:21:58 CST(-0600)] <athena> thanks

[15:22:01 CST(-0600)] <EricDalquist> and add logging

[15:22:14 CST(-0600)] <EricDalquist> to see if you can figure out why that string is null

[15:22:21 CST(-0600)] <EricDalquist> it should just be empty for a portlet that doesn't render

[15:22:43 CST(-0600)] <athena> makes sense

[15:23:00 CST(-0600)] <athena> ok, here we go

[15:23:16 CST(-0600)] <athena> looks like at least something related is happening consistently w/ the email preview portlet in the student user account

[15:23:19 CST(-0600)] <athena> so i'll start there

[15:23:30 CST(-0600)] <EricDalquist> great (smile)

[15:57:31 CST(-0600)] <athena> interesting.

[15:57:41 CST(-0600)] <athena> looks like actually this is being caused by the email preview portlet timing out, maybe?

[15:57:53 CST(-0600)] <athena> looking at PortletExecutionManager.getPortletLink

[15:58:08 CST(-0600)] <athena> the exception is caught, and then returns null

[15:58:12 CST(-0600)] <EricDalquist> hrm

[15:58:22 CST(-0600)] <athena> and PortletRenderingIncorporationComponent choked on the null link

[15:59:24 CST(-0600)] <athena> not sure i understand why anything would be timing out in the first place, but seems like there's definitely an exception there

[16:19:26 CST(-0600)] <athena> heh, ok.

[16:19:32 CST(-0600)] <athena> think i've finally tracked this down EricDalquist

[16:19:41 CST(-0600)] <EricDalquist> what's going on?

[16:19:52 CST(-0600)] <EricDalquist> sorry for not responding earlier, people keep stoping in

[16:19:52 CST(-0600)] <athena> email preview portlet is breaking on something i haven't tracked down yet that's unrelated

[16:19:55 CST(-0600)] <athena> oh, no worries

[16:20:00 CST(-0600)] <athena> appreciate the tips on where to start

[16:20:06 CST(-0600)] <athena> anyway, once it breaks it throws an exception

[16:20:18 CST(-0600)] <athena> and since it does, the link is never assigned

[16:20:24 CST(-0600)] <athena> and the pipeline breaks on the null link

[16:20:27 CST(-0600)] <EricDalquist> ah

[16:20:36 CST(-0600)] <athena> so my thought is that where the exception is caught we just set the link to the defaultPortletUrl

[16:20:42 CST(-0600)] <athena> does that seem reasonable?

[16:20:44 CST(-0600)] <EricDalquist> yeah

[16:20:49 CST(-0600)] <athena> ok

[16:20:51 CST(-0600)] <athena> easy enough fix then (smile)

[16:20:57 CST(-0600)] <athena> and i'll figure out what's going on w/ the portlet itself

[16:21:06 CST(-0600)] <athena> i also finally found the source of my maps JSON bug

[16:21:15 CST(-0600)] <EricDalquist> yay (smile)

[16:21:19 CST(-0600)] <athena> turns out that w/ a really big page full of JSON data the JsonView would crash

[16:21:30 CST(-0600)] <athena> turns out it's actually related to something in uportal, not the library

[16:21:50 CST(-0600)] <athena> our LimitedBufferOutputStream just gives up and sets the stream to null if it reaches the threshold

[16:22:01 CST(-0600)] <athena> then the next time the portlet tries writing to it it gets a NPE

[16:22:20 CST(-0600)] <athena> i'm not sure what we actually want that stream to do, but that seems like probably not what we want (smile)

[16:22:29 CST(-0600)] <athena> could of course temporarily solve it by just upping the threshold, i guess

[16:24:46 CST(-0600)] <EricDalquist> hrm

[16:24:53 CST(-0600)] <EricDalquist> yeah that is a caching bug

[16:25:00 CST(-0600)] <EricDalquist> it should be giving up and stop caching

[16:25:06 CST(-0600)] <EricDalquist> but it should continue to write through

[16:25:20 CST(-0600)] <EricDalquist> that is the bit of code that prevents the portal from caching like a 200MB resource response

[16:25:55 CST(-0600)] <athena> makes sense

[16:26:10 CST(-0600)] <athena> and in this case maybe we do actually want it higher so we can cache that response and set an etag and whatever

[16:26:18 CST(-0600)] <athena> but yeah, sounds really good to have a limit on that

[16:26:22 CST(-0600)] <athena> i'll file that as a bug