uPortal IRC Logs-2011-04-05
[12:55:27 CDT(-0500)] <EricDalquist> athena apetro holdorph1 and anyone else paying attention
[12:55:39 CDT(-0500)] <EricDalquist> here is a portlet spec interpretation question for you
[12:55:49 CDT(-0500)] <EricDalquist> Relating to Resource Requests the spec says:
[12:55:49 CDT(-0500)] <EricDalquist> The ResourceRequest should be provided with the current portlet mode and window state. The ResourceRequest call should also be provided with the current render parameters of the portlet.
[12:56:13 CDT(-0500)] <EricDalquist> so with that in mind, when the portal is building a resource URL
[12:56:24 CDT(-0500)] <EricDalquist> should we capture the mode, state and parameters from when the URL was created?
[12:56:43 CDT(-0500)] <EricDalquist> or should it use the current mode, state and parameters at the time of the request
[12:57:33 CDT(-0500)] <holdorph1> hmm... you're right that does seem open to interpretation. So it seems like maybe it would be what do we think would be better in a real life case of using this?
[12:57:56 CDT(-0500)] <EricDalquist> well resource urls are intended for things like ajax requests
[12:57:58 CDT(-0500)] <athena> i'm about to get on a scrum call, but i'll be back shortly
[12:58:28 CDT(-0500)] <EricDalquist> and the portal keeps track of the "last set of request parameters" for every portlet window
[12:58:29 CDT(-0500)] <athena> we do have the use case of also maybe wanting to use resource URLs to do REST-ish calls from the umobile app
[12:59:05 CDT(-0500)] <EricDalquist> but you could have a case where the resource url is created under parameters A, then another render request happens setting new parameters B
[12:59:28 CDT(-0500)] <EricDalquist> so the question is what should happen when that resource url, created when parameters A where in scope, is called
[12:59:33 CDT(-0500)] <EricDalquist> should it see parameters A or B
[12:59:37 CDT(-0500)] <EricDalquist> I'm not really sure
[12:59:54 CDT(-0500)] <EricDalquist> though I'm leaning toward it seeing the render parameters used when it was created
[13:00:37 CDT(-0500)] <holdorph> I don't have a strong opinion, i can see reasons for both
[13:01:09 CDT(-0500)] <holdorph> but i think the opportunity for it to be different and have a significant impact, is probably a pretty small chance
[13:02:13 CDT(-0500)] <EricDalquist> yeah
[13:02:32 CDT(-0500)] <EricDalquist> the "parameters when created" option is simpler to implement
[13:02:43 CDT(-0500)] <EricDalquist> and I think would generate more consistent behavior
[13:06:04 CDT(-0500)] <athena> ok, back
[13:06:20 CDT(-0500)] <athena> sounds reasonable to me
[13:08:43 CDT(-0500)] <EricDalquist> yeah the more I think about that the more I like it
[13:08:58 CDT(-0500)] <EricDalquist> otherwise it could get really weird if someone has multiple tabs open to a single portlet
[13:09:17 CDT(-0500)] <EricDalquist> also resource responses can generate new action, render and resource urls
[13:09:25 CDT(-0500)] <EricDalquist> so the response could include a new URL if needed
[13:44:12 CDT(-0500)] <athena> is JAXBContext thread-safe?
[13:44:19 CDT(-0500)] <athena> yeah that makes a lot fo sense
[13:44:21 CDT(-0500)] <EricDalquist> yes
[13:44:27 CDT(-0500)] <EricDalquist> but marshaller and unmarshaller are not
[13:44:40 CDT(-0500)] <EricDalquist> also JAXBContext is VERY expensive to create
[13:44:56 CDT(-0500)] <EricDalquist> when doing some testing on pluto it was taking ~ 500ms to create one to unmarshall portlet.xml files
[13:46:26 CDT(-0500)] <athena> ok, so we definitely want to have a JAXBContext that's at least set as a property of a service, and potentially shared between multiple services as appropriate?
[13:46:38 CDT(-0500)] <EricDalquist> yes
[13:46:42 CDT(-0500)] <athena> thanks, good to know
[13:46:42 CDT(-0500)] <EricDalquist> what is this for?
[13:46:58 CDT(-0500)] <athena> i figured that was the case, but i didn't see it explicitly marked as thread safe in the javadocs
[13:47:03 CDT(-0500)] <athena> https://wiki.jasig.org/display/UPC/Mobile+Courses+Portlet
[13:47:11 CDT(-0500)] <athena> writing an initial implementation that just takes an XML feed
[13:47:16 CDT(-0500)] <EricDalquist> ah got it
[13:47:53 CDT(-0500)] <EricDalquist> yeah you want to create a single JAXBContext per schema (or related schemas) and inject it
[13:48:26 CDT(-0500)] <athena> terrific
[13:48:40 CDT(-0500)] <athena> bet i've missed that in a portlet or two - goign to have to go back and look at that
[13:49:29 CDT(-0500)] <athena> woo, running unit tests on mock data already
[13:49:34 CDT(-0500)] <athena> doing dev this way is awfully speedy
[13:49:36 CDT(-0500)] <athena> <3
[13:49:42 CDT(-0500)] <EricDalquist>
[13:50:28 CDT(-0500)] <athena> should be a cool portlet
[14:34:00 CDT(-0500)] <athena> hmm.
[14:34:16 CDT(-0500)] <athena> Getting "Caused by: java.sql.BatchUpdateException: failed batch" when attempting to update a portlet
[14:34:50 CDT(-0500)] <athena> http://pastebin.com/A0nPurn7
[14:37:00 CDT(-0500)] <athena> think it's not reporting that the title is already in use
[14:38:00 CDT(-0500)] <EricDalquist> title shouldn't be unique
[14:38:02 CDT(-0500)] <EricDalquist> just name should be
[14:38:07 CDT(-0500)] <EricDalquist> and isn't there a check before the persist?
[14:39:00 CDT(-0500)] <athena> er, name, sorry
[14:39:11 CDT(-0500)] <athena> check might only be on the portlet side :/
[14:39:13 CDT(-0500)] <athena> bet that'st he case
[14:39:27 CDT(-0500)] <athena> guess it needs to get into the service layer
[14:45:50 CDT(-0500)] <EricDalquist> yeah
[14:56:17 CDT(-0500)] <athena> hmm, looks like the current RDBMDistributedLayoutStore code also makes the whole page return a stack trace if a channel is missing
[14:56:25 CDT(-0500)] <EricDalquist> yup
[14:56:33 CDT(-0500)] <EricDalquist> I've been meaning to file a bug about that
[14:56:52 CDT(-0500)] <EricDalquist> starting with 3.2 where you could actually delete a channel
[14:57:05 CDT(-0500)] <EricDalquist> a user's layout breaks if it includes a completely missing channel
[14:57:17 CDT(-0500)] <EricDalquist> we just removed the delete link
[14:57:30 CDT(-0500)] <athena> oh wow, that's in 3.2 as well?
[14:57:34 CDT(-0500)] <athena> yikes!
[14:57:53 CDT(-0500)] <EricDalquist> yeah
[14:57:56 CDT(-0500)] <athena> didn't we used to strip stuff out or display a missing channel alert?
[14:58:26 CDT(-0500)] <EricDalquist> we never truely deleted channels until 3.2
[14:58:29 CDT(-0500)] <EricDalquist> they were just expired
[14:58:34 CDT(-0500)] <EricDalquist> and stayed in the up_channel table
[14:58:47 CDT(-0500)] <EricDalquist> 3.2 was the first time that delete actually removed them
[15:01:24 CDT(-0500)] <athena> ah, yeah
[15:25:58 CDT(-0500)] <athena> EricDalquist: should export-channel.crn be completely deleted now?
[15:27:24 CDT(-0500)] <athena> have a coworker who's getting errors on tomcat start about missing that file
[15:52:52 CDT(-0500)] <EricDalquist> huh, it should be gone
[15:53:03 CDT(-0500)] <EricDalquist> but I may have missed spomething in importExportContext.xml related to it
[16:03:08 CDT(-0500)] <athena> i deleted the reference to it
[16:03:23 CDT(-0500)] <athena> that stuff probably needs to be reworked to use your new service anyway
[16:06:41 CDT(-0500)] <EricDalquist> yeah
[16:06:54 CDT(-0500)] <EricDalquist> I was planning on spending a bunch of time on import and export after RC1
[16:07:16 CDT(-0500)] <EricDalquist> figure until then as long as initportal and starting tomcat works we're good
[16:09:46 CDT(-0500)] <athena> makes sense to me
[16:17:55 CDT(-0500)] <athena> EricDalquist: this isnt' a stack trace you've seen before, is it? http://pastebin.com/v1HMmj1e
[16:22:40 CDT(-0500)] <EricDalquist> hrm
[16:22:44 CDT(-0500)] <EricDalquist> and thats the full stack?
[16:23:09 CDT(-0500)] <athena> i guess so? can ask esh to join chat
[16:23:25 CDT(-0500)] <EricDalquist> looks like there is something missing
[16:23:36 CDT(-0500)] <EricDalquist> line 232 in FutureTask is:
[16:23:37 CDT(-0500)] <EricDalquist> if (exception != null)
[16:23:37 CDT(-0500)] <EricDalquist> throw new ExecutionException(exception);
[16:23:56 CDT(-0500)] <EricDalquist> so it is re-throwing an exception that the Runnable that Future is for threw
[16:24:15 CDT(-0500)] <athena> hmm
[16:24:45 CDT(-0500)] <EricDalquist> so I'm guessing there is a Caused By missing from that pastebin
[16:24:51 CDT(-0500)] <EricDalquist> oh wait
[16:24:52 CDT(-0500)] <EricDalquist> found it
[16:24:56 CDT(-0500)] <EricDalquist> just got lost in the line wraps
[16:25:18 CDT(-0500)] <EricDalquist> final IPortletEntity parentPortletEntity = portletWindowRegistry.getParentPortletEntity(request, portletWindowId);
[16:25:18 CDT(-0500)] <EricDalquist> final IPortletDefinition parentPortletDefinition = portletEntityRegistry.getParentPortletDefinition(parentPortletEntity.getPortletEntityId());
[16:25:18 CDT(-0500)] <EricDalquist> return parentPortletDefinition.getFName();
[16:25:33 CDT(-0500)] <EricDalquist> no parentPortletEntity was found for the specified portlet window
[16:25:40 CDT(-0500)] <EricDalquist> do you know how this was caused?
[16:25:50 CDT(-0500)] <athena> no
[16:26:01 CDT(-0500)] <athena> i'll ask her if she has any customizations
[16:26:14 CDT(-0500)] <EricDalquist> and what she was doing when it happened
[16:26:15 CDT(-0500)] <athena> coworker that's trying to get trunk set up to work with the grouper integration
[16:26:19 CDT(-0500)] <athena> so new trunk install
[19:57:44 CDT(-0500)] <EricDalquist> blarg
[19:58:04 CDT(-0500)] <EricDalquist> the portlet spec is not anything close to clear about how these various parameters work for resource urls & resource requests