I agree, the pipeline model should support generic divert valves, which open
new subpipelines at any level of hierarchy. Divert valves could have
customized mappers selecting the pipeline to open based on any information
in RunData, not just URL.
As the pipeline model is the base architecture for request processing in
Turbine 3, its functionality should be implemented separately from the
Turbine servlet and let the servlet only pass initilization data to the
model during servlet instantiation and then RunData to the servlet's
configured root pipeline. Most operations still performed by the Turbine
servlet, like session validation, login/logout actions, module target
selection, etc. could be performed by the customizable valves of the root
pipeline instead.
The configuration of the pipeline model should have at least two levels, XML
for describing the initial structure but direct bean getters/setters for
run-time changes. We've also found scripts (BSF) to provide much more
freedom both in initial and run-time configuration compared to XML. With
some helper classes and declarative naming of classes and methods the
configuration scripts can be keps at least as readable as XML files when
performing complicated configurations.
The valve interface should have open/close methods in addition to those
defined in Catalina. This would make it possible to temporarily disable some
valves from the pipeline without changing the pipeline configuration.
-- Ilkka
----- Original Message -----
From: "Dave Bryson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, July 21, 2001 07:24
Subject: Re: Pipes, Valves, and Subapps
> On Thursday 19 July 2001 10:58 pm, you wrote:
> > > 2. How can these subapps be mapped to their pipelines?
> > >
> > > <my thought> Again this could be specified in the XML.
> > > The Turbine Servlet could use something like a "PipeManager".
> > > The PipeManager could load it's mappings in init() and be keyed by
> > > URL "context" as mentioned above. Each Pipeline would map to a
> > > subapp. Each Pipeline would contain it's own module loader and
> > > an aggregation of valves. Again *all* of this being configurable
in
> > > XML.
> >
> > I think more like an AppManager not a PipeManager. The pipeline used by
> > the application would be defined in an application descriptor. The
> > application descriptor would house all the app specific config info
> > and the pipeline definition would be contained within the app
descriptor.
>
> Then what to do with actions ( you kinda mention this in your notes )
> ...relating specifically to security? What if I want a single security
> policy ( action ) to govern all the subapps? I need a way to specify this
at
> the top of my configuration. Otherwise I'd need to duplicate this in each
> subapp configuration. Maybe a "root" app or pipeline that can perform
filters
> ( valves) on the request with nested apps.
>
> Something like this:
>
> <app pipeline="root" map="/">
> <valve name="accesscontrol"/>
> <app pipeline="subapp1" map="/subapp1">
> <valve>
> ....
> </app>
> <app pipeline="subapp2" map="/subapp2">
> <valve>
> ....
> </app>
> ....
> <valve name="postprocess"/>
> </app>
>
>
> Dave
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
