|
> 1. support for multiple pipelines
You would register multiple pipelines as indvidual components within the root container. > 2. ability to select your pipeline in the http request -- no change > to that functionality. Reference the pipeline by the ket it is registered under in the root container. > 3. ability to have logic in pipeline, and have simple workflow caps > such as have a valve short-circuit the process as the ActionValve > does I am not proposing changing the currently funtionallity of the pipeline/valves at all. The actual classes would not change at all except for removing the need for Descriptor objects. > 4. continue the valve concept See number 3 > 5. Keep the pipeline concept. This is my concept and contribution to > J2. I feel its a core piece of the Jetspeed architecture, and don't > want to throw aside in the zealous pursuit of COP. Nowehere in my proposal did I ever mention removing the current pipeline/valve approach. It is the core of the way J2 works and I personally think is one of the things that makes J2 such an extensible piece of software. I just want to make configuring/assembling Jetspeed as much of a "one stop shopping experience" as possible. By using Pico to assemble the pipeline, we can capitalize on all the pico has to offer. I think the ability to hotswap a valve or even an entire pipeline, real-time is pretty damn kewl! > 1. support for multiple pipelines
> You would register multiple pipelines as indvidual components within the root container. There are currently 2 pipelines in J2. We need to continue support of these 2 pipelines (and potentially more) > 2. ability to select your pipeline in the http request -- no change > to that functionality. > Reference the pipeline by the ket it is registered under in the root container. The JetspeedEngine currently does this. Sounds like an easy conversion > 3. ability to have logic in pipeline, and have simple workflow caps > such as have a valve short-circuit the process as the ActionValve > does > I am not proposing changing the currently funtionallity of the pipeline/valves at all. The > actual classes would not change at all except for removing the need for Descriptor objects. Cool. just making sure. I > 4. continue the valve concept See number 3 > 5. Keep the pipeline concept. This is my concept and contribution to > J2. I feel its a core piece of the Jetspeed architecture, and don't > want to throw aside in the zealous pursuit of COP. > Nowehere in my proposal did I ever mention removing the current pipeline/valve > >approach. It is the core of the way J2 works and I personally think is one of the things >that makes J2 such an extensible piece of software. I just want to make configuring/>assembling Jetspeed as much of a "one stop shopping experience" as possible. >By using Pico to assemble the pipeline, we can capitalize on all the pico has to offer. I >think the ability to hotswap a valve or even an entire pipeline, real-time is pretty damn >kewl! It does sound cool. Im fine with it. +1 > There are currently 2 pipelines in J2.
> We need to continue support of these 2 pipelines (and potentially > more) Shouldn't a problem to support n number of pipelines. While we are at it working on pipelines, I was wondering if we should extend their pattern to work on any kind of object, not just RequestContext objects.
If you look at the current implementation we use RequestContext objects as the context. What now if I wanted to use a pipeline for a specific operation, without providing a RequestContext object, but maybe just a Map ? I think it might be interesting to revise the Pipeline interface to change this : void invoke (RequestContext context) throws PipelineException; to : void invoke (Object context) throws PipelineException; We could then if needed create a RequestPipeline that would provide a wrapper method that casts the object into a RequestContext. The reason why I'm proposing this is that I had a need for a pipeline in another project, and I needed to provide something else than RequestContext. Anyway, it's just a proposal, but it might make the code a bit more generic (until we actually start using Java Generics which would probably be an even better solution :)). > What now if I wanted to use a pipeline for a specific operation, without providing a
> RequestContext object, but maybe just a Map ? What if RequestContext extended Map... > I think it might be interesting to revise the Pipeline interface to change this : > void invoke (RequestContext context) throws PipelineException; > to : > void invoke (Object context) throws PipelineException; > We could then if needed create a RequestPipeline that would provide a wrapper method > that casts the object into a RequestContext. I am very supportive of re-using J2 components in building other portals and systems (not just J2). With this refactoring, the pipeline will become a standalone component. +1 on this proposal, as long as we keep the casting to an absolute minimal. RequestContexnt extending Map would still require all the dependencies that RequestContext requires. So I am -1 one on that just because it keeps the pipeline to tightly bound to the jetspeed/portal/pluto apis.
I also feel that Object is to generic. Maybe an array of Objects, like an arg list instead of a map. Unfortunatley I have no good suggestions right now what we should be passing around within pipeline. What if the pipeline passed around a Map.
The pipeline would be changed from: invoke(RequestContext request) to invoke(Map map) and valves from: invoke(RequestContext request, ValveContext context) to invoke(Map request, ValveContext context) RequestContext would take a constructor with a Map, and delegate all getter setters to getting attributes out of the Map, requiring no changes to any components accessing RequestContext. My proposal was for passing an Object instead of a Map because Map have a tendency to be used as "dynamic" object structures, which make the code hard to read. Passing an object means that we could keep using the pipeline with RequestContext objects for J2, but also use the pipeline impl outside of J2.
Concretely what I am proposing is that : - Pipeline.java uses Object instead of RequestContext in it's interface - JetspeedPipeline only needs to change it's interface, the impl does *NOT* have to change, passing an RequestContext is perfectly acceptable since we are using Object. - Valve.java uses Object instead of RequestContext in it's interface - Valve implementations be simply modified to cast from Object to RequestContext. I know this cast is not perfect, but until we can use Java Generics I don't see a way around this. Again this is just a proposal I am coming forward with because I needed a pipeline in another project and I liked the one in J2, except for the RequestContext dependency.
Ate Douma made changes - 02/Apr/05 01:37 AM
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Task
Closed
Major
Move pipeline assembly out of XML and into jetspeed.groovy assembly
1. support for multiple pipelines
2. ability to select your pipeline in the http request -- no change to that functionality
3. ability to have logic in pipeline, and have simple workflow caps such as have a valve short-circuit the process as the ActionValve does
4. continue the valve concept
5. Keep the pipeline concept. This is my concept and contribution to J2. I feel its a core piece of the Jetspeed architecture, and don't want to throw aside in the zealous pursuit of COP.
Finally, XML configurations can be changed at runtime, and edited by UI tools.
Of course groovy scripts can be editing at runtime too. Im just weighing the advantages of one editing a script for workflow controls over using a UI Editor. IMO, I think editing a groovy script may be more appropriate for Jetspeed's main pipeline since the script can support any logic that groovy supports, flow control, conditional execution, makes for nice workflow but requires some programming knowledge.