portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: XSLT filter, Callback filter and Jetspeed-2
Date Wed, 26 Jan 2005 11:22:49 GMT
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/ReadMsg?listName=jetspeed-dev@jakarta.apache.org&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).


> 
> 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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message