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:26:38 GMT
The link I provided in my previous response to the new features of the
Struts Bridge 0.2 wasn't correct (although relevant, it describes additional
enhancements I made after the upgrade to 0.2).

This is the correct link to the first announcement for Struts Bridge 0.2:
   http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22&msgNo=19886

Ate Douma wrote:
> 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
> 
> 
> 
> 
> 


---------------------------------------------------------------------
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