DO NOT REPLY [Bug 26376] - No samples run with JDK1.3

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 26450] - Allow the Authentication Framework to invoke a pipeline during logout

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: [proposal] Cleaning up our component library

On 28.01.2004 16:44, Geoff Howard wrote: So alltogether: a) Components that are just renamed or replaced with only sitemap changes (FileGenerator => XMLGenerator, DirectoryGenerator => TraversableGenerator (or however it is called ;-) ), StreamGenerator => XMLGenerator + ModuleSource) are depr

DO NOT REPLY [Bug 23269] - better exception handling for JSP

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: source resolving in 2.2

Carsten Ziegeler wrote: Unico Hommes wrote: Ah, ok, so what do you think of using that then? I just noticed that the key for the processor is just "treeprocessor", what do you think of using a more qualified name like org.apache.cocoon.Processor or the name of the implementation? Yes, th

Re: Cocoon Woody

Vadim Gritsenko wrote: Harald Wehr wrote: Hi Vadim, sorry for writing directly to you, but I did not get an answer to my posting to the developer list. Well, you have to have a bit more patience. I generally agree that image input handling should be present in this way or another in the Woo

Re: testing cocoon components

Ugo Cei wrote: > Of course. Look into src/test and specifically > o.a.c.SitemapComponentTestCase. BTW: Can anybody interested in unit tests look at my post: http://article.gmane.org/gmane.text.xml.cocoon.devel/29889 and answer the questions. -- Wojciech Gdela

Re: testing cocoon components

Leszek Gawron wrote: > Is there a way to test the cocoon component without the need to do HTTP > requests? If you are talking about action, generator, serializer, etc. unit tests take a look at src/test and SitemapComponentTestCase: http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/test/org/apache

DO NOT REPLY [Bug 26460] - [PATCH] DASLTransformer add substitute-value feature

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: [proposal] Cleaning up our component library

> -Original Message- > From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 28, 2004 6:13 PM > To: [EMAIL PROTECTED] > Subject: Re: [proposal] Cleaning up our component library > > > Ralph Goers wrote: > > >I thought actions were performed before generators and

RE: ServletException in JSPGenerator.generate()

I tried to reproduce the error but the samples are running fine on my machine. Could you provide more details about your environment? Cocoon version, Java version. Also the stacktrace in the logs and on the console if any... Unico Elvira Nieto Carretero wrote: In Samples Cocoon is a example

Improving the Woody Flowscript API

I've just checked in some experimental improvements to the Woody Flowscript API and an associated sample. Because the changes are not backward compatible I've placed the files in a new package. The idea is to try to remove the duplication present in the current API in two places: 1) The origin

General use of CompilingClassLoader?

How hard would it be to make the CompilingClassLoader work for classes within Cocoon, such as when working directly on the cforms classes? Of course this would only be for use during development to shorten the edit-compile-restart-test cycle. --Tim Larson

Re: [proposal] Cleaning up our component library

Le Mercredi, 28 jan 2004, à 11:52 Europe/Zurich, Joerg Heinicke a écrit : ...With our deprecated block we have another mean to lead the user to the new components. When it's excluded the application will just not work. But I don't know if this is true for 2.2 and real blocks too... hmm...I don't

RE: [proposal] Cleaning up our component library

I'll admit that I didn't do the work evaluating Woody. My colleague indicated he had problems figuring out how to get Woody bindings to work without flow. If there are samples of that let me know and I'll have him look at it again. Thanks, Ralph -Original Message- From: Steven Noels [mail

Re: Managing Continuation Trees

Christopher Oliver wrote: Ok, I just committed changes that implement createWebContinuation(). The support for continuation local variables is also included. It works! At least it seem to ;-) Vadim

Re: [proposal] Cleaning up our component library

Ralph Goers wrote: I thought actions were performed before generators and transformers? If so, how could an action copy data from a generator or transformer? PS Fictious syntax used for simplicity Vadim

Problems with Last Modified Header using ResourceReader

Hi! We have some strange effects here. It seems that the lastmodified header set by the ResourceReader only sometimes reflects the actual Last-Modified Timestamp from the file system. Most of the time the last modified header is set to the current time. Which has the effect that the browsers ca

RE: [proposal] Cleaning up our component library

Joerg Heinicke <[EMAIL PROTECTED]> proposes: > I propose to > deprecate > those components in 2.1 and to remove them in 2.2. Yes please! As Cocoon grows it gets harder and harder to see the real direction it is heading as long as it continues to carry with it every single experiment and work

Re: [flowscript] How to set an integer value in the FlowScript?

