[BUG]: Endless recursion in source resolving

After updating to the latest cvs I get an infinite loop in the new portal demo: http://localhost:/samples/portal/portal I guess this is caused by the recent changes to the source resolving. Any clues? Carsten Carsten Ziegeler Open Source Group, S&N AG http://radio.weblogs.com/0107211/

cvs commit: cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/source CopletSourceFactory.java

cziegeler2003/06/09 23:15:42 Modified:src/blocks/portal/java/org/apache/cocoon/portal/source CopletSourceFactory.java Log: Corrected execution order Revision ChangesPath 1.3 +2 -2 cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/port

DO NOT REPLY [Bug 20271] - [PATCH] General background task manager leveraging Avalon

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 20271] - General background task manager leveraging Avalon

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 20271] - General background task manager leveraging Avalon

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 20271] - General background task manager leveraging Avalon

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 20631] - [PATCH] Support for transactions in SQLTransformer

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 20631] New: - [PATCH] Support for transactions in SQLTransformer

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: Cocoon Nuke

Bertrand Delacretaz wrote: Le Samedi, 7 juin 2003, à 09:44 Europe/Zurich, Sylvain Wallez a écrit : the code samples made my hair draw up on my head : hardcoded HTML in Java code !! Blessed arth thou, who haveth hair on their head ;-) ROFL ;-) It shows that users of such apps (simple CM

Re: exolab mail manager misbehaving

On Mon, 9 Jun 2003, Steven Noels wrote: > Could one of you check the subscriber database and unsubscribe > [EMAIL PROTECTED] from the Cocoon mailinglists? > (cocoon-dev/-users/[EMAIL PROTECTED]) [EMAIL PROTECTED] was on [EMAIL PROTECTED], and has been removed. I see no other exolab.org addresses

exolab mail manager misbehaving

Hi, I've repeatedly tried to remotely unsubscribe [EMAIL PROTECTED] who sends numerous moderation requests to the cocoon-* list admins, to no avail. Could one of you check the subscriber database and unsubscribe [EMAIL PROTECTED] from the Cocoon mailinglists? (cocoon-dev/-users/[EMAIL PROTECT

sitemap.xls - XSLTFactoryLoader flaw?

lines 454 of sitemap.xls // Prepare the pattern for "" this._expr = this.preparePattern("", ""); The XSLTFactoryLoader:escapeBraces($factory-loader, @pattern) seems to be causing the site mappings "pattern" to come out blank after the first map:match tag. In the generated

DO NOT REPLY [Bug 20623] New: - No connection for MySQL

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: Flow layer in CVS head fails

Bruno Dumon wrote: On Mon, 2003-06-09 at 18:27, Maciek Kaminski wrote: I get NPE while doing simple sendPage, pipelines that don;t touch flow works ok. Line 467 in AbstractEnvironment.java is somewhere in the middle of a javadoc. Are you using a modified version of AbstractEnvironment (or maybe a

Re: Antwort: Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/modules/inputBaseLinkModule.java RequestURIModule.java

[EMAIL PROTECTED] wrote: may be we can write: Object value = getAttribute(name, modeConf, objectModel); return (value == null ? null : new Object[]{value}); If the value is null no Object[] is generated. You need to know, that I am the best friend of the GC ;-) Sorry for the nitpicking ;-) Here yo

cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/modules/input RequestURIModule.java BaseLinkModule.java

haul2003/06/09 10:16:10 Modified:src/java/org/apache/cocoon/components/modules/input RequestURIModule.java BaseLinkModule.java Log: Error spotted by joerg and further optimization by volker saves creating Object[1] if null Revision ChangesPath

Re: What hacks are going on in Cocoon?

On Sun, 2003-06-08 at 10:38, Joerg Heinicke wrote: [...] > > Not remembering the LogTransformer I did the logging in the > HTMLSerializer, but I get the same output using LogTransformer. > And I saw XSLTC does not use any prefix mapping, but as you can see it > does neither use URIs. How is it p

Re: Flow layer in CVS head fails

