uPortal IRC Logs-2012-05-11

Owned by Apereo Infrastructure
Last updated: May 11, 2012
5 min read

[10:51:38 CDT(-0500)] <EricDalquist> that's a fun bug in calendar portlet 1.0 (smile)

[10:52:30 CDT(-0500)] <athena> i guess? i'm actually surprised that that causes such misbehavior

[10:52:47 CDT(-0500)] <EricDalquist> so in uP4 I added entity versioning to all our JPA objects

[10:52:53 CDT(-0500)] <EricDalquist> as a form of optomistic locking

[10:53:03 CDT(-0500)] <EricDalquist> every time an object is updated its version number increments

[10:53:07 CDT(-0500)] <athena> ah

[10:53:08 CDT(-0500)] <EricDalquist> and the updates all include the version number

[10:53:18 CDT(-0500)] <athena> so the misbehavior is up4-specfic?

[10:53:22 CDT(-0500)] <EricDalquist> prevents concurrent updates from stepping on each other

[10:53:23 CDT(-0500)] <EricDalquist> yeah

[10:53:33 CDT(-0500)] <EricDalquist> essentially concurrently updating portlet preferences has always been bad

[10:53:33 CDT(-0500)] <athena> well, good to know

[10:53:46 CDT(-0500)] <EricDalquist> in uP3 it would fail silently, last update always won

[10:53:53 CDT(-0500)] <EricDalquist> in uP4 it fails loudly

[10:54:06 CDT(-0500)] <EricDalquist> if you really have a concurrent preference update use case you need to sync on the session or some such

[10:54:36 CDT(-0500)] <athena> i know we actually talked at this at some point

[10:54:50 CDT(-0500)] <athena> and for that portlet we knew it was fine if the last update won

[10:55:02 CDT(-0500)] <athena> don't think there was discussion around it actually creating performance problems

[10:55:02 CDT(-0500)] <EricDalquist> huh

[10:55:05 CDT(-0500)] <EricDalquist> yeah

[10:55:34 CDT(-0500)] <EricDalquist> well and I'm going to look into adding more logic in the preferences service

[10:55:41 CDT(-0500)] <EricDalquist> so that if you don't actually change anything

[10:55:45 CDT(-0500)] <EricDalquist> and call store nothing happens

[10:55:45 CDT(-0500)] <athena> ok, great

[10:55:56 CDT(-0500)] <EricDalquist> since that code looks like it will be setting the same value every time

[10:56:08 CDT(-0500)] <athena> well, the days is

[10:56:25 CDT(-0500)] <athena> i worry that other portlets may be doing similar things, and not always setting the same value

[10:56:33 CDT(-0500)] <EricDalquist> yeah

[10:56:37 CDT(-0500)] <athena> like the news reader portlet definitely used to set the feedId as a preference

[10:56:48 CDT(-0500)] <EricDalquist> on every ajax request?

[10:56:50 CDT(-0500)] <athena> so that when you came back to the portlet it would remember the last feed you looked at

[10:56:57 CDT(-0500)] <athena> yes

[10:56:59 CDT(-0500)] <EricDalquist> so it all depends

[10:57:12 CDT(-0500)] <EricDalquist> it seems like the cal portlet does lots of concurrent ajax requests per user

[10:57:23 CDT(-0500)] <EricDalquist> in that case modifying prefs in each can be bad

[10:57:46 CDT(-0500)] <athena> i don't think it should be doing concurrent ajax requests

[10:58:00 CDT(-0500)] <EricDalquist> I'm not sure how else bruce could be getting that error

[10:58:01 CDT(-0500)] <athena> i'm not sure why we'd be seeing those at all, actually

[10:58:13 CDT(-0500)] <athena> the portlet makes one when loaded

[10:58:24 CDT(-0500)] <athena> then makes a request any time the user changes the date, etc.

[10:58:32 CDT(-0500)] <EricDalquist> hrm

[10:58:44 CDT(-0500)] <EricDalquist> so I just realized there is locking in the prefs service too

[10:58:58 CDT(-0500)] <athena> you know . . . i think they have a single-feed version of the calendar and may be displaying a bunch of calendar portlets on a page

[10:59:00 CDT(-0500)] <EricDalquist> in prefs service .store the code gets a Lock scoped to the portlet entity

[10:59:02 CDT(-0500)] <athena> don't know if that might be a factor

[11:00:21 CDT(-0500)] <EricDalquist> oh ... huh

[11:00:29 CDT(-0500)] <EricDalquist> my lock and tx are not scoped correctly

[11:02:05 CDT(-0500)] <EricDalquist> the lock happens inside the tx

[11:02:09 CDT(-0500)] <EricDalquist> but it shuld happen outside