Hi Joerg, i am think this is related with the datatype of Woody and Java the datatype in woody integer is converter in java.lang.Integer and the datatype in woody decimal is converter in java.math.BigDecimal Joerg Heinicke Escribio :-) > I have a little problem when setting a value of a Wood

RE: [proposal] Cleaning up our component library

I thought actions were performed before generators and transformers? If so, how could an action copy data from a generator or transformer? Ralph -Original Message- From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 28, 2004 8:11 AM To: [EMAIL PROTECTED] Subject: Re:

Re: [proposal] Cleaning up our component library

Geoff Howard wrote: Vadim Gritsenko wrote: And we should only move things into the deprecated part if there is a usable alternative. IMHO, using flow instead of a transformer isn't really an alternative as the overhead is way to much (just my opinion here). -1 to replacing of SourceWritingTran

RE: [proposal] Cleaning up our component library

I totally agree with this. I have focused totally on 2.1 in building our system. For things to suddenly be deprecated now would be most irritating. If 2.2 manages to make the process of building one's webapp easier with "real" blocks, a lot of folks like me will want to switch to it just for that.

RE: [proposal] Cleaning up our component library

From: Carsten Ziegeler > Joerg Heinicke wrote: > > So alltogether: > > > > a) Components that are just renamed or replaced with only sitemap > > changes (FileGenerator => XMLGenerator, DirectoryGenerator => > > TraversableGenerator (or however it is called ;-) ), > StreamGenerator => > > XMLG

Re: processing dynamically genereated xml

Erik Hofstra wrote: Hi, The data from a form is bound to a XML data model (with Woody). Now i want to show this XML-document After the form is submitted, right? (with some kind of stylesheet) without having to write it to a file first or with another (static) file: dynamically. I think you c

Re: FW: [proposal] Cleaning up our component library

Bruno Dumon wrote: On Wed, 2004-01-28 at 08:43, Ralph Goers wrote: We'd love to use Woody (aka Cocoon Forms), but if it can be used without FlowScript it isn't obvious. So we will be using the SimpleFormTransformer etc., for the forseeable future. Woody doesn't require flowscript. While

Re: [proposal] Cleaning up our component library

Vadim Gritsenko wrote: Carsten Ziegeler wrote: Joerg Heinicke wrote: So alltogether: a) Components that are just renamed or replaced with only sitemap changes (FileGenerator => XMLGenerator, DirectoryGenerator => TraversableGenerator (or however it is called ;-) ), StreamGenerator => XMLGene

Re: Flow

Jan Hoskens wrote: (Stephan asked to post this in the dev maillist) Jan, JFYI: Dev does not read HTML mails. Please set your Microsoft Outlook Express 6.00.2800.1158 to produce plain text email. Thanks ;-) Vadim PS Evidence: --=_NextPart_000_0161_01C3E5A0.1C5841E0 Content-Type: text/htm

RE: [proposal] Cleaning up our component library

Ralph Goers <[EMAIL PROTECTED]> writes: > Our > environment has special security concerns that just won't > allow a scripting language - or even JSPs or XSPs for that > matter. Ok, I'll bite; why single out scripting languages and dynamically produced pages? What about dynamically compiled

Re: ServletException in JSPGenerator.generate()

In Samples Cocoon is a example about to use JSP with JSPGenerator and it happens somthing similar but with JSPReader:   http://localhost:8080/cocoon/samples/jsp/   I modified my code using JSPGenerator and JSPReader (equal what the sample cocoon) and i obtain "ServletException in JSPReader.g

Re: [OT] Flow and Scheme

SISC http://sisc.sourceforge.net Brian McCallister wrote: Which scheme implementation was used for the original implementation of flow, or did somebody create their own? Is it still available? Thanks! -Brian

RE: [OT] Flow and Scheme

