On 7/20/01 2:47 AM, "Ilkka Priha" <[EMAIL PROTECTED]> wrote:
> 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.
That would be more flexible for sure.
> 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.
With the services being separated, what would you use the non-servlet
version of Turbine for? Turbine 3.0 itself will basically be a rendering
system only. Are thinking that a non-servlet version of Turbine could
be used for something like a WAP gateway or something along those lines?
> 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.
I definitely agree that scripts would be good for application configuration,
but how do you this working with the pipelines?
> 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.
There is a ValveContext in Catalina that is used to change the flow through
the valves as passing through one valve may preclude the flow through
another. Catalina uses the ValveContext to divert flow through the
pipeline.
I will definitely be in a better position to talk about this in a couple
of days. I'm still trying to get to torque setup as a persistence layer
which talking about putting the db service code into torque so that torque
is a functional entity as itself. Torque and the db service work together
to provide persistence and I think the dbservice code should go into torque
so its fully functional and the db service would than become a wrapper
around torque. The other thing is decoupling the services, there are still
issues.
I would like to get these things cleaned up and than discuss how pooling
and caching should be utilized across turbine and fulcrum than clean all
that up and than talk about the additions like the pipeline design and
subapps.
> -- 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]
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
