uPortal IRC Logs-2010-09-13

[10:28:44 CDT(-0500)] <EricDalquist> so athena the new rendering pipeline stuff ran into a bit of a road block last week
[10:28:53 CDT(-0500)] <EricDalquist> a nice bug in the JDK's StAX implementation
[10:29:41 CDT(-0500)] <athena> oh no
[10:29:41 CDT(-0500)] <athena> wha
[10:29:41 CDT(-0500)] <athena> t
[10:29:44 CDT(-0500)] <athena> what's the deal?
[10:30:57 CDT(-0500)] <EricDalquist> so in: http://www.docjar.com/html/api/com/sun/org/apache/xalan/internal/xsltc/trax/StAXEvent2SAX.java.html
[10:31:10 CDT(-0500)] <EricDalquist> line 341/342
[10:31:21 CDT(-0500)] <EricDalquist> the code calls EndElement.getNamespaces()
[10:31:28 CDT(-0500)] <EricDalquist> which returns an Iterator
[10:31:41 CDT(-0500)] <EricDalquist> the JavaDoc for EndElement says it is an Iterator of Namepsace objects
[10:31:47 CDT(-0500)] <EricDalquist> String prefix = (String)i.next();
[10:31:51 CDT(-0500)] <EricDalquist> and that is what the code does
[10:31:54 CDT(-0500)] <athena> heh
[10:32:02 CDT(-0500)] <EricDalquist> I submitted a bug with Sun
[10:32:03 CDT(-0500)] <athena> was about to ask why that code didn't include generics
[10:32:09 CDT(-0500)] <EricDalquist> I wish
[10:32:13 CDT(-0500)] <athena> guess it should have (smile)
[10:32:19 CDT(-0500)] <EricDalquist> none of the StAX APIs use generics (sad)
[10:32:26 CDT(-0500)] <athena> sad (sad)
[10:32:29 CDT(-0500)] <EricDalquist> and am going to see what we have for sun/oracle support contacts here
[10:32:35 CDT(-0500)] <EricDalquist> and have a few ideas for work arounds
[10:32:36 CDT(-0500)] <athena> isn't that a newer API too?
[10:32:39 CDT(-0500)] <EricDalquist> yes
[10:32:43 CDT(-0500)] <EricDalquist> new in JDK1.5
[10:32:47 CDT(-0500)] <athena> weird
[10:32:48 CDT(-0500)] <athena> d
[10:32:52 CDT(-0500)] <EricDalquist> yeah
[10:32:56 CDT(-0500)] <athena> don't understand why they didn't make the code more modern
[10:33:00 CDT(-0500)] <athena> but anyway, that sucks
[10:33:07 CDT(-0500)] <EricDalquist> yeah
[10:33:22 CDT(-0500)] <athena> i guess if it did get fixed that'd make the next release dependent on later releases of java 6?
[10:33:24 CDT(-0500)] <EricDalquist> so I have some things I'm going to try tonight
[10:33:28 CDT(-0500)] <EricDalquist> yup
[10:33:39 CDT(-0500)] <athena> which probably wouldn't be the end of the world for most deployers
[10:33:46 CDT(-0500)] <athena> but could be pretty bad for us that develop on a mac
[10:36:13 CDT(-0500)] <athena> you think there will be any way to get around it?
[10:36:32 CDT(-0500)] <EricDalquist> I think so
[10:36:48 CDT(-0500)] <EricDalquist> we currently don't declare namespaces anywhere other than the root element
[10:36:56 CDT(-0500)] <EricDalquist> so there is no namespace scope issue there
[10:37:08 CDT(-0500)] <athena> that's good at least i guess
[10:37:22 CDT(-0500)] <athena> i did notice that there were less svn updates than i expected
[10:37:27 CDT(-0500)] <athena> looks like gary made some updates though
[10:37:35 CDT(-0500)] <EricDalquist> and because of that I can filter the EndElement events and return an empty iterator for that call
[10:38:01 CDT(-0500)] <EricDalquist> Also in XSLT is already expensive I might try doing StAX -> XSLT -> DOM -> StAX instead of StAX -> XSLT -> StAX which is what I'm doing now
[10:38:35 CDT(-0500)] <EricDalquist> I verified the code runs with the empty-iterator trick
[10:38:55 CDT(-0500)] <EricDalquist> I just need to figure out what all the possible implications are
[10:38:58 CDT(-0500)] <athena> gotcha
[10:39:35 CDT(-0500)] <EricDalquist> there is also a cursor-based StAX api
[10:39:38 CDT(-0500)] <EricDalquist> which doesn't have the bug
[10:39:47 CDT(-0500)] <EricDalquist> but caching would be MUCH more complex
[10:39:50 CDT(-0500)] <athena> ah
[10:39:54 CDT(-0500)] <EricDalquist> I'm not even sure how it would work
[10:42:58 CDT(-0500)] <EricDalquist> just really frustraiting
[10:43:07 CDT(-0500)] <EricDalquist> since I thought I had this all worked out in the sandbox
[10:43:19 CDT(-0500)] <EricDalquist> but I wasn't using namespaces in my XSL there
[10:43:26 CDT(-0500)] <EricDalquist> so I didn't trigger the bug{color}
[10:44:16 CDT(-0500)] <EricDalquist> hrm ... I got disconnected apparently

