Figured it out. The rendering pipeline customizations as such work just fine.
Locally, httpd was configured to helpfully intercept bare /portal and redirect it to /Login since MyUW doesn't in general support un-authenticated uPortal sessions. The uPortal /Login handling zaps the existing session and bootstraps a new session on every request to /Login, regardless of whether there's an existing session. So that means that under the Bucky profile, requests for /portal were resulting in the session being zapped, the new session having no record of the desire for non-default Bucky profile, and so the effect was to switch profiles back to default. (Functionally, that yielded the right result until the advent of multiple profiles such that the default isn't always the right profile to be using.) I've got some logging enhancements created in the course of troubleshooting this that I'll tee up as a Pull Request, and I hope to look into making /Login handling less needlessly-thrashy in the case where your existing session is really just fine. Kind regards, Andrew On Mon, Oct 13, 2014 at 8:56 AM, Andrew Petro <[email protected]> wrote: > An update: > > It turns out this rendering pipeline plugin doesn't, well, entirely > work, at least not for what MyUW is trying to use it for. :/ > > It's catching the "Return to Dashboard" link from the contextual menu > when you're looking at a maximized portlet. As in, you click a link > like this: > > https://my-qa.wisc.edu/portal/f/u4514l1s4/normal/render.uP?pCt=wisccal-available-portlet.u4514l1n210&pCs=normal&pCp > > and it sends you right back to > > https://my-qa.wisc.edu/web/ > > where you belong. > > > However, if you manually go to (or bookmarked) > > https://my-qa.wisc.edu/portal > > you get the wrong thing. Rather intensively. You show up not only at > the traditional rendering of the dashboard experience, but back under > Universality rather than under, in our case, Bucky. > > This also only happens on our test server tiers, not on localhost. > "Works for me." :) > > I don't yet know why, but I'm sure to eventually figure it out. :) > > In any case, I'm sure the proffered Pull Requests can be merged > without incident, since > > 1) the way it fails is to fail to intercede, not stack trace out or > anything spectacular like that, and > 2) the offered Pull Requests only add the source code to the codebase, > they don't configure it for use, so it won't affect anything anyway. > :) > > Kind regards, > > Andrew > > > > On Fri, Oct 10, 2014 at 9:17 AM, Andrew Petro <[email protected]> wrote: >> uPortal developers, >> >> This solution is now coded, deployed to a MyUW test tier, and >> configured. It seems to work well. >> >> There were a couple improvements to the design and working out of >> implementation details in coding it. >> >> https://apetro.ghost.io/pipelines-need-valves/ >> >> is updated to reflect, and to link Pull Requests proposing inclusion >> of these generic, cross-adopter-applicable rendering pipeline >> components in the uPortal codebase for the uPortal 4.2 release (i.e., >> into master). >> >> They're proffered as several atomic Pull Requests because they have no >> formal dependencies upon one another, which is one of the nice things >> about the implementation. The MyUW configuration is offered as an >> example configuration in the Pull Request description, but the actual >> `renderingPipelineContext.xml` is untouched so including these >> components in the codebase will make no change to the out of the box >> rendering pipeline behavior. >> >> Kind regards, >> >> Andrew >> >> >> On Wed, Oct 8, 2014 at 11:34 AM, James Wennmacher >> <[email protected]> wrote: >>> Andrew I wish I could say I understood the rendering pipeline well enough to >>> give a reasonable critique, but unfortunately my understanding is fairly >>> high level. To my knowledge what you propose sounds reasonable and seems >>> like it would work. I'll be curious to find out if you run into a lot of >>> edge cases. >>> >>> James Wennmacher - Unicon >>> 480.558.2420 >>> >>> On 10/08/2014 08:26 AM, Eric Dalquist wrote: >>> >>> +1 >>> >>> the rendering pipeline is supposed to be flexible enough to do whatever you >>> need to do for making the portal render, escaping with a redirect seems >>> perfectly fine to me. >>> >>> On Fri, Oct 3, 2014 at 1:30 PM, Andrew Petro <[email protected]> wrote: >>>> >>>> uPortal developers, >>>> >>>> I think MyUW has a local need to conditionally branch the rendering >>>> pipeline (and to terminate it in a redirect on one of those branches). >>>> >>>> Design sketch here: >>>> >>>> http://apetro.ghost.io/pipelines-need-valves/ >>>> >>>> I'd love your perspectives and feedback. >>>> >>>> I expect that one way or another there will be some portions of the >>>> eventual solution that should make their way into the uPortal >>>> framework. >>>> >>>> Kind regards, >>>> >>>> Andrew >>>> >>>> -- >>>> You are currently subscribed to [email protected] as: >>>> [email protected] >>>> To unsubscribe, change settings or access archives, see >>>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev >>> >>> >>> -- >>> >>> You are currently subscribed to [email protected] as: >>> [email protected] >>> To unsubscribe, change settings or access archives, see >>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev >>> >>> >>> -- >>> >>> You are currently subscribed to [email protected] as: >>> [email protected] >>> To unsubscribe, change settings or access archives, see >>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
