cvs commit: xml-cocoon2/src/test/org/apache/cocoon/components/resolver/test ResolverImplTestCase.xtest

crossley02/02/20 19:49:53 Modified:src/test/org/apache/cocoon/components/resolver/test ResolverImplTestCase.xtest Log: Use the new entity-resolver role that utilises the new xml-parser role, i.e. the Excalibur JaxpParser Revision ChangesPath 1.3

Re: XSLT benchmarks: dbonerow

You know... I wonder why you guys don't spend time on optimizing the XSL (I know Steven Noels is). This is most probably the bottleneck you are experiencing?? You guys are taking the path away from general adoption... - Original Message - From: "Jacek Ambroziak" <[EMAIL PROTECTED]> To: <

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/language/markup/xsp/java esql.xsl form-validator.xsl log.xsl logicsheet-util.xsl sendmail.xsl util.xsl

vgritsenko02/02/20 19:36:10 Modified:src/java/org/apache/cocoon/components/language/markup/xsp/java esql.xsl form-validator.xsl log.xsl logicsheet-util.xsl sendmail.xsl util.xsl Log: Fix get-nested-content template: xsp:text should be

cvs commit: xml-cocoon2/src/scratchpad/schecoon/webapp cocoon.xconf

crossley02/02/20 19:35:12 Modified:src/scratchpad/schecoon/webapp cocoon.xconf Log: - Use the entity-resolver role that utilises the new xml-parser role, i.e. the Excalibur JaxpParser Revision ChangesPath 1.6 +13 -35xml-cocoon2/src/scratchpad/schecoon/webapp/

XSLT benchmarks: dbonerow

Setting the stage: Today's XSLTC translets perform abysmally on the 'dbonerow' benchmark. The XML document is a set of 10^4 records and the stylesheet contains one template designed to match (and process) one of the records; XSLT essentially performs a search by matching. On my machine 10 iterat

cvs commit: xml-cocoon2/src/webapp/docs/samples/xsp cookie.xsp

vgritsenko02/02/20 19:20:09 Modified:src/java/org/apache/cocoon/components/language/markup/xsp/java cookie.xsl src/webapp/docs/samples/xsp cookie.xsp Log: fix cookie logicsheet Revision ChangesPath 1.5 +3 -2 xml-cocoon2/

cvs commit: xml-cocoon2/src/webapp/docs/samples/xsp request.xsp

vgritsenko02/02/20 19:06:15 Modified:src/webapp/docs/samples/xsp request.xsp Log: add test Revision ChangesPath 1.3 +4 -6 xml-cocoon2/src/webapp/docs/samples/xsp/request.xsp Index: request.xsp

cvs commit: xml-cocoon2/src/webapp/docs/samples/xsp sessionpage.xsp session.xsp

vgritsenko02/02/20 19:02:09 Modified:src/webapp/docs/samples sample-xsp.xml src/webapp/docs/samples/xsp session.xsp Added: src/webapp/docs/samples/xsp sessionpage.xsp Log: fix session sample; add session test skeleton Revision ChangesPath 1.3

RE: Session:set-attribute logicsheet bug?

> From: Paolo Scaffardi [mailto:[EMAIL PROTECTED]] > > I tried Cocoon 2.0.1 with an existing project of mine, and i discovered > that the session logicsheet has changed. In my code i have something > like that: > >name="pippo">myVar > > But the logicsheet transforms it to: > > XS

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/language/markup/xsp/java request.xsl response.xsl session.xsl

vgritsenko02/02/20 18:51:49 Modified:src/java/org/apache/cocoon/components/language/markup/xsp/java request.xsl response.xsl session.xsl Log: Fix xsp-session:set-attribute bug reported by Paolo Scaffardi [[EMAIL PROTECTED]] Revision ChangesPath 1.

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/language/markup/xsp JSGenerator.java

vgritsenko02/02/20 18:44:23 Modified:src/java/org/apache/cocoon/components/language/markup/xsp JSGenerator.java Log: Implement dependency checking for Javascript XSP pages Revision ChangesPath 1.4 +14 -9 xml-cocoon2/src/java/org/apache/

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/language/programming/javascript CompiledJavascriptLanguage.java JavascriptLanguage.java JavascriptProgram.java

vgritsenko02/02/20 18:42:49 Modified:src/java/org/apache/cocoon/components/language/markup/xsp/javascript xsp.xsl src/java/org/apache/cocoon/components/language/programming/javascript CompiledJavascriptLanguage.java