[11:02:42 CDT(-0500)] <athena> ooh

[11:02:59 CDT(-0500)] <EricDalquist> since hibernate doesn't actually flush anything to the DB until the TX completes

[11:03:05 CDT(-0500)] <EricDalquist> that means the lock is released and then the commit happens

[11:03:08 CDT(-0500)] <EricDalquist> not the other way around

[11:51:40 CDT(-0500)] <peterjhart> What is everyone's favorite way to edit the user agent for the different browsers?

[11:52:24 CDT(-0500)] <athena> with firefox i have a plugin

[11:52:28 CDT(-0500)] <athena> in safari it's built-in

[11:53:14 CDT(-0500)] <EricDalquist> chome is built in too

[11:53:36 CDT(-0500)] <athena> is it on os x now?

[11:53:53 CDT(-0500)] <EricDalquist> yeah

[11:54:01 CDT(-0500)] <EricDalquist> it is hidden in the dev tool

[11:55:16 CDT(-0500)] <peterjhart> Just saw the blog post about Chrome. It looks like they added that in December.

[11:55:29 CDT(-0500)] <peterjhart> I haven't had to edit my user agent for a long while

[11:55:53 CDT(-0500)] <peterjhart> took me a very long time to figure out that is how you see the mobile skin (smile)

[11:56:04 CDT(-0500)] <peterjhart> so... workin on the documentation... (smile)

[12:06:13 CDT(-0500)] <peterjhart> I was thinking there would be a setting in the code to show the mobile version when in development

[12:06:39 CDT(-0500)] <athena> hmm, interesting

[12:07:06 CDT(-0500)] <athena> in the past we just told people to use safari because the old mobile theme didn't work well on non-webkit browsers anyway

[12:07:32 CDT(-0500)] <athena> new one is better though

[12:08:37 CDT(-0500)] <athena> if you want to change the default, you could go into userContext.xml and add a new rule to match .* to mobileDefault

[12:09:36 CDT(-0500)] <peterjhart> oh

[12:10:13 CDT(-0500)] <athena> we just match profiles on regexes

[12:10:27 CDT(-0500)] <peterjhart> the mobile theme in uP4 assumes the viewport is only 320x480

[12:11:22 CDT(-0500)] <athena> which probably doesn't make sense anymore

[12:11:30 CDT(-0500)] <athena> what should we be doing?

[12:11:49 CDT(-0500)] <peterjhart> my first answer is "responsive design"

[12:12:00 CDT(-0500)] <peterjhart> but that might not be the whole solution

[12:12:24 CDT(-0500)] <peterjhart> because it seems like there are many backend changes when the user is on a mobile device

[12:12:29 CDT(-0500)] <peterjhart> e.g. some portlets don't show

[12:12:58 CDT(-0500)] <peterjhart> responsive design loads different CSS based on screen size

[12:13:45 CDT(-0500)] <peterjhart> its a feature of CSS3.

[12:14:28 CDT(-0500)] <peterjhart> So, when EricDalquist refers to "4.1", is that the same thing as master?

[12:14:46 CDT(-0500)] <EricDalquist> right now there is no 4.1

[12:14:57 CDT(-0500)] <EricDalquist> "real soon now" I'll be create a 4.0 branch

[12:15:01 CDT(-0500)] <peterjhart> I thought you said you put the SASS/Maven stuff into 4.1

[12:15:04 CDT(-0500)] <EricDalquist> and updating master to 4.1.0-SNPASHOT

[12:15:07 CDT(-0500)] <EricDalquist> I will be

[12:15:12 CDT(-0500)] <EricDalquist> it is all on a working branch right now

[12:15:16 CDT(-0500)] <peterjhart> ok

[12:15:19 CDT(-0500)] <EricDalquist> until I make sure I have it sorted out

[12:15:34 CDT(-0500)] <EricDalquist> I think I have things straight so I'm going to try and do that this weekend

[12:15:55 CDT(-0500)] <peterjhart> the SASS in muniversality looks to be in disarray. I don't know if I can get to it today

[12:16:39 CDT(-0500)] <EricDalquist> not a problem

[12:16:51 CDT(-0500)] <EricDalquist> I just won't touch the .css files for the muniv stuff

[12:17:07 CDT(-0500)] <peterjhart> k

[12:28:21 CDT(-0500)] <peterjhart> Palm Pre support in userContext.xml! I love you guys!!

[12:28:54 CDT(-0500)] <athena> if there are updates that need to be made to that file please do suggest them (smile)

[12:29:29 CDT(-0500)] <peterjhart> I had a palm pre for 2 years. I loved it, but the web didn't.

[12:29:51 CDT(-0500)] <athena> aww

[12:29:54 CDT(-0500)] <athena> poor phone