On Mon, 2003-06-09 at 18:27, Maciek Kaminski wrote: > I get NPE while doing simple sendPage, pipelines that don;t touch flow > works ok. > > Any ideas? > > Original exception : java.lang.NullPointerException > at > org.apache.cocoon.environment.AbstractEnvironment.resolveURI(AbstractEnvir

Antwort: Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/modules/inputBaseLinkModule.java RequestURIModule.java

Hi, may be we can write: Object value = getAttribute(name, modeConf, objectModel); return (value == null ? null : new Object[]{value}); If the value is null no Object[] is generated. You need to know, that I am the best friend of the GC ;-) Sorry for the nitpicking ;-) Volker Hello Christian,

Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/modules/inputBaseLinkModule.java RequestURIModule.java

Hello Christian, applying to your commit message and in comparison to the second example shouldn't it be return (result[0] == null? null : result); Otherwise it seems to make no sense. Joerg [EMAIL PROTECTED] wrote: Make sure to return null instead of { null } ... Object[] resul

Re: Antwort: Re: build failed using current CVS

[EMAIL PROTECTED] wrote: Thanks Chris, if you like you can change this in RequestURIModule too ;-) It is impl. a little bit different so I didn't get a compile error :-) Done. Thanks for spotting. Chris. -- C h r i s t i a n H a u l [EMAIL PROTECTED] fingerprint: 99B0 1D9D 7919 644A 4

cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/modules/input BaseLinkModule.java RequestURIModule.java

haul2003/06/09 09:30:19 Modified:src/java/org/apache/cocoon/components/modules/input BaseLinkModule.java RequestURIModule.java Log: Replace List.add().toArray() with Object[1] Spotted by volker.schmitt.at.basf-it-services.com Make sure to return nul

Flow layer in CVS head fails

I get NPE while doing simple sendPage, pipelines that don;t touch flow works ok. Any ideas? Original exception : java.lang.NullPointerException at org.apache.cocoon.environment.AbstractEnvironment.resolveURI(AbstractEnvironment.java:467) at org.apache.cocoon.environment.AbstractEnvironment.r

Antwort: Re: build failed using current CVS

Thanks Chris, if you like you can change this in RequestURIModule too ;-) It is impl. a little bit different so I didn't get a compile error :-) Volker [EMAIL PROTECTED] wrote: > Hi, > > I get the following build error with the current CVS, it compiles inside > Eclipse but not using > "Java(TM

DO NOT REPLY [Bug 20381] - XSLTC: top-level xsl:variable with document() breaks

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: cvs commit: cocoon-2.0/lib/core xalan-2.5.1.jar xercesImpl-2.4.0.jarxml-apis.jar xalan-2.3.1.jar xercesImpl-2.0.0.jar

On 6/06/2003 20:50 Joerg Heinicke wrote: Carsten Ziegeler wrote: But there is another reason for this mail: Now with the current XSLTC we can switch to it as default processor in 2.0 too, can't we? I'm currently -1 on this because imho xsltc has not proven to be 100% working and I think we sho

Re: cvs commit: cocoon-2.1/src/blocks/databases/java/org/apache/cocoon/components/language/markup/xsp JdbcEsqlQuery.java

> tcurdt 2003/06/09 04:02:03 > Log: > reusing the statement for the limit clause seems not to always work, > reverting to the proposed JDBC way until this got fixed in the > AbstractEsqlQuery Hi torsten! What this mean? Can you explain a little more about this? Best Regards, Antonio Ga

cvs commit: cocoon-2.1/src/blocks/databases/java/org/apache/cocoon/components/language/markup/xsp JdbcEsqlQuery.java

tcurdt 2003/06/09 04:02:03 Modified: src/blocks/databases/java/org/apache/cocoon/components/language/markup/xsp JdbcEsqlQuery.java Log: reusing the statement for the limit clause seems not to always work, reverting to the proposed JDBC way until this got fi

cvs commit: cocoon-2.1/src/blocks/databases/java/org/apache/cocoon/components/language/markup/xsp AbstractEsqlConnection.java

tcurdt 2003/06/09 03:55:48 Modified: src/blocks/databases/java/org/apache/cocoon/components/language/markup/xsp AbstractEsqlConnection.java Log: added recognition of "access" and "sap db" Revision ChangesPath 1.5 +5 -2 cocoon-2.1/src/b