You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Thorsten Scherler <sc...@gmail.com> on 2011/08/12 21:08:38 UTC
Reuse of pipelines in java
Hi all,
I am migrating a StAX development from a customer to c3 StAX, since the
resulting code will be much more generic and understandable.
In my case I need to process all files from different folders, parse
them and invoke a second pipeline from the main pipe.
Meaning I have one principal pipeline which I need to repeat x times.
I started to create the pipeline and it works very nice, however I
encounter some downsides with reusing the pipe.
I found that you can execute a java based pipe exactly one time. There
is no such method to reset the pipe. My plan was to inject the pipeline
in my main code and then configure it on the Fly (reusing the same pipe
on different files).
Further there is as well no way to dynamically change the different
components once added to the pipe.
I mean
Pipeline<StAXPipelineComponent> pipeStAX = new
NonCachingPipeline<StAXPipelineComponent>();
pipeStAX.addComponent(new XMLGenerator(input));
...
pipeStAX.setup(System.out);
pipeStAX.execute();
Now my question is how people feel about:
a) Making java based pipes resettable pipeStAX.reset()
b) Adding a method like pipeStAX.getComonponet(int i) to retrieve the
component x in position i.
salu2
--
Thorsten Scherler <thorsten.at.apache.org>
codeBusters S.L. - web based systems
<consulting, training and solutions>
http://www.codebusters.es/
Re: Reuse of pipelines in java
Posted by Thorsten Scherler <sc...@gmail.com>.
On Thu, 2011-08-18 at 11:39 +0200, Thorsten Scherler wrote:
> On Tue, 2011-08-16 at 22:45 +0200, Sylvain Wallez wrote:
...
> >
> > Please read: I suggested to clone them, so that there is no need for
> > them nor their components to be thread safe. You create a "master"
> > pipeline that is never executed and then deep-clone it every time it
> > needs to be processed.
>
> Actually that sounds very interesting for NonCaching pipes, however the
> main problem ATM for me is that I cannot execute a pipeline two times.
In in the end I did the clone approach due to the limitation that I was
not able to reuse the same pipe. So I created:
public class SummaryPipe extends
NonCachingPipeline<StAXPipelineComponent> implements Cloneable{
...
public Object clone() throws CloneNotSupportedException{
...
}
The pipe is a pre-setup pipeline wich I then configure via my custom
public void setup(Myargs args,...){
//prepare components with args
this.addComponent(generator);
this.addComponent(transformer);
this.addComponent(serializer);
this.setup(output);
and in my business code I do
clone = (SummaryPipe) pipe.clone();
clone.setup(Myargs args,...);
clone.execute();
>
> If that is a limitation of the pipes or a bug I do not know, but reading
> Steven answer makes me think it is a bug.
Actually somebody with more knowledge on the pipeline API may comment on
this.
salu2
--
Thorsten Scherler <thorsten.at.apache.org>
codeBusters S.L. - web based systems
<consulting, training and solutions>
http://www.codebusters.es/
Re: Reuse of pipelines in java
Posted by Thorsten Scherler <sc...@gmail.com>.
On Tue, 2011-08-16 at 22:45 +0200, Sylvain Wallez wrote:
> Le 16/08/11 09:25, Steven Dolg a écrit :
> > Am 14.08.2011 14:18, schrieb Sylvain Wallez:
> >> Le 12/08/11 21:08, Thorsten Scherler a écrit :
> >>> Hi all,
> >>>
> >>> I am migrating a StAX development from a customer to c3 StAX, since the
> >>> resulting code will be much more generic and understandable.
> >>>
> >>> In my case I need to process all files from different folders, parse
> >>> them and invoke a second pipeline from the main pipe.
> >>>
> >>> Meaning I have one principal pipeline which I need to repeat x times.
> >>> I started to create the pipeline and it works very nice, however I
> >>> encounter some downsides with reusing the pipe.
> >>>
> >>> I found that you can execute a java based pipe exactly one time. There
> >>> is no such method to reset the pipe. My plan was to inject the pipeline
> >>> in my main code and then configure it on the Fly (reusing the same pipe
> >>> on different files).
> >>>
> >>> Further there is as well no way to dynamically change the different
> >>> components once added to the pipe.
> >>>
> >>> I mean
> >>>
> >>> Pipeline<StAXPipelineComponent> pipeStAX = new
> >>> NonCachingPipeline<StAXPipelineComponent>();
> >>> pipeStAX.addComponent(new XMLGenerator(input));
> >>> ...
> >>> pipeStAX.setup(System.out);
> >>> pipeStAX.execute();
> >>>
> >>> Now my question is how people feel about:
> >>> a) Making java based pipes resettable pipeStAX.reset()
> >>> b) Adding a method like pipeStAX.getComonponet(int i) to retrieve the
> >>> component x in position i.
> >>
> >
> > a) What exactly should Pipeline.reset() do? (Besides calling reset on
> > each component)
> > And what should a component do during a reset?
> > I think components can be configured/set up as often as you like.
> >
> > b) If you construct the components directly, can't you keep a
> > reference to them and just call the setters/methods directly when needed?
> > I guess I don't understand why the pipeline is not reusable in your
> > case or what you need to reconfigure between the runs.
> > Maybe you need x different pipelines for x different configurations?
> >
> >
> >> Although reset() can allow pipeline reuse, it won't solve the problem
> >> when you have multiple concurrent threads that could benefit from
> >> reusing the pipeline.
> >>
> >> Cocoon 2.x had component pools to allow reuse in a multithreaded
> >> context while avoiding the big cost of reparsing the component's
> >> configuration, but this proved to have a significant overhead.
> >>
> >> A solution that wouldn't require much changes in the current API
> >> would be to require pipelines and pipeline components to be
> >> Cloneable, so that you could build a pipeline instance once at
> >> startup and then clone it each time you need to use it. That would
> >> require component writers to be careful about cloneability though.
> >>
> >> Sylvain
> >>
> >
> > Pipelines are not thread-safe!
>
> Please read: I suggested to clone them, so that there is no need for
> them nor their components to be thread safe. You create a "master"
> pipeline that is never executed and then deep-clone it every time it
> needs to be processed.
Actually that sounds very interesting for NonCaching pipes, however the
main problem ATM for me is that I cannot execute a pipeline two times.
If that is a limitation of the pipes or a bug I do not know, but reading
Steven answer makes me think it is a bug.
salu2
--
Thorsten Scherler <thorsten.at.apache.org>
codeBusters S.L. - web based systems
<consulting, training and solutions>
http://www.codebusters.es/
Re: Reuse of pipelines in java
Posted by Sylvain Wallez <sy...@apache.org>.
Le 16/08/11 09:25, Steven Dolg a écrit :
> Am 14.08.2011 14:18, schrieb Sylvain Wallez:
>> Le 12/08/11 21:08, Thorsten Scherler a écrit :
>>> Hi all,
>>>
>>> I am migrating a StAX development from a customer to c3 StAX, since the
>>> resulting code will be much more generic and understandable.
>>>
>>> In my case I need to process all files from different folders, parse
>>> them and invoke a second pipeline from the main pipe.
>>>
>>> Meaning I have one principal pipeline which I need to repeat x times.
>>> I started to create the pipeline and it works very nice, however I
>>> encounter some downsides with reusing the pipe.
>>>
>>> I found that you can execute a java based pipe exactly one time. There
>>> is no such method to reset the pipe. My plan was to inject the pipeline
>>> in my main code and then configure it on the Fly (reusing the same pipe
>>> on different files).
>>>
>>> Further there is as well no way to dynamically change the different
>>> components once added to the pipe.
>>>
>>> I mean
>>>
>>> Pipeline<StAXPipelineComponent> pipeStAX = new
>>> NonCachingPipeline<StAXPipelineComponent>();
>>> pipeStAX.addComponent(new XMLGenerator(input));
>>> ...
>>> pipeStAX.setup(System.out);
>>> pipeStAX.execute();
>>>
>>> Now my question is how people feel about:
>>> a) Making java based pipes resettable pipeStAX.reset()
>>> b) Adding a method like pipeStAX.getComonponet(int i) to retrieve the
>>> component x in position i.
>>
>
> a) What exactly should Pipeline.reset() do? (Besides calling reset on
> each component)
> And what should a component do during a reset?
> I think components can be configured/set up as often as you like.
>
> b) If you construct the components directly, can't you keep a
> reference to them and just call the setters/methods directly when needed?
> I guess I don't understand why the pipeline is not reusable in your
> case or what you need to reconfigure between the runs.
> Maybe you need x different pipelines for x different configurations?
>
>
>> Although reset() can allow pipeline reuse, it won't solve the problem
>> when you have multiple concurrent threads that could benefit from
>> reusing the pipeline.
>>
>> Cocoon 2.x had component pools to allow reuse in a multithreaded
>> context while avoiding the big cost of reparsing the component's
>> configuration, but this proved to have a significant overhead.
>>
>> A solution that wouldn't require much changes in the current API
>> would be to require pipelines and pipeline components to be
>> Cloneable, so that you could build a pipeline instance once at
>> startup and then clone it each time you need to use it. That would
>> require component writers to be careful about cloneability though.
>>
>> Sylvain
>>
>
> Pipelines are not thread-safe!
Please read: I suggested to clone them, so that there is no need for
them nor their components to be thread safe. You create a "master"
pipeline that is never executed and then deep-clone it every time it
needs to be processed.
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: Reuse of pipelines in java
Posted by Thorsten Scherler <sc...@gmail.com>.
On Wed, 2011-08-17 at 14:46 -0500, Peter Hunsberger wrote:
> [snip...]
>
> > Now everything is working fine for the first time I use the pipeline.
> > However the second time it is not working anymore. I am using
> > this.addEventToQueue(event) in the transformer to add the events to the
> > queue. However the second time I am calling the transformer I get
> > "org.apache.cocoon.pipeline.ProcessingException: Error during writing
> > output elements."
> >
> > Whiles debug I found that the summaryTransformer is adding correctly the
> > "StartDocument"/"EndDocument" however in the second call the
> > XMLSerializer is getting in initiatePullProcessing() as first event a
> > START_DOCUMENT (which is expected), however
> > resulting in
> > "javax.xml.stream.XMLStreamException: Can not output XML declaration,
> > after other output has already been done."
> >
> > I debugged summaryTransformer.setup(...) and I figured that
> > StAXConsumer consumer = this.getConsumer();
> > the first time is null, but the second time is the "old" consumer. Can
> > it be related?
> >
>
> Don't know about C3, but certainly in C2 that is an issue. Don't
> recall how to fix it but I think you are looking at the right issue.
> You've either got to clean up after you are done or reset things
> properly when you use it again. You've got a setup() method to work
> with so that seems the place to start, since adding a new finis() (or
> whatever) method to cleanup after you are done would obviously have
> much broader implications...
Actually I found the problem in my transformer. Since it was a migration
of an interdependent StAX component I forgot to change a throw clause in
one place where before it was controlled. Now it just had thrown the
above XMLStreamException in one document where a non fatal error had
occurred.
Thanks for your feedback.
salu2
--
Thorsten Scherler <thorsten.at.apache.org>
codeBusters S.L. - web based systems
<consulting, training and solutions>
http://www.codebusters.es/
Re: Reuse of pipelines in java
Posted by Peter Hunsberger <pe...@gmail.com>.
[snip...]
> Now everything is working fine for the first time I use the pipeline.
> However the second time it is not working anymore. I am using
> this.addEventToQueue(event) in the transformer to add the events to the
> queue. However the second time I am calling the transformer I get
> "org.apache.cocoon.pipeline.ProcessingException: Error during writing
> output elements."
>
> Whiles debug I found that the summaryTransformer is adding correctly the
> "StartDocument"/"EndDocument" however in the second call the
> XMLSerializer is getting in initiatePullProcessing() as first event a
> START_DOCUMENT (which is expected), however
> resulting in
> "javax.xml.stream.XMLStreamException: Can not output XML declaration,
> after other output has already been done."
>
> I debugged summaryTransformer.setup(...) and I figured that
> StAXConsumer consumer = this.getConsumer();
> the first time is null, but the second time is the "old" consumer. Can
> it be related?
>
Don't know about C3, but certainly in C2 that is an issue. Don't
recall how to fix it but I think you are looking at the right issue.
You've either got to clean up after you are done or reset things
properly when you use it again. You've got a setup() method to work
with so that seems the place to start, since adding a new finis() (or
whatever) method to cleanup after you are done would obviously have
much broader implications...
Re: Reuse of pipelines in java
Posted by Thorsten Scherler <sc...@gmail.com>.
On Tue, 2011-08-16 at 10:08 +0200, Thorsten Scherler wrote:
> On Tue, 2011-08-16 at 09:25 +0200, Steven Dolg wrote:
> > Am 14.08.2011 14:18, schrieb Sylvain Wallez:
> > >....
> > >> I mean
> > >>
> > >> Pipeline<StAXPipelineComponent> pipeStAX = new
> > >> NonCachingPipeline<StAXPipelineComponent>();
> > >> pipeStAX.addComponent(new XMLGenerator(input));
> > >> ...
> > >> pipeStAX.setup(System.out);
> > >> pipeStAX.execute();
> > >>
> > >> Now my question is how people feel about:
> > >> a) Making java based pipes resettable pipeStAX.reset()
> > >> b) Adding a method like pipeStAX.getComonponet(int i) to retrieve the
> > >> component x in position i.
> > >
> >
> > a) What exactly should Pipeline.reset() do? (Besides calling reset on
> > each component)
> > And what should a component do during a reset?
> > I think components can be configured/set up as often as you like.
> >
> > b) If you construct the components directly, can't you keep a reference
> > to them and just call the setters/methods directly when needed?
>
> Yes, but only if I can execute the pipe x times.
>
> > I guess I don't understand why the pipeline is not reusable in your case
> > or what you need to reconfigure between the runs.
> > Maybe you need x different pipelines for x different configurations?
>
> If you see above example you cannot do
>
> // first time works fine
> pipeStAX.setup(System.out);
> pipeStAX.execute();
> // the next time it is doing nothing
> pipeStAX.setup(System.out);
> pipeStAX.execute();
>
> The second call of execute() will not do anything. The reset() or
> redeploy() would refactor the pipeline to be usable again.
>
> Then I can configure the different pipes again tu use it x times.
Actually I did some more testing and it is quite curious (and annoying):
I am creating now a new pipeline due to the limitation I mentioned early
that you cannot execute two times the same pipe.
While I am doing this I am using:
@Autowired
private SummaryStAXTransformer summaryTransformer;
...
private void invokePipe(FileInputStream input,
FileOutputStream output) throws Exception {
...
// prepare summary transformer
summaryTransformer.setup(bean,dispoNumber);
Pipeline<StAXPipelineComponent> pipeStAX = new
NonCachingPipeline<StAXPipelineComponent>();
pipeStAX.addComponent(generator);
pipeStAX.addComponent(new
SAXForStAXPipelineWrapper(saxSummaryCleaner));
pipeStAX.addComponent(summaryTransformer);
pipeStAX.addComponent(new XMLSerializer());
pipeStAX.setup(output);
pipeStAX.execute();
}
Now everything is working fine for the first time I use the pipeline.
However the second time it is not working anymore. I am using
this.addEventToQueue(event) in the transformer to add the events to the
queue. However the second time I am calling the transformer I get
"org.apache.cocoon.pipeline.ProcessingException: Error during writing
output elements."
Whiles debug I found that the summaryTransformer is adding correctly the
"StartDocument"/"EndDocument" however in the second call the
XMLSerializer is getting in initiatePullProcessing() as first event a
START_DOCUMENT (which is expected), however
resulting in
"javax.xml.stream.XMLStreamException: Can not output XML declaration,
after other output has already been done."
I debugged summaryTransformer.setup(...) and I figured that
StAXConsumer consumer = this.getConsumer();
the first time is null, but the second time is the "old" consumer. Can
it be related?
Any help appreciated.
salu2
--
Thorsten Scherler <thorsten.at.apache.org>
codeBusters S.L. - web based systems
<consulting, training and solutions>
http://www.codebusters.es/
Re: Reuse of pipelines in java
Posted by Thorsten Scherler <sc...@gmail.com>.
On Tue, 2011-08-16 at 09:25 +0200, Steven Dolg wrote:
> Am 14.08.2011 14:18, schrieb Sylvain Wallez:
> > Le 12/08/11 21:08, Thorsten Scherler a écrit :
> >> Hi all,
> >>
> >> I am migrating a StAX development from a customer to c3 StAX, since the
> >> resulting code will be much more generic and understandable.
> >>
> >> In my case I need to process all files from different folders, parse
> >> them and invoke a second pipeline from the main pipe.
> >>
> >> Meaning I have one principal pipeline which I need to repeat x times.
> >> I started to create the pipeline and it works very nice, however I
> >> encounter some downsides with reusing the pipe.
> >>
> >> I found that you can execute a java based pipe exactly one time. There
> >> is no such method to reset the pipe. My plan was to inject the pipeline
> >> in my main code and then configure it on the Fly (reusing the same pipe
> >> on different files).
> >>
> >> Further there is as well no way to dynamically change the different
> >> components once added to the pipe.
> >>
> >> I mean
> >>
> >> Pipeline<StAXPipelineComponent> pipeStAX = new
> >> NonCachingPipeline<StAXPipelineComponent>();
> >> pipeStAX.addComponent(new XMLGenerator(input));
> >> ...
> >> pipeStAX.setup(System.out);
> >> pipeStAX.execute();
> >>
> >> Now my question is how people feel about:
> >> a) Making java based pipes resettable pipeStAX.reset()
> >> b) Adding a method like pipeStAX.getComonponet(int i) to retrieve the
> >> component x in position i.
> >
>
> a) What exactly should Pipeline.reset() do? (Besides calling reset on
> each component)
> And what should a component do during a reset?
> I think components can be configured/set up as often as you like.
>
> b) If you construct the components directly, can't you keep a reference
> to them and just call the setters/methods directly when needed?
Yes, but only if I can execute the pipe x times.
> I guess I don't understand why the pipeline is not reusable in your case
> or what you need to reconfigure between the runs.
> Maybe you need x different pipelines for x different configurations?
If you see above example you cannot do
// first time works fine
pipeStAX.setup(System.out);
pipeStAX.execute();
// the next time it is doing nothing
pipeStAX.setup(System.out);
pipeStAX.execute();
The second call of execute() will not do anything. The reset() or
redeploy() would refactor the pipeline to be usable again.
Then I can configure the different pipes again tu use it x times.
>
> > Although reset() can allow pipeline reuse, it won't solve the problem
> > when you have multiple concurrent threads that could benefit from
> > reusing the pipeline.
> >
> > Cocoon 2.x had component pools to allow reuse in a multithreaded
> > context while avoiding the big cost of reparsing the component's
> > configuration, but this proved to have a significant overhead.
> >
> > A solution that wouldn't require much changes in the current API would
> > be to require pipelines and pipeline components to be Cloneable, so
> > that you could build a pipeline instance once at startup and then
> > clone it each time you need to use it. That would require component
> > writers to be careful about cloneability though.
> >
> > Sylvain
> >
>
> Pipelines are not thread-safe!
> I think the effort required to make them thread-safe is far too great
> given the (IMO negligible) benefits.
> Since everyone can create their own pipeline components there is no way
> to guarantee that it will work correctly all the time.
> (I don't think "should work in multi-threaded environments if the
> component developer didn't make a mistake" should appear in any
> documentation)
>
> In the case mentioned above (direct Pipeline API calls) component
> instances are created by the user's code, so the responsibility of doing
> that efficiently and correctly is the user's and not ours, IMO.
> Something like a component factory / provider is currently well outside
> the Pipeline API's responsibilities - actually it's part of the sitemap
> - and I think it should stay that way.
> I see the Pipeline API as a small library that provides some helpful
> classes, which you use in a very controlled and precise manner (like
> commons-lang, commons-io, etc.)
> Not like a full execution environment with it's own flow of control (you
> get that when you use cocoon-servlet with sitemaps).
>
> If you really need/want more efficient construction of components, give
> this task to someone who specializes in that.
> Make a Spring context and use prototype beans or even create an object
> pool, or use some other dependency injection container you like.
> I don't think we should try to compete with those frameworks on their
> home field.
I agree to not reinvent the wheel in that areas, maybe we can learn from
the thread "Springification" to implement this.
salu2
--
Thorsten Scherler <thorsten.at.apache.org>
codeBusters S.L. - web based systems
<consulting, training and solutions>
http://www.codebusters.es/
Re: Reuse of pipelines in java
Posted by Steven Dolg <st...@indoqa.com>.
Am 14.08.2011 14:18, schrieb Sylvain Wallez:
> Le 12/08/11 21:08, Thorsten Scherler a écrit :
>> Hi all,
>>
>> I am migrating a StAX development from a customer to c3 StAX, since the
>> resulting code will be much more generic and understandable.
>>
>> In my case I need to process all files from different folders, parse
>> them and invoke a second pipeline from the main pipe.
>>
>> Meaning I have one principal pipeline which I need to repeat x times.
>> I started to create the pipeline and it works very nice, however I
>> encounter some downsides with reusing the pipe.
>>
>> I found that you can execute a java based pipe exactly one time. There
>> is no such method to reset the pipe. My plan was to inject the pipeline
>> in my main code and then configure it on the Fly (reusing the same pipe
>> on different files).
>>
>> Further there is as well no way to dynamically change the different
>> components once added to the pipe.
>>
>> I mean
>>
>> Pipeline<StAXPipelineComponent> pipeStAX = new
>> NonCachingPipeline<StAXPipelineComponent>();
>> pipeStAX.addComponent(new XMLGenerator(input));
>> ...
>> pipeStAX.setup(System.out);
>> pipeStAX.execute();
>>
>> Now my question is how people feel about:
>> a) Making java based pipes resettable pipeStAX.reset()
>> b) Adding a method like pipeStAX.getComonponet(int i) to retrieve the
>> component x in position i.
>
a) What exactly should Pipeline.reset() do? (Besides calling reset on
each component)
And what should a component do during a reset?
I think components can be configured/set up as often as you like.
b) If you construct the components directly, can't you keep a reference
to them and just call the setters/methods directly when needed?
I guess I don't understand why the pipeline is not reusable in your case
or what you need to reconfigure between the runs.
Maybe you need x different pipelines for x different configurations?
> Although reset() can allow pipeline reuse, it won't solve the problem
> when you have multiple concurrent threads that could benefit from
> reusing the pipeline.
>
> Cocoon 2.x had component pools to allow reuse in a multithreaded
> context while avoiding the big cost of reparsing the component's
> configuration, but this proved to have a significant overhead.
>
> A solution that wouldn't require much changes in the current API would
> be to require pipelines and pipeline components to be Cloneable, so
> that you could build a pipeline instance once at startup and then
> clone it each time you need to use it. That would require component
> writers to be careful about cloneability though.
>
> Sylvain
>
Pipelines are not thread-safe!
I think the effort required to make them thread-safe is far too great
given the (IMO negligible) benefits.
Since everyone can create their own pipeline components there is no way
to guarantee that it will work correctly all the time.
(I don't think "should work in multi-threaded environments if the
component developer didn't make a mistake" should appear in any
documentation)
In the case mentioned above (direct Pipeline API calls) component
instances are created by the user's code, so the responsibility of doing
that efficiently and correctly is the user's and not ours, IMO.
Something like a component factory / provider is currently well outside
the Pipeline API's responsibilities - actually it's part of the sitemap
- and I think it should stay that way.
I see the Pipeline API as a small library that provides some helpful
classes, which you use in a very controlled and precise manner (like
commons-lang, commons-io, etc.)
Not like a full execution environment with it's own flow of control (you
get that when you use cocoon-servlet with sitemaps).
If you really need/want more efficient construction of components, give
this task to someone who specializes in that.
Make a Spring context and use prototype beans or even create an object
pool, or use some other dependency injection container you like.
I don't think we should try to compete with those frameworks on their
home field.
Steven
Re: Reuse of pipelines in java
Posted by Sylvain Wallez <sy...@apache.org>.
Le 12/08/11 21:08, Thorsten Scherler a écrit :
> Hi all,
>
> I am migrating a StAX development from a customer to c3 StAX, since the
> resulting code will be much more generic and understandable.
>
> In my case I need to process all files from different folders, parse
> them and invoke a second pipeline from the main pipe.
>
> Meaning I have one principal pipeline which I need to repeat x times.
> I started to create the pipeline and it works very nice, however I
> encounter some downsides with reusing the pipe.
>
> I found that you can execute a java based pipe exactly one time. There
> is no such method to reset the pipe. My plan was to inject the pipeline
> in my main code and then configure it on the Fly (reusing the same pipe
> on different files).
>
> Further there is as well no way to dynamically change the different
> components once added to the pipe.
>
> I mean
>
> Pipeline<StAXPipelineComponent> pipeStAX = new
> NonCachingPipeline<StAXPipelineComponent>();
> pipeStAX.addComponent(new XMLGenerator(input));
> ...
> pipeStAX.setup(System.out);
> pipeStAX.execute();
>
> Now my question is how people feel about:
> a) Making java based pipes resettable pipeStAX.reset()
> b) Adding a method like pipeStAX.getComonponet(int i) to retrieve the
> component x in position i.
Although reset() can allow pipeline reuse, it won't solve the problem
when you have multiple concurrent threads that could benefit from
reusing the pipeline.
Cocoon 2.x had component pools to allow reuse in a multithreaded context
while avoiding the big cost of reparsing the component's configuration,
but this proved to have a significant overhead.
A solution that wouldn't require much changes in the current API would
be to require pipelines and pipeline components to be Cloneable, so that
you could build a pipeline instance once at startup and then clone it
each time you need to use it. That would require component writers to be
careful about cloneability though.
Sylvain
--
Sylvain Wallez - http://bluxte.net