Page Comparison

[03:35:12 EDT(-0400)] * mad (n=chatzill@pcit-8752.HIG.SE) has joined ##uportal
[08:22:35 EDT(-0400)] * lennar1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[09:13:37 EDT(-0400)] * athena7 (n=athena7@adsl-99-149-83-32.dsl.wlfrct.sbcglobal.net) has joined ##uportal
[09:58:46 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[10:01:04 EDT(-0400)] * jessm (n=Jess@c-76-19-199-61.hsd1.ma.comcast.net) has joined ##uportal
[10:05:16 EDT(-0400)] * michelled (n=team@142.150.154.197) has joined ##uportal
[10:07:53 EDT(-0400)] * anastasiac (n=team@142.150.154.160) has joined ##uportal
[10:42:58 EDT(-0400)] <athena7> what's the time frame for up 3.0.2?
[10:43:18 EDT(-0400)] <EricDalquist> this morning
[10:44:19 EDT(-0400)] <athena7> ah
[10:44:20 EDT(-0400)] <athena7> cool!
[11:01:09 EDT(-0400)] * bulloche (n=bulloche@134.250.4.77) has joined ##uportal
[11:01:56 EDT(-0400)] <lennar1>
[11:02:43 EDT(-0400)] <lennar1> Eric, I didn't get a chance to take a look at the unit test issues related to yanking the merge calls in the JPA DAOs.
[11:02:56 EDT(-0400)] <lennar1> did you clean that up already?
[11:03:19 EDT(-0400)] <EricDalquist> fixed those over the weekendf
[11:03:42 EDT(-0400)] <lennar1> what did it take?
[11:03:56 EDT(-0400)] <EricDalquist> just not using detached objects
[11:04:00 EDT(-0400)] <lennar1>
[11:04:03 EDT(-0400)] <lennar1> figured
[11:04:26 EDT(-0400)] <EricDalquist> so retrieving an object after a checkPoint() call instead of using the previous reference
[11:04:33 EDT(-0400)] <lennar1> did you have to wrap the interceptors differently or did you just restructure the test?
[11:04:44 EDT(-0400)] <lennar1> makes sense.
[11:04:58 EDT(-0400)] <lennar1> had hoped it would be simple.
[11:05:02 EDT(-0400)] <EricDalquist> yeah, very easy
[11:05:07 EDT(-0400)] <lennar1> been real crazy in pearson land lately
[11:05:24 EDT(-0400)] <lennar1> lots of requirement shifting... but no shifts in deliverable dates.
[11:05:34 EDT(-0400)] <lennar1> going to make for a fun end of year experience
[11:05:57 EDT(-0400)] <EricDalquist> that's always fun
[11:05:59 EDT(-0400)] <lennar1> am sure that never happens anywhere else though
[11:06:44 EDT(-0400)] * holdorph (n=holdorph@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[11:07:08 EDT(-0400)] <athena7> of course not, that's crazy talk
[11:26:08 EDT(-0400)] * jessm (n=Jess@c-76-19-199-61.hsd1.ma.comcast.net) has joined ##uportal
[12:42:06 EDT(-0400)] * jessm (n=Jess@c-76-19-199-61.hsd1.ma.comcast.net) has joined ##uportal
[13:50:19 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[13:56:59 EDT(-0400)] * holdorph (n=holdorph@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[14:09:10 EDT(-0400)] <athena7> i'm having trouble with the spring AbstractXsltView
[14:09:18 EDT(-0400)] <athena7> in this instance it's trying to get a dtd
[14:09:32 EDT(-0400)] <athena7> is there some way i can tell it to use a specific dtd that i've added to the classpath?
[14:09:42 EDT(-0400)] <EricDalquist> yup
[14:09:49 EDT(-0400)] <EricDalquist> you have to implement DTDResolver
[14:10:05 EDT(-0400)] <athena7> hm.
[14:10:15 EDT(-0400)] <athena7> is there a way to feed that to the xsltview?
[14:10:29 EDT(-0400)] <EricDalquist> probably
[14:10:37 EDT(-0400)] <EricDalquist> but I've never done it
[14:10:55 EDT(-0400)] <EricDalquist> uriResolver: the URIResolver to be used in the transform
[14:11:06 EDT(-0400)] <EricDalquist> one of the properties from the JavaDoc
[14:11:14 EDT(-0400)] <EricDalquist> and it is URIResolver not DTDREsolver
[14:11:17 EDT(-0400)] <athena7> ah ok, i see it now
[14:11:18 EDT(-0400)] <athena7> thanks
[14:11:20 EDT(-0400)] <EricDalquist> been a while since I've done that stuff
[14:11:26 EDT(-0400)] <athena7> yeah me too
[14:11:58 EDT(-0400)] <athena7> this could be ugly, hm.
[14:12:06 EDT(-0400)] <EricDalquist> ?
[14:12:10 EDT(-0400)] <athena7> the document has a dtd that's just a relative link
[14:12:26 EDT(-0400)] <athena7> i'm not sure what's going to show up as parameters to the uri resolver
[14:12:37 EDT(-0400)] <EricDalquist> ah
[14:12:46 EDT(-0400)] <EricDalquist> easy enough to just write a little debugging resovler that prints it first
[14:13:56 EDT(-0400)] <athena7> yeah
[14:18:45 EDT(-0400)] <athena7> it's really too bad the GSA doesn't just generate a fully qualified url
[14:21:20 EDT(-0400)] <EricDalquist> yeah, places don't like doing that because of load on their servers
[14:21:33 EDT(-0400)] <EricDalquist> the w3c recommendation is to implement local URI resolution
[14:22:43 EDT(-0400)] <athena7> yeah
[14:22:47 EDT(-0400)] <athena7> which makes sense
[14:22:59 EDT(-0400)] <athena7> i'm just not sure how to coerce spring into using a local dtd
[14:23:21 EDT(-0400)] <EricDalquist> for that XSLTView it should be quite easy
[14:23:23 EDT(-0400)] <athena7> putting in a different uri resolver doesnt' seem to affect anything - i'm not sure that's quite the right thing
[14:23:33 EDT(-0400)] <EricDalquist> nothing being written out?
[14:23:51 EDT(-0400)] <athena7> breakpoints aren't even getting hit
[14:23:57 EDT(-0400)] <athena7> here's the trace:
[14:24:15 EDT(-0400)] <athena7> http://uportal.pastebin.com/m10c496c7
[14:24:56 EDT(-0400)] <EricDalquist> :/
[14:24:58 EDT(-0400)] <EricDalquist> I'm not sure
[14:25:06 EDT(-0400)] <EricDalquist> last time I did it (not with the xslt view)
[14:25:19 EDT(-0400)] <EricDalquist> I just provided a URIResolver and returned the appropriate stream for the URI
[14:25:34 EDT(-0400)] <athena7> was it the XsltView or AbstractXsltView?
[14:25:42 EDT(-0400)] <athena7> they're actually kind of different
[14:25:43 EDT(-0400)] <EricDalquist> not sure
[14:25:48 EDT(-0400)] <EricDalquist> check the javadoc
[14:25:50 EDT(-0400)] <EricDalquist> brb
[14:40:31 EDT(-0400)] * apetro-_ (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[15:04:16 EDT(-0400)] <EricDalquist> hey lennar1 I found an issue with our refresh/merge changes
[15:04:42 EDT(-0400)] <EricDalquist> when doing a data import there is no long-running session
[15:04:54 EDT(-0400)] <EricDalquist> so in this case when a channel is being published things fail
[15:05:08 EDT(-0400)] <EricDalquist> because one line does: final IPortletDefinition portletDefinition = this.portletDefinitionRegistry.getOrCreatePortletDefinition(channelPublishId);
[15:05:14 EDT(-0400)] <EricDalquist> then the defintion is modified a bit
[15:05:21 EDT(-0400)] <EricDalquist> then another line does: this.portletDefinitionRegistry.updatePortletDefinition(portletDefinition);
[15:05:29 EDT(-0400)] <EricDalquist> and those end up being made in two different sessions
[15:06:27 EDT(-0400)] <lennar1> so the import lacks a JPA session for the span of a specific amount of import work?
[15:06:34 EDT(-0400)] <EricDalquist> yup
[15:06:44 EDT(-0400)] <lennar1> why not give it a JPA session?
[15:08:09 EDT(-0400)] <EricDalquist> yeah, I suppose I can do that
[15:08:29 EDT(-0400)] <EricDalquist> quick question though ... do you have any experience with the EntityManager.contains(Object) API?
[15:11:25 EDT(-0400)] <lennar1> you using proxies?
[15:12:01 EDT(-0400)] <EricDalquist> for what?
[15:12:07 EDT(-0400)] <lennar1> nm
[15:13:52 EDT(-0400)] <lennar1> I guess you could give that a shot.
[15:14:26 EDT(-0400)] <lennar1> Bear in mind that we really aren't running in an EJB3 container managed env.
[15:14:41 EDT(-0400)] <lennar1> with spring we get something pretty similar... but not quite
[15:14:51 EDT(-0400)] <EricDalquist> yeah, so I'm going to update ChannelPublisher to wrap itself in a Jpanterceptor
[15:14:59 EDT(-0400)] <EricDalquist> but this is likely going to keep coming up
[15:15:15 EDT(-0400)] <EricDalquist> I'm just wondering how expensive EntityManager.contains(Object) is
[15:15:30 EDT(-0400)] <EricDalquist> and if that could be used to detect this case and do a merge in that instance
[15:15:37 EDT(-0400)] <EricDalquist> with a big loud log warning
[15:15:41 EDT(-0400)] <lennar1> wrap a few key points and it won't keep coming up
[15:15:58 EDT(-0400)] <EricDalquist> yeah
[15:16:04 EDT(-0400)] <lennar1> we don't have an EJB3 container manager to make our life easy
[15:16:15 EDT(-0400)] <lennar1> so we need to do a little more work to wrap things.
[15:16:33 EDT(-0400)] <lennar1> going the other route is just going to be a pain in the keaster in its own right.
[15:16:41 EDT(-0400)] <lennar1> likely an expensive one at that.
[15:17:12 EDT(-0400)] <EricDalquist> yeah
[15:17:20 EDT(-0400)] <lennar1> You can try the contains call, and there is no way I would expect it to be as expensive as the refresh or the merge.
[15:17:32 EDT(-0400)] <EricDalquist> we'll just have to keep this in mind as more things move to hibernate and update the import scripts
[15:19:07 EDT(-0400)] <lennar1> should be real easy if ChannelPublisher is a spring managed bean.
[15:19:09 EDT(-0400)] <lennar1> is it?
[15:19:36 EDT(-0400)] <EricDalquist> nope
[15:23:52 EDT(-0400)] <athena7> finally!!
[15:24:11 EDT(-0400)] <athena7> turns out you can set the base url via calling setSystemId on the Source object
[15:24:12 EDT(-0400)] <athena7> gah.
[15:26:49 EDT(-0400)] <EricDalquist> well that programatic JPAInterceptor approach fixed it
[16:35:54 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[17:06:19 EDT(-0400)] <lennar1>
[17:11:33 EDT(-0400)] <lennar1> not as pretty as converting things into spring beans and using a more standard approach, but it is effective.
[17:11:40 EDT(-0400)] <EricDalquist> yup
[17:11:49 EDT(-0400)] <EricDalquist> and was fairly minimal code
[18:29:35 EDT(-0400)] * jessm (n=Jess@c-76-19-199-61.hsd1.ma.comcast.net) has joined ##uportal
[18:44:22 EDT(-0400)] <EricDalquist> 3.0.2
[18:44:23 EDT(-0400)] <EricDalquist> is out
[18:44:30 EDT(-0400)] <EricDalquist> announcement will be coming tomorrow
[19:04:54 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[20:04:09 EDT(-0400)] * Sememmon thwaps lennar1
[20:38:04 EDT(-0400)] <lennar1>