Hello,
Vadim thank you for your advice. It helped me. I was busy some time and
had postponed this problem. Unfortunatelly it still remains.
I've found out that WildcardSessionAttributeMatcher (I'm using Cocoon
2.0.1) doesn't see session attributes changed or created before in the same
request by some xsp (I'm using aggregation of xsp and "cocoon://somepattern"
which includes branch based on sessionstate matcher).
It seems that objectModel are not up to date at the processing of
WildcardSessionAttributeMatcher.getMatchString method.
Is it a known problem?
I've tested it so: first, I call an aggregation which first part is an
xsp setting and printing session attribute "isChanged" and second part is
call to a pipeline via cocoon protocol wich returns some data if
sessionstate matcher recognize that "isChanged" is "yes", otherwise calls
xsp which prints a value of the session attribute "isChanged":
<map:match pattern="read_filtered_results">
<map:match type="sessionstate" pattern="yes">
<map:parameter name="attribute-name" value="isChanged"/>
<map:generate src="cocoon://read_query_results"/>
<map:serialize type="xml"/>
</map:match>
<map:generate src="cocoon://check_idlist_1.xsp"/>
<map:serialize type="xml"/>
</map:match>
Despite the first xsp in aggregation _always_ sets the session attribute
"isChanged" to "yes" or "no" (and first time it is "yes"), in the
sitemap.log for the first call I always see:
HttpProcessor[8080][4]/WildcardSessionAttributeMatcher: Session attribute
'isChanged' not set.
Though the second xsp (check_id_list_1.xsp), which is called in this
case, always prints correct value.
So the problem is an organizing of a branch in sitemap according to a
change of some session attribute calculated in xsp. Here "isChanged"
attribute is just a flag.
Thank you for any response.
Roman
Vadim Gritsenko wrote:
> Roman,
>
> Aggregation is being executed linearly, which means that first part is
> executed before second. If first part contains an XSP and that XSP is
> not cached, it could change session attribute which will be visible in
> the second part's XSP (if it is not cached)
>
> XSPs are not cacheable by default.
>
> PS Use System.outs or <log/> to see how it (doesn't) works.
>
> Vadim
>
> > From: KOZLOV Roman [mailto:[EMAIL PROTECTED]]
> >
> > Hi,
> >
> > Is it possible in Cocoon 2.01 to set session attribute within
> > aggregation so that the change would be in a first part (xsp) and next
> > part could use the new value of the changed attribute. It seems that
> the
> > new value is not available for the rest parts of aggregation within
> the
> > same request.
> > If it is true, then how is it possible to make a branch comparing a
> > request parameter's value with some session attribute's value?
> > In particular, I'd like to store some parameter as a session attribute
> > and if it is not changed then read query results stored as DOM in a
> > session before, otherwise update query results. My xsp part of
> > aggregation is the following:
> >
> > <?xml version="1.0" encoding="ISO-8859-1"?>
> > <xsp:page
> > language="java"
> > xmlns:xsp="http://apache.org/xsp";
> > xmlns:xsp-request="http://apache.org/xsp/request/2.0";
> > xmlns:session="http://apache.org/xsp/session/2.0";
> > xmlns:util="http://apache.org/xsp/util/2.0";
> > create-session="true">
> > <page>
> > <xsp:logic>
> > String idList = (String)<xsp-request:get-parameter name="idList"
> > default=""/>;
> > String idListOld = (String)<session:get-attribute name="idList"
> > default=""/>;
> > String isChanged = (idList.equals(idListOld))?"no":"yes";
> > </xsp:logic>
> > <session:set-attribute
> >
> name="idList"><xsp:logic><xsp:expr>idList</xsp:expr></xsp:logic></sessio
> n:set-
> > attribute>
> >
> > <session:set-attribute
> >
> name="isChanged"><xsp:logic><xsp:expr>isChanged</xsp:expr></xsp:logic></
> sessio
> > n:set-attribute>
> >
> >
> >
> <idList><xsp:logic><util:expr><xsp:expr>idList</xsp:expr></util:expr></x
> sp:log
> > ic></idList>
> >
> >
> >
> <isChanged><xsp:logic><util:expr><xsp:expr>isChanged</xsp:expr></util:ex
> pr></x
> > sp:logic></isChanged>
> >
> > </page>
> > </xsp:page>
> >
> > The second part of aggregation calls the following via cocoon://
> > protocol:
> >
> > <map:match pattern="read_filtered_results">
> > <map:match type="sessionstate" pattern="yes">
> > <map:parameter name="attribute-name" value="isChanged"/>
> > <!-- Update filtered result -->
> > <map:generate src="cocoon://read_query_results"/>
> > <map:serialize type="xml"/>
> > </map:match>
> > <!-- if idList is not changed try to read stored filtered result -->
> > <map:match type="sessionstate" pattern="**">
> > <map:parameter name="attribute-name" value="filtered_results"/>
> > <!-- Read filtered result if it was already stored -->
> > <map:generate src="data/null.xml"/>
> > <map:transform type="readDOMsession">
> > <map:parameter name="dom-name" value="filtered_results"/>
> > <map:parameter name="trigger-element" value="null"/>
> > <map:parameter name="position" value="in"/>
> > </map:transform>
> > <map:serialize type="xml"/>
> > </map:match>
> > <!-- Create filtered result if it was not stored before -->
> > <map:generate src="cocoon://read_query_results"/>
> > <map:serialize type="xml"/>
> > </map:match>
> >
> > So the problem is that after changing idList parameter I have to call
> > the aggregating pipeline twice (i.e. to make two requests from browser
> > with the same idList parameter) to get an updated query result.
> >
> > Thank you very much for any advice.
> > Roman
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail: <[EMAIL PROTECTED]>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
