Month / March 2013

In the beginning of this year, God taught me a very important lesson that I couldn’t have grasped by myself. About six months prior I remember swearing to myself that this particular experience could not make any sense, I would never understand and it was stupid. Yet here I am now, thankful for my newly learned lesson. Its hard not to see the mystical side of life when something used to hurt can now be used to heal. I’m not talking about a wound healing itself over time, but a wound provoking healing beyond what was initially damaged. Whether it is the cross itself or a more personal experience, things that used to be signs of suffering, sadness, and loneliness can be used to help bring goodness, life, and hope.

Sometimes it is the little things that make it so evident to me that Heaven is actively crashing into, interacting with, and forever changing our world. But we aren’t just supposed to sit here and watch it happen either, we are called to grasp ahold of Heaven’s tendrils and help pull it in.

…left to ourselves we lapse into a kind of collusion with entrophy, acquiescing in the general belief that things may be getting worse but that there’s nothing much we can do about them. And we are wrong. Our task in the present…is to live as resurrection people in between Easter and the final day, with our Christian life, corporate and individual, in both worship and mission, as a sign of the first and a foretaste of the second.

Spring Portlet made a change to the way portlets return resource requests. They changed the default behavior of DispatcherPortlet when handling resource
requests to use PortletRequestDispatcher.forward instead of PortletRequestDispatcher.include; JIRA issue here — SPR-9876. I’m indifferent about the change. It seems more people use the ResourceRequest with the .forward, so its good for them I guess. I mostly use resource requests with small custom jsps, so I use the .include. But it doesn’t really matter to me aslong as they maintain compatibility, which they did. If you set renderResourceViewViaInclude property to true(defaults as false) it should work the same as before.

Well, I can’t get my views to render through resource requests anymore after this change. The only change that was supposed to be needed was adding an init-param into your portlet.xml, but even with that in place my views just return blank.

I’m still trying to figure out why this isn’t working. Based on the git commit tied to the issue, it looks like aslong as renderResourceViewViaInclude is set to true then the dispatcher should call .include. Is it not working as intended? Or is renderResourceViewViaInclude not being set properly?

The culprit has been found! While talking with the person who made the JIRA issue and git commit, it looks like Spring never implemented the renderResourceViewViaInclude flag on DispatcherPortlet(and now rereading the last comment on JIRA I can see that they actually said they weren’t going to). So all resource requests were ALWAYS using .forward. The fix? You will have to subclass DispatcherPortlet and override doDispatch to use .include, or set up your own flag.

Hopefully Spring will actually put this the flag into the their portlet library so people won’t have to do this for every portlet that wants a review returned from a resource request.Talking with some other portlet developers, it seems I am in the minority of using resource requests to return views, they are mostly used to return pure json data. It seems I either need to get with the times or I will have to use my subclassed DispatcherPortlet in all future portlets.