RE: Storing MaverickContext in request causing issues with portal processes

"Schnitzer, Jeff" <[email protected]>
Newsgroups gmane.comp.web.maverick.general,gmane.comp.web.sitemesh.general
Message-ID <[email protected]>
This was done to facilitate chaining maverick commands together, so one
command can forward to another and each one can take a shot at modifying
the model.  Here is the relevant discussion:

 

http://www.mail-archive.com/mav-user%40lists.sourceforge.net/msg00493.ht
ml

 

In what way does this break SiteMesh?  I'm open to discussion as to why
we should change back to the old behavior.

 

J2FF

 

-----Original Message-----
From: Eric Kreiser [mailto:[email protected]] 
Sent: Thursday, May 01, 2003 5:48 AM
To: Maverick-User (E-mail)
Cc: Opensymphony-Sitemesh (E-mail)
Subject: [Mav-user] Storing MaverickContext in request causing issues
with portal processes

 

I just tried to make the switch from version 2.1.1 to 2.1.2 and ran into
the following issue.

 

The direct issue is that I have a portal screen which uses Sitemesh to
pull in all the content configured to show to the user.  All the content
is rendered thru maverick controllers.  The problem now is that under
2.1.2 only the first controller called is rendered to completion, all
the rest, resulting in the XML being dumped to the screen.  The root of
the issue is the way org.infohazard.maverick.Dispatcher sets the
MaverickContext in a request attribute, and if present reuses it.  Since
the same request is used and passed along to each controller, the first
one sets the MaverickContext and the others use the context from the
first.

 

Exactly what situation was trying to be solved by this change.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.