RE: is cocoon symmetry a holy grail?

> -Original Message- > From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 20, 2002 4:28 PM > To: [EMAIL PROTECTED] > Subject: RE: is cocoon symmetry a holy grail? > > > From: Greg Weinger [mailto:[EMAIL PROTECTED]] > > > > > I have another one, it provides differ

cvs commit: xml-cocoon2/src/webapp/WEB-INF logkit.xconf

vgritsenko02/02/20 16:53:55 Modified:src/webapp/WEB-INF logkit.xconf Log: add categories Revision ChangesPath 1.6 +7 -0 xml-cocoon2/src/webapp/WEB-INF/logkit.xconf Index: logkit.xconf ===

cvs commit: xml-cocoon2/src/webapp sitemap.xmap

vgritsenko02/02/20 16:40:58 Modified:src/webapp sitemap.xmap Log: Sample of explicitly specifying sitemap file name Revision ChangesPath 1.29 +1 -1 xml-cocoon2/src/webapp/sitemap.xmap Index: sitemap.xmap ==

RE: is cocoon symmetry a holy grail?

> From: Greg Weinger [mailto:[EMAIL PROTECTED]] > > > I have another one, it provides different functionality but > > it features similar approach. > > As I don't have a name for this (multiplexer?), here > > is the diagram: > > > > - pipeline1 - > > /

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/sitemap Handler.java

vgritsenko02/02/20 16:08:13 Modified:src/java/org/apache/cocoon/sitemap Handler.java Log: Unclutter [core] log category: feed sitemap with sitemap handler's logger instead of program generator's logger. Revision ChangesPath 1.10 +11 -6 xml-cocoon2/src/java/org/

cvs commit: xml-cocoon2/src/java/org/apache/cocoon Cocoon.java

vgritsenko02/02/20 16:03:51 Modified:src/java/org/apache/cocoon Cocoon.java Log: Unclutter [core] log category, add: core.manager core.startup core.roles core.roles.user (is this correct approach?) Revision ChangesPath 1.17 +7 -8 xml-cocoon2/src/java/

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/servlet CocoonServlet.java

vgritsenko02/02/20 16:02:05 Modified:src/java/org/apache/cocoon/servlet CocoonServlet.java Log: Clear map after printing info Revision ChangesPath 1.11 +96 -94 xml-cocoon2/src/java/org/apache/cocoon/servlet/CocoonServlet.java Index: CocoonServlet.java ===

cvs commit: xml-cocoon2 changes.xml

vgritsenko02/02/20 16:01:11 Modified:.changes.xml Log: Document changes Revision ChangesPath 1.107 +7 -3 xml-cocoon2/changes.xml Index: changes.xml === RCS file: /home/cvs/xml-cocoo

RE: is cocoon symmetry a holy grail?

> I have another one, it provides different functionality but it features > similar approach. As I don't have a name for this (multiplexer?), here > is the diagram: > > - pipeline1 - > / \ > request -> A -> X - pipeline2 - X -> C -> response >

cvs commit: xml-cocoon2 build.bat

stefano 02/02/20 15:31:18 Modified:.build.bat Log: avoid recopying jars required for ant everytime (improves speed in subsequent calls) Revision ChangesPath 1.17 +4 -4 xml-cocoon2/build.bat Index: build.bat ===

RE: What needs to be downloaded to get the portal?

Strange? In my local copy, it is... Either your or mine is not up to sync with CVS, then. > -Original Message- > From: Carlos [mailto:[EMAIL PROTECTED]] > Sent: donderdag 21 februari 2002 0:15 > To: [EMAIL PROTECTED] > Subject: Re: What needs to be downloaded to get the portal? > >

Re: What needs to be downloaded to get the portal?

Steve: I've reported this earlier today but webapp is no longer a recognized build target. It is not listed in ./build.sh -projecthelp or appears on the build.xml file Carlos On 02/20/02 15:03, "Steven Noels" <[EMAIL PROTECTED]> wrote: > Sorry, hit the send button accidentaly: > > the scratch

RE: What needs to be downloaded to get the portal?

Sorry, hit the send button accidentaly: the scratchpad is in the same CVS module as cocoon, located in xml-cocoon2\src\scratchpad build.sh -Dinclude.webapps.libs=yes -Dinclude.scratchpad.libs=yes webapp will get you a war which includes the portal, it is accessible from the default cocoon demo p

