uPortal IRC Logs-2010-08-25

Owned by Apereo Infrastructure
Last updated: Aug 25, 2010Version comment

[12:50:44 CDT(-0500)] <EricDalquist> athena: I saw that same blank javadoc page this morning
[12:50:54 CDT(-0500)] <athena> yeah i saw your tweet
[12:50:57 CDT(-0500)] <EricDalquist> did some digging and looks like oracle's webserver may be getting overloaded (tongue)
[12:50:59 CDT(-0500)] <athena> not very encouraging, huh?
[12:51:01 CDT(-0500)] <athena> lol
[12:51:09 CDT(-0500)] <EricDalquist> it's just dropping the connection part way through the response
[12:52:12 CDT(-0500)] <athena> ick
[12:52:23 CDT(-0500)] <EricDalquist> yeah
[12:52:38 CDT(-0500)] <EricDalquist> not very encouraging at all (tongue)
[13:37:44 CDT(-0500)] <EricDalquist> hrm
[13:37:57 CDT(-0500)] <EricDalquist> so how bad would it be if the DLM processing pipe was replaced in trunk ...
[14:15:47 CDT(-0500)] <athena> i don't know
[14:15:50 CDT(-0500)] <athena> how bad would it be? (smile)
[14:16:04 CDT(-0500)] <EricDalquist> well all that stuff is built in SAX ContentHandlers
[14:16:09 CDT(-0500)] <EricDalquist> and the new pipeline is all StAX
[14:16:39 CDT(-0500)] <EricDalquist> I think it will be ok technically, you'll be able to add in StAX event filters at any point in the pipeline
[14:16:59 CDT(-0500)] <EricDalquist> versus right now you can only add in a DLM processor between the layout manager and the structure XSLT
[14:17:16 CDT(-0500)] <EricDalquist> it will just result in any existing DLM processor having to be re-written
[14:17:56 CDT(-0500)] <athena> i think as long as there's an equivalent for any existing extention functionality it's not the end of the world to have to make some code updates
[14:18:01 CDT(-0500)] <athena> i mean, this will be a pretty major release
[14:18:17 CDT(-0500)] <athena> and i would assume most of the institutions that have written their own plugins for that system are pretty technical
[14:18:50 CDT(-0500)] <EricDalquist> yeah
[14:19:01 CDT(-0500)] <EricDalquist> and this is going to be a big step forward in features
[14:19:07 CDT(-0500)] <athena> awesome (smile)
[14:19:13 CDT(-0500)] <EricDalquist> like the new pipeline compontent interface includes a cachekey
[14:19:14 CDT(-0500)] <athena> yeah i'm pretty excited about all these changes
[14:19:47 CDT(-0500)] <EricDalquist> so if your processor can generate an intelligent key based on the request you can trigger re-execution of the pipeline from your component on by simply having the key change
[14:20:14 CDT(-0500)] <athena> that's fantastic (smile)
[14:20:42 CDT(-0500)] <EricDalquist> yeah
[14:20:50 CDT(-0500)] <EricDalquist> so if you're basing your processor on a user attribute
[14:20:53 CDT(-0500)] <EricDalquist> expose that in your key
[14:20:55 CDT(-0500)] <EricDalquist> and the attribute changes
[14:21:01 CDT(-0500)] <athena> very nice
[14:21:08 CDT(-0500)] <EricDalquist> the pipeline will re-render from that point on
[14:21:13 CDT(-0500)] <athena> cool (smile)
[14:22:44 CDT(-0500)] <athena> i wanted to talk a little bit about the i18n stuff
[14:22:51 CDT(-0500)] <athena> particularly about what sort of message keys we use
[14:22:56 CDT(-0500)] <athena> it seems like there are two potential strategies:
[14:23:32 CDT(-0500)] <athena> 1. create names based on where and how the string is used, like groups-manager.selectGroupType.Title
[14:23:59 CDT(-0500)] <athena> 2. create names based on the string itself, like "groups.by.type", or "save"
[14:24:45 CDT(-0500)] <athena> for option 2, i think one advantage would be that the file itself would be simpler, and since there's a clear correlation between the string and the message it would be easier to edit and translate
[14:24:52 CDT(-0500)] <EricDalquist> right
[14:24:54 CDT(-0500)] <athena> option 2 is also better for message re-use
[14:24:57 CDT(-0500)] <EricDalquist> yeah
[14:26:52 CDT(-0500)] <EricDalquist> yeah
[14:27:00 CDT(-0500)] <EricDalquist> I think we should do option 2
[14:27:14 CDT(-0500)] <EricDalquist> might be worth a quick poll on the dev list just to see if there are other views
[14:27:25 CDT(-0500)] <EricDalquist> but I'd go ahead with work using #2
[14:27:37 CDT(-0500)] <athena> sounds like a start (smile)
[14:28:14 CDT(-0500)] <athena> you have a preference for message key format?
[14:28:18 CDT(-0500)] <athena> dashes, dots, etc.?
[14:33:21 CDT(-0500)] <EricDalquist> I use dots
[14:33:26 CDT(-0500)] <EricDalquist> but don't really care that much
[14:34:58 CDT(-0500)] <athena> i wasn't sure if dots would imply some sort of path information
[14:35:05 CDT(-0500)] <athena> for the record i don't care either, really (smile)
[16:15:08 CDT(-0500)] <athena> hey EricDalquist - lfuller1 noticed that when you refresh a page in uPortal, the uPortal internal javascript resources have a 304 Not-Modified HTTP response, while the RSW javascript resources answer with a 200 OK
[16:15:22 CDT(-0500)] <athena> is there a reason for that, or should RSW be sending back 304s as well?
[16:15:32 CDT(-0500)] <EricDalquist> hrm
[16:15:43 CDT(-0500)] <EricDalquist> there was a bug in ehcache-web at one point that was horking the headers
[16:15:46 CDT(-0500)] <EricDalquist> that could be the issue
[16:15:54 CDT(-0500)] <lfuller1> is confusing the heck out of bob dias our UI guy.
[16:16:06 CDT(-0500)] <lfuller1> doesn't seem to be delivering what we had hoped.
[16:16:07 CDT(-0500)] <athena> interesting - you think the RSW and uPortal have different versions of ehcache-web?
[16:16:11 CDT(-0500)] <EricDalquist> are the requests to the RSW files including an ETag or LastModified header?
[16:16:16 CDT(-0500)] <EricDalquist> they could
[16:16:40 CDT(-0500)] <athena> i don't know, but i'd think that the request headers would be the same to all resources imported in the same page?
[16:17:11 CDT(-0500)] <athena> for the record though lfuller1, i still don't see the resources actually being downloaded on every request - i just see them pulled in when i reload the page, as opposed to clicking to new URLs
[16:17:17 CDT(-0500)] <EricDalquist> depends on what the response headers were the last time they were requests
[16:17:29 CDT(-0500)] <EricDalquist> the browser tracks ETag and Last Modified values for content
[16:17:40 CDT(-0500)] <EricDalquist> and can provide that back to the server
[16:17:45 CDT(-0500)] <athena> the response headers for the RSW include both Etags and Last-Modified
[16:17:49 CDT(-0500)] <EricDalquist> that is how the server knows it can respond with a 304
[16:19:35 CDT(-0500)] <athena> looks like the request is sending back both the If-None-Match w /the Etag and the If-Modified_since as well
[16:19:38 CDT(-0500)] <athena> so not sure what's up there
[16:20:08 CDT(-0500)] <athena> expires header looks ok
[16:20:23 CDT(-0500)] <EricDalquist> sounds like the ehcache filter may need checking
[16:20:38 CDT(-0500)] <athena> let me look at the versions
[16:20:49 CDT(-0500)] <lfuller1> would love to check the version Eric... but am not finding a name that even comes close in the pom.xml files I am digging in.
[16:21:15 CDT(-0500)] <EricDalquist> do "mvn dependency:tree"
[16:21:23 CDT(-0500)] <EricDalquist> or if you have m2eclipse installed
[16:21:25 CDT(-0500)] <athena> yep - RSW has ehcache 1.6.0 and ehcache-web 1.6.0-beta2
[16:21:36 CDT(-0500)] <EricDalquist> go to the Depdency Heirarchy tab
[16:21:39 CDT(-0500)] <athena> uPortal has 2.2.0 and 2.0 respectively
[16:24:22 CDT(-0500)] <lfuller1> for uPortal 3.1.1 it seems to be consistent though
[16:24:33 CDT(-0500)] <lfuller1> could just be my version... will check the vanilla
[16:24:45 CDT(-0500)] <athena> no, i've confirmed it in the trunk
[16:25:09 CDT(-0500)] <lfuller1> consistent in that I only see the older configs
[16:25:11 CDT(-0500)] <EricDalquist> so the ehcache-web version in RSW needs updating then ...
[16:25:14 CDT(-0500)] <lfuller1> er versions
[16:25:14 CDT(-0500)] <athena> probably
[16:25:27 CDT(-0500)] <athena> going to restart to see if the dependency version change fixes it
[16:26:06 CDT(-0500)] <athena> lfuller1: if this does fix it, you can probably just change the version number via an overlay, since you're creating one anyway
[16:26:19 CDT(-0500)] * lfuller1 nods
[16:44:08 CDT(-0500)] <athena> ooook that did work
[16:44:16 CDT(-0500)] <athena> though it took so long that lennard fell off the internets (smile)
[16:45:10 CDT(-0500)] <EricDalquist> athena: try ehcache-web 2.0.2
[16:45:29 CDT(-0500)] <athena> should probably upgrade both, i guess?
[16:45:30 CDT(-0500)] <EricDalquist> I just remembered there was a bug that I fixed for them in 2.0 that may be the cause of this
[16:45:33 CDT(-0500)] <EricDalquist> yeah
[16:45:39 CDT(-0500)] <holdorph> lfuller is off to scouts, but he got your message athena
[16:45:50 CDT(-0500)] <EricDalquist> though ehcache 2.2 disables cache statistics by default
[16:46:10 CDT(-0500)] <EricDalquist> so you don't get any info in JMX unless you add statistics=true to every entry in ehcache.xml
[16:46:17 CDT(-0500)] <EricDalquist> see: http://ehcache-spring-annotations.googlecode.com/svn/trunk/src/test/resources/ehcache.xml
[16:46:35 CDT(-0500)] <EricDalquist> though also in 2.2 you can add an attribute in ehcache.xml to turn off the update check "feature" in ehcache
[16:46:38 CDT(-0500)] <holdorph> lfuller (still off irc, but in the office) says good to know
[16:47:44 CDT(-0500)] <athena> oh good, thanks holdorph (smile)