Steve Ebersole wrote:

So my question is: What is the best way in Avalon to ensure that the above startContextScope() and endContextScope() methods get called at appropriate moments?

Well, these are not Avalon-methods, but application-specific methods, i.e. X:Forge itself manages that. If you want these methods to be called automatically, you could use your container's lifecycle methods.


> Also,
since the containing environment maybe multi-threaded (like an app server),
what is the best way to maintain a context-identifier correalation to a
given client?

The way X:Forge does it: look at the getContextId() method in RequestContext.


> I guess maybe what I was looking for is the concept of a
Front-Controller from the MVC world or the RequestProcessor concept JBoss
used to have.  Basically something which allows me perform pre-processing
(and hopefully post-processing also) on each incoming request.

X:Forge solves that by defining a custom context that extends RequestContext. For examples see the XForgeC1URLContext or XForgeC2URLContext and the XForgeC1Processor and XForgeC2Processor. This shows how to integrate X:Forge into Cocoon1 or Cocoon2. Your app could do something similar.


For Pre- and PostProcessing X:Forge provides the ContextEventListener interface, maybe that model would also work for your app.

Ulrich



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to