You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@sundn.de> on 2001/02/14 10:49:48 UTC
[C2]: Patch for TraxTransformer
Hi,
attached is a patch for the TraxTransformer.
It simply renames the use-cache parameter to use-store.
As Giacomo suggested, we should call this storing and
not caching for a clear and simple naming of things.
Carsten
Re: [C2]: Patch for TraxTransformer
Posted by Paul Russell <pa...@luminas.co.uk>.
* Giacomo Pati (giacomo@apache.org) wrote :
> I'm in the middle of commiting some changes to make the sitemap able to use
> the newly created URLFactory class for loading classes outside the classpath.
> This was originally suggested to work (see
> xdocs/drafts/sitemap-working-draft.xmap).
Funky.
> Then the next issue is to make use of the URLFactory it in sitemap components
> itself either by the sitemap component itself or by the sitemap engine.
> Former will leave everything as it is, later will change all the interfaces
> from a String to an URL.
>
> What do you all think?
>
> Personally I'd like to change the interfaces because it would make the system
> consistent based on the draft.
Yep, I'd prefer that too. Good software design 101: If the method parameter
should be a URL, then force the issue by making it a URL, not a String.
--
Paul Russell Email: paul@luminas.co.uk
Technical Director Tel: +44 (0)20 8553 6622
Luminas Internet Applications Fax: +44 (0)870 28 47489
This is not an official statement or order. Web: www.luminas.co.uk
Re: [C2]: Patch for TraxTransformer
Posted by Giacomo Pati <gi...@apache.org>.
Thanks Carsten, will do soon.
I'm in the middle of commiting some changes to make the sitemap able to use
the newly created URLFactory class for loading classes outside the classpath.
This was originally suggested to work (see
xdocs/drafts/sitemap-working-draft.xmap).
It will be possible to use something like this:
<map:generator name="mygen"
src="file:///home/mystuff/java/MyGenerator.class"/>
Then the next issue is to make use of the URLFactory it in sitemap components
itself either by the sitemap component itself or by the sitemap engine.
Former will leave everything as it is, later will change all the interfaces
from a String to an URL.
What do you all think?
Personally I'd like to change the interfaces because it would make the system
consistent based on the draft.
Giacomo
Carsten Ziegeler wrote:
> > Hi,
>
> attached is a patch for the TraxTransformer.
>
> It simply renames the use-cache parameter to use-store.
> As Giacomo suggested, we should call this storing and
> not caching for a clear and simple naming of things.
>
> Carsten
----------------------------------------
Content-Type: application/x-zip-compressed; charset="iso-8859-1";
name="diff.zip"
Content-Transfer-Encoding: base64
Content-Description:
----------------------------------------
----------------------------------------
Content-Type: text/plain; charset="us-ascii"; name="Anhang: 2"
Content-Transfer-Encoding: 7bit
Content-Description:
----------------------------------------
Re: [Vote] Patch for CocoonServlet
Posted by Giacomo Pati <gi...@apache.org>.
Paul Russell wrote:
> Fellow Developers,
>
> * Carsten Ziegeler (cziegeler@sundn.de) wrote :
> > attached is a simple patch for the CocoonServlet.
> > It addes an own method for the creating of the Environment.
> > So changing the real class for the environment used is very easy.
>
> Carsten seems to be producing more patches than any of us can cope with,
> and from what I've seen of them, they appear to be of universally high
> quality. Therefore, I propose Carsten Ziegeler for commit access to the
> xml-cocoon CVS repository, before I suffer any more 'patch -p0 <diff.txt'
> related RSI. Votes & thoughts?
+1 he deserves it. I thought of it one or two days ago but forgot to start a
vote
Giacomo
Re: [Vote] Patch for CocoonServlet
Posted by Stefano Mazzocchi <st...@apache.org>.
Berin Loritsch wrote:
>
> Paul Russell wrote:
> >
> > Fellow Developers,
> >
> > * Carsten Ziegeler (cziegeler@sundn.de) wrote :
> > > attached is a simple patch for the CocoonServlet.
> > > It addes an own method for the creating of the Environment.
> > > So changing the real class for the environment used is very easy.
> >
> > Carsten seems to be producing more patches than any of us can cope with,
> > and from what I've seen of them, they appear to be of universally high
> > quality. Therefore, I propose Carsten Ziegeler for commit access to the
> > xml-cocoon CVS repository, before I suffer any more 'patch -p0 <diff.txt'
> > related RSI. Votes & thoughts?
>
> +1 from me!
+1 as well.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Re: [Vote] Patch for CocoonServlet
Posted by Berin Loritsch <bl...@apache.org>.
Paul Russell wrote:
>
> Fellow Developers,
>
> * Carsten Ziegeler (cziegeler@sundn.de) wrote :
> > attached is a simple patch for the CocoonServlet.
> > It addes an own method for the creating of the Environment.
> > So changing the real class for the environment used is very easy.
>
> Carsten seems to be producing more patches than any of us can cope with,
> and from what I've seen of them, they appear to be of universally high
> quality. Therefore, I propose Carsten Ziegeler for commit access to the
> xml-cocoon CVS repository, before I suffer any more 'patch -p0 <diff.txt'
> related RSI. Votes & thoughts?
+1 from me!
Re: [Vote] Patch for CocoonServlet
Posted by Brian Behlendorf <br...@apache.org>.
Sorry about the delay; account created, password sent, cvs karma granted
to xml-cocoon.
Brian
On Thu, 15 Feb 2001, Giacomo Pati wrote:
> I think we've got enough +1 to open the account.
>
> Brian, could you please create a Cocoon commiter account for Carten Ziegeler
> and grant him enough karam?
>
> Thanks in advance
>
> Giacomo
>
> Paul Russell wrote:
> > Fellow Developers,
> >
> > * Carsten Ziegeler (cziegeler@sundn.de) wrote :
> > > attached is a simple patch for the CocoonServlet.
> > > It addes an own method for the creating of the Environment.
> > > So changing the real class for the environment used is very easy.
> >
> > Carsten seems to be producing more patches than any of us can cope with,
> > and from what I've seen of them, they appear to be of universally high
> > quality. Therefore, I propose Carsten Ziegeler for commit access to the
> > xml-cocoon CVS repository, before I suffer any more 'patch -p0 <diff.txt'
> > related RSI. Votes & thoughts?
> >
> >
> > P.
>
Re: [Vote] Patch for CocoonServlet
Posted by Giacomo Pati <gi...@apache.org>.
I think we've got enough +1 to open the account.
Brian, could you please create a Cocoon commiter account for Carten Ziegeler
and grant him enough karam?
Thanks in advance
Giacomo
Paul Russell wrote:
> Fellow Developers,
>
> * Carsten Ziegeler (cziegeler@sundn.de) wrote :
> > attached is a simple patch for the CocoonServlet.
> > It addes an own method for the creating of the Environment.
> > So changing the real class for the environment used is very easy.
>
> Carsten seems to be producing more patches than any of us can cope with,
> and from what I've seen of them, they appear to be of universally high
> quality. Therefore, I propose Carsten Ziegeler for commit access to the
> xml-cocoon CVS repository, before I suffer any more 'patch -p0 <diff.txt'
> related RSI. Votes & thoughts?
>
>
> P.
AW: [Vote] Patch for CocoonServlet
Posted by Matthew Langham <ml...@sundn.de>.
>>
* Carsten Ziegeler (cziegeler@sundn.de) wrote :
> attached is a simple patch for the CocoonServlet.
> It addes an own method for the creating of the Environment.
> So changing the real class for the environment used is very easy.
Carsten seems to be producing more patches than any of us can cope with,
and from what I've seen of them, they appear to be of universally high
quality. Therefore, I propose Carsten Ziegeler for commit access to the
xml-cocoon CVS repository, before I suffer any more 'patch -p0 <diff.txt'
related RSI. Votes & thoughts?
<<
+1 (but then I'm biased).
On the other hand it might get to his head....so.... (just joking Carsten
:-)).
Matthew Langham
Techincal Director
Open Source Group
s&n AG
--
Open Source Group sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel: +49-5251-1581-30 [mlangham@sundn.de - http://www.sundn.de]
=================================================================
-----Ursprungliche Nachricht-----
Von: Paul Russell [mailto:paulr@hydrogen.internal.luminas.co.uk]Im
Auftrag von Paul Russell
Gesendet: Mittwoch, 14. Februar 2001 11:31
An: cocoon-dev@xml.apache.org
Betreff: [Vote] Patch for CocoonServlet
Fellow Developers,
* Carsten Ziegeler (cziegeler@sundn.de) wrote :
> attached is a simple patch for the CocoonServlet.
> It addes an own method for the creating of the Environment.
> So changing the real class for the environment used is very easy.
Carsten seems to be producing more patches than any of us can cope with,
and from what I've seen of them, they appear to be of universally high
quality. Therefore, I propose Carsten Ziegeler for commit access to the
xml-cocoon CVS repository, before I suffer any more 'patch -p0 <diff.txt'
related RSI. Votes & thoughts?
P.
--
Paul Russell Email: paul@luminas.co.uk
Technical Director Tel: +44 (0)20 8553 6622
Luminas Internet Applications Fax: +44 (0)870 28 47489
This is not an official statement or order. Web: www.luminas.co.uk
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: Strange problems with concurrent access of Xalan-2.0.0
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Scott Boag wrote:
>> Any guesses from the Xalan Team?
>
>I've been off sick with the flu, so I'm a bit behind this thread. As far
>as we know the Templates objects are safe among concurent threads. The
>easiest way to reproduce threading problems may be to use a multi-processor
>system.
>
>> A thread might finish first, resetting the template and the other
>> thread still try to use it.
>
>What do you mean by "resetting the template"?
After looking for some time into the Xalan-J 2.0.0 code, I think that the
reset() method on the TransformerImpl is invoked, so resetting the m_resultTreeHandler
to null. So "resetting the template" was wrong, sorry for this wrong hint.
>> java.lang.NullPointerException
>> at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:145)
>The value that is failing here is obtained from the Transformer. As Myriam
>asked, is there any chance a Transformer is being used across threads?
What we suspect after our research is, that the TransformerImpl (or some other object
below the TransformerImpl) is creating a thread which hasn't finished its work
when the main thread finishes - which means leaves the transform(Source source) method.
The finally clause of the transform method invokes the reset() method.
Is it possible, that in some circumstances the main thread does not wait for his child
threads to finish.
We use the Xalan-J inside the Cocoon2 servlet environment. It seams that the problem only
arises when frames are used, so upto 4 threads are created simultaniously.
For each Cocoon2-Thread a new Transformer instance is created.
Although I indicated in the first mail that the problem only occurs with Xalan-Stylesheet-Storing
turned on in Cocoon2, this is not true. We had some rare cases where the problem arise without
storing turned on.
Carsten
AW: Strange problems with concurrent access of Xalan-2.0.0
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Scott Boag wrote:
>> Any guesses from the Xalan Team?
>
>I've been off sick with the flu, so I'm a bit behind this thread. As far
>as we know the Templates objects are safe among concurent threads. The
>easiest way to reproduce threading problems may be to use a multi-processor
>system.
>
>> A thread might finish first, resetting the template and the other
>> thread still try to use it.
>
>What do you mean by "resetting the template"?
After looking for some time into the Xalan-J 2.0.0 code, I think that the
reset() method on the TransformerImpl is invoked, so resetting the m_resultTreeHandler
to null. So "resetting the template" was wrong, sorry for this wrong hint.
>> java.lang.NullPointerException
>> at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:145)
>The value that is failing here is obtained from the Transformer. As Myriam
>asked, is there any chance a Transformer is being used across threads?
What we suspect after our research is, that the TransformerImpl (or some other object
below the TransformerImpl) is creating a thread which hasn't finished its work
when the main thread finishes - which means leaves the transform(Source source) method.
The finally clause of the transform method invokes the reset() method.
Is it possible, that in some circumstances the main thread does not wait for his child
threads to finish.
We use the Xalan-J inside the Cocoon2 servlet environment. It seams that the problem only
arises when frames are used, so upto 4 threads are created simultaniously.
For each Cocoon2-Thread a new Transformer instance is created.
Although I indicated in the first mail that the problem only occurs with Xalan-Stylesheet-Storing
turned on in Cocoon2, this is not true. We had some rare cases where the problem arise without
storing turned on.
Carsten
Re: Strange problems with concurrent access of Xalan-2.0.0
Posted by Berin Loritsch <bl...@apache.org>.
Stefano Mazzocchi wrote:
>
> Berin Loritsch wrote:
>
> > I ran accross this abnormality when I stress tested Cocoon using
> > Apache JRun.
>
> There is no such thing as "Apache JRun" :)
>
> You mean "Apache JMeter", right?
>
> I'm picky because the Allaire guys might be offended by this :) or some
> apache members as well :)
Yup, that's what I meant. I was discussing alternative J2EE architectures
to IBM WebSphere with my bosses--so my brain didn't completely switch
gears.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Strange problems with concurrent access of Xalan-2.0.0
Posted by Stefano Mazzocchi <st...@apache.org>.
Berin Loritsch wrote:
> I ran accross this abnormality when I stress tested Cocoon using
> Apache JRun.
There is no such thing as "Apache JRun" :)
You mean "Apache JMeter", right?
I'm picky because the Allaire guys might be offended by this :) or some
apache members as well :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Re: Strange problems with concurrent access of Xalan-2.0.0
Posted by Berin Loritsch <bl...@apache.org>.
Giacomo Pati wrote:
>
> Berin Loritsch wrote:
> > Giacomo Pati wrote:
> > > Carsten Ziegeler wrote:
> > > > Hello,
> > > >
> > > > since the switch from the Xalan2D07 to the Xalan-2.0.0 version in
> > > > Cocoon2 we get sometimes very strange problems.
> > > >
> > > > We are using frames which all four use the same stylesheets. The xalan
> > > > is driven by the cocoon pipeline.
> > > >
> > > > If we turn on the storing (formerly known as caching) of the
> > > > TraxTransformer we get from time to time a NPE in one frame. Sometimes
> > > > its even worse: One frame contains part of the content of another frame
> > > > and the other frame is totally broken. Reloading the whole page brings
> > > > up all frames correctly.
> > > >
> > > > However if we turn off the storing we never did see this phenomenen. So
> > > > we assume that this problems have something to do with the storing.
> > > >
> > > > The store stores the Templates. Is it possible, that this problem can
> > > > occure, when several threads use the same Template (as delivered by the
> > > > store). A thread might finish first, resetting the template and the
> > > > other thread still try to use it.
> > >
> > > A Template IIRC should be thread safe but the actual transformation is
> > > done by a Transformer object which can be obtained from the Template (or
> > > is it the other way around?).
> > >
> > > Wait a second I'll try to do a stress test using ab....
> > >
> > > ab -c 20 -n 200 http://localhost:8080/cocoon/welcome
> > >
> > > No, I can't reproduce the failure. All runs well here.
> > >
> > > Any guesses from the Xalan Team?
> > >
> > > Giacomo
> >
> > I ran accross this abnormality when I stress tested Cocoon using
> > Apache JRun. Please note, that I had to have the requests comming
> > _very_ quickly to to actually get it to show up.
>
> What is Apache JRun? The ab command I've use above uses 20 concurrent threads
> pounding a total of 200 requests on to a Tomcat 3.2.1 and the latest C2. Did
> you add more concurrent requests?
>
> Giacomo
Ooops, I meant Apache JMeter--I have been discussing alternative Application
Servers with people at my job, My brain farted on me.
I had 20 threads pounding every 300 ms +/- 300 ms with a gaussian dispersion
on the deviation. I actually got this running JMeter with 12 concurrent
threads every 1000 ms +/- 1000 ms with gaussian dispersion on deviation.
Note, that it was only once or twice. I didn't think too much of it because
the webapp we are designing won't be seeing that much activity. Note the
12 thread scenario corresponds to 1,036,800 page requests a day spread
evenly throughout the day.
I ran the test for ~20-30 seconds. It happened early in the test, but it
didn't happen again after that.
Re: Strange problems with concurrent access of Xalan-2.0.0
Posted by Giacomo Pati <gi...@apache.org>.
Berin Loritsch wrote:
> Giacomo Pati wrote:
> > Carsten Ziegeler wrote:
> > > Hello,
> > >
> > > since the switch from the Xalan2D07 to the Xalan-2.0.0 version in
> > > Cocoon2 we get sometimes very strange problems.
> > >
> > > We are using frames which all four use the same stylesheets. The xalan
> > > is driven by the cocoon pipeline.
> > >
> > > If we turn on the storing (formerly known as caching) of the
> > > TraxTransformer we get from time to time a NPE in one frame. Sometimes
> > > its even worse: One frame contains part of the content of another frame
> > > and the other frame is totally broken. Reloading the whole page brings
> > > up all frames correctly.
> > >
> > > However if we turn off the storing we never did see this phenomenen. So
> > > we assume that this problems have something to do with the storing.
> > >
> > > The store stores the Templates. Is it possible, that this problem can
> > > occure, when several threads use the same Template (as delivered by the
> > > store). A thread might finish first, resetting the template and the
> > > other thread still try to use it.
> >
> > A Template IIRC should be thread safe but the actual transformation is
> > done by a Transformer object which can be obtained from the Template (or
> > is it the other way around?).
> >
> > Wait a second I'll try to do a stress test using ab....
> >
> > ab -c 20 -n 200 http://localhost:8080/cocoon/welcome
> >
> > No, I can't reproduce the failure. All runs well here.
> >
> > Any guesses from the Xalan Team?
> >
> > Giacomo
>
> I ran accross this abnormality when I stress tested Cocoon using
> Apache JRun. Please note, that I had to have the requests comming
> _very_ quickly to to actually get it to show up.
What is Apache JRun? The ab command I've use above uses 20 concurrent threads
pounding a total of 200 requests on to a Tomcat 3.2.1 and the latest C2. Did
you add more concurrent requests?
Giacomo
>
> > > This is only a guess - has someone else had these problems?
> > >
> > > As they only occur occasionally it his very hard to reproduce them...
> > >
> > > Perhaps someone of you has a guess whats going on.
> > >
> > > The exception we get is the following:
> > >
> > > java.lang.NullPointerException
> > > at
> > > org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:145) at
> > > org.apache.xalan.templates.ElemForEach.transformSelectedNodes(ElemFor
> > > Each.java:495)
> > > at
> > > org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTempla
> > > tes.java:193)
> > > at
> > > org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Tr
> > > ansformerImpl.java:2154)
> > > at
> > > org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Tr
> > > ansformerImpl.java:2097)
> > > at
> > > org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(Tran
> > > sformerImpl.java:2029)
> > > at
> > > org.apache.xalan.transformer.TransformerImpl.transformNode(Transforme
> > > rImpl.java:1189)
> > > at
> > > org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java
> > >
> > > :2894)
> > >
> > > This indicates that the ResultTreeHandler is not available (set to
> > > null).
> > >
> > > As most times everything is working fine it must have to do with the
> > > parallel usage of the stylesheets.
> > >
> > >
> > >
> > > Carsten Ziegeler
> > >
> > > Open Source Group sunShine - Lighting up e:Business
> > > ================================================================
> > > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > > www.sundn.de mailto:cziegeler@sundn.de
> > > ================================================================
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Strange problems with concurrent access of Xalan-2.0.0
Posted by Berin Loritsch <bl...@apache.org>.
Giacomo Pati wrote:
>
> Carsten Ziegeler wrote:
> > Hello,
> >
> > since the switch from the Xalan2D07 to the Xalan-2.0.0 version in Cocoon2
> > we get sometimes very strange problems.
> >
> > We are using frames which all four use the same stylesheets. The xalan is
> > driven by the cocoon pipeline.
> >
> > If we turn on the storing (formerly known as caching) of the
> > TraxTransformer we get from time to time a NPE in one frame. Sometimes its
> > even worse: One frame contains part of the content of another frame and the
> > other frame is totally broken. Reloading the whole page brings up all
> > frames correctly.
> >
> > However if we turn off the storing we never did see this phenomenen. So we
> > assume that this problems have something to do with the storing.
> >
> > The store stores the Templates. Is it possible, that this problem can
> > occure, when several threads use the same Template (as delivered by the
> > store). A thread might finish first, resetting the template and the other
> > thread still try to use it.
>
> A Template IIRC should be thread safe but the actual transformation is done
> by a Transformer object which can be obtained from the Template (or is it the
> other way around?).
>
> Wait a second I'll try to do a stress test using ab....
>
> ab -c 20 -n 200 http://localhost:8080/cocoon/welcome
>
> No, I can't reproduce the failure. All runs well here.
>
> Any guesses from the Xalan Team?
>
> Giacomo
I ran accross this abnormality when I stress tested Cocoon using
Apache JRun. Please note, that I had to have the requests comming
_very_ quickly to to actually get it to show up.
>
> >
> > This is only a guess - has someone else had these problems?
> >
> > As they only occur occasionally it his very hard to reproduce them...
> >
> > Perhaps someone of you has a guess whats going on.
> >
> > The exception we get is the following:
> >
> > java.lang.NullPointerException
> > at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:145)
> > at
> > org.apache.xalan.templates.ElemForEach.transformSelectedNodes(ElemFor
> > Each.java:495)
> > at
> > org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTempla
> > tes.java:193)
> > at
> > org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Tr
> > ansformerImpl.java:2154)
> > at
> > org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Tr
> > ansformerImpl.java:2097)
> > at
> > org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(Tran
> > sformerImpl.java:2029)
> > at
> > org.apache.xalan.transformer.TransformerImpl.transformNode(Transforme
> > rImpl.java:1189)
> > at
> > org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java
> >
> > :2894)
> >
> > This indicates that the ResultTreeHandler is not available (set to null).
> >
> > As most times everything is working fine it must have to do with the
> > parallel usage of the stylesheets.
> >
> >
> >
> > Carsten Ziegeler
> >
> > Open Source Group sunShine - Lighting up e:Business
> > ================================================================
> > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > www.sundn.de mailto:cziegeler@sundn.de
> > ================================================================
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Strange problems with concurrent access of Xalan-2.0.0
Posted by Giacomo Pati <gi...@apache.org>.
Davanum Srinivas wrote:
> Giacomo,
>
> > Wait a second I'll try to do a stress test using ab....
> > ab -c 20 -n 200 http://localhost:8080/cocoon/welcome
>
> Where can i download this utility from?
It is normally included in your Apache httpd dist (or get it from cvs)
Giacomo
>
> Thanks,
> dims
>
> --- Giacomo Pati <gi...@apache.org> wrote:
> > Carsten Ziegeler wrote:
> > > Hello,
> > >
> > > since the switch from the Xalan2D07 to the Xalan-2.0.0 version in
> > > Cocoon2 we get sometimes very strange problems.
> > >
> > > We are using frames which all four use the same stylesheets. The xalan
> > > is driven by the cocoon pipeline.
> > >
> > > If we turn on the storing (formerly known as caching) of the
> > > TraxTransformer we get from time to time a NPE in one frame. Sometimes
> > > its even worse: One frame contains part of the content of another frame
> > > and the other frame is totally broken. Reloading the whole page brings
> > > up all frames correctly.
> > >
> > > However if we turn off the storing we never did see this phenomenen. So
> > > we assume that this problems have something to do with the storing.
> > >
> > > The store stores the Templates. Is it possible, that this problem can
> > > occure, when several threads use the same Template (as delivered by the
> > > store). A thread might finish first, resetting the template and the
> > > other thread still try to use it.
> >
> > A Template IIRC should be thread safe but the actual transformation is
> > done by a Transformer object which can be obtained from the Template (or
> > is it the other way around?).
> >
> > Wait a second I'll try to do a stress test using ab....
> >
> > ab -c 20 -n 200 http://localhost:8080/cocoon/welcome
> >
> > No, I can't reproduce the failure. All runs well here.
> >
> > Any guesses from the Xalan Team?
> >
> > Giacomo
> >
> > > This is only a guess - has someone else had these problems?
> > >
> > > As they only occur occasionally it his very hard to reproduce them...
> > >
> > > Perhaps someone of you has a guess whats going on.
> > >
> > > The exception we get is the following:
> > >
> > > java.lang.NullPointerException
> > > at
> > > org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:145) at
> > > org.apache.xalan.templates.ElemForEach.transformSelectedNodes(ElemFor
> > > Each.java:495)
> > > at
> > > org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTempla
> > > tes.java:193)
> > > at
> > > org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Tr
> > > ansformerImpl.java:2154)
> > > at
> > > org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Tr
> > > ansformerImpl.java:2097)
> > > at
> > > org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(Tran
> > > sformerImpl.java:2029)
> > > at
> > > org.apache.xalan.transformer.TransformerImpl.transformNode(Transforme
> > > rImpl.java:1189)
> > > at
> > > org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java
> > >
> > > :2894)
> > >
> > > This indicates that the ResultTreeHandler is not available (set to
> > > null).
> > >
> > > As most times everything is working fine it must have to do with the
> > > parallel usage of the stylesheets.
> > >
> > >
> > >
> > > Carsten Ziegeler
> > >
> > > Open Source Group sunShine - Lighting up e:Business
> > > ================================================================
> > > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > > www.sundn.de mailto:cziegeler@sundn.de
> > > ================================================================
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
>
> =====
> Davanum Srinivas, JNI-FAQ Manager
> http://www.jGuru.com/faq/JNI
>
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail - only $35
> a year! http://personal.mail.yahoo.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Strange problems with concurrent access of Xalan-2.0.0
Posted by Davanum Srinivas <di...@yahoo.com>.
Giacomo,
> Wait a second I'll try to do a stress test using ab....
> ab -c 20 -n 200 http://localhost:8080/cocoon/welcome
Where can i download this utility from?
Thanks,
dims
--- Giacomo Pati <gi...@apache.org> wrote:
> Carsten Ziegeler wrote:
> > Hello,
> >
> > since the switch from the Xalan2D07 to the Xalan-2.0.0 version in Cocoon2
> > we get sometimes very strange problems.
> >
> > We are using frames which all four use the same stylesheets. The xalan is
> > driven by the cocoon pipeline.
> >
> > If we turn on the storing (formerly known as caching) of the
> > TraxTransformer we get from time to time a NPE in one frame. Sometimes its
> > even worse: One frame contains part of the content of another frame and the
> > other frame is totally broken. Reloading the whole page brings up all
> > frames correctly.
> >
> > However if we turn off the storing we never did see this phenomenen. So we
> > assume that this problems have something to do with the storing.
> >
> > The store stores the Templates. Is it possible, that this problem can
> > occure, when several threads use the same Template (as delivered by the
> > store). A thread might finish first, resetting the template and the other
> > thread still try to use it.
>
> A Template IIRC should be thread safe but the actual transformation is done
> by a Transformer object which can be obtained from the Template (or is it the
> other way around?).
>
> Wait a second I'll try to do a stress test using ab....
>
> ab -c 20 -n 200 http://localhost:8080/cocoon/welcome
>
> No, I can't reproduce the failure. All runs well here.
>
> Any guesses from the Xalan Team?
>
> Giacomo
>
> >
> > This is only a guess - has someone else had these problems?
> >
> > As they only occur occasionally it his very hard to reproduce them...
> >
> > Perhaps someone of you has a guess whats going on.
> >
> > The exception we get is the following:
> >
> > java.lang.NullPointerException
> > at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:145)
> > at
> > org.apache.xalan.templates.ElemForEach.transformSelectedNodes(ElemFor
> > Each.java:495)
> > at
> > org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTempla
> > tes.java:193)
> > at
> > org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Tr
> > ansformerImpl.java:2154)
> > at
> > org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Tr
> > ansformerImpl.java:2097)
> > at
> > org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(Tran
> > sformerImpl.java:2029)
> > at
> > org.apache.xalan.transformer.TransformerImpl.transformNode(Transforme
> > rImpl.java:1189)
> > at
> > org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java
> >
> > :2894)
> >
> > This indicates that the ResultTreeHandler is not available (set to null).
> >
> > As most times everything is working fine it must have to do with the
> > parallel usage of the stylesheets.
> >
> >
> >
> > Carsten Ziegeler
> >
> > Open Source Group sunShine - Lighting up e:Business
> > ================================================================
> > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > www.sundn.de mailto:cziegeler@sundn.de
> > ================================================================
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
Re: Strange problems with concurrent access of Xalan-2.0.0
Posted by Giacomo Pati <gi...@apache.org>.
Carsten Ziegeler wrote:
> Hello,
>
> since the switch from the Xalan2D07 to the Xalan-2.0.0 version in Cocoon2
> we get sometimes very strange problems.
>
> We are using frames which all four use the same stylesheets. The xalan is
> driven by the cocoon pipeline.
>
> If we turn on the storing (formerly known as caching) of the
> TraxTransformer we get from time to time a NPE in one frame. Sometimes its
> even worse: One frame contains part of the content of another frame and the
> other frame is totally broken. Reloading the whole page brings up all
> frames correctly.
>
> However if we turn off the storing we never did see this phenomenen. So we
> assume that this problems have something to do with the storing.
>
> The store stores the Templates. Is it possible, that this problem can
> occure, when several threads use the same Template (as delivered by the
> store). A thread might finish first, resetting the template and the other
> thread still try to use it.
A Template IIRC should be thread safe but the actual transformation is done
by a Transformer object which can be obtained from the Template (or is it the
other way around?).
Wait a second I'll try to do a stress test using ab....
ab -c 20 -n 200 http://localhost:8080/cocoon/welcome
No, I can't reproduce the failure. All runs well here.
Any guesses from the Xalan Team?
Giacomo
>
> This is only a guess - has someone else had these problems?
>
> As they only occur occasionally it his very hard to reproduce them...
>
> Perhaps someone of you has a guess whats going on.
>
> The exception we get is the following:
>
> java.lang.NullPointerException
> at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:145)
> at
> org.apache.xalan.templates.ElemForEach.transformSelectedNodes(ElemFor
> Each.java:495)
> at
> org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTempla
> tes.java:193)
> at
> org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Tr
> ansformerImpl.java:2154)
> at
> org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Tr
> ansformerImpl.java:2097)
> at
> org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(Tran
> sformerImpl.java:2029)
> at
> org.apache.xalan.transformer.TransformerImpl.transformNode(Transforme
> rImpl.java:1189)
> at
> org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java
>
> :2894)
>
> This indicates that the ResultTreeHandler is not available (set to null).
>
> As most times everything is working fine it must have to do with the
> parallel usage of the stylesheets.
>
>
>
> Carsten Ziegeler
>
> Open Source Group sunShine - Lighting up e:Business
> ================================================================
> Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> www.sundn.de mailto:cziegeler@sundn.de
> ================================================================
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Strange problems with concurrent access of Xalan-2.0.0
Posted by Giacomo Pati <gi...@apache.org>.
Carsten Ziegeler wrote:
> Hello,
>
> since the switch from the Xalan2D07 to the Xalan-2.0.0 version in Cocoon2
> we get sometimes very strange problems.
>
> We are using frames which all four use the same stylesheets. The xalan is
> driven by the cocoon pipeline.
>
> If we turn on the storing (formerly known as caching) of the
> TraxTransformer we get from time to time a NPE in one frame. Sometimes its
> even worse: One frame contains part of the content of another frame and the
> other frame is totally broken. Reloading the whole page brings up all
> frames correctly.
>
> However if we turn off the storing we never did see this phenomenen. So we
> assume that this problems have something to do with the storing.
>
> The store stores the Templates. Is it possible, that this problem can
> occure, when several threads use the same Template (as delivered by the
> store). A thread might finish first, resetting the template and the other
> thread still try to use it.
A Template IIRC should be thread safe but the actual transformation is done
by a Transformer object which can be obtained from the Template (or is it the
other way around?).
Wait a second I'll try to do a stress test using ab....
ab -c 20 -n 200 http://localhost:8080/cocoon/welcome
No, I can't reproduce the failure. All runs well here.
Any guesses from the Xalan Team?
Giacomo
>
> This is only a guess - has someone else had these problems?
>
> As they only occur occasionally it his very hard to reproduce them...
>
> Perhaps someone of you has a guess whats going on.
>
> The exception we get is the following:
>
> java.lang.NullPointerException
> at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:145)
> at
> org.apache.xalan.templates.ElemForEach.transformSelectedNodes(ElemFor
> Each.java:495)
> at
> org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTempla
> tes.java:193)
> at
> org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Tr
> ansformerImpl.java:2154)
> at
> org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Tr
> ansformerImpl.java:2097)
> at
> org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(Tran
> sformerImpl.java:2029)
> at
> org.apache.xalan.transformer.TransformerImpl.transformNode(Transforme
> rImpl.java:1189)
> at
> org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java
>
> :2894)
>
> This indicates that the ResultTreeHandler is not available (set to null).
>
> As most times everything is working fine it must have to do with the
> parallel usage of the stylesheets.
>
>
>
> Carsten Ziegeler
>
> Open Source Group sunShine - Lighting up e:Business
> ================================================================
> Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> www.sundn.de mailto:cziegeler@sundn.de
> ================================================================
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
Strange problems with concurrent access of Xalan-2.0.0
Posted by Carsten Ziegeler <cz...@sundn.de>.
Hello,
since the switch from the Xalan2D07 to the Xalan-2.0.0 version in Cocoon2 we get sometimes very strange problems.
We are using frames which all four use the same stylesheets. The xalan is driven by the cocoon pipeline.
If we turn on the storing (formerly known as caching) of the TraxTransformer we get from time to time a NPE in one frame. Sometimes its even worse: One frame contains part of the content of another frame and the other frame is totally broken. Reloading the whole page brings up all frames correctly.
However if we turn off the storing we never did see this phenomenen. So we assume that this problems have something to do with the storing.
The store stores the Templates. Is it possible, that this problem can occure, when several threads use the same Template (as delivered by the store). A thread might finish first, resetting the template and the other thread still try to use it.
This is only a guess - has someone else had these problems?
As they only occur occasionally it his very hard to reproduce them...
Perhaps someone of you has a guess whats going on.
The exception we get is the following:
java.lang.NullPointerException
at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:145)
at org.apache.xalan.templates.ElemForEach.transformSelectedNodes(ElemFor
Each.java:495)
at org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTempla
tes.java:193)
at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Tr
ansformerImpl.java:2154)
at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Tr
ansformerImpl.java:2097)
at org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(Tran
sformerImpl.java:2029)
at org.apache.xalan.transformer.TransformerImpl.transformNode(Transforme
rImpl.java:1189)
at org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java
:2894)
This indicates that the ResultTreeHandler is not available (set to null).
As most times everything is working fine it must have to do with the parallel usage of the stylesheets.
Carsten Ziegeler
Open Source Group sunShine - Lighting up e:Business
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto:cziegeler@sundn.de
================================================================
Strange problems with concurrent access of Xalan-2.0.0
Posted by Carsten Ziegeler <cz...@sundn.de>.
Hello,
since the switch from the Xalan2D07 to the Xalan-2.0.0 version in Cocoon2 we get sometimes very strange problems.
We are using frames which all four use the same stylesheets. The xalan is driven by the cocoon pipeline.
If we turn on the storing (formerly known as caching) of the TraxTransformer we get from time to time a NPE in one frame. Sometimes its even worse: One frame contains part of the content of another frame and the other frame is totally broken. Reloading the whole page brings up all frames correctly.
However if we turn off the storing we never did see this phenomenen. So we assume that this problems have something to do with the storing.
The store stores the Templates. Is it possible, that this problem can occure, when several threads use the same Template (as delivered by the store). A thread might finish first, resetting the template and the other thread still try to use it.
This is only a guess - has someone else had these problems?
As they only occur occasionally it his very hard to reproduce them...
Perhaps someone of you has a guess whats going on.
The exception we get is the following:
java.lang.NullPointerException
at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:145)
at org.apache.xalan.templates.ElemForEach.transformSelectedNodes(ElemFor
Each.java:495)
at org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTempla
tes.java:193)
at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Tr
ansformerImpl.java:2154)
at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Tr
ansformerImpl.java:2097)
at org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(Tran
sformerImpl.java:2029)
at org.apache.xalan.transformer.TransformerImpl.transformNode(Transforme
rImpl.java:1189)
at org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java
:2894)
This indicates that the ResultTreeHandler is not available (set to null).
As most times everything is working fine it must have to do with the parallel usage of the stylesheets.
Carsten Ziegeler
Open Source Group sunShine - Lighting up e:Business
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto:cziegeler@sundn.de
================================================================
Re: AW: [Vote] Patch for CocoonServlet
Posted by Stefano Mazzocchi <st...@apache.org>.
Donald Ball wrote:
> (stefano needs heckling to keep him honest anyway)
:-Prrrrr
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Re: AW: [Vote] Patch for CocoonServlet
Posted by Stefano Mazzocchi <st...@apache.org>.
Torsten Curdt wrote:
>
> > On Thu, 15 Feb 2001, Carsten Ziegeler wrote:
> > > > Donald Ball wrote:
> > > > +1 from me. carsten's thoughts and patches have always impressed me
> > > > (especially when heckling stefano at the last apachecon ;))
> > >
> > > Hmmmm, sorry to disappoint you on this, but *I* didn't heckle stefano.
> > > That really was not me.
> >
> > are you sure? i seem to recall you asking some good pointed questions
> > about practical problems of presenting the same information in different
> > skins to different (sized) user agents (heckling is, admittedly, a strong
> > word, but i was using it in jest :)) (stefano needs heckling to keep him
> > honest anyway). regardless, glad to have you on board.
>
> Hm.. I fear the heckler was me :)
>
> At least I was talking about the practical problems we had...
> I feeling very uncomfortable this came across as heckling ;(
Donald was joking, don't worry.
He is right when he says that I need somebody to "keep me honest". I
tend to fly very high and sometimes this is dangerous. Anyway, the net
result of my 'quest to touch the sky' and your 'keeping me with the feet
on the ground' as a whole is pretty powerful, don't you think?
Anyway, I wish more people wrote RT :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
RE: AW: [Vote] Patch for CocoonServlet
Posted by Torsten Curdt <tc...@dff.st>.
> On Thu, 15 Feb 2001, Carsten Ziegeler wrote:
> > > Donald Ball wrote:
> > > +1 from me. carsten's thoughts and patches have always impressed me
> > > (especially when heckling stefano at the last apachecon ;))
> >
> > Hmmmm, sorry to disappoint you on this, but *I* didn't heckle stefano.
> > That really was not me.
>
> are you sure? i seem to recall you asking some good pointed questions
> about practical problems of presenting the same information in different
> skins to different (sized) user agents (heckling is, admittedly, a strong
> word, but i was using it in jest :)) (stefano needs heckling to keep him
> honest anyway). regardless, glad to have you on board.
Hm.. I fear the heckler was me :)
At least I was talking about the practical problems we had...
I feeling very uncomfortable this came across as heckling ;(
--
Torsten
Re: AW: [Vote] Patch for CocoonServlet
Posted by Donald Ball <ba...@webslingerZ.com>.
On Thu, 15 Feb 2001, Carsten Ziegeler wrote:
> > Donald Ball wrote:
> > +1 from me. carsten's thoughts and patches have always impressed me
> > (especially when heckling stefano at the last apachecon ;))
>
> Hmmmm, sorry to disappoint you on this, but *I* didn't heckle stefano.
> That really was not me.
are you sure? i seem to recall you asking some good pointed questions
about practical problems of presenting the same information in different
skins to different (sized) user agents (heckling is, admittedly, a strong
word, but i was using it in jest :)) (stefano needs heckling to keep him
honest anyway). regardless, glad to have you on board.
- donald
AW: [Vote] Patch for CocoonServlet
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Donald Ball wrote:
> +1 from me. carsten's thoughts and patches have always impressed me
> (especially when heckling stefano at the last apachecon ;))
Hmmmm, sorry to disappoint you on this, but *I* didn't heckle stefano.
That really was not me.
Carsten
Re: [Vote] Patch for CocoonServlet
Posted by Donald Ball <ba...@webslingerZ.com>.
On Wed, 14 Feb 2001, Paul Russell wrote:
> * Carsten Ziegeler (cziegeler@sundn.de) wrote :
> > attached is a simple patch for the CocoonServlet.
> > It addes an own method for the creating of the Environment.
> > So changing the real class for the environment used is very easy.
>
> Carsten seems to be producing more patches than any of us can cope with,
> and from what I've seen of them, they appear to be of universally high
> quality. Therefore, I propose Carsten Ziegeler for commit access to the
> xml-cocoon CVS repository, before I suffer any more 'patch -p0 <diff.txt'
> related RSI. Votes & thoughts?
+1 from me. carsten's thoughts and patches have always impressed me
(especially when heckling stefano at the last apachecon ;))
- donald
Re: [Vote] Patch for CocoonServlet
Posted by Davanum Srinivas <di...@yahoo.com>.
+1 (Great work Carsten...)
Thanks,
dims
--- Paul Russell <pa...@luminas.co.uk> wrote:
> Fellow Developers,
>
> * Carsten Ziegeler (cziegeler@sundn.de) wrote :
> > attached is a simple patch for the CocoonServlet.
> > It addes an own method for the creating of the Environment.
> > So changing the real class for the environment used is very easy.
>
> Carsten seems to be producing more patches than any of us can cope with,
> and from what I've seen of them, they appear to be of universally high
> quality. Therefore, I propose Carsten Ziegeler for commit access to the
> xml-cocoon CVS repository, before I suffer any more 'patch -p0 <diff.txt'
> related RSI. Votes & thoughts?
>
>
> P.
>
> --
> Paul Russell Email: paul@luminas.co.uk
> Technical Director Tel: +44 (0)20 8553 6622
> Luminas Internet Applications Fax: +44 (0)870 28 47489
> This is not an official statement or order. Web: www.luminas.co.uk
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
[Vote] Patch for CocoonServlet
Posted by Paul Russell <pa...@luminas.co.uk>.
Fellow Developers,
* Carsten Ziegeler (cziegeler@sundn.de) wrote :
> attached is a simple patch for the CocoonServlet.
> It addes an own method for the creating of the Environment.
> So changing the real class for the environment used is very easy.
Carsten seems to be producing more patches than any of us can cope with,
and from what I've seen of them, they appear to be of universally high
quality. Therefore, I propose Carsten Ziegeler for commit access to the
xml-cocoon CVS repository, before I suffer any more 'patch -p0 <diff.txt'
related RSI. Votes & thoughts?
P.
--
Paul Russell Email: paul@luminas.co.uk
Technical Director Tel: +44 (0)20 8553 6622
Luminas Internet Applications Fax: +44 (0)870 28 47489
This is not an official statement or order. Web: www.luminas.co.uk
[C2]: Patch for CocoonServlet
Posted by Carsten Ziegeler <cz...@sundn.de>.
Hi,
attached is a simple patch for the CocoonServlet.
It addes an own method for the creating of the Environment.
So changing the real class for the environment used is very easy.
Carsten