Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 29 Next »

[00:57:00 EDT(-0400)] * tsnfoo (~tsnfoo@cpe-173-88-27-191.columbus.res.rr.com) has joined ##uportal
[09:35:56 EDT(-0400)] * colinclark (~colin@bas2-toronto09-2925239674.dsl.bell.ca) has joined ##uportal
[09:36:00 EDT(-0400)] * tsnfoo (~tsnfoo@wso-mbp15-2.test.denison.edu) has joined ##uportal
[10:23:58 EDT(-0400)] * lfuller (~sparhk@ip68-98-56-21.ph.ph.cox.net) has left ##uportal
[10:33:52 EDT(-0400)] * colinclark (~colin@142.150.154.101) has joined ##uportal
[10:56:45 EDT(-0400)] * lfuller (~sparhk@wsip-72-215-204-133.ph.ph.cox.net) has joined ##uportal
[11:26:28 EDT(-0400)] * athena (~athena@adsl-99-90-242-49.dsl.wlfrct.sbcglobal.net) has joined ##uportal
[11:47:45 EDT(-0400)] * michelled (~michelled@142.150.154.101) has joined ##uportal
[12:04:47 EDT(-0400)] * lfuller1 (~sparhk@wsip-72-215-204-133.ph.ph.cox.net) has joined ##uportal
[12:13:04 EDT(-0400)] * pberry (~pberry@waldorf.CSUChico.EDU) has joined ##uportal
[12:55:41 EDT(-0400)] * EricDalquist (~apollo@adsl-99-135-74-102.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
[12:56:30 EDT(-0400)] <EricDalquist> so I discovered last night that the way uPortal 3 configures webflow is dependent on an imlementation detail of pluto 1.1
[12:56:45 EDT(-0400)] <pberry> o_0
[12:57:11 EDT(-0400)] <EricDalquist> apparently (and very stupidly in my view) webflow reflects on the type of ApplicationContext it is configured in
[12:57:21 EDT(-0400)] <EricDalquist> if it is an instance of ConfigurablePortletApplicationContext
[12:57:28 EDT(-0400)] <EricDalquist> it uses a portlet specific class for view rendering
[12:57:33 EDT(-0400)] <EricDalquist> if not it uses the servlet version
[12:57:44 EDT(-0400)] <pberry> that could be interesting...
[12:57:54 EDT(-0400)] <EricDalquist> we configure webflow in the root app context so that each portlet has access to all flows, this is how we re-use admin UIs
[12:58:22 EDT(-0400)] <EricDalquist> the only reason it has worked to date is that pluto 1.1's RenderRequest and RenderResponse impls also implement HttpServletRequest and HttpServletResponse
[12:58:26 EDT(-0400)] <EricDalquist> so the casts work
[12:58:38 EDT(-0400)] <EricDalquist> the stupid part
[12:58:49 EDT(-0400)] <EricDalquist> is that they generate this portlet vs servlet specific class for each view request
[12:59:07 EDT(-0400)] <EricDalquist> and they could just reflect on the type of the current request & response to determine which handler class to uase
[12:59:15 EDT(-0400)] <EricDalquist> so I ended up writing that this morning
[12:59:17 EDT(-0400)] <EricDalquist> and it works!
[12:59:22 EDT(-0400)] <pberry> brilliant!
[12:59:34 EDT(-0400)] <EricDalquist> so fairly easy fix รขย€ยฆ after a few hours of digging through webflow source
[12:59:37 EDT(-0400)] <pberry> which may lead into a question I was about to ask...
[13:00:02 EDT(-0400)] <pberry> memory usage compared to 2.6...
[13:00:18 EDT(-0400)] <pberry> We're looking at moving to VMs for everything except the database
[13:00:32 EDT(-0400)] <EricDalquist> ok
[13:00:59 EDT(-0400)] <pberry> So, right now we allocate 1G of ram for each Tomcat
[13:01:04 EDT(-0400)] <pberry> and that seems to do just fine
[13:01:21 EDT(-0400)] <pberry> especially given the fact that we run almost all webproxy channels
[13:01:37 EDT(-0400)] <pberry> I'm curious if we can get away with the same kind of memory allocation
[13:01:55 EDT(-0400)] <EricDalquist> in 3.x?
[13:02:26 EDT(-0400)] <pberry> ya
[13:02:32 EDT(-0400)] <EricDalquist> you should be fine
[13:02:34 EDT(-0400)] <EricDalquist> if not better
[13:02:41 EDT(-0400)] <EricDalquist> we've been moving a lot of stuff to ehcache
[13:02:44 EDT(-0400)] <EricDalquist> more with each version
[13:02:59 EDT(-0400)] <EricDalquist> and that results in less memory usage each time
[13:03:33 EDT(-0400)] <EricDalquist> since then ehcache can actually clear stuff out
[13:03:42 EDT(-0400)] <pberry> I was curious about how the migration to more spring was impacting memory usage (I have no idea if it should be higher or lower)
[13:04:18 EDT(-0400)] <EricDalquist> ah
[13:04:21 EDT(-0400)] <EricDalquist> probably lower
[13:04:29 EDT(-0400)] <EricDalquist> uPortal does a lot of static Map caching for channels
[13:06:03 EDT(-0400)] <EricDalquist> and that stuff never really gets cleared out
[13:06:11 EDT(-0400)] <EricDalquist> some of the spring/hibernate is a little more heavy weight
[13:06:19 EDT(-0400)] <EricDalquist> but it is all stored in a user's session
[13:06:24 EDT(-0400)] <pberry> gotcha
[13:07:06 EDT(-0400)] <EricDalquist> so I don't think you'll see an increase
[13:07:13 EDT(-0400)] <EricDalquist> and it should be more stable over time
[13:07:16 EDT(-0400)] <pberry> cool
[13:08:06 EDT(-0400)] <pberry> So, kudos on all the work that has been done to make uPortal "demoable" right from the download.
[13:08:19 EDT(-0400)] <EricDalquist> thanks,
[13:08:24 EDT(-0400)] <EricDalquist> those quick starts are wonderful
[13:08:47 EDT(-0400)] <pberry> yeah, until you want to start ripping stuff out for a "real" deploy (wink)
[13:08:53 EDT(-0400)] <EricDalquist> hopefully when we get moved over to our new hosting we can get an CI build of the quickstart for a live demo site
[13:08:58 EDT(-0400)] <EricDalquist> yeah
[13:09:04 EDT(-0400)] <EricDalquist> we need to get that cleaned up more
[13:09:34 EDT(-0400)] <EricDalquist> there is an open issue about separating out the 'base' or required entities from the optional stuff
[13:09:42 EDT(-0400)] <pberry> ah
[13:10:01 EDT(-0400)] * lfuller (~sparhk@wsip-72-215-204-133.ph.ph.cox.net) has joined ##uportal
[13:10:09 EDT(-0400)] <pberry> What might be cool, if @athena is listening, are scenario-based deploy docs
[13:10:24 EDT(-0400)] <pberry> I'm guessing that uP + CAS + Oracle + LDAP for "groups" isn't all that uncommon
[13:11:25 EDT(-0400)] <pberry> One of the things about the CAS "User Manual" that gets frustrating is that each feature is its own page, with it's own style
[13:11:37 EDT(-0400)] <pberry> there lacks some cohesiveness when you want to try and configure more than one thing
[13:12:12 EDT(-0400)] <pberry> it's hard to "crack down" on style guides when it's all volunteer documentation though
[13:13:08 EDT(-0400)] <EricDalquist> yeah
[13:13:18 EDT(-0400)] * athena is on the phone
[13:13:21 EDT(-0400)] <athena> but sounds good to me
[13:13:23 EDT(-0400)] <pberry> I'm sure with infinite time we could do more (wink)
[13:14:29 EDT(-0400)] <athena> if you have suggestions for the uportal manual, i'm all ears
[13:14:52 EDT(-0400)] * pberry thinks out loud
[13:15:28 EDT(-0400)] <pberry> So what if, based on a few criteria, a mini-manual could be done for the most common scenarios
[13:15:52 EDT(-0400)] <pberry> If you're doing x, y, and z here are the files you will need to mod and here are the mods, and here is how you deploy
[13:16:00 EDT(-0400)] <pberry> bing, bang, boom
[13:16:06 EDT(-0400)] <pberry> (as if it's really that easy)
[13:16:46 EDT(-0400)] <pberry> heck, I'm going to have to put together something just like this is we do move to 3.2 anyway
[13:17:05 EDT(-0400)] <pberry> oddly enough, mine will be uP + CAS + Oracle + LDAP for "groups"
[13:17:38 EDT(-0400)] <pberry> EricDalquist: how crazy do you get with groups? Rather, how granular do you get?
[13:17:48 EDT(-0400)] <pberry> We don't really go past faculty, staff, student
[13:18:00 EDT(-0400)] <pberry> the three big "buckets" so to speak
[13:18:15 EDT(-0400)] <EricDalquist> I think UW's pags config is posted somewhere ...
[13:18:22 EDT(-0400)] <EricDalquist> we have maybe 20ish groups?
[13:18:26 EDT(-0400)] <pberry> not bad
[13:21:13 EDT(-0400)] <athena> yeah, i think some sort of recipe-based strategy might be really helpful
[13:21:53 EDT(-0400)] <pberry> with multiple poms, it can get confusing
[13:22:28 EDT(-0400)] <pberry> Like I was saying to Eric, the quickstart download is awesome, but gets confusing because everything is turned on
[13:22:48 EDT(-0400)] <pberry> when you start to look at deployment...
[13:23:17 EDT(-0400)] <athena> i'd love to think about adding a filter file or something too
[13:23:52 EDT(-0400)] <athena> quickly going to become a pain to configure each portlet with the same db info
[13:26:19 EDT(-0400)] <pberry> wait...whut?
[13:26:30 EDT(-0400)] <pberry> oh, right
[13:28:40 EDT(-0400)] * lfuller (~sparhk@wsip-72-215-204-133.ph.ph.cox.net) has joined ##uportal
[13:42:13 EDT(-0400)] * colinclark (~colin@142.150.154.101) has joined ##uportal
[14:10:06 EDT(-0400)] * jessm (~Jess@c-71-232-3-151.hsd1.ma.comcast.net) has joined ##uportal
[14:23:28 EDT(-0400)] <EricDalquist> WOOOHOOO!
[14:23:40 EDT(-0400)] <EricDalquist> portlets are rendering correctly under pluto 2!
[14:23:49 EDT(-0400)] <EricDalquist> now to make the rendered URLs actually work (big grin)
[14:23:53 EDT(-0400)] <EricDalquist> and fix a bunch of pluto bugs (tongue)
[14:53:10 EDT(-0400)] <athena> YAY!
[14:53:27 EDT(-0400)] <EricDalquist> though I'm going to take a break and look at that config mode bug
[14:53:33 EDT(-0400)] <athena> even better (tongue)
[15:17:26 EDT(-0400)] <EricDalquist> looks like the URL work that Nick & I did a while back will be coming over into trunk with the new pluto 2 support too
[15:17:39 EDT(-0400)] <EricDalquist> since the last thing blocking us there was generating URLs for channels
[15:25:55 EDT(-0400)] * pho3nixf1re (~pho3nixf1@69.57.58.162) has joined ##uportal
[15:31:33 EDT(-0400)] * pho3nixf1re (~pho3nixf1@69.57.58.162) has left ##uportal
[15:44:38 EDT(-0400)] <EricDalquist> wow รขย€ยฆ stacks for config mode are long (tongue)
[15:49:57 EDT(-0400)] <athena> yah (tongue)
[15:50:07 EDT(-0400)] <athena> i'm playing w/ the new jquery autocomplete widget
[15:50:15 EDT(-0400)] <athena> actually pretty decent - think we should be able to use it
[15:50:26 EDT(-0400)] <athena> which is good - give us a bit more flexibility
[15:50:33 EDT(-0400)] <EricDalquist> great
[15:50:41 EDT(-0400)] <athena> so we can get rid of these super-customized AJAX targets for the permissions portlet
[15:50:50 EDT(-0400)] <EricDalquist> hopefully we can have the pluto2 code merged back into trunk next friday
[15:51:01 EDT(-0400)] <athena> wooo!
[15:51:04 EDT(-0400)] <athena> that's so awesome (smile)
[15:51:06 EDT(-0400)] <EricDalquist> (another furlough day so both nick and I will be coding on pluto 2 all day)
[15:51:11 EDT(-0400)] <athena> gotcha (smile)
[15:51:14 EDT(-0400)] <athena> that's terrific
[15:51:17 EDT(-0400)] <EricDalquist> and then you can use Spring 3 for your REST URLs
[15:51:23 EDT(-0400)] <athena> yessssss
[15:51:30 EDT(-0400)] <EricDalquist> which should make that part significantly easier
[15:51:31 EDT(-0400)] <athena> it'll be fantastic
[15:51:32 EDT(-0400)] <athena> yes
[15:51:36 EDT(-0400)] <athena> i'm really excited!
[15:52:02 EDT(-0400)] <EricDalquist> I think after the merge but before the real portlet2 support work I'm also going to switch uPortal to use a spring DispatcherServlet
[15:52:07 EDT(-0400)] <EricDalquist> make uPortal a real spring webapp
[15:59:54 EDT(-0400)] <EricDalquist> oi
[16:00:06 EDT(-0400)] <EricDalquist> hopefully when we get of the channel registry code portlet manager won't take so long to load
[16:00:25 EDT(-0400)] <EricDalquist> hrm

  • No labels