Hello Jonathan, I just wanted to confirm the behavior of your portlets. So when you navigate between links the pages are always presented as they were right. For e.g. if you went to link1 and did some actions and that resulted in another result page. You navigate to link2 and come back to link1 are you presented with the first page or the result page? Thanks for your time, Regards, Archana
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, October 24, 2005 3:47 AM To: [email protected] Subject: RE: REQUEST PROBLEM in JSR 168 portlets > Thanks for the info Jonathan. I appreciate the response. > > I'm new to the whole JSR168 spec and therefore am discovering stuff as > I go along. If you can bear with me and answer some of these questions > then it will help me proceed better: > > 1) Is this library under some license? Is there a license agreement? > Because before I explore anything further I need to verify the terms of > the license (Company rules!!!:-(). For e.g Jetspeed is under the Apache > license. There is no licence and changes to source are allowed, contact Mechelle Osmond for clarification. > > 2) I just read the library and it seems that certain modifications have > to be done to the "doView" method (So that I can make the Render action > behave differently). As you know this method resides within the > struts-bridges library. I'm by the way using Jetspeet 1.6 with fusion. > I did not see any mechanism of pulling out the strutsPortletAction > class to override the doView method. Is there a way I can do that? > I created my struts portlet from the example in Jetspeed2, so am using the execute method. You have to compile the latest struts bridges source so the javax.portlet.reqeust is available. > 3) This question is about session sharing. Since I have a struts webapp > that is a JSR168 portlet within Jetspeed using this library I can pass > along attributes of my choice to the JSR 168 portlet from the Jetspeed > webapp session RIGHT? Also does this library do some sort of session > matching? i.e. if the Jetspeed session ends does it also help > invalidating the JSR168 portlet webapps' session. For this I guess I > will have to read the MessageStore stuff that is specified in the > library. I'm going to go and dig further into that doc...but since you > have already used it if you can just give me some guidance that will be > great. Not sure about session invalidating. If you require some sample code, let me know and I can send a zip file to you. > > Thanks for your time and patience in advance. > Regards, > Archana > > -----Original Message----- > From: Jonathan Hawkins [mailto:[EMAIL PROTECTED] > Sent: Saturday, October 22, 2005 2:08 AM > To: Jetspeed Users List > Subject: Re: REQUEST PROBLEM in JSR 168 portlets > > Take a look at > http://www.doc.ic.ac.uk/~mo197/portlets/portlet_messaging/ > > Just used this myself to set the source of an iFrame in one portlet > from the struts action within another ortlet. > > Hope that helps > > Jon > > > Jacek Wi¶licki wrote: > >> Wiadomosc od Archana Turaga z 2005-10-21 23:55 brzmiala: >> >>> Thanks for the response. Well the difference here is that I have the >>> same portlet showing up for create/update/delete. So the distinction >>> is done in the portlet.xml (Snippet is as below). So a menu link is >>> associated with that page with specific parameters. The menu is >>> rendered within the Jetspeed scope but the link is to a JSR168 >>> portlet which is an external webapp. Unless I do something like when >>> the link is clicked I somehow pass the attribute along as to what was >>> clicked...then based on that the jsp can show up in the relevant >>> mode. WELL THE BIG QUESTION IS WHERE CAN I SET THIS ATTRIBUTE? What >>> you said is more in the JSR168 session context Right? Do let me know >>> if there is any additional information that is needed? And thanks >>> once again for the response. >> >> As far as I understand, the only problem is passing some attribute >> between different web aplications (within the same container), right? >> I don't know much about other servlet containers, but with Tomcat you >> could set the "crossContext" attribute for either application context >> to "true" and then setup the parameter (identified e.g. by the HTTP >> session id) in the other servlet context (another webapp), like this: >> //your application context: >> <HTTPServlet>.getServletContext().getContext(<String:other app context >> name>).setAttribute(<String>, <Object>); >> //other application context >> <HTTPServlet>.getServletContext().getAttribute(<String>); >> >> The above code can be applied from within a servlet, you should modify >> it to execute from a portlet, i.e. get a servlet context from a >> portlet context. I am not sure if a PortletContext object could by >> fully functional as a ServletContext object, however if such a >> solution fails, use an intermediate redirection servlet for setting >> the other context attributes. >> >> I do hope that it's what you meant. >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > This e-mail transmission may contain information that is proprietary, > privileged and/or confidential and is intended exclusively for the > person(s) to whom it is addressed. Any use, copying, retention or > disclosure by any person other than the intended recipient or the > intended recipient's designees is strictly prohibited. If you are the > intended recipient, you must treat the information in confidence and in > accordance with all laws related to the privacy and confidentiality of > such information. If you are not the intended recipient or their > designee, please notify the sender immediately by return e-mail and > delete all copies of this email, including all attachments. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are the intended recipient, you must treat the information in confidence and in accordance with all laws related to the privacy and confidentiality of such information. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies of this email, including all attachments. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
