Jason Novotny wrote:
Cool-- I appreciate your work in this area! Developing standards
compliant briodges that we as portal vendors can use will greatly
enhance all of our projects as well as give people confidence in
developing solutions that avoid vendor lock-in-- kep up the great work :-)
Thanks :-)
I'm inlining your original question here so others will understand what this
is all about. And also cc'ing Stefan and jsr-168-comments as I'd like to provide
a solution that is acceptable (as much as possible) to all.
Jason Novotny wrote:
>
> Hi Ate,
>
> Great work on the struts portlet brige! I'm trying to heist the code
> and get it working in GridSphere. I just used the struts-demo and it all
> worked fine with the right tweaks in web.xml and using our
> PortletServlet driver. Not too sure how that app really works ;-) but
> navigation and form handling seem to work fine. One issue I had though
> where I had to change my code is make sure to add the
> "javax.portlet.request" attribute in the request since some the bridge
> code uses a check like:
>
> public static boolean isPortletRequest(ServletRequest request)
> {
> return request.getAttribute("javax.portlet.request") != null;
> }
>
> But it seems according to the spec. that it shouldn't need to be set
> before performing an action method, since the RenderRequest which
> represents "javax.portlet.request" PLT 16.3.2 would only be accessible
> when a servlet is included as part of a render request... but I can't
> really come up with any other way that would indicate that it's a
> portlet request.
>
> Cheers, Jason
>
>
I gave this problem some more thought.
Its true that the portlet api doesn't specify anything about setting
the javax.portlet.* attributes during ActionRequest handling.
But then, the spec doesn't (formally) support Servlet inclusion from an
ActionRequest
either (which is a *big* omission in my opinion).
So, using the Struts Bridge (or more specific: the Portals Bridges Common
ServletContextProvider interface)
is already not fully in compliance with JSR-168. But then, I don't think its in
violation either.
It just requires access to the underlying Servlet context.
But *not* that a Portlet request extends the Servlet request as Stefan Hepper
thought.
Now, I see two ways to solve this problem:
a) use a different request attribute to test against, like
StrutsPortlet.REQUEST_TYPE
b) actually set this attribute (and the others) from
StrutsPortlet.processRequest before
including the StrutsServlet when handling an ActionRequest.
Solution a) is quick and simple to do as this request attribute already is set
when the StrutsServlet
is invoked from StrutsPortlet.
Solution b) might be more generic though.
This way, Portals are not required to set these attributes (won't harm either,
Jetspeed-2 itself *does* set these).
And, the Struts application has an easy and *transparent* access to the
PortletRequest/Response/Config
components, even during ActionRequest handling. These attributes then are guaranteed to exist when using the Struts
Bridge, independent of the underlying Portal.
This might be an "extension" of the portlet specs, but I don't think it is a
violation.
I certainly would like to see something like this (and the
ServletContextProvider)
supported in an upcoming spec update :-)
Clearly I prefer solution b). What do you think?
Cheers, Jason
Ate Douma wrote:
Hi Jason,
Funny, I was just looking at your mail about it :-)
I think you we're right in that it is not standards-compliant and I'm
thinking
of a different solution. I don't think it will be difficult to do.
I come back on that as soon as possible.
Regards,
Ate
Jason Novotny wrote:
Hi Ate,
Welcome back from your vacation and glad you started the bridges
mail lists-- did you ever get a chance to check out the mail exchange
between me and Stefan Hepper, JSR 168 co-author? I'm concerned that
the approach may not be standards-compliant... did that make any
sense to you?
Thanks, Jason
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
