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:29:48 GMT
Again, a wrong link, sigh.

Forget about the previous correction, this is the real one (truly):
   http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22&msgNo=19866

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


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