From: Brian McCallister > Which scheme implementation was used for the original > implementation of > flow, or did somebody create their own? > > Is it still available? IIRC it was SISC (http://sisc.sourceforge.net/) -- Reinhard

Re: [OT] Flow and Scheme

Brian McCallister wrote: Which scheme implementation was used for the original implementation of flow, or did somebody create their own? Is it still available? It was removed. You can get it from the Attic: http://cvs.apache.org/viewcvs.cgi/cocoon-2-historical/src/scratchpad/schecoon/?hid

Flow

(Stephan asked to post this in the dev maillist)   I've tried to just call the function (like your suggestion), but when I havean apple  and call it, it gives an error because it looks for a _javascript_: org.apache.cocoon.ResourceNotFoundException: Function"_javascript_:Package.MyClass()"I

Re: Problems with Last Modified Header using ResourceReader

Gernot Koller wrote: Hi! We have some strange effects here. It seems that the lastmodified header set by the ResourceReader only sometimes reflects the actual Last-Modified Timestamp from the file system. ... This is Cocoon Version 2.1-M2-dev running on IBM Websphere 4.0 under zOS Any hint

Re: Cocoon Woody

Harald Wehr wrote: Hi Vadim, sorry for writing directly to you, but I did not get an answer to my posting to the developer list. Well, you have to have a bit more patience. I generally agree that image input handling should be present in this way or another in the Woody, but I currently do n

[OT] Flow and Scheme

Which scheme implementation was used for the original implementation of flow, or did somebody create their own? Is it still available? Thanks! -Brian

Re: [proposal] Cleaning up our component library

Carsten Ziegeler wrote: Joerg Heinicke wrote: So alltogether: a) Components that are just renamed or replaced with only sitemap changes (FileGenerator => XMLGenerator, DirectoryGenerator => TraversableGenerator (or however it is called ;-) ), StreamGenerator => XMLGenerator + ModuleSource)

[flowscript] How to set an integer value in the FlowScript?

I have a little problem when setting a value of a Woody widget which is type integer in the FlowScript: "Tried to set value of output widget "repeater.offset" with an object of an incorrect type: expected class java.lang.Integer, received class java.lang.Double." The JavaScript code is simple: off

RE: [proposal] Cleaning up our component library

Joerg Heinicke wrote: > So alltogether: > > a) Components that are just renamed or replaced with only sitemap > changes (FileGenerator => XMLGenerator, DirectoryGenerator => > TraversableGenerator (or however it is called ;-) ), StreamGenerator => > XMLGenerator + ModuleSource) are deprecated i

ServletException in JSPGenerator.generate()

This error ocurr frecuently but in list mailing what i visited isn't the definitive solution.   Only i found to copy jasper-compiler.jar in /WEB-INF/lib/ but it don't succeed.   Any idea?   Thanks   Best desires   --    Elvira Nieto Carretero   Isotrol, S.A.  

RE: [OT] Blogs, RSS

> For Eclipse really EVERYTHING seems to be available :) I prefer the > integration into the browser, not the IDE. I use Newsmonster (http://www.newsmonster.org/) which is a Mozilla plugin. It isn't free of bugs (maybe using a newer Firebird or Mozilla version or the use of the commercial Newsm

RE: [proposal] Cleaning up our component library

From: Joerg Heinicke > One problem often mentioned is that Cocoon provides to many > possibilities to achieve some goals. Cocoon's flexibility > ends where it > is more confusing than helpful. Therefore I want to propose to > remove/deprecate the components that are no longer the correct way

AW: Cocoon performance results

Hi Arje, you're right. We use the tool from http://joedog.org/siege/index.php. I have updated the "Scenario 1" page in the Wiki on how to use it and attached the awk script that generates the "... pages delivered in interval ..." as well. Best regards Lars >-Ursprüngliche Nachricht-

Re: testing cocoon components

Leszek Gawron wrote: Hello, Is there a way to test the cocoon component without the need to do HTTP requests? Of course. Look into src/test and specifically o.a.c.SitemapComponentTestCase. Ugo

Re: [proposal] Cleaning up our component library

On 28.01.2004 07:52, Bertrand Delacretaz wrote: One problem often mentioned is that Cocoon provides to many possibilities to achieve some goals. Cocoon's flexibility ends where it is more confusing than helpful. Therefore I want to propose to remove/deprecate the components that are no longer t

Re: [proposal] Cleaning up our component library

On 28.01.2004 10:55, Andreas Hartmann wrote: b) maybe add an option to throw an exception when such components are used ("strict deprecation") This sounds very useful. There are some non-IDE users in our community who aren't that much aware of deprecation. Could it be switched on/off globally?

Problems with Last Modified Header using ResourceReader

Hi! We have some strange effects here. It seems that the lastmodified header set by the ResourceReader only sometimes reflects the actual Last-Modified Timestamp from the file system. Most of the time the last modified header is set to the current time. Which has the effect that the browsers ca

Re: [proposal] Cleaning up our component library

Bertrand Delacretaz wrote: Le Mercredi, 28 jan 2004, à 02:40 Europe/Zurich, Joerg Heinicke a écrit : [...] ...I propose to deprecate those components in 2.1 and to remove them in 2.2... In cases where this just needs sitemap changes, no problem. But if deprecation requires code changes to exi

RE: source resolving in 2.2

Unico Hommes wrote: > > Ah, ok, so what do you think of using that then? > > I just noticed that the key for the processor is just > > "treeprocessor", what do you think of using a more qualified > > name like org.apache.cocoon.Processor or the name of the > > implementation? > > > > Yes, that was

