RE: JSR-168 and Struts
Hello Struts and Pluto developers, There was a thread about developing JSR-168 support into Struts 2.0 in the pluto-dev list and we thought it might be best to continue this thread on both lists, pluto-dev and struts-dev synchronously. Below is the last email in the thread send by Scott Weaver to the pluto-dev list. Please reply all so that your emails will go to both groups. Thanks, Mete Scott's message: -- Original Message -- From: Weaver, Scott [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Wed, 29 Oct 2003 15:33:03 -0500 Hi Martin, -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 29, 2003 3:16 PM To: '[EMAIL PROTECTED]' Subject: RE: Pluto and Struts On Wed, 29 Oct 2003, Weaver, Scott wrote: Maybe it's just me, but I tried to build the contrib stuff in the CVS for struts a while back as I wanted to start taking a look at. However, I could never get it built. There were deps I had never heard of, nor did I know were to get them. If you could let me know what you're having problems with, I'll try to help you through getting it all built. The chances are that anything you haven't heard of comes from Jakarta Commons or the Commons Sandbox. (For example, 'chain' is currently in the sandbox.) I know most of the stuff in commons proper, I don't think that's were my issue lies. I am pretty sure it was chain that I couldn't find and, at the time, I am not sure it was available, even within commons-sandbox. I don't remember the specific issues as this was around 2 months ago when I last tried. I was actually having the same problem but from the other side of the coin, as it were. I need to build 'chain' against the Portlet API, but I couldn't get Pluto to build, and couldn't figure out the deps for that. (BTW, since Pluto's build.xml depends on ant-contrib, '-projecthelp' doesn't work until that's configured, which is quite mysterious until you look at the build file itself. ;) Try build driver, there are custom ant tasks that get included when you call the build script. I really don't do much at all with Pluto portal implementation in that my focus, concerning Jetspeed, is the core Pluto container itself. That is were I spend most of my time in regards to Pluto. That being said, there should be no fork in development to support either Pluto Portal or Jetspeed 2. In fact, if we do this correctly, the whole thing should be transparent to the Struts portlet app and that app should be easily portable to any other JSR-168 portal. p.s. I have no issues whatsoever with joining the Struts-dev mailing list, however, I think it might be in the best interest of all involved that we cross-post to both struts-dev and pluto-dev. I look forward to working with you. Regards, ** | Scott T Weaver | | [EMAIL PROTECTED]| | Apache Jetspeed Portal Project | | Apache Pluto Portlet Container | ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSR-168 and Struts
Pretty much the only dependency of struts-chain is a recent build of jakarta-commons-sandbox/chain. To fully build commons-chain, in addition to other commons jars, you need the porlet api jar, the servlet jar, and the latest jsf jar from the sun web services pack 1.3 I believe. However, you should be able to build commons-chain with one of these jars missing if you don't need their related chain classes. Currently, struts-chain implements most of Struts functionality in the form of small commands, strung together by chain-config.xml. For any commands that would have a use outside servlets, there exist abstract classes in org.apache.struts.chain in the form of Abstract*.java which perform all possible tasks without accessing servlet apis. The abstract commands are implemented in o.a.s.c.servlet by servlet specific commands which handle all direct servlet contact. To make struts-chain work with the portlet api, a new package will be created, o.a.s.c.portlet, which will contain implementations of the abstract classes in o.a.s.chain. These commands will take the context, cast it into a PortletContext (I believe that's the name), and access portlet apis directly just as the servlet commands did. These commands, particularly the api dependent ones, are very short and should be very easy to port. Of course Struts in a portlet context will use a different chain-config.xml with commands pointing to the porlet implementations rather than the servlet ones, but it should pretty much be the same structure and behavior. I'm new to struts-chain, so hopefully this is an accurate description of the current state of struts-chain and how the portlet api will be supported. Don On Wed, 29 Oct 2003, Mete Kural wrote: Hello Struts and Pluto developers, There was a thread about developing JSR-168 support into Struts 2.0 in the pluto-dev list and we thought it might be best to continue this thread on both lists, pluto-dev and struts-dev synchronously. Below is the last email in the thread send by Scott Weaver to the pluto-dev list. Please reply all so that your emails will go to both groups. Thanks, Mete Scott's message: -- Original Message -- From: Weaver, Scott [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Wed, 29 Oct 2003 15:33:03 -0500 Hi Martin, -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 29, 2003 3:16 PM To: '[EMAIL PROTECTED]' Subject: RE: Pluto and Struts On Wed, 29 Oct 2003, Weaver, Scott wrote: Maybe it's just me, but I tried to build the contrib stuff in the CVS for struts a while back as I wanted to start taking a look at. However, I could never get it built. There were deps I had never heard of, nor did I know were to get them. If you could let me know what you're having problems with, I'll try to help you through getting it all built. The chances are that anything you haven't heard of comes from Jakarta Commons or the Commons Sandbox. (For example, 'chain' is currently in the sandbox.) I know most of the stuff in commons proper, I don't think that's were my issue lies. I am pretty sure it was chain that I couldn't find and, at the time, I am not sure it was available, even within commons-sandbox. I don't remember the specific issues as this was around 2 months ago when I last tried. I was actually having the same problem but from the other side of the coin, as it were. I need to build 'chain' against the Portlet API, but I couldn't get Pluto to build, and couldn't figure out the deps for that. (BTW, since Pluto's build.xml depends on ant-contrib, '-projecthelp' doesn't work until that's configured, which is quite mysterious until you look at the build file itself. ;) Try build driver, there are custom ant tasks that get included when you call the build script. I really don't do much at all with Pluto portal implementation in that my focus, concerning Jetspeed, is the core Pluto container itself. That is were I spend most of my time in regards to Pluto. That being said, there should be no fork in development to support either Pluto Portal or Jetspeed 2. In fact, if we do this correctly, the whole thing should be transparent to the Struts portlet app and that app should be easily portable to any other JSR-168 portal. p.s. I have no issues whatsoever with joining the Struts-dev mailing list, however, I think it might be in the best interest of all involved that we cross-post to both struts-dev and pluto-dev. I look forward to working with you. Regards, ** | Scott T Weaver | | [EMAIL PROTECTED]| | Apache Jetspeed Portal Project | | Apache Pluto Portlet Container | ** - To unsubscribe, e-mail: [EMAIL PROTECTED
Re: JSR-168 and Struts
Don Brown wrote: Pretty much the only dependency of struts-chain is a recent build of jakarta-commons-sandbox/chain. To fully build commons-chain, in addition to other commons jars, you need the porlet api jar, the servlet jar, and the latest jsf jar from the sun web services pack 1.3 I believe. However, you should be able to build commons-chain with one of these jars missing if you don't need their related chain classes. Currently, struts-chain implements most of Struts functionality in the form of small commands, strung together by chain-config.xml. For any commands that would have a use outside servlets, there exist abstract classes in org.apache.struts.chain in the form of Abstract*.java which perform all possible tasks without accessing servlet apis. The abstract commands are implemented in o.a.s.c.servlet by servlet specific commands which handle all direct servlet contact. To make struts-chain work with the portlet api, a new package will be created, o.a.s.c.portlet, which will contain implementations of the abstract classes in o.a.s.chain. These commands will take the context, cast it into a PortletContext (I believe that's the name), and access portlet apis directly just as the servlet commands did. These commands, particularly the api dependent ones, are very short and should be very easy to port. Of course Struts in a portlet context will use a different chain-config.xml with commands pointing to the porlet implementations rather than the servlet ones, but it should pretty much be the same structure and behavior. All of the above will be needed, but there's a couple of additional wrinkles to the portlet environment that are going to be interesting: * Portlet doesn't let you do a RequestDispatcher.forward(), which is the normal way that Struts passes final control to the JSP or other resource that renders the response. I suspect we can deal with this by using RequestDispatcher.include() instead. * Portlet divides the lifetime of a request into two phases (processAction and render) -- in a Struts world, that roughly corresponds to everything before the processForwardConfig() call and the processForwardConfig() itself. I suspect this is probably best modelled as two separate chains (but both executing on the same Context instance, so stuff accumulated during processAction is available during rendering) but haven't thought it all the way through yet. I'm new to struts-chain, so hopefully this is an accurate description of the current state of struts-chain and how the portlet api will be supported. Don Craig On Wed, 29 Oct 2003, Mete Kural wrote: Hello Struts and Pluto developers, There was a thread about developing JSR-168 support into Struts 2.0 in the pluto-dev list and we thought it might be best to continue this thread on both lists, pluto-dev and struts-dev synchronously. Below is the last email in the thread send by Scott Weaver to the pluto-dev list. Please reply all so that your emails will go to both groups. Thanks, Mete Scott's message: -- Original Message -- From: Weaver, Scott [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Wed, 29 Oct 2003 15:33:03 -0500 Hi Martin, -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 29, 2003 3:16 PM To: '[EMAIL PROTECTED]' Subject: RE: Pluto and Struts On Wed, 29 Oct 2003, Weaver, Scott wrote: Maybe it's just me, but I tried to build the contrib stuff in the CVS for struts a while back as I wanted to start taking a look at. However, I could never get it built. There were deps I had never heard of, nor did I know were to get them. If you could let me know what you're having problems with, I'll try to help you through getting it all built. The chances are that anything you haven't heard of comes from Jakarta Commons or the Commons Sandbox. (For example, 'chain' is currently in the sandbox.) I know most of the stuff in commons proper, I don't think that's were my issue lies. I am pretty sure it was chain that I couldn't find and, at the time, I am not sure it was available, even within commons-sandbox. I don't remember the specific issues as this was around 2 months ago when I last tried. I was actually having the same problem but from the other side of the coin, as it were. I need to build 'chain' against the Portlet API, but I couldn't get Pluto to build, and couldn't figure out the deps for that. (BTW, since Pluto's build.xml depends on ant-contrib, '-projecthelp' doesn't work until that's configured, which is quite mysterious until you look at the build file itself. ;) Try build driver, there are custom ant tasks that get included when you call the build script. I really don't do much at all with Pluto portal implementation in that my focus, concerning Jetspeed, is the core Pluto container itself. That is were I spend most of my time in regards to Pluto. That being said
JSR 168 and Struts
I apologize if anyone has already asked this question, but I searched the board and didn't see it. Also, I tried the user forum first, but figured maybe this was more appropriate. JSR 168 has the following line in it (Section PLT.16.3): Servlets and JSPs included from portlets should not use the servlet RequestDispatcher forward method as its behavior may be non-deterministic. I am no expert on Struts, although I have used it quite a bit. It seems that if I wanted to wrap my Struts app in a Portlet and access various actions through the PortletRequestDispatcher (the most logical approach), I would run afoul of this warning. Lacking an implementation to test my hypothesis (*$# IBM legal department), I am unsure whether this actually fails or not. My gut instinct is that it probably wouldn't, but that it may not be reliable across implementations of servlet and portlet containers. I wanted to get some thoughts from the Struts community about this possible issue. Also, I wanted to know what the impact would be of using RequestDispatcher's include method instead? Or at least providing the facility to portlet developers? I apologize if I have wrongly assumed anything in my question. This is my best estimate based on what I have read. Thanks, Clay Richardson W. Clay Richardson Adjunct Professor of Computer Science Northern Virginia Graduate Center Virginia Polytechnic Institute and State University Oh, and how is education supposed to make me feel smarter? Besides, every time I learn something new, it pushes some old stuff out of my brain. Remember when I took that home wine-making course and I forgot how to drive? - Homer J. Simpson
RE: JSR 168 and Struts
Regarding: Lacking an implementation to test my hypothesis (*$# IBM legal department), I am unsure whether this actually fails or not. My gut instinct is that it probably wouldn't, but that it may not be reliable across implementations of servlet and portlet containers. Jaco Portal Server is a Java portal server which is compliant with the Portlet Specification (JSR-168). http://pharos.inria.fr/Java/display.jsp?id=c_14701 I have a client that is mixing Portlets and Struts. I am not an expert on Portlets. They did a lot of research on the best ways to mix the two technologies (white papers, prototypes, etc.). Rick Hightower Chief Technology Officer Trivera Technologies http://www.triveratech.com 520 290 6855 (Phone) 520 977 8605 (Mobile) -Original Message- From: Clay Richardson [mailto:[EMAIL PROTECTED] Sent: Thursday, August 28, 2003 9:05 PM To: [EMAIL PROTECTED] Subject: JSR 168 and Struts I apologize if anyone has already asked this question, but I searched the board and didn't see it. Also, I tried the user forum first, but figured maybe this was more appropriate. JSR 168 has the following line in it (Section PLT.16.3): Servlets and JSPs included from portlets should not use the servlet RequestDispatcher forward method as its behavior may be non-deterministic. I am no expert on Struts, although I have used it quite a bit. It seems that if I wanted to wrap my Struts app in a Portlet and access various actions through the PortletRequestDispatcher (the most logical approach), I would run afoul of this warning. Lacking an implementation to test my hypothesis (*$# IBM legal department), I am unsure whether this actually fails or not. My gut instinct is that it probably wouldn't, but that it may not be reliable across implementations of servlet and portlet containers. I wanted to get some thoughts from the Struts community about this possible issue. Also, I wanted to know what the impact would be of using RequestDispatcher's include method instead? Or at least providing the facility to portlet developers? I apologize if I have wrongly assumed anything in my question. This is my best estimate based on what I have read. Thanks, Clay Richardson W. Clay Richardson Adjunct Professor of Computer Science Northern Virginia Graduate Center Virginia Polytechnic Institute and State University Oh, and how is education supposed to make me feel smarter? Besides, every time I learn something new, it pushes some old stuff out of my brain. Remember when I took that home wine-making course and I forgot how to drive? - Homer J. Simpson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSR 168 and Struts
Clay Richardson wrote: I apologize if anyone has already asked this question, but I searched the board and didn't see it. Also, I tried the user forum first, but figured maybe this was more appropriate. JSR 168 has the following line in it (Section PLT.16.3): Servlets and JSPs included from portlets should not use the servlet RequestDispatcher forward method as its behavior may be non-deterministic. Yes, this is one of my concern as well and did not response to this question in user group since i have not put enough time in it. It seems to me that Struts needs to be refactoring to be MVC for portlets since portlets can delegate the creation of content to servlet and JSP via PortletRequestDispatcher. If there is a proper hook then Tiles can still be an intelligent assembling part of the view. Craig is the best guy to iron these issues. BaTien DBGROUPS I am no expert on Struts, although I have used it quite a bit. It seems that if I wanted to wrap my Struts app in a Portlet and access various actions through the PortletRequestDispatcher (the most logical approach), I would run afoul of this warning. Lacking an implementation to test my hypothesis (*$# IBM legal department), I am unsure whether this actually fails or not. My gut instinct is that it probably wouldn't, but that it may not be reliable across implementations of servlet and portlet containers. I wanted to get some thoughts from the Struts community about this possible issue. Also, I wanted to know what the impact would be of using RequestDispatcher's include method instead? Or at least providing the facility to portlet developers? I apologize if I have wrongly assumed anything in my question. This is my best estimate based on what I have read. Thanks, Clay Richardson W. Clay Richardson Adjunct Professor of Computer Science Northern Virginia Graduate Center Virginia Polytechnic Institute and State University Oh, and how is education supposed to make me feel smarter? Besides, every time I learn something new, it pushes some old stuff out of my brain. Remember when I took that home wine-making course and I forgot how to drive? - Homer J. Simpson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
