portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Lawrence" <xlawre...@jahia.com>
Subject Re: XSLT filter, Callback filter and Jetspeed-2
Date Wed, 26 Jan 2005 13:06:55 GMT
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/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).

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


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


Mime
View raw message