Page Comparison

[11:37:17 CST(-0600)] <DrewWills> 'morning EricDalquist... FYI: http://uportal.pastebin.com/RqTbgGrv
[11:37:38 CST(-0600)] <EricDalquist> have you done an initdb recently?
[11:37:44 CST(-0600)] <DrewWills> was getting it Friday... i see the class changed... still getting it (if that's at all interesting)
[11:37:49 CST(-0600)] <DrewWills> friday i did
[11:37:53 CST(-0600)] <EricDalquist> try another one
[11:37:57 CST(-0600)] <DrewWills> k
[11:43:45 CST(-0600)] <DrewWills> same error, afaik
[11:44:13 CST(-0600)] <athena> hey folks
[11:44:20 CST(-0600)] <athena> i'm getting strange behavior this morning as well
[11:44:25 CST(-0600)] <EricDalquist> ok can you post it to https://issues.jasig.org/browse/UP-2861
[11:44:30 CST(-0600)] <EricDalquist> and nick can take a look at it
[11:44:33 CST(-0600)] <EricDalquist> that should affect runtime at all
[11:44:36 CST(-0600)] <athena> in particular, none of the webflow portlets work past the first screen
[11:44:43 CST(-0600)] <athena> just get a blank portal page w/ no stack traces
[11:44:45 CST(-0600)] <EricDalquist> since it is just a background thread trying to do cleanup
[11:44:50 CST(-0600)] <EricDalquist> nothing in the logs at all?
[11:44:51 CST(-0600)] <athena> reverted the weekends changes and the behavior went away
[11:44:56 CST(-0600)] <athena> didn't see anything, no
[11:45:03 CST(-0600)] <athena> though my logs seem to be pretty cluttered at the moment
[11:45:03 CST(-0600)] <EricDalquist> uhg
[11:45:28 CST(-0600)] <athena> not sure which change it was that caused the behavior - i may be able to narrow it down to a specific patch this afternoon if no one finds it first
[11:46:17 CST(-0600)] <EricDalquist> ok, I'm not doing any uportal related work today
[11:46:23 CST(-0600)] <athena> ok
[11:46:30 CST(-0600)] <athena> i've got a few meetings, but i'll take a look later on today
[11:46:33 CST(-0600)] <EricDalquist> ok
[11:46:37 CST(-0600)] <DrewWills> Column not found: PORTLETCOO0_.PORTAL_COOKIE_ID in statement [select portletcoo0_.PORTAL_COOKIE_ID as PORTAL10_5_1_, portletcoo0_.PORTLET_COOKIE_ID as PORTLET1_1_, portletcoo0_.PORTLET_COOKIE_ID as PORTLET1_4_0_, portletcoo0_.COOKIE_COMMENT as COOKIE2_4_0_, portletcoo0_.DOMAIN as DOMAIN4_0_, portletcoo0_.EXPIRES as EXPIRES4_0_, portletcoo0_.NAME as NAME4_0_, portletcoo0_.PATH as PATH4_0_, portletcoo0_.SECURE as SECURE4_0_, portle
[11:46:40 CST(-0600)] <EricDalquist> nick said he can take a look at the cookie error tonight
[11:46:42 CST(-0600)] <DrewWills> lol, that's big
[11:47:07 CST(-0600)] <DrewWills> not sure about the table name "PORTLETCOO0_"
[11:47:21 CST(-0600)] <EricDalquist> it is an alias
[11:47:37 CST(-0600)] <EricDalquist> from UP_PORTLET_COOKIES portletcoo0_
[11:47:54 CST(-0600)] <EricDalquist> that is really weird since that SQL is 100% generated by hibernate
[11:48:14 CST(-0600)] <EricDalquist> and it should be referencing columns that actually exist when generating the SQL from the JPQL statement
[11:48:37 CST(-0600)] <DrewWills> well, the UP_PORTLET_COOKIES table has a "PORTLET_COOKIE_ID" but not a "PORTAL_COOKIE_ID"
[11:56:48 CST(-0600)] <athena> EricDalquist: do you have an issue with me updating the trunk to use a snapshot of the resource server?
[11:56:56 CST(-0600)] <EricDalquist> nope
[11:57:01 CST(-0600)] <athena> would kind of like to get a bit of testing on that new JSP tag before we cut a release
[11:57:01 CST(-0600)] <athena> ok
[11:57:02 CST(-0600)] <EricDalquist> snapshot deps in trunk are just fine
[11:57:18 CST(-0600)] <EricDalquist> DrewWills: I realized I had my laptop with me, looking at the DB (I did an initdb around 7am today) there is a PORTAL_COOKIE_ID column in my UP_PORTLET_COOKIES table
[11:57:25 CST(-0600)] <EricDalquist> are you sure you're initdb worked?
[11:57:34 CST(-0600)] <EricDalquist> (er your)'
[12:29:08 CST(-0600)] <DrewWills> EricDalquist there is? how did you get one
[12:29:17 CST(-0600)] <EricDalquist> svn update
[12:29:19 CST(-0600)] <DrewWills> i'm looking at the PortletCookieImpl class
[12:29:20 CST(-0600)] <EricDalquist> ant clean initdb
[12:29:24 CST(-0600)] <EricDalquist> right
[12:29:26 CST(-0600)] <EricDalquist> it isn't on the class
[12:29:47 CST(-0600)] <EricDalquist> it is added because of the relationship defintion from PortalCookieImpl to PortletCookieImpl
[12:29:58 CST(-0600)] <DrewWills> hmm
[12:31:08 CST(-0600)] <DrewWills> do you have a UP_PORTAL_COOKIES_UP_PORTLET_COOKIES table like I do?
[12:31:12 CST(-0600)] <EricDalquist> nope
[12:31:31 CST(-0600)] <EricDalquist> did you see the up-dev email that said to delete your DB before running initdb?
[12:31:42 CST(-0600)] <DrewWills> heh... no
[12:31:52 CST(-0600)] <EricDalquist> it was on the 13th
[12:31:55 CST(-0600)] <DrewWills> but I thought initdb deleted all the tables?
[12:32:02 CST(-0600)] <EricDalquist> it deletes all the tables uportal knows about
[12:32:14 CST(-0600)] <EricDalquist> during development of the cookie support there were some tables added that no longer exist
[12:32:21 CST(-0600)] <EricDalquist> which include some constraints
[12:33:56 CST(-0600)] <EricDalquist> I'm guessing what is happing is that table plus some constraints aren't getting dropped because that table has some FK constraints on up_portlet_cookies
[12:34:14 CST(-0600)] <DrewWills> sounds very plausible
[12:34:52 CST(-0600)] <EricDalquist> and our initdb target doesn't fail on SQL errors