DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=29502>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=29502 Extend the Struts framework to allow Struts application to be executed within a JSR168 portlet. ------- Additional Comments From [EMAIL PROTECTED] 2004-06-10 20:26 ------- I'd like to inform you that I have developed a Struts Portlet Framework for Jetspeed 2 a few weeks ago. Although it is far from complete, it already is running the Struts MailReader example just fine within Jetspeed 2. I'm now a committer of Jetspeed 2 and intend to further improve this soon. I've been swamped with other tasks, otherwise I would have already send an announcement to the Struts community about this new framework earlier. My framework more or less follows the lines of the proposal from Pradeep. There are a few differences though. It uses its own StrutsPortlet to include an minimal extended version of ActionServlet (PortletServlet). I did that mainly to have the least possible impact on the current Struts implementation. I developed the framework to be used *with* a Struts version, not embedding it into it. I know formal JSR-168 support was planned for Struts but only from version 2.0 and up and I needed this now (I've a big client developing portlets based on my framework). I defined a StrutsServletContextProvider, similar to the proposed ServletObjectFactory. Except for access to a ServletConfig (which my framework doesn't need) it provides the same functionality. Jetspeed 2 delivers an implementation of this interface, and as Jetspeed 2 uses Pluto as portlet container my framework can probably be used with other Pluto based portals without much modifications. My framework handles the Struts application url separately from the portlet url as a portlet render parameter. I didn't read anything about that yet in the proposal but it is really something to be addressed. My framework uses a StrutsRenderContext object to save the state/result of an actionRequest to be processed during rendering somewhat similar to the AbstractStrutsCommand. I think this is a fine proposal which matches to a large part of the Jetspeed 2 Struts Portlet Framework already implements. I'm more than willing to share my experience with creating this framework with anyone who wants to implement this new proposal. Note that the framework of Jetspeed 2 is also under Apache license so you are more than free to use any part of it. You can access the current version through cvs here: http://cvs.apache.org/viewcvs.cgi/jakarta-jetspeed-2/struts-portlet/ Note: I've developed this framework against the 20040407 nightly build. Once the Struts 1.2.1 release is available (now soon I hope) I will make sure it is working against that version also. Its current features, shortcomings and restrictions are described in: http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-jetspeed-2/struts- portlet/README.txt?rev=1.1 If the struts framework is extended for JSR-168 support in a way which is not to far deviating from my current implementation for Jetspeed 2, nor loses features we now have, we probably will switch over to the Struts version as soon as its properly functional. Having JSR-168 support from the Struts community really would be great. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