[10:44:46 CDT(-0500)] <EricDalquist> all of that makes for delays (sad)
[11:09:37 CDT(-0500)] <athena> trying to remember what i was doing before vacation (tongue)
[11:09:46 CDT(-0500)] <athena> probably need to reconnect w/ chyzer
[11:38:35 CDT(-0500)] <athena> any objection to me renaming the groups-selector stuff "entity-selector"?
[11:38:45 CDT(-0500)] <athena> since we're really using it to select people, groups, portlets, etc.
[11:38:56 CDT(-0500)] <EricDalquist> sounds good
[11:39:06 CDT(-0500)] <athena> cool
[11:39:17 CDT(-0500)] <athena> figure we might as well assign it a more representative name
[11:39:34 CDT(-0500)] <EricDalquist> eyah
[12:03:17 CDT(-0500)] <athena> hmm
[12:03:36 CDT(-0500)] <athena> i'm a bit worried about i18n for places where we have things like "Permissions for <span>Name</span>"
[12:04:02 CDT(-0500)] <athena> since in other languages the part in the span might be supposed to be in a different place in the phrase
[12:04:23 CDT(-0500)] <EricDalquist> right you end up having to embedd the span in the messages file ?
[12:04:24 CDT(-0500)] <EricDalquist> :./
[12:04:29 CDT(-0500)] <EricDalquist> which is no fun
[12:04:35 CDT(-0500)] <EricDalquist> but possible I think
[12:04:56 CDT(-0500)] <athena> yeah, i think it should be possible
[12:05:00 CDT(-0500)] <athena> dunno if we want to do it or not
[12:05:05 CDT(-0500)] <athena> i'll talk to gary about it
[12:05:22 CDT(-0500)] <EricDalquist> ok
[12:05:35 CDT(-0500)] <athena> by the way, do you know how to successfully get an apostrophe into the message?
[12:06:04 CDT(-0500)] <EricDalquist> ''?
[12:06:17 CDT(-0500)] <athena> '
[12:06:26 CDT(-0500)] <EricDalquist> try putting two of them in
[12:06:30 CDT(-0500)] <athena> hm, ok
[12:06:39 CDT(-0500)] <athena> i tried a backslash, which did not work (smile)
[12:10:03 CDT(-0500)] <athena> yay, that did it
[12:10:12 CDT(-0500)] <athena> thanks - i would not have guessed that one
[12:12:05 CDT(-0500)] <athena> so right now the permission owners have names like "uPortal Groups", "uPortal Fragments", "uPortal Portlet Subscribing", etc.
[12:12:20 CDT(-0500)] <athena> does it make sense to have all of them prefaced w/ uPortal, or would it be clearer to just leave that part out?
[12:12:40 CDT(-0500)] <EricDalquist> I think that can just be left out
[12:12:45 CDT(-0500)] <athena> yeah
[12:12:54 CDT(-0500)] <athena> seems like it just makes it harder to parse now
[12:13:00 CDT(-0500)] <athena> though i'm not sure if it might be useful when we start introducing portlet or custom permissions
[12:13:11 CDT(-0500)] <athena> i guess we could always change it back later if it gets confusing
[12:43:09 CDT(-0500)] <athena> EricDalquist: you haven't seen any oracle constraint violations when creating portlet entities, have you?
[12:43:16 CDT(-0500)] <EricDalquist> no
[12:43:21 CDT(-0500)] <athena> k
[12:43:21 CDT(-0500)] <EricDalquist> awills: asked about that on Friday
[12:43:24 CDT(-0500)] <athena> yeah
[12:43:25 CDT(-0500)] <athena> same issue
[12:43:31 CDT(-0500)] <athena> i inherited it, now that i'm back from vacation
[12:43:37 CDT(-0500)] <EricDalquist> I was wondering if subscribe IDs are being reused
[12:43:52 CDT(-0500)] <EricDalquist> I think the entity code assumes they are unique per user 'forever'
[12:44:50 CDT(-0500)] <athena> hm
[12:45:03 CDT(-0500)] <athena> can you think of any reason subscribe ids would be reused?
[12:45:21 CDT(-0500)] <EricDalquist> my only thought is perhaps the new 'reset layout' in 3.2?
[12:45:29 CDT(-0500)] <athena> i can take a look at that code
[12:45:31 CDT(-0500)] <EricDalquist> does that reset the user's 'next_node_id' to 0?
[12:45:39 CDT(-0500)] <athena> probably not
[12:45:40 CDT(-0500)] <EricDalquist> if so it also needs to nuke all portlet entities for that user
[12:46:09 CDT(-0500)] <athena> i'm pretty sure that portlet just uses the logic from the old DLM preferences channel
[12:46:16 CDT(-0500)] <athena> which i think just sets the layout id back to zero
[12:47:12 CDT(-0500)] <athena> yep
[12:47:20 CDT(-0500)] <athena> userProfile.setLayoutId(0);
[12:47:23 CDT(-0500)] <EricDalquist> and if you modify the layout after that
[12:47:33 CDT(-0500)] <EricDalquist> does it continue with subscribe IDs from where it left off?
[12:47:40 CDT(-0500)] <EricDalquist> or does it start back at 1 again?
[12:47:42 CDT(-0500)] <athena> i'll have to do some testing
[12:49:10 CDT(-0500)] <athena> would those IDs be in up_layout_struct?
[12:49:22 CDT(-0500)] <EricDalquist> that is where they are stored
[12:49:34 CDT(-0500)] <EricDalquist> I think it is actually a column in UP_USER that tracks the next ID for the user
[12:50:09 CDT(-0500)] <EricDalquist> brb
[12:57:06 CDT(-0500)] <athena> heh
[12:57:17 CDT(-0500)] <athena> so in trunk none of the person lookup stuff works
[13:04:58 CDT(-0500)] <athena> ok, it does not reset the user's next node id
[13:05:05 CDT(-0500)] <athena> nor does it delete any of the existing structs
[13:05:12 CDT(-0500)] <athena> i assume it doesn't delete any portlet entities either
[13:08:35 CDT(-0500)] <EricDalquist> yeah there is no DB level link between those
[13:09:42 CDT(-0500)] <athena> ok, i need to go for a bit
[13:09:45 CDT(-0500)] <athena> back in an hour or so
[15:16:25 CDT(-0500)] <athena> EricDalquist: so it turns out that unique violation is on the portlet_ent_id column
[15:16:34 CDT(-0500)] <EricDalquist> ouch
[15:16:36 CDT(-0500)] <EricDalquist> that's no good
[15:16:48 CDT(-0500)] <EricDalquist> since that should be dictated by a sequence
[15:17:35 CDT(-0500)] <athena> yeah
[15:17:44 CDT(-0500)] <athena> not sure what would cause that
[15:18:06 CDT(-0500)] <EricDalquist> is it possible that their sequence rolled over?
[15:18:12 CDT(-0500)] <EricDalquist> I can't imagine that happening
[15:18:25 CDT(-0500)] <EricDalquist> it should default to some unfathomably large max value
[15:18:44 CDT(-0500)] <athena> yeah that seems like it'd be surprising
[15:19:14 CDT(-0500)] <athena> think there's any chance it's something like the table not getting properly cleaned out during initdb or somethign?
[15:19:21 CDT(-0500)] <EricDalquist> perhaps
[15:20:16 CDT(-0500)] <athena> see there was some interesting RSS discussion while i was gone
[15:20:33 CDT(-0500)] <athena> need to implement that caching service you've described (smile)
[15:20:38 CDT(-0500)] <EricDalquist> yeah
[15:20:40 CDT(-0500)] <EricDalquist> we really do
[15:21:03 CDT(-0500)] <EricDalquist> oh ... any thoughts on how to access the channelList for the current user from a portlet in 3.2?
[15:21:17 CDT(-0500)] <EricDalquist> I need proxy auth from a portlet just to a portal servlet (tongue)
[15:23:01 CDT(-0500)] <athena> do you need to do it via ajax or the backend?
[15:23:14 CDT(-0500)] <athena> if it's ajax it should just work, no?
[15:23:19 CDT(-0500)] <EricDalquist> from the backend
[15:23:31 CDT(-0500)] <EricDalquist> the hope is that the initial display of the portlet won't require JS
[15:23:32 CDT(-0500)] <EricDalquist> I'm writing a "uw search portlet"
[15:23:41 CDT(-0500)] <EricDalquist> so you go to the search box in the header
[15:23:49 CDT(-0500)] <EricDalquist> enter "Course Guide"
[15:24:19 CDT(-0500)] <EricDalquist> and you get a portlet in maximized view that shows UW custom google search results, UW people search results and MyUW portlet search results all on one page
[15:24:44 CDT(-0500)] <EricDalquist> similar UI to this: http://www.wisc.edu/search/?q=Dalquist
[15:25:03 CDT(-0500)] <EricDalquist> for now I think I'm just going to do the portlet search via AJAX in the user's browser
[15:25:13 CDT(-0500)] <EricDalquist> also I'm going to have to look into channelList performance
[15:25:24 CDT(-0500)] <EricDalquist> on a 'warm' system it can take ~ 30 seconds to load for us
[15:25:38 CDT(-0500)] <EricDalquist> since we have something like 250 portlets published
[15:25:45 CDT(-0500)] <athena> was about to ask if you have a lot of channels
[15:25:53 CDT(-0500)] <athena> i think most of that code was written against the default db
[15:26:02 CDT(-0500)] <athena> and it does nested lookups
[15:26:08 CDT(-0500)] <EricDalquist> ouch
[15:26:12 CDT(-0500)] <EricDalquist> ok
[15:26:14 CDT(-0500)] <athena> so probably worst performance when you have lots of nested categories
[15:26:38 CDT(-0500)] <athena> so if you notice a performance diff between 3.1 and 3.2 my guess would be it's because of the way the logic changed
[15:26:56 CDT(-0500)] <athena> the old version generated the entire category-channel map, then filtered it by channel permissions
[15:27:09 CDT(-0500)] <athena> the current version generates the map fresh for each user according to permissions
[15:27:10 CDT(-0500)] <EricDalquist> this is 3.2
[15:27:30 CDT(-0500)] <athena> so i think instead of the old way it looks up each nested relationship per user, so that's no longer cached across the portal
[15:27:32 CDT(-0500)] <athena> that's my guess, anyway
[15:27:45 CDT(-0500)] <EricDalquist> ah
[15:27:46 CDT(-0500)] <EricDalquist> ok
[15:31:21 CDT(-0500)] <athena> it may be more efficient to generate the overall map, cache it, then filter through per-user
[15:31:29 CDT(-0500)] <EricDalquist> yeah