RE: What needs to be downloaded to get the portal?

just get the current CVS HEAD and compile with the -Dinclude.scratchpad.libs=true option > -Original Message- > From: Carlos [mailto:[EMAIL PROTECTED]] > Sent: woensdag 20 februari 2002 21:07 > To: [EMAIL PROTECTED] > Subject: What needs to be downloaded to get the portal? > > > What mod

Weird problem with JDK 1.4 on win32

I just compiled the fresh CVS and I got a bunch of compilation errors such as class org.apache.cocoon.components.language.markup.xsp.EsqlConnection must be declared abstract. It does not define void setHoldability(int) from interface java.sql.Connection. [javac] public class EsqlConnection im

Re: cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/transformation/pagination ItemGroup.java PageRules.java Pagesheet.java Paginator.java

John Morrison wrote: > > Files missing? > > ./build.sh -Dinclude.webapps.libs=yes -Dinclude.scratchpad.libs=yes webapp > > > > D:\Wrkfile\Repositories\apache\xml-cocoon2\build\cocoon\scratchpad\src\org\a > pache\cocoon\transformat > ion\pagination\Pagesheet.java:67: Class > org.apache.cocoon.

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/transformation/pagination Paginator.java

stefano 02/02/20 14:21:34 Modified:src/scratchpad/src/org/apache/cocoon/reading DirectoryZipArchiver.java ImageReader.java src/scratchpad/src/org/apache/cocoon/transformation/pagination Paginator.java Log: added missing

Re: Problems with build

John: Build.xml no longer includes webapp as a target. I used the -project help command and also looked on the build.xml file itself Carlos On 02/20/02 13:21, "John Morrison" <[EMAIL PROTECTED]> wrote: > If you entered it *exactly* as below - it works for me. It doesn't compile > properly - b

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/transformation/pagination Paginator.java

stefano 02/02/20 13:23:07 Modified:src/scratchpad/src/org/apache/cocoon/transformation/pagination Paginator.java Log: removed the PathMap component which isn't really useful at this point Revision ChangesPath 1.2 +1 -11 xml-cocoon2/src/

RE: Problems with build

If you entered it *exactly* as below - it works for me. It doesn't compile properly - but that's another issue. check that ./build.sh -projecthelp lists webapp. J. > From: Carlos [mailto:[EMAIL PROTECTED]] > I'm trying the following command on a CVS download from today: > > ./build.sh -Dinclud

RE: cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/transformation/pagination ItemGroup.java PageRules.java Pagesheet.java Paginator.java

Files missing? ./build.sh -Dinclude.webapps.libs=yes -Dinclude.scratchpad.libs=yes webapp D:\Wrkfile\Repositories\apache\xml-cocoon2\build\cocoon\scratchpad\src\org\a pache\cocoon\transformat ion\pagination\Pagesheet.java:67: Class org.apache.cocoon.util.ResizableContainer not found in impor t

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/reading DirectoryZipArchiver.java

stefano 02/02/20 12:58:21 Added: src/scratchpad/src/org/apache/cocoon/reading DirectoryZipArchiver.java Log: added a directory archiver which is able to create a zip file of the content of a directory on the file system. Revision ChangesPath 1

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/reading ImageReader.java

stefano 02/02/20 12:57:38 Added: src/scratchpad/src/org/apache/cocoon/reading ImageReader.java Log: added an image reader that is able to resize the requested image depending on sitemap parameters (useful to generate image thumbnails or normalize the si

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/transformation/pagination ItemGroup.java PageRules.java Pagesheet.java Paginator.java

stefano 02/02/20 12:56:19 Added: src/scratchpad/src/org/apache/cocoon/transformation/pagination ItemGroup.java PageRules.java Pagesheet.java Paginator.java Log: added a paginating transformer to the scratchpad Revision Changes

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/transformation/pagination - New directory

stefano 02/02/20 12:52:49 xml-cocoon2/src/scratchpad/src/org/apache/cocoon/transformation/pagination - New directory -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED]

Problems with build

I'm trying the following command on a CVS download from today: ./build.sh -Dinclude.webapps.libs=yes -Dinclude.scratchpad.libs=yes webapp And I'm getting: Webapp is not a valid target Any ideas why? Carlos -- Carlos E. Araya ---+ WebCT Administrator/Trainer P | California Virtual Campus -

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/reading - New directory

