[11:12:56 CDT(-0500)] <rlewis> Hi, I am setting up uPortal 4.0.5 trying to use external cas server. put change in local.properties ran "ant deploy-ear" and "ant start" , no luck, login button still says localhost. Help!
[11:15:04 CDT(-0500)] <EricDalquist> so you followed all the steps here? https://wiki.jasig.org/display/UPM40/CAS
[11:17:58 CDT(-0500)] <EricDalquist> athena: https://issues.jasig.org/browse/UP-3517
[11:19:13 CDT(-0500)] <athena> yay thanks!
[11:19:36 CDT(-0500)] <athena> rlewis: set the Cas login url in security.properties to a blank string, redeploy, and restart
[11:36:18 CDT(-0500)] <rlewis> athena: do I make that change to the security.props file under uPortal or the file under tomcat? I am using the quick start pkg.
[11:38:00 CDT(-0500)] <athena> depends on how you want to work with that codebase - if you anticipate rebuilding it at some point you should probably change the source file and redeploy
[11:38:04 CDT(-0500)] <athena> otherwise you can just change the one in tomcat
[11:38:36 CDT(-0500)] <rlewis> ok, thanks
[13:21:40 CDT(-0500)] <drewwills> you there EricDalquist?
[13:21:44 CDT(-0500)] <EricDalquist> YES
[13:21:49 CDT(-0500)] <EricDalquist> oops ... capslock 
[13:22:00 CDT(-0500)] <drewwills> I've gotten myself in a bit of a bind...https://gist.github.com/3131072
[13:22:16 CDT(-0500)] <drewwills> remember that restapi invoker thingee?
[13:22:47 CDT(-0500)] <drewwills> at first I didn't think i would need the ability to invoke from a portlet, just from a servlet
[13:22:56 CDT(-0500)] <drewwills> but I was wrong, i do 
[13:23:11 CDT(-0500)] <EricDalquist> 
[13:23:27 CDT(-0500)] <EricDalquist> that is quite the stack trace
[13:23:37 CDT(-0500)] <drewwills> so i'm going back and enhancing it... adding the extra layer of portlet -> proxyservlet -> xContext include
[13:23:50 CDT(-0500)] <drewwills> yes... a bit ahrd to follow
[13:24:21 CDT(-0500)] <drewwills> i think i may not be wrapping so object sufficiently
[13:24:41 CDT(-0500)] <EricDalquist> heh ... I'm not sure this is even possible
[13:24:46 CDT(-0500)] <EricDalquist> let me read through the stack for a minute
[13:24:54 CDT(-0500)] <drewwills> https://gist.github.com/3131108
[13:25:41 CDT(-0500)] <drewwills> (sorry for system.out noise on that one)
[13:26:31 CDT(-0500)] <drewwills> (proxying servlet https://gist.github.com/3131119)
[13:26:36 CDT(-0500)] <EricDalquist> so this is going from
[13:27:51 CDT(-0500)] <EricDalquist> portal -> pluto container -> crossCTX -> pluto servlet -> your custom portlet filter -> local servlet dispatcher -> crossCTX -> portal rest api
[13:29:36 CDT(-0500)] <drewwills> sounds about right
[13:30:19 CDT(-0500)] <drewwills> trying to get at /api/permissions/etc
[13:30:33 CDT(-0500)] <EricDalquist> uhg
[13:30:38 CDT(-0500)] <EricDalquist> this is really really really gross
[13:31:02 CDT(-0500)] <drewwills> (the more I mess with this, the more curios I get about maybe putting an API jar in shared and registering a request attribute)
[13:31:23 CDT(-0500)] <EricDalquist> heh
[13:31:24 CDT(-0500)] <EricDalquist> yeah
[13:31:29 CDT(-0500)] <EricDalquist> that is probably more sane ...
[13:32:23 CDT(-0500)] <EricDalquist> really the best would be a API jar in shared and providing it as a PortletContext attribute
[13:32:33 CDT(-0500)] <drewwills> bb in a bit...
[13:32:35 CDT(-0500)] <EricDalquist> though that may require a bit more work up front in uPortal to expose that
[13:32:39 CDT(-0500)] <EricDalquist> oh ...
[13:32:47 CDT(-0500)] <EricDalquist> well let me know when you're back
[13:32:49 CDT(-0500)] <EricDalquist> and we can look at this more
[13:33:31 CDT(-0500)] <drewwills> yeah sorry mtg crept up on me
[13:39:08 CDT(-0500)] <drewwills> ok, false alarm... meeting moved
[13:39:21 CDT(-0500)] <drewwills> i have another at noon ()20 min though
[13:39:41 CDT(-0500)] <EricDalquist> so in that stack trace
[13:39:51 CDT(-0500)] <EricDalquist> the last caused by
[13:40:55 CDT(-0500)] <drewwills> yep
[13:41:37 CDT(-0500)] <EricDalquist> it looks like spring is doing something around request attributes and includes
[13:42:08 CDT(-0500)] <drewwills> yeah... messing with them when wrapping, restoring when unwrapping
[13:42:12 CDT(-0500)] <EricDalquist> yeah
[13:42:25 CDT(-0500)] <EricDalquist> I'm assuming it is doing this to deal with spring dispatcher including another spring dispatcher
[13:42:29 CDT(-0500)] <EricDalquist> which is good since that is happening here
[13:42:57 CDT(-0500)] <EricDalquist> the problem is we have logic in uPortal that is supposed to prevent portlet code from messing with certain classes of attributes
[13:43:15 CDT(-0500)] <drewwills> yeah, looks that way
[13:43:27 CDT(-0500)] <EricDalquist> so when spring is doing it's restore it triggers that protection
[13:43:36 CDT(-0500)] <EricDalquist> one thought is to change PortletRequestContextImpl
[13:43:43 CDT(-0500)] <EricDalquist> and have it do a silent ignore
[13:43:50 CDT(-0500)] <EricDalquist> or a logger.debug ignore
[13:43:53 CDT(-0500)] <EricDalquist> instead of throwing
[13:44:09 CDT(-0500)] <EricDalquist> which would probably be reasonable
[13:44:16 CDT(-0500)] <EricDalquist> so go into org.jasig.portal.portlet.container.PortletRequestContextImpl.setAttribute(PortletRequestContextImpl.java:169)
[13:44:23 CDT(-0500)] <EricDalquist> and change the throw
[13:44:26 CDT(-0500)] <EricDalquist> to a logger.debug
[13:44:30 CDT(-0500)] <EricDalquist> and a return
[13:44:47 CDT(-0500)] <EricDalquist> that will have the desired effect of not letting portlets touch those attributes
[13:45:01 CDT(-0500)] <EricDalquist> and let spring's restore process work
[13:47:33 CDT(-0500)] <drewwills> trying that
[13:49:27 CDT(-0500)] <drewwills> i bet a java API (as a PortletContext attr) would cover most use cases if it just had user attributes, groups, permissions
[14:04:47 CDT(-0500)] <athena> that seems plausible
[14:05:00 CDT(-0500)] <EricDalquist> yeah and will be easier if I can get time to finish this spring-portlet contrib work
[14:05:08 CDT(-0500)] <EricDalquist> that would fit well into the new portlet-application level context config
[14:05:15 CDT(-0500)] <EricDalquist> since we would have the PortletContext availble there
[14:09:38 CDT(-0500)] <mmoayyed> Hi everyone. I am experiencing a strange issue. Working on an instance of the email-preview portlet, for some reason the USER_INFO map is completely empty. Any ideas?
[14:10:26 CDT(-0500)] <EricDalquist> you have user attributes configured in portlet.xml?
[14:11:30 CDT(-0500)] <mmoayyed> I have the user attribute entries defined for both password and user.login.id. I have configured clearpass and I do see the log entry that indicates psw is being retrieved. I have also added the 'cachedPasswordUserInfoService' bean into the context
[14:11:46 CDT(-0500)] <mmoayyed> still, isEmpty() returns true
[14:11:51 CDT(-0500)] <EricDalquist> weird
[14:16:17 CDT(-0500)] <mmoayyed> I had no values for attributes, that would have been slightly better. But a completely empty map makes very suspicious. javadocs say the attribute needs to be supported by the current runtime system. Is there any other configuration that I should add?
[14:16:27 CDT(-0500)] <mmoayyed> *if I had...
[14:16:55 CDT(-0500)] <athena> that does seem odd - maybe set a breakpoint in CachedPasswordUserInfoService?
[14:17:07 CDT(-0500)] <athena> make sure it' sgetting called, retrieving successfully, etc.
[14:17:35 CDT(-0500)] <EricDalquist> so the parts that need to match are:
[14:17:35 CDT(-0500)] <EricDalquist> the attribute(s) are needed in portlet.xml
[14:17:35 CDT(-0500)] <EricDalquist> the same attribute(s) need to exist in personDirectory
[14:17:35 CDT(-0500)] <EricDalquist> the exception to the previous point are "special" attribute names for things like the cached password or CAS PGT
[14:27:22 CDT(-0500)] <mmoayyed> I definitely have uid, username and user.login.id defined in person-dir. This particular user does exist inside UP_USER. my person directory config for uPortalJdbcUserSource and uPortalAccountUserSource is identical to the copy of the file on github
[14:29:08 CDT(-0500)] <mmoayyed> just one thing though. I dont have to do anything special for CachedPasswordUserInfoService to kick in right? user info beans are all loaded by type?
[14:29:22 CDT(-0500)] <EricDalquist> I believe so
[14:29:29 CDT(-0500)] <mmoayyed> 'cause the documentation suggested that it needed to be added to somewhere else, but I suspect that's old
[14:29:33 CDT(-0500)] <EricDalquist> @Autowired
[14:29:33 CDT(-0500)] <EricDalquist> public void setUserInfoServices(Set<UserInfoService> userInfoServices) {
[14:29:37 CDT(-0500)] <EricDalquist> looks like it
[14:41:55 CDT(-0500)] <mmoayyed> does UP has a logging aspect, such that if I turn up the TRACE level, I'd be able to review method arguments on entering and exiting methods?
[14:42:56 CDT(-0500)] <EricDalquist> no
[14:43:03 CDT(-0500)] <EricDalquist> would be a nice thing to add
[14:43:05 CDT(-0500)] <mmoayyed> I am working on a remote linux server, and it's hooked up in a way that makes the build very difficult locally. If it's possibly, I'd rather debug the issue through logs
[14:43:24 CDT(-0500)] <mmoayyed> This is what CAS does:
[14:43:25 CDT(-0500)] <mmoayyed> http://grepcode.com/file/repo1.maven.org/maven2/org.jasig.cas/cas-server-core/3.4.11/org/jasig/cas/aspect/LogAspect.java#LogAspect
[14:44:01 CDT(-0500)] <mmoayyed> should be able to use the same exact code, with very little changes
[14:44:42 CDT(-0500)] <EricDalquist> yeah