Thanks a lot ATE !!! I'll try what you advise. Things are a bit difficult for me since I did not write the initial application...
I just have 1 comment about the Guess number portlet. See below. > See comments below > > Xavier Lawrence wrote: >> Hi all, >> >> I would appreciate any help on the following problem. It is holding me >> for >> now several days, and I am getting completely lost. >> >> I have a struts portlet which uses a filter. The SvcIFilter call has to >> be >> the first on the way in and the last on the way out. It is used to >> open/close Connections to a database. >> >> * We assume that any SvcI object must remain open until after the jsp >> * has done its stuff, i.e. after the action returns but before we >> finally >> * deliver the response. This filter allows us to implant a callback >> object >> * which has a close method which will be called when the request >> returns. >> >> I also have a second filter, which is a badic XSLT filter. >> >> The stand-alone struts application works fine, with the following >> configuration: >> >> <filter-mapping> >> <filter-name>SvcI Filter</filter-name> >> <url-pattern>/*</url-pattern> >> </filter-mapping> >> >> <filter-mapping> >> <filter-name>XSLT Filter</filter-name> >> <url-pattern>/*</url-pattern> >> </filter-mapping> >> >> For the Portlet, I started getting into troubles because the close >> method >> of the SvcI filter was called more than once. That is, we have a strict >> open-close sequence which works fine in the stand alone application. >> Basically, open opens connection and close commits transactions and >> closes >> connections. I first tried to configure the web.xml file like this: >> >> <web-app xmlns="http://java.sun.com/xml/ns/j2ee"; >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >> xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee >> http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"; >> version="2.4"> >> . >> . >> . >> <filter-mapping> >> <filter-name>SvcI Filter</filter-name> >> <url-pattern>/*</url-pattern> >> <dispatcher>REQUEST</dispatcher> >> <dispatcher>FORWARD</dispatcher> >> <dispatcher>INCLUDE</dispatcher> >> </filter-mapping> >> >> <filter-mapping> >> <filter-name>XSLT Filter</filter-name> >> <url-pattern>/*</url-pattern> >> <dispatcher>REQUEST</dispatcher> >> <dispatcher>FORWARD</dispatcher> >> <dispatcher>INCLUDE</dispatcher> >> </filter-mapping> >> >> Then I tried this: (change in the url-patttern) >> >> <filter-mapping> >> <filter-name>SvcI Filter</filter-name> >> <url-pattern>*.do</url-pattern> >> <dispatcher>REQUEST</dispatcher> >> <dispatcher>FORWARD</dispatcher> >> <dispatcher>INCLUDE</dispatcher> >> </filter-mapping> >> >> <filter-mapping> >> <filter-name>XSLT Filter</filter-name> >> <url-pattern>*.do</url-pattern> >> <dispatcher>REQUEST</dispatcher> >> <dispatcher>FORWARD</dispatcher> >> <dispatcher>INCLUDE</dispatcher> >> </filter-mapping> >> >> The last configuration gave better results (I could get up to the >> initial display of the portlet), but any click on a link (invoking a >> struts action) gave Exceptions because the close method of the filter >> was >> executed more than once. I also noticed that everything relied on the >> INCLUDE method of the dispatcher, (REQUEST and FORWARD don't seem to >> have >> any effect). If I don't put INCLUDE the filter is not called on the way >> out. So I have a situation where with some config the filter is called >> too >> often and the other not often enough :( > Jetspeed-2 delegates the processing of PortletRequests to portlets using > the RequestDispatcher include method only. > > Once you enter your Struts Portlet application the Struts Bridge (0.1 or > 0.2) > will process the request mapped by dispatching to the Struts > PortletServlet. > Your SvcI Filter will thus be activated at least two times already if you > map it to /*. > > Now, Struts action processing normally results in a forward or include > of a JSP for rendering. This means, the RequestDispatcher include will > be called again. In your initial filter-mapping (on /*) this would trigger > the > filter once more with your dispatcher methods mapping (this will probably > lead > to similar problems in your non-portlet application I think). > Your second attempt using the /*.do url-pattern thus is much better as the > the > initial dispatch from the Portal to your Portlet Application and the > dispatch from Struts to the jsp won't trigger your filter anymore. > > The problems you are now still experiencing are most likely the result of > an > incorrect struts-config definition within a Portlet context. > When you have an action mapping which forwards to another action mapping > (called action chaining) you should take the following design issues in > mind: > - if the initial action mapping is targeted from an Action PortletURL > using > sp:form or the default from an sp:link or sp:rewrite tag in Struts > Bridge 0.1, > (see > http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgId=2087322 > for an explanation how this has changed in Struts Bridge 0.2) > *AND* your forward isn't defined as redirect="true", the Struts Bridge > will hold on to the original action mapping to be executed *again* > during the following RenderRequest! > This means that during the following RenderRequest a dispatch will > follow > to the original action url, as well as a dispatch to the forward action > url (which will be automatically be transformed to an include by the > Bridge), > resulting in (at least) two times triggering of your filter. > - if the initial action mapping is targeted from an Render PortletURL > (using > renderURL="true" on sp:link or sp:rewrite in Struts Bridge 0.1) the > *same* > thing will occurs during RenderRequest processing and even > redirect="true" > won't help you here (and you should have the same problem with your > non-portlet > version of the application if you have <dispatcher>INCLUDE</dispatcher> > in > the filter mapping). > > Solutions: > - in case your original action is targeted from an Action PorletURL use > redirect="true" > in your forward definition > - in case of chained render actions just don't do it: try to consolidate > the > actions into one and forward (type include) to the jsp from that. > - in case above isn't feasible or correct, you could maintain a invocation > counter as > request attribute in your filter and only do your initialization on > first invocation > and only cleanup when it goes down to zero again. > > I hope this will get you going. > >> >> A strange thing was that when I tried to launch the portlet, Jetspeed >> started to print out these lines, just after the XSLT filter was called: >> >> cheater: target value = 99 >> cheater: target value = 59 >> cheater: target value = 55 >> cheater: target value = 29 >> >> So what is going on ? It seems that the filter reloads the Number Guess >> portlet ??? Why would it do so ? > Totally unrelated. > > The Number Guess porlet is on the start page of Jetspeed-2 and writes out > a > few debug messages to the console. You can ignore these. > I guess you have your Portlet Application also defined on the start page > and > that is why you see the XSLT Filter being called as result of the same > (Portal) > request (if its before or after the Number Guess Portlet depends on the > order the > Poral Aggregator invokes the portlets). No, my portlet is invoked from another PSML page, that's why I found it strange that the Guess number portlet was logging debug messages. Any idea why a portlet in a separate portal page would make a portlet in another portal page reload ??? > > >> >> How should I configure the url-pattern so the SVCI filter gets called >> the >> firston the way in and the last on the way out ??? I repeat, the >> stand-alone struts application works fine, and I am a bit lost at the >> moment. >> >> Note that I am using the struts-bridge 0.1. > I advise to upgrade to the latest version in cvs. It gives you much easier > control over Action/Render PorletURL creation as well as many new > enhancements > like Struts-EL support, transparent taglib usage and the ability to deploy > your > application.war as web application and/or as portlet application at the > same time > (see above link for further information). > >> >> Thanks in advance for any help. >> >> Regards >> >> Xavier >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- -------------=[ xlawrence at jahia dot com ]=------------- Jahia : A collaborative source CMS and Portal Server www.jahia.org Community and product web site www.jahia.com Commercial services company www.collaborativesource.org Jahia's collaborative license --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
