[02:01:23 CST(-0600)] * EricDalquist (n=dalquist@76.210.74.156) has joined ##uportal
[03:13:31 CST(-0600)] * EricDalquist (n=dalquist@76.210.74.156) has joined ##uportal
[09:29:48 CST(-0600)] * dmccallum (n=dmccallu@uni1.unicon.net) has joined ##uportal
[09:45:36 CST(-0600)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[09:57:08 CST(-0600)] <EricDalquist> dmccallum it looks like the sudo privs for restarting apache are there now
[09:57:18 CST(-0600)] <EricDalquist> did you get a test SVN import done last night?
[12:27:18 CST(-0600)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[12:34:10 CST(-0600)] * dmccallum (n=dmccallu@uni1.unicon.net) has joined ##uportal
[14:16:16 CST(-0600)] <EricDalquist> dmccallum did you get a chance to do the SVN test yesterday?
[14:20:00 CST(-0600)] <dmccallum> no i did not
[14:20:25 CST(-0600)] <EricDalquist> you should have all the sudo privs you need for controlling apache now
[14:20:32 CST(-0600)] <dmccallum> yes
[14:23:04 CST(-0600)] <EricDalquist> do you think the SVN move is still feasable this week or does it need to be postponed?
[14:24:41 CST(-0600)] <dmccallum> i think i can get to it by cob on friday
[14:25:16 CST(-0600)] <dmccallum> unfortunately, i'm in all-day meetings today and tomorrow
[14:25:43 CST(-0600)] <EricDalquist> cool, I just want to make sure the folks that may have uP3 work on their machines get it all in before we do the move so they don't loose it
[14:25:58 CST(-0600)] <dmccallum> agreed
[14:26:07 CST(-0600)] <EricDalquist> let me know if you need any help with that
[14:26:14 CST(-0600)] <EricDalquist> and have fun at those meetings
[14:26:23 CST(-0600)] <dmccallum> thx and thx
[14:27:10 CST(-0600)] <dmccallum> hey, do you have any special insights into why uP3 custom collection types may not work in Hibernate 3.2?
[14:28:16 CST(-0600)] <EricDalquist> probably because Hibernate is only paying attention to the interface not the actual type and replacing the custom uP type with a custom Hibernate type
[14:28:29 CST(-0600)] <EricDalquist> I'm not so content with the all the custom collection types we have
[14:30:38 CST(-0600)] <EricDalquist> back in a few
[14:30:53 CST(-0600)] <dmccallum> hmmm.... it seemed to be using our custom type(s) when fetching the collections, but with erratic success. for example, all the custom types in the portlet def mapping worked OK except for the BaseListUserCollectionType used to contain portlet info keywords. in that case hibernate fails to take a snapshot at load time and we end up with an NPE at flush time
[14:41:22 CST(-0600)] <EricDalquist> hrm
[14:42:00 CST(-0600)] <EricDalquist> does the hibernate mapping for those properties declare the custom type handler for the collection?
[14:42:06 CST(-0600)] <EricDalquist> I believe thats what I had to do with the other custom types
[14:46:37 CST(-0600)] <dmccallum> <list name="keywords" table="UP_PORT_DEF_INFO_KEYWORDS" cascade="all" collection-type="org.jasig.portal.portlet.dao.hibernate.types.BaseListUserCollectionType" />
[14:47:08 CST(-0600)] <EricDalquist> hrm
[14:49:44 CST(-0600)] <dmccallum> from what i can see, there's no good reason why this particular mapping needs the custom type, and it appears to work just fine if i let hibernate use its default list impl. but then i run into further issues with cascading deletes into the collection of preferences (another custom collection type). specifically, it doesn't even try to delete the preferences, even with cascade set to 'all-delete-orphan'. now, it works with hib 3.0.5 once i specify t
[14:51:25 CST(-0600)] <dmccallum> i assume the next question will be "well, why are you using 3.2, then?"
[14:51:48 CST(-0600)] <EricDalquist> 
[14:52:00 CST(-0600)] <EricDalquist> well I would prefer that we can use the latest versions of jars
[14:52:51 CST(-0600)] <dmccallum> and the answer is.... b/c XxxEntities and PortletWindows are per-user, we're looking at potentially 100s of 1000s of these objects, so deleting an entire portlet app def or portlet def could be quite costly if we have to load those 1000s of objects into memory just to delete them.
[14:53:17 CST(-0600)] <EricDalquist> yeah that wouldn't be the way to do it
[14:53:28 CST(-0600)] <dmccallum> So i tried a DML approach for those user-scoped objects and it works fine in 3.0.5 except for collections of preference values
[14:53:29 CST(-0600)] <EricDalquist> could some HQL queries help with that?
[14:53:56 CST(-0600)] <EricDalquist> and can HQL even do deletes (been a while since I used hibernate)
[14:53:59 CST(-0600)] <dmccallum> when you use HQL DML Hibernate does not calculate associations
[14:54:04 CST(-0600)] <EricDalquist> ah
[14:54:14 CST(-0600)] <dmccallum> so i can use HQL to delete portlet preferences en masse, but not their values
[14:55:08 CST(-0600)] <EricDalquist> thats annoying
[14:55:16 CST(-0600)] <dmccallum> now, in 3.2, i can mix and match SQL and HQL DML statements and i can delete the pref values with raw SQL queries, which i can't do in 3.0.5, but then i have these problems with custom collection types
[14:55:38 CST(-0600)] <dmccallum> so my current thinking is to re-map portlet pref values as entities so i can directly address them with an HQL DML query
[14:56:28 CST(-0600)] <dmccallum> this sucks b/c the current mapping is technically correct.... there's no good reason for pref vals to be entities other than we have (potentially) zillions of corresponding records and hibernate DML doesnt work quite right
[14:56:56 CST(-0600)] <dmccallum> needless to say, this has all taken much longer than orginally anticipated
[14:57:08 CST(-0600)] <EricDalquist> sounds like a very frustrating task
[14:57:17 CST(-0600)] <EricDalquist> sorry I can't be of more help right now
[14:57:18 CST(-0600)] <dmccallum> oh well
[14:57:22 CST(-0600)] <dmccallum> np.
[14:57:29 CST(-0600)] <EricDalquist> are you going to be in Atlanta?
[14:57:37 CST(-0600)] <dmccallum> for sakai, but not for ja-sig
[14:57:49 CST(-0600)] <EricDalquist> ah
[15:12:05 CST(-0600)] * deuce (n=deuce@ip68-110-100-205.ph.ph.cox.net) has joined ##uportal
[15:38:06 CST(-0600)] <EricDalquist> hey deuce, are we going to be ditching the current subscription portlet?
[15:38:32 CST(-0600)] <deuce> not completely
[15:38:59 CST(-0600)] <EricDalquist> too bad
[15:39:15 CST(-0600)] <deuce> it will defer to the groups servant, which will redirect back to the subscription portlet for the action
[15:39:22 CST(-0600)] <EricDalquist> ah, that works
[15:39:24 CST(-0600)] <deuce> i just checked it it
[15:39:28 CST(-0600)] <deuce> in
[15:40:10 CST(-0600)] <EricDalquist> cool
[16:08:44 CST(-0600)] <deuce> eric?
[16:08:48 CST(-0600)] <EricDalquist> hey
[16:09:11 CST(-0600)] <deuce> are you familiar with how the url constructors and param processors work?
[16:09:53 CST(-0600)] <EricDalquist> somewhat
[16:10:38 CST(-0600)] <deuce> i'm trying to track down when the "uP_add_target" gets generated and/or added to urls
[16:11:25 CST(-0600)] <EricDalquist> hrm, give me a minute and I'll see if I can help figure that out
[16:11:55 CST(-0600)] <EricDalquist> I'm assuming it would be in the theme transform for the integrated modes using the custom XSL namespace processor
[16:12:32 CST(-0600)] <EricDalquist> but in there it would show up as an API call or generic URL parameter, then some code would actually add the string to the URL when it is generated
[16:12:49 CST(-0600)] <deuce> ah .. i only grepped the src tree
[16:13:08 CST(-0600)] <EricDalquist> also the uP_ is likely a prefix
[16:13:11 CST(-0600)] <EricDalquist> so grep for add_target
[16:15:11 CST(-0600)] <deuce> hrmm .. the url is actually created by the subscription/group selection portlet tho
[16:15:25 CST(-0600)] <deuce> i mean...
[16:15:38 CST(-0600)] <deuce> grrr
[16:15:45 CST(-0600)] <EricDalquist> where in the code is the URL generated?
[16:16:03 CST(-0600)] <deuce> maybe i'll step back and explain the situation
[16:16:07 CST(-0600)] <EricDalquist> ok
[16:17:00 CST(-0600)] <deuce> when you click on a portlet link in the subscription portlet the first time, the portlet doesn't get added to the layout
[16:17:17 CST(-0600)] <deuce> on the second time through the subscription portlet, however, it does
[16:17:59 CST(-0600)] <deuce> i notice that after the first click-thru, the uP_add_target param is missing from the address bar .. whereas it appears on the second
[16:18:06 CST(-0600)] <EricDalquist> hrm
[16:21:01 CST(-0600)] <EricDalquist> I remember working with peter on this when I first hacked that simple subscription portlet together
[16:21:29 CST(-0600)] <EricDalquist> I think this may need to be an email question to him though
[16:22:18 CST(-0600)] <deuce> ok .. np
[16:22:20 CST(-0600)] <deuce> thanks
[16:22:34 CST(-0600)] <EricDalquist> could you CC me if you email him (or just use jasig-dev for the email?)
[16:23:36 CST(-0600)] <deuce> willdo
[16:23:50 CST(-0600)] <EricDalquist> thanks
[16:40:47 CST(-0600)] <EricDalquist> woohoo, I have UW's web proxy portlet working in uP3
[16:41:11 CST(-0600)] <EricDalquist> (not really all that tested yet but it is proxying as expected)
[16:50:47 CST(-0600)] <deuce> that's sweet
[16:51:59 CST(-0600)] <EricDalquist> we should have bookmarks, the stand along XSLT (and RSS based on it) as well
[16:52:24 CST(-0600)] <EricDalquist> we'll actually have a usefull portal
[16:52:36 CST(-0600)] <deuce> i guess we'll actually have something to demo
[16:52:37 CST(-0600)] <deuce>
[17:35:46 CST(-0600)] * dmccallum (n=dmccallu@uni1.unicon.net) has joined ##uportal
[18:49:11 CST(-0600)] * dmccallum (n=dmccallu@uni1.unicon.net) has left ##uportal
[21:06:44 CST(-0600)] * EricDalquist (n=dalquist@76.210.67.218) has joined ##uportal
General
Content
Integrations