The bridge relies on blind-casts of the PortletContext, RenderRequest and RenderResponse objects to retrieve the underlying javax.servlet API objects. This is not allowed under the JSR-168 specification and the manner these interfaces are implemented is completely up to the individual portal. As these are internal APIs work to make a 3rd party library function is not within the scope of the project. While external solutions may be found these should be considered un-stable as the internal APIs of the portal may change between any version and without any prominent warning.
Eric Dalquist[16/Jun/08 03:30 PM]
The Struts Bridge for portals is not a JSR-168 compliant framework despite what is stated on its site: http://portals.apache.org/bridges/multiproject/portals-bridges-struts/index.html
The bridge relies on blind-casts of the PortletContext, RenderRequest and RenderResponse objects to retrieve the underlying javax.servlet API objects. This is not allowed under the JSR-168 specification and the manner these interfaces are implemented is completely up to the individual portal. As these are internal APIs work to make a 3rd party library function is not within the scope of the project. While external solutions may be found these should be considered un-stable as the internal APIs of the portal may change between any version and without any prominent warning.
The bridge relies on blind-casts of the PortletContext, RenderRequest and RenderResponse objects to retrieve the underlying javax.servlet API objects. This is not allowed under the JSR-168 specification and the manner these interfaces are implemented is completely up to the individual portal. As these are internal APIs work to make a 3rd party library function is not within the scope of the project. While external solutions may be found these should be considered un-stable as the internal APIs of the portal may change between any version and without any prominent warning.