stefano 02/02/20 12:49:44 xml-cocoon2/src/scratchpad/src/org/apache/cocoon/reading - New directory -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional com

What needs to be downloaded to get the portal?

What modules do I need to download to get the portal working? How do I download the scratchpad? Carlos -- Carlos E. Araya ---+ WebCT Administrator/Trainer P | California Virtual Campus - | C/O De Anza College G | 21250 Stevens Creek Blvd ---+ Cupertino, CA 95014 email [EMAIL PR

Re: C2 Scalability Issues

Stefano Mazzocchi wrote: > Berin Loritsch wrote: > > >>The approach I would like to take for the Cocoon component model is >>a refining of all the interfaces. Unfortunately, that would require >>some backwards incompatible changes. :( >> >>When I get the ContainerManager done and a new scratchp

C2 Scalability Issues

Berin Loritsch wrote: > The approach I would like to take for the Cocoon component model is > a refining of all the interfaces. Unfortunately, that would require > some backwards incompatible changes. :( > > When I get the ContainerManager done and a new scratchpad > implementation of Cocoon (a

Re: AW: some XSLT benchmarks

[EMAIL PROTECTED] wrote: > > Yes, I agree with Berin on this, though I also agree with Jacek that > there's little reason that it should not scale well. > > Another factor is "incremental" output, which Xalan interpretive does a lot > of work to do well (and tends to take penalty for), and XSLTC

Re: [HEADS UP] Don't use -Xincgc with JDK 1.4

Berin Loritsch wrote: > -Xprofile > Provides a very useful human readable dump of JVM activity. Hats > off to the JDK 1.4 crew! Here is the typical execution thread for ContainerManager code: Flat profile of 27.64 secs (1402 total ticks): Latched_Thread_68 Interpreted + native

Re: AW: some XSLT benchmarks

Santiago Pericas wrote: >> yes, automatically generated, but the 'XSLT to bytecode' patterns have >> been manually crafted, right? and I'm pretty sure that you guys crafted >> them based on the assumption on how the underlying JVM was going to >> interpret them. Which shows why it is faster on the

[HEADS UP] Don't use -Xincgc with JDK 1.4

There was a tip running around late last year that if you ran the JVM with the -Xincgc that the system would perform better. With my current testing using JDK 1.4 (final release), I found that enabling that option lengthens the time of the ECM/ContainerManager test by a factor of 2. In both cas

Re: AW: some XSLT benchmarks

> yes, automatically generated, but the 'XSLT to bytecode' patterns have > been manually crafted, right? and I'm pretty sure that you guys crafted > them based on the assumption on how the underlying JVM was going to > interpret them. Which shows why it is faster on the Sun 1.3.1 JVM (but > this i

Re: AW: some XSLT benchmarks

Yes, I agree with Berin on this, though I also agree with Jacek that there's little reason that it should not scale well. Another factor is "incremental" output, which Xalan interpretive does a lot of work to do well (and tends to take penalty for), and XSLTC may have a much harder time at. On

Re: Threadsafe ServerPages (was Re: esql thread unsafe - bug)

Berin Loritsch wrote: > When I get the ContainerManager done and a new scratchpad > implementation of Cocoon (as extending AbstractContainer), Main, and > CocoonServlet; we can start to assess the real limitations that the > current component model has with scalibility. > > Until then, you are go

Re: AW: some XSLT benchmarks

You guys may find another data point interesting... (I am using Sun's newest 1.4 on Linux) I reran the test with '-verbosegc' flag gathering GC info into files. and then counted Full garbage collections grep Full gcXSLTC | wc -l grep Full gcXT| wc -l and so on. The results: XSLTC21 X

DO NOT REPLY [Bug 6555] - Can't start first time (tomcat 4.0.2)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: AW: some XSLT benchmarks

Santiago Pericas wrote: > > > yes, automatically generated, but the 'XSLT to bytecode' patterns have > > been manually crafted, right? and I'm pretty sure that you guys crafted > > them based on the assumption on how the underlying JVM was going to > > interpret them. Which shows why it is faster

cvs commit: xml-cocoon2/src/webapp/sunspotdemo/resources/auth portal.xml

cziegeler02/02/20 08:07:26 Modified:src/java/org/apache/cocoon/transformation TraxTransformer.java src/webapp/sunspotdemo/profiles sunletprofile.xml src/webapp/sunspotdemo/resources/auth portal.xml Log: Fixing saving of profile a

Fwd: Re: AW: some XSLT benchmarks

Note: forwarded message attached. __ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com --- Begin Message --- No assumptions about JVMs have been made; in fact translets used to run faster on IBM's VMs (esp.

Re: AW: some XSLT benchmarks

No assumptions about JVMs have been made; in fact translets used to run faster on IBM's VMs (esp. 1.1.8) which was a bit embarassing for me as a Sun-er at the time. I am sure translets can be further optimized but JVM tuning would be the last (if at all) place to look at, maybe except for small d

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/transformation FileWritingTransformer.java

cziegeler02/02/20 05:59:16 Modified:src/scratchpad/src/org/apache/cocoon/transformation FileWritingTransformer.java Log: Fixed FileWriterTransformer Revision ChangesPath 1.4 +2 -1 xml-cocoon2/src/scratchpad/src/org/apache/cocoon/transf

RE: Various memory leak fixes

> From: Marcus Crafter [mailto:[EMAIL PROTECTED]] > > Hi Carsten, > > On Wed, Feb 20, 2002 at 02:05:07PM +0100, Carsten Ziegeler wrote: > > > thanks for your patch - it's applied, well not exactly: The patches > > for the TraxTransformer and the CocoonServlet were already in the > > current CVS

Re: Threadsafe ServerPages (was Re: esql thread unsafe - bug)

Let me step in to say this now: The way that the component model in general is for Cocoon, it is difficult to impossible to make any sitemap component ThreadSafe. The exceptions are the Reader, the Matcher, the Action, and the Selector. Before we went Beta with Cocoon 2, I proposed that we chan

Re: [RT] Cocoon subcomponent object model (was: Re: is cocoon symmetry a holy grail?)

Nicola Ken Barozzi wrote: > > And this should be KISS? > > Ok, so let me explain it from a sitemap view. > > You can add a parameter parallel="true" to make queries run simultaneously. > > Simple enough? In order to use something you have to understand how it works. For a cocoon pipeline, th

Re: Various memory leak fixes

Hi Carsten, On Wed, Feb 20, 2002 at 02:05:07PM +0100, Carsten Ziegeler wrote: > thanks for your patch - it's applied, well not exactly: The patches > for the TraxTransformer and the CocoonServlet were already in the > current CVS, but in a slightly different form. > > Could you please check if t

Re: AW: some XSLT benchmarks

MORAVEK Peter wrote: > > > Results: > > Xalan 2.3 XSLTC > > XT > > MSXML 3.0 > > And what about SAXON and MSXML 4.0 ? How are the results of the benchmarks > with these two transformers ? Saxon was way slower (around 100, check my previous post on the matter) I couldn't test MSXML 4.0 because

Re: AW: some XSLT benchmarks

Jacek Ambroziak wrote: > > Stefano, > > that is cool! Except for the mysterious 'dbonerow'. I > will attempt to fix it > an in general I am going continue to follow my > original vision > to make XSLTC a good technology for people to actually > use. Cool. > You are right, there are multiple '

RE: Portal ArrayIndexOutOfBounds error

Hi Carsten, I rebuilt Cocoon today (seem to do that several times each day lately :-)) after some updates were released on CVS and tested the Portal again. Is there any way I can get a version when I checkout a CVS version? I am still having some problems with the portal though. I am getting

RE: Various memory leak fixes

Hi Marcus, thanks for your patch - it's applied, well not exactly: The patches for the TraxTransformer and the CocoonServlet were already in the current CVS, but in a slightly different form. Could you please check if that is ok - I think it is, it seems that they were already contained in a prev

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/serialization AbstractTextSerializer.java

cziegeler02/02/20 05:02:01 Modified:src/java/org/apache/cocoon/serialization AbstractTextSerializer.java Log: Applied patch for memory leaks. PR: #6574 Submitted by: Marcus Crafter [[EMAIL PROTECTED]] Revision ChangesPath 1.8 +9 -1

DO NOT REPLY [Bug 6574] - [PATCH] Fixes for memory leaks

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 6574] - [PATCH] Fixes for memory leaks

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 6574] New: - [PATCH] Fixes for memory leaks

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Various memory leak fixes

Hi All, Hope all is well. Yesterday Christian and I did some intensive hunting for memory leaks inside of our application and Cocoon 2.0.1. We found various leaks including: 1. TraxTransformer's xsltProcessor not releasing it's source resolver. 2.

inter-pipeline communication

Hi there, I'm fairly new to cocoon, and especially to the programmer's api, so forgive me if I'm way off here. What I'm trying to do is to 'call' pipelines. Although this could be achieved by using the CIncludeTransformer, with the source set to a pipeline entry, I'd like to pass on a parameter i

DO NOT REPLY [Bug 4932] - and processing error

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/language/markup/xsp/java esql.xsl

tcurdt 02/02/20 03:31:28 Modified:src/java/org/apache/cocoon/components/language/markup/xsp/java esql.xsl Log: fixed bug #4932 submitted by [EMAIL PROTECTED] fixed multi-threading bug with cocoon1 reported by [EMAIL PROTECTED] Revision ChangesPat

RE: Threadsafe ServerPages (was Re: esql thread unsafe - bug)

This could be a reasonable explanation for the scalability problem. Isn't this a problem with all generators? In Cocoon 1 the following method generates the output of an XSP page: public void populateDocument( HttpServletRequest request, HttpServletResponse response, Do

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/sunshine/xml XMLUtil.java

cziegeler02/02/20 03:00:31 Modified:src/scratchpad/src/org/apache/cocoon/sunshine/context RequestSessionContext.java src/scratchpad/src/org/apache/cocoon/sunshine/xml XMLUtil.java Log: Use excalibur parser Revision

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/transformation FileWritingTransformer.java

cziegeler02/02/20 02:39:25 Modified:src/scratchpad/src/org/apache/cocoon/sunshine/transformation InsertTransformer.java src/scratchpad/src/org/apache/cocoon/transformation FileWritingTransformer.java Log: Making subclass

DO NOT REPLY [Bug 6334] - [PATCH] Adding context support to parent-component-managers

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/servlet CocoonServlet.java

tcurdt 02/02/20 02:38:46 Modified:src/java/org/apache/cocoon/servlet CocoonServlet.java Log: Patch/Bug 6334: Adding context support to parent-component-managers Submitted by: [EMAIL PROTECTED] (Marcus Crafter) Revision ChangesPath 1.10 +5 -1 xml-cocoon2/src

DO NOT REPLY [Bug 6334] - [PATCH] Adding context support to parent-component-managers

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

RE: Core libraries

> Ugo Cei wrote: > > > Carsten Ziegeler wrote: > > Hi, > > > > you have to remove the libraries from the lib/opt directory *before* > > building cocoon. The resulting webapp should be runnable without > > any changes. > > Then there are a couple of problems in the build script. > > Environment: R

DO NOT REPLY [Bug 4932] - and processing error

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: Core libraries

Carsten Ziegeler wrote: > Hi, > > you have to remove the libraries from the lib/opt directory *before* > building cocoon. The resulting webapp should be runnable without > any changes. Then there are a couple of problems in the build script. Environment: RedHat Linux 7.1, Sun JDK 1.3.1, Cocoon

Re: Threadsafe ServerPages (was Re: esql thread unsafe - bug)

Torsten Curdt wrote: >>I've discovered serious bug in esql logicsheet while using it with >>cocoon-1.8.3. However the same bug seems to exists in cocoon2. The >>problem is that while node stack logic variables (xspParentNode, >>xspCurrentNode, xspNodeStack) are defined inside populateDocument >>

RE: FileWritingTransformer and Windows

At 12:52 pm +0100 19/2/02, Carsten Ziegeler wrote: >Hi, > >I'm not sure, but I think windows needs two slashes after "file:" - the >backslashes are not required. > >How do you construct the whole file URI? Do you use the SourceResolver? >If you for example use the relative path "mount/editor/docs/

Threadsafe ServerPages (was Re: esql thread unsafe - bug)

On Tue, 19 Feb 2002, Szymon Stasik wrote: > Hi, > > I've discovered serious bug in esql logicsheet while using it with > cocoon-1.8.3. However the same bug seems to exists in cocoon2. The > problem is that while node stack logic variables (xspParentNode, > xspCurrentNode, xspNodeStack) are define

Re: [RT] Cocoon subcomponent object model (was: Re: is cocoon symmetry a holy grail?)

From: "Stefano Mazzocchi" <[EMAIL PROTECTED]> > Nicola Ken Barozzi wrote: > > > My opinion is that developers are not yet taken correctly into account. > > While the other three have a componentization which is sufficient for their > > part of work, developers suffer for the lack of it. Usually a