testing cocoon components

Hello, Is there a way to test the cocoon component without the need to do HTTP requests? -- Leszek Gawron

RE: source resolving in 2.2

Carsten Ziegeler wrote: > > Unico Hommes wrote: > > > > The Processor currently is already available to a > ProcessingNode from > > the Context so a ProcessingNode implementing > Contextualizable will be > > able to get to the EnvironmentHelper via that route. > > > Ah, ok, so what do you t

RE: source resolving in 2.2

Unico Hommes wrote: > > The Processor currently is already available to a ProcessingNode from > the Context so a ProcessingNode implementing Contextualizable will be > able to get to the EnvironmentHelper via that route. > Ah, ok, so what do you think of using that then? I just noticed that the k

RE: Cocoon performance results

Lars, Can you tell me what software you use to run your tests? Is that Siege from http://joedog.org/siege/index.php? I would like to run the same configuration to see how my settings perform. If more people could run the same test we could make a nice graph of what platform / config runs best.

RE: DO NOT REPLY [Bug 25356] - [Slide block] Revamping of Slide integration

Joerg Heinicke wrote: > > On 27.01.2004 17:08, [EMAIL PROTECTED] wrote: > > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25356 > > > > [Slide block] Revamping of Slide integration > > > > [EMAIL PROTECTED] changed: > > > >What|Removed |Added > > > -

RE: source resolving in 2.2

Carsten Ziegeler wrote: > > Sylvain Wallez wrote: > > Two suggestions regarding sourceResolver and redirector: > > > > SourceResolver (the Cocoon one) is a legacy requirement because we > > can't change the interface of actions, generators, etc, and > is used by > > the Processor (for Actions

Re: [proposal] Cleaning up our component library

On Jan 28, 2004, at 8:43 AM, Ralph Goers wrote: We'd love to use Woody (aka Cocoon Forms), but if it can be used without FlowScript it isn't obvious. Woody and FlowScript should be totally independent from each other. Much of the fun stuff lately has been done in the JS utility library, but

RE: source resolving in 2.2

Sylvain Wallez wrote: > Two suggestions regarding sourceResolver and redirector: > > SourceResolver (the Cocoon one) is a legacy requirement because we can't > change the interface of actions, generators, etc, and is used by the > Processor (for Actions) and the pipelines (for SitemapModelCompon

Re: FW: [proposal] Cleaning up our component library

On Wed, 2004-01-28 at 08:43, Ralph Goers wrote: > > We'd love to use Woody (aka Cocoon Forms), but if it can be used without > FlowScript it isn't obvious. So we will be using the > SimpleFormTransformer etc., for the forseeable future. Woody doesn't require flowscript. While flowscript integra

processing dynamically genereated xml

Hi, The data from a form is bound to a XML data model (with Woody). Now i want to show this XML-document (with some kind of stylesheet) without having to write it to a file first or with another (static) file: dynamically. i looked at the 'Order Page' example (http://ts:8080/forms/samples/stream/

Re: [proposal] Cleaning up our component library

Le Mercredi, 28 jan 2004, à 02:40 Europe/Zurich, Joerg Heinicke a écrit : One problem often mentioned is that Cocoon provides to many possibilities to achieve some goals. Cocoon's flexibility ends where it is more confusing than helpful. Therefore I want to propose to remove/deprecate the comp

Re: CVS build broken, missing PageLocalScopeHolder

Sorry, my bad. Should be fixed now. it is - thanks! -Bertrand

FW: [proposal] Cleaning up our component library

Darn. Meant for this to go to the list, not to you directly. -Original Message- From: Ralph Goers To: 'Joerg Heinicke ' Sent: 1/27/2004 9:06 PM Subject: RE: [proposal] Cleaning up our component library I realise I am fairly new to Cocoon and my opinion probably doesn't carry as much weigh

Re: CVS build broken, missing PageLocalScopeHolder

Sorry, my bad. Should be fixed now. Bertrand Delacretaz wrote: Current CVS does not compile here, looks like the PageLocalScopeHolder class source code is missing: src/java/org/apache/cocoon/components/flow/javascript/fom/ FOM_Cocoon.java:238: cannot resolve symbol symbol : class PageLocalSc

CVS build broken, missing PageLocalScopeHolder

Current CVS does not compile here, looks like the PageLocalScopeHolder class source code is missing: src/java/org/apache/cocoon/components/flow/javascript/fom/ FOM_Cocoon.java:238: cannot resolve symbol symbol : class PageLocalScopeHolder location: class org.apache.cocoon.components.flow.jav