You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Xavier Lawrence <xl...@jahia.com> on 2005/01/26 10:18:17 UTC
XSLT filter, Callback filter and Jetspeed-2
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 :(
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 ?
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.
Thanks in advance for any help.
Regards
Xavier
--
-------------=[ 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
Re: XSLT filter, Callback filter and Jetspeed-2
Posted by Ate Douma <at...@douma.nu>.
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
Re: XSLT filter, Callback filter and Jetspeed-2
Posted by Ate Douma <at...@douma.nu>.
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
Re: XSLT filter, Callback filter and Jetspeed-2
Posted by Xavier Lawrence <xl...@jahia.com>.
>
> <snip/>
>
>> 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.
>>
>
> I added in some extra log information and I noticed that probably the
> problem occured during the Struts forward.
>
> If I look at the logs. I have twice the same RequestURI (...do). The
> filter is called twice from the same RequestURI.
>
> What is though very strange, is that everything works fine to initialize
> the portlet. At load time, the portlet calles setup.do, which does some
> initialization and displays the main screen.
>
> Then whenever I click on a link (sp:link or sp:form) everthing goes fine
> till the rendering. At this point, it seems the filter is called twice in
> a row (same URI) and Exceptions occur at the second call.
>
> So my first page is not called from a Portlet URL (I just invoke setup.do,
> as init param in portlet.xml). If I put redirect true, the action is
> executed but the output is a white screen with no content...
>
> Could this be an issue of the bridge ?? I guess I have to use your third
> solution...
I tried not calling the close method at the second invocation of the
filter. No output is rendered. The portlet is blank white :(
>
>
>
> ---------------------------------------------------------------------
> 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
Re: XSLT filter, Callback filter and Jetspeed-2
Posted by Xavier Lawrence <xl...@jahia.com>.
<snip/>
> 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.
>
I added in some extra log information and I noticed that probably the
problem occured during the Struts forward.
If I look at the logs. I have twice the same RequestURI (...do). The
filter is called twice from the same RequestURI.
What is though very strange, is that everything works fine to initialize
the portlet. At load time, the portlet calles setup.do, which does some
initialization and displays the main screen.
Then whenever I click on a link (sp:link or sp:form) everthing goes fine
till the rendering. At this point, it seems the filter is called twice in
a row (same URI) and Exceptions occur at the second call.
So my first page is not called from a Portlet URL (I just invoke setup.do,
as init param in portlet.xml). If I put redirect true, the action is
executed but the output is a white screen with no content...
Could this be an issue of the bridge ?? I guess I have to use your third
solution...
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: XSLT filter, Callback filter and Jetspeed-2
Posted by Xavier Lawrence <xl...@jahia.com>.
<snip/>
>>>>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 ???
>>
> I don't know. and I can't reproduce that, I tested it out just a sec ago.
> If I start Tomcat and open my browser on:
> http://localhost:8080/jetspeed/portal/jpetstore.psml
> I don't get that message.
> Only when I access a page containing the NumberGuess portlet.
It must be something to do with my incorrect filter configuration: the
logs appeared straight after the XSLT filter was called, in the middle of
the other log messages...
Still, this is very strange...
--
-------------=[ 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
Re: XSLT filter, Callback filter and Jetspeed-2
Posted by Ate Douma <at...@douma.nu>.
Xavier Lawrence wrote:
> 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.
>
<snip/>
>>>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 ???
>
I don't know. and I can't reproduce that, I tested it out just a sec ago.
If I start Tomcat and open my browser on:
http://localhost:8080/jetspeed/portal/jpetstore.psml
I don't get that message.
Only when I access a page containing the NumberGuess portlet.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: XSLT filter, Callback filter and Jetspeed-2
Posted by Xavier Lawrence <xl...@jahia.com>.
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
Re: XSLT filter, Callback filter and Jetspeed-2
Posted by Ate Douma <at...@douma.nu>.
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