And here's that Pull Request proffering the logging enhancements: https://github.com/Jasig/uPortal/pull/437/
On Tue, Oct 14, 2014 at 10:54 AM, Andrew Petro <[email protected]> wrote: > 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
