Page Comparison

[07:07:16 EST(-0500)] * JASIGLogBot (n=PircBot@jasig.Princeton.EDU) has joined ##uportal
[07:07:16 EST(-0500)] * Topic is 'http://uportal.pastebin.com/ - http://www.ja-sig.org/wiki/display/UPC/uportal+IRC+Logs' set by EricDalquist on 2008-02-27 12:32:13 EST(-0500)
[08:27:02 EST(-0500)] * athena (n=athena@adsl-76-250-193-123.dsl.wlfrct.sbcglobal.net) has joined ##uportal
[08:41:37 EST(-0500)] * athena (n=athena@adsl-76-250-193-123.dsl.wlfrct.sbcglobal.net) has joined ##uportal
[09:55:25 EST(-0500)] * holdorph (n=holdorph@wsip-72-215-204-133.ph.ph.cox.net) has joined ##uportal
[10:00:12 EST(-0500)] * lfuller (n=sparhk@wsip-72-215-204-133.ph.ph.cox.net) has joined ##uportal
[10:19:16 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[10:20:00 EST(-0500)] * Sememmon (n=Sememmon@unaffiliated/sememmon) has joined ##uportal
[10:47:26 EST(-0500)] <athena> can we please start using something to enforce svn newline styles?
[10:47:48 EST(-0500)] <EricDalquist> uhoh
[10:47:52 EST(-0500)] <EricDalquist> more problems?
[10:47:55 EST(-0500)] <athena> yep.
[10:47:57 EST(-0500)] <EricDalquist>
[10:47:59 EST(-0500)] <holdorph> public humiliation is a good motivator
[10:48:11 EST(-0500)] <holdorph> tar and feather the person who screwed up last
[10:48:15 EST(-0500)] <athena> and the really horrible thing is that the import fails after like 45 min, but only fails on one file
[10:48:30 EST(-0500)] <EricDalquist> yeah, emailing the dev list with the svn blame info
[10:48:38 EST(-0500)] <EricDalquist> also I can email about that svn config file I know you've posted
[10:48:40 EST(-0500)] <EricDalquist> once I find it ...
[10:48:43 EST(-0500)] <athena> well, this one is probably yours
[10:48:48 EST(-0500)] <holdorph> lol
[10:48:52 EST(-0500)] <EricDalquist>
[10:48:55 EST(-0500)] <EricDalquist> I feared as much
[10:49:04 EST(-0500)] <athena> lol
[10:49:41 EST(-0500)] <athena> most of them are usually you and dwills
[10:50:31 EST(-0500)] <EricDalquist> what was the offending file this time?
[10:50:51 EST(-0500)] <athena> bootstrap/pom/uportal-ant-tasks-pom.xml
[10:50:55 EST(-0500)] <athena> that was the first, anyway
[10:51:00 EST(-0500)] <athena> got through uportal-impl ok
[10:53:58 EST(-0500)] <athena> i need to find a way to find these programmatically
[10:54:08 EST(-0500)] <athena> so i don't have to run a 45 min import a bunch of times
[10:55:20 EST(-0500)] <EricDalquist> http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/check-mime-type.pl
[10:55:21 EST(-0500)] <EricDalquist> hrm
[10:55:26 EST(-0500)] <EricDalquist> may have to set that up
[10:57:49 EST(-0500)] <athena> does that enforce newline styles as well as mime-type?
[10:58:13 EST(-0500)] <EricDalquist> # commit-mime-type-check.pl: check that every added file has the # svn:mime-type property set and every added file with a mime-type # matching text/* also has svn:eol-style set. If any file fails this # test the user is sent a verbose error message suggesting solutions and # the commit is aborted.
[10:58:52 EST(-0500)] <athena> sounds good to me
[10:58:58 EST(-0500)] <athena>
[11:07:49 EST(-0500)] <EricDalquist> hopefully this will reduce your problems athena
[11:07:57 EST(-0500)] <athena> thanks, i really do appreciate it
[11:08:02 EST(-0500)] <EricDalquist> when do you run into this?
[11:08:13 EST(-0500)] <athena> we'll still have to go through all the ones that are in now, but hopefully i won't have to do it again
[11:08:25 EST(-0500)] <athena> when i do vendor imports to set up local projects
[11:08:37 EST(-0500)] <EricDalquist> ah
[11:08:43 EST(-0500)] <athena> i use a svn config file that enforces newline properties (the one i've shared)
[11:08:48 EST(-0500)] <athena> so i could delete that and the import would run
[11:08:58 EST(-0500)] <EricDalquist> yeah
[11:09:01 EST(-0500)] <athena> but sometimes having different newlines trips up other things
[11:09:21 EST(-0500)] <EricDalquist> do you know of a script we could run to fix all the files that exist now?
[11:09:26 EST(-0500)] <athena> no
[11:09:39 EST(-0500)] <athena> i thought i found something that helped last release, and i just can't remember
[11:09:56 EST(-0500)] <athena> maybe a shell script that searched for files w/ both /r/n and /n?
[11:49:16 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[13:14:12 EST(-0500)] * awills (n=awills@wsip-72-215-204-133.ph.ph.cox.net) has joined ##uportal
[13:40:59 EST(-0500)] * jessm (n=Jess@c-71-232-3-151.hsd1.ma.comcast.net) has joined ##uportal
[14:38:39 EST(-0500)] <athena> EricDalquist: the uportal-war pom doesn't use the war and pluto plugins anymore?
[14:45:53 EST(-0500)] <EricDalquist> it should
[14:45:57 EST(-0500)] <EricDalquist> I think
[14:48:43 EST(-0500)] <athena> hm
[14:48:49 EST(-0500)] <athena> i don't see them in the build list
[14:49:19 EST(-0500)] <athena> oh!
[14:49:24 EST(-0500)] <athena> i bet i was looking at the profile
[14:49:25 EST(-0500)] <EricDalquist> looking at the pom in trunk I see the maven-war-plugin and maven-pluto-plugin
[14:49:31 EST(-0500)] <athena> it all makes sense now
[14:49:35 EST(-0500)] <EricDalquist> ah yeah
[14:49:40 EST(-0500)] <EricDalquist> there is the jspc profile
[14:49:44 EST(-0500)] <athena> so used to just scrolling to the bottom
[14:49:47 EST(-0500)] <athena> sorry!
[14:49:52 EST(-0500)] <EricDalquist> wish we could have that on by default
[14:50:10 EST(-0500)] <EricDalquist> I suppose we can if we document how to turn it off if you want to use a container other than Tomcat6
[14:50:19 EST(-0500)] <EricDalquist> it makes things run so much faster with pre-compiled JSPs
[14:52:22 EST(-0500)] <athena> ah
[14:52:33 EST(-0500)] <athena> though it's annoying when you're in development
[14:52:40 EST(-0500)] <EricDalquist> yeah
[14:52:47 EST(-0500)] <EricDalquist> I'm not sure if there is a 'debug' option
[14:52:56 EST(-0500)] <EricDalquist> since the pre-compiled JSPs don't seem to print out line #s
[14:55:53 EST(-0500)] <EricDalquist> I did try a while ago to get JSP pre-compilation working for the portlet overlays
[14:56:04 EST(-0500)] <EricDalquist> couldn't get the pluto + jspc + war plugins to play nice together though
[14:56:12 EST(-0500)] <EricDalquist> perhaps once we're on pluto 2.0 I'll try again
[14:56:21 EST(-0500)] <EricDalquist> since then I could more easily just patch pluto's plugin
[15:13:29 EST(-0500)] * poofman (i=80876350@gateway/web/freenode/x-lyxhqoxuxygvzzdl) has joined ##uportal
[15:15:10 EST(-0500)] <poofman> Greetings uPortal Devs: EricDalquist showed me yesterday that I can test membership in a group for a user with request.isUserInRole(portalGroupKey). Is there a way to get a list of all groups for the user?
[15:23:00 EST(-0500)] <holdorph> no
[15:23:12 EST(-0500)] <holdorph> well, qualify that, not with the portlet api
[15:24:03 EST(-0500)] <holdorph> if you use the gap api's directly there might be a way, but those are challenging to use from a portlet.
[15:39:29 EST(-0500)] <poofman> ok Thanks holdorph are the gap api's the ones from here: http://www.ja-sig.org/wiki/display/UPM31/99+Developer%27s+Guide+to+Groups ?
[15:48:53 EST(-0500)] <holdorph> well beyond the java interfaces though, you have the issue of the configuration and instantiation of the subsystem.
[15:49:03 EST(-0500)] <holdorph> it's configured an instantiated in the uPortal web app
[15:49:10 EST(-0500)] <holdorph> and portlets run in their own web app
[15:49:32 EST(-0500)] <holdorph> so there normally is no way for them to access the GAP objects, cross webapps like that
[15:50:08 EST(-0500)] <holdorph> so either you configure/instantiate all of GAP a second time, in your own webapp, or you put the portlet in the uPortal webapp
[15:50:17 EST(-0500)] <holdorph> neither approach is a good one.
[15:50:47 EST(-0500)] <poofman> yeah. thats doesn't sound like what we'd like to do.
[15:51:23 EST(-0500)] <holdorph> the last option is to create some kind of bridging/api, which has been done before, but i'm not sure if any of those are publiclly available and/or up to date
[15:55:51 EST(-0500)] <poofman> ok. it seems like we'd like to get the data brought into the PortletRequest.USER_INFO map as maybe a key->value where the key is something like portal.groups and the value is some jacked up semi-colon delimited list of groups the user belongs to.
[15:56:52 EST(-0500)] <poofman> somewhere in the portal (maybe pluto not uportal) the USER_INFO is getting filled with user attribute data.
[16:23:00 EST(-0500)] <EricDalquist> poofman: look at PersonDirectoryUserInfoService in uPortal
[16:23:25 EST(-0500)] <EricDalquist> it is configured in the portletContainerContext.xml file
[16:23:43 EST(-0500)] <EricDalquist> you could create an additional implementation of the UserInfoService interface
[16:24:02 EST(-0500)] <EricDalquist> and have it provide the info you need via the userInfoService bean.
[16:25:05 EST(-0500)] <poofman> I see that file. What about adding to PortletHttpRequestWrapper and adding the securityRoleRefs there to be retrievable from a getAttribute("portal.groups")
[16:25:06 EST(-0500)] <poofman> ?
[16:26:13 EST(-0500)] <EricDalquist> the security role refs is data from your portlet.xml
[16:26:23 EST(-0500)] <poofman> oh.
[16:26:30 EST(-0500)] <EricDalquist> also passing objects from that class to the portlet only works if the class is part of the JDK
[16:26:53 EST(-0500)] <EricDalquist> since the portal and your portlet are in two different class loaders and class equality is based on both class name and class loader
[16:28:16 EST(-0500)] <poofman> ok. we still have the GroupService in the PortletHttpRequestWrapper that has all the group info we could need.
[16:29:53 EST(-0500)] <poofman> seems like we could feed the request attributes with string data from there that would visible to the portlet.
[16:29:58 EST(-0500)] <EricDalquist> right, but you can only pass it in as a string and the APIs in PortletHttpRequestWrapper aren't a 1:1 match for the PortletRequest APIs
[16:30:18 EST(-0500)] <EricDalquist> meaning when you call PortletRequest.getAttribute("foo") PortletHttpRequestWrapper.gettAttribute("foo") is not called
[16:30:29 EST(-0500)] <EricDalquist> an attribute service API that pluto provides is used
[16:31:00 EST(-0500)] <poofman> I was thinking in the RenderRequest
[16:31:23 EST(-0500)] <EricDalquist> there is no RenderRequest implementation in uPortal, Pluto provides that
[16:31:25 EST(-0500)] <poofman> that comes in the doView( method
[16:31:33 EST(-0500)] <EricDalquist> and we just implement service APIs that the RenderRequest calls back to
[16:31:53 EST(-0500)] <poofman> ok.
[16:31:54 EST(-0500)] <EricDalquist> which is why implementing a UserInfoService is an approach that will give you better results as that is part of the service API that RenderRequest will call back to for getting the USER_INFO Map
[16:33:04 EST(-0500)] <EricDalquist> I know it is a bit obtuse but the reasoning for this approach is there are a lot of rules in the portlet spec and using Pluto's versions of the core classes ensures that we don't make a modification in uPortal that breaks part of the spec compliance
[16:33:12 EST(-0500)] <poofman> that is partially more clear now. thanks. I need to study up some more on the UserInfoService API.
[16:33:47 EST(-0500)] <EricDalquist> PersonDirectoryUserInfoService should be a decent example
[16:34:46 EST(-0500)] <EricDalquist> you'll just need to implement the UserInfoService interface, define your instance as a bean in portletContainerContext.xml and then add it to the list of "userInfoServices" that the "userInfoService" bean has
[16:35:09 EST(-0500)] <poofman> ok. I'll start there again. Will that mean that we will end up with something in the portlet that calls the request.getAttribute(PortletRequest.USER_INFO)).get("getGroups..."); to get the group info?
[16:41:13 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[16:57:40 EST(-0500)] <EricDalquist> so when the portlet calls equest.getAttribute(PortletRequest.USER_INFO))'
[16:58:07 EST(-0500)] <EricDalquist> the Map that is returned will be partially populated by your UserInfoService implementation as well as the PersonDirectoryUserInfoService
[17:05:45 EST(-0500)] <poofman> great EricDalquist! thanks again for your help today.
[19:13:49 EST(-0500)] * lfuller (n=sparhk@wsip-72-215-204-133.ph.ph.cox.net) has left ##uportal