Re: the multipartparser

[Jorg Heymans]

Micah Dubinko wrote:
I want to get involved in Cocoon more, and wonder if this would be a 
good project to cut my teeth on.

So, provided nobody objects, I'd like to volunteer to take on this 
little project. I'm sure I'll have some questions along the way, but 
nothing the fine folks on IRC or this list can't handle.
well i actually already started this - but that shouldn't stop you from 
doing the same thing :)

Jorg

DO NOT REPLY [Bug 31649] - [Patch] Flowscript: Switch to re-implementation of official Rhino

[bugzilla]

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://issues.apache.org/bugzilla/show_bug.cgi?id=31649

[Patch] Flowscript: Switch to re-implementation of official Rhino





--- Additional Comments From [EMAIL PROTECTED]  2004-11-03 07:43 ---
Reinhard Poetz wrote:

> When did you commit those changes?

That was on 2004-10-31.

RE: CForms: widget states added

[Bart Molenkamp]

Does it fix this one?
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27598

Bart.

> -Original Message-
> From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 02, 2004 11:12 AM
> To: [EMAIL PROTECTED]
> Subject: CForms: widget states added
> 
> Hi all,
> 
> I finally added widget states to CForms. All widgets can have a
"state"
> attribute withe the values "active" (the default), "disabled" or
> "invisible", which are defined in a new WidgetState class.
> 
> In disable state, values are displayed, but are not read from the
> request. In invisible state, nothing is displayed (not even labels)
and
> values are of course not read from the request. The stylesheets have
> been updated so that disabled widgets are displayed using disabled
html
> inputs (eh!).
> 
> Tim, this new widget state feature conflicts with your
> "getProcessingRequests()" stuff in 2.2, and I think your "swan"
> experiment could be updated to use widget states.
> 
> Sylvain
> 
> --
> Sylvain Wallez  Anyware Technologies
> http://www.apache.org/~sylvain   http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

XMLSerializer Reference

[Rokibul Islam Khan]

Hi folks,

Do u know any reference for customizing xmlserializer ?

Thanx in advance

 

rokib

Re: latest Moin

[Reinhard Poetz]

Upayavira wrote:
Reinhard Poetz wrote:
Is the content of the right-side bar customizable so that we get our 
former menu back?

What you mean you want a customisable right side bar? Not just a right 
side bar? Fussy eh? ;-)

More seriously, I believe there is a way to configure the options, 
somewhere behind the scenes, but not via the wiki interface.
Not sure if we speak of the same. What I want is the content of 
http://wiki.apache.org/cocoon/SiteNavigation in the menu. Without a menu that 
leads to all pages I have the sense of a big mess.

--
Reinhard

DO NOT REPLY [Bug 31649] - [Patch] Flowscript: Switch to re-implementation of official Rhino

[bugzilla]

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://issues.apache.org/bugzilla/show_bug.cgi?id=31649

[Patch] Flowscript: Switch to re-implementation of official Rhino





--- Additional Comments From [EMAIL PROTECTED]  2004-11-03 07:08 ---
When did you commit those changes?

RE: Questions to be answered for link request - V3

[H . vanderLinden]

After some time I found some questions we could ask. I added them below.

If nobody has any objections to the text below I will make two Bugzilla
entries on Monday: one as sample entry and one as a request to update the
Livesites directions with the information below.

Bye, Helma

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] 
> Sent: Friday, 22 October, 2004 13:06
> To: [EMAIL PROTECTED]
> Subject: RE: Questions to be answered for link request - V2
> 
> 
> Good comments by Bertrand and David, so I'll integrate them 
> in the original text to get a better idea of the end result.
> 
> ---
> How to get listed
> 
> If you do not find your site here, make sure you tell us. 
> Please follow the instructions below, or we will not be able 
> to honor your request. 
>  
> - Create an entry in Bugzilla following these instructions. 
> You will find an example here [[link to sample entry]]:
> 
> - select the usual options for submitting a patch.
> - Enter a summary like this: [Link] NameOfYourSite
>  
> - In the comments, please answer the following questions:
>  
> URL of the website:

If the website is actually an intranet, can you provide some screenshots?

> Title of the website (to be used on the Livesites page):

Note: add '(intranet)' to the title if necessary.

> Cocoon version used:
> Short summary of your site:
> 
> How can we verify this site is actually built with Cocoon?
> 
> If you agree, answering the following questions helps 
> potential Cocoon users to find references that are similar to 
> their needs. But there's no obligation if you don't want to 
> disclose that kind of information.
> 
> - How much time did it take to build the site from design to publish?
> - How many people were involved in the project?
> - How much traffic does the site handle?
> - What made you choose Cocoon to build the site?
> - What other information do you want to disclose (e.g. how 
> does it work, how did you build it, what parts of Cocoon did you use)?

- Can you provide a contact email address if people want further
information?

- If you have already provided the same/a similar link for the Livesites
pages, please state it here and indicate if this link should be replaced
with the above information or if it should be kept as well.

> 
> Thank you for helping spread the word about Cocoon!
> 
> --
> Bye, Helma
> 

Re: Implementation of the Continuations checker

[Henrik Gustafsson]

From: "Giacomo Pati" <[EMAIL PROTECTED]>
Ok, guys, lets see if we can find a consensus for this issue.
The issues have been:
- Excalibur Event package is deprecated. We need a replacement of those
  functionalities we are in need for the core (scheduling Runnables once,
  with delays, periodically)
- Some stated that the cron block seems too heavy for that (I take that as
  a veto :-)
- I'd like to have Thread spawning in one single component so that users
  of "sophisticated" EAS can write their own implementation of the
  following proposed interfaces.
A BackgroundManager/AsyncManager (name it as you like) manages ThreadPools 
(named and anonymous ones) and executions of Runnables using them:

  interface ThreadPool {
void execute( Runnable command );
TYPE getPROPERTY(); // what ever values should be exposed
  }
  interface BackgroundManager {
void execute( Runnable command );   *1 *a
void execute( Runnable command,
  long delay ); *1 *b
void execute( Runnable command,
  long delay,
  long period );*1 *c
void execute( String threadPoolName,
  Runnable command );   *2 *a
void execute( String threadPoolName,
  Runnable command,
  long delay ); *2 *b
void execute( String threadPoolName,
  Runnable command,
  long delay,
  long period );*2 *c
ThreadPool createPool( String name, ... ) *3
ThreadPool createPool( ... ) *4
  }
  *1 runs a Runnable in the default ThreadPool
  *2 runs a Runnable in a named ThreadPool
  *3 creates a named ThreadPool (shared usage of ThreadPools)
  *4 creates a anonymous ThreadPool (private usage by some client)
  *a runs command once
  *b runs command after a delay
  *c runs command periodically after a delay
A DefaultBackgroundManager implementation will create ThreadPools based on 
one of concurrent-utils Executors depending on the configuration (this is 
ready to use code from the cron block).

The settings of the default ThreadPool will be based on the current 
CommandManager configuration. The configuration of the default ThreadPool 
can be overwritten using normal configuration methods (see 
src/blocks/cron/conf/cron.xconf adding a name attribute). Named 
ThreadPools can be created at strartup by configuration.

What do you think about this as a replacement for the Event package?
And you will never need to cancel a scheduled command, or?
/Henrik Gustafsson 

Re: Implementation of the Continuations checker

[Giacomo Pati]

On Tue, 2 Nov 2004, Vadim Gritsenko wrote:
Giacomo Pati wrote:
Ok, guys, lets see if we can find a consensus for this issue.
The issues have been:
- Excalibur Event package is deprecated. We need a replacement of those
functionalities we are in need for the core (scheduling Runnables once,
with delays, periodically)
- Some stated that the cron block seems too heavy for that (I take that 
as
 a veto :-)
- I'd like to have Thread spawning in one single component so that users
of "sophisticated" EAS can write their own implementation of the
following proposed interfaces.

A BackgroundManager/AsyncManager (name it as you like) manages 
ThreadPools (named and anonymous ones) and executions of Runnables using 
them:

interface ThreadPool {
void execute( Runnable command );
TYPE getPROPERTY(); // what ever values should be exposed
}
interface BackgroundManager {
void execute( Runnable command );   *1 *a
void execute( Runnable command,
 long delay ); *1 *b
void execute( Runnable command,
long delay,
long period );*1 *c
void execute( String threadPoolName,
 Runnable command );   *2 *a
void execute( String threadPoolName,
Runnable command,
long delay ); *2 *b
void execute( String threadPoolName,
Runnable command,
long delay,
long period );*2 *c
ThreadPool createPool( String name, ... ) *3
ThreadPool createPool( ... ) *4
}
*1 runs a Runnable in the default ThreadPool
*2 runs a Runnable in a named ThreadPool
*3 creates a named ThreadPool (shared usage of ThreadPools)
*4 creates a anonymous ThreadPool (private usage by some client)
*a runs command once
*b runs command after a delay
*c runs command periodically after a delay
A DefaultBackgroundManager implementation will create ThreadPools based 
on one of concurrent-utils Executors depending on the configuration (this 
is ready to use code from the cron block).

The settings of the default ThreadPool will be based on the current 
CommandManager configuration. The configuration of the default ThreadPool 
can be overwritten using normal configuration methods (see 
src/blocks/cron/conf/cron.xconf adding a name attribute). Named 
ThreadPools can be created at strartup by configuration.

What do you think about this as a replacement for the Event package?
Looks good to me (disclaimer: I've not examined event pacjage). One question: 
why multiple thread pools?
Have you looked at the thread pool in the cron block?
A thread pool consists of:
  - max. # of threads that run simultaneously
  - a possible queue to stack up ready to run Runnables
If you have a lot of short living Runnables at low priority (logically) 
you'd prefere to have a thread pool with only a few threads ready but a 
large queue. If you have some long running jobs to be done you'd like to 
have a pool of many threads. Thread pools is the way to balance "work to 
be done" with "resources needed for".

--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com

Re: Implementation of the Continuations checker

[Vadim Gritsenko]

Giacomo Pati wrote:
Ok, guys, lets see if we can find a consensus for this issue.
The issues have been:
- Excalibur Event package is deprecated. We need a replacement of those
  functionalities we are in need for the core (scheduling Runnables once,
  with delays, periodically)
- Some stated that the cron block seems too heavy for that (I take that as
  a veto :-)
- I'd like to have Thread spawning in one single component so that users
  of "sophisticated" EAS can write their own implementation of the
  following proposed interfaces.
A BackgroundManager/AsyncManager (name it as you like) manages 
ThreadPools (named and anonymous ones) and executions of Runnables using 
them:

  interface ThreadPool {
void execute( Runnable command );
TYPE getPROPERTY(); // what ever values should be exposed
  }
  interface BackgroundManager {
void execute( Runnable command );   *1 *a
void execute( Runnable command,
  long delay ); *1 *b
void execute( Runnable command,
  long delay,
  long period );*1 *c
void execute( String threadPoolName,
  Runnable command );   *2 *a
void execute( String threadPoolName,
  Runnable command,
  long delay ); *2 *b
void execute( String threadPoolName,
  Runnable command,
  long delay,
  long period );*2 *c
ThreadPool createPool( String name, ... ) *3
ThreadPool createPool( ... ) *4
  }
  *1 runs a Runnable in the default ThreadPool
  *2 runs a Runnable in a named ThreadPool
  *3 creates a named ThreadPool (shared usage of ThreadPools)
  *4 creates a anonymous ThreadPool (private usage by some client)
  *a runs command once
  *b runs command after a delay
  *c runs command periodically after a delay
A DefaultBackgroundManager implementation will create ThreadPools based 
on one of concurrent-utils Executors depending on the configuration 
(this is ready to use code from the cron block).

The settings of the default ThreadPool will be based on the current 
CommandManager configuration. The configuration of the default 
ThreadPool can be overwritten using normal configuration methods (see 
src/blocks/cron/conf/cron.xconf adding a name attribute). Named 
ThreadPools can be created at strartup by configuration.

What do you think about this as a replacement for the Event package?
Looks good to me (disclaimer: I've not examined event pacjage). One question: 
why multiple thread pools?

I'd imaging the need for different task priorities (cinclude is normal priority, 
janitor is high), but what are the use cases for multiple thread pools?

Vadim

Re: [GUMP@brutus]: Project cocoon-block-proxy (in module cocoon) failed

[Stefano Mazzocchi]

Antonio Gallardo wrote:
Stefano Mazzocchi dijo:
Antonio Gallardo wrote:

Stefano Mazzocchi dijo:

Gump wrote:

cocoon-block-proxy-compile:
  [javac] Compiling 4 source files to
/home/gump/workspaces2/public/workspace/cocoon/build/cocoon-02112004/blocks/proxy/dest
  [javac]
/home/gump/workspaces2/public/workspace/cocoon/src/blocks/proxy/java/org/apache/cocoon/generation/HttpProxyGenerator.java:294:
cannot resolve symbol
  [javac] symbol  : method getRequestBodyAsString ()
  [javac] location: class
org.apache.commons.httpclient.methods.PostMethod
  [javac] String body = ((PostMethod)
this.method).getRequestBodyAsString();
  [javac]   ^
  [javac] 1 error
I don't know how to fix this one from the gump side, it needs some code
changes since httpclient change a lot since this code was created.
Any ideas?

I saw the code of httpclient 2.0.x and 3.0 and it is quite diferent.
They
are changing a lot in the new 3.0.x release. If we want gump compile
this
block, we need to add a dependency to our own distributed jar version
2.0.2.
I know this is a hack. The other way is to see more in depth and find a
way to compile code using both httpclient 2.0.2 and 3.0 too.
WDYT?
That build is against the 2.0.x branch.

Its posible in the CVS version.
In the javadocs for release 2.0.2, the PostMethod. Because is direct
derived from EntityEnclosingMethod:
http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/methods/PostMethod.html
Now go to the CVS. in the HTTPCLIENT_2_0_BRANCH We still see the
method getRequestBodyAsString() inside:
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/methods/EntityEnclosingMethod.java?rev=1.18.2.5&only_with_tag=HTTPCLIENT_2_0_BRANCH&view=markup
...
I am not a CVS guru, but in the HEAD (3.0 release) there is not the method.
Seems like they broke a contract? I mean removing a method without
deprecate it first?
yeah, they did, but what I don't  understand is why we didn't build 
against HTTPCLIENT_2_0_BRANCH.

puzzled.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

DO NOT REPLY [Bug 31649] - [Patch] Flowscript: Switch to re-implementation of official Rhino

[bugzilla]

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://issues.apache.org/bugzilla/show_bug.cgi?id=31649

[Patch] Flowscript: Switch to re-implementation of official Rhino





--- Additional Comments From [EMAIL PROTECTED]  2004-11-02 23:51 ---
Reinhard Poetz wrote:

> For now I keep this issue open in order to remind (me) that the patch
disabling invoker optimization has to be applied. 

I did some testing and it seems that with JDK 1.4.2 and especially with 1.5 the
invoker optimization does not have noticeable improvements even with tailored
script/Java bindings usage to justify the memory overhead of generated code or
potential class loader troubles. So I disabled that by default in Rhino from
cvs.mozilla.org.

DO NOT REPLY [Bug 31649] - [Patch] Flowscript: Switch to re-implementation of official Rhino

[bugzilla]

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://issues.apache.org/bugzilla/show_bug.cgi?id=31649

[Patch] Flowscript: Switch to re-implementation of official Rhino





--- Additional Comments From [EMAIL PROTECTED]  2004-11-02 23:40 ---
I switched to rhino-1.6 in trunk. For now I keep this issue open in order to
remind (me) that the patch disabling invoker optimization has to be applied.

Re: svn commit: rev 56438 - cocoon/trunk/src/blocks/javaflow/java/org/apache/cocoon/components/flow/javascript

[Reinhard Poetz]

Reinhard Poetz wrote:
[EMAIL PROTECTED] wrote:
Author: reinhard
Date: Tue Nov  2 15:20:30 2004
New Revision: 56438
Modified:
   
cocoon/trunk/src/blocks/javaflow/java/org/apache/cocoon/components/flow/javascript/JavaScriptCompilingClassLoader.java 

Log:
Because of switching to rhino-1.6 it doesn't compile any more - had to 
comment out two lines to make code compile again. Due to Torsten the 
compiling classloader doesn't work anyway

Modified: 
cocoon/trunk/src/blocks/javaflow/java/org/apache/cocoon/components/flow/javascript/JavaScriptCompilingClassLoader.java 

== 

--- 
cocoon/trunk/src/blocks/javaflow/java/org/apache/cocoon/components/flow/javascript/JavaScriptCompilingClassLoader.java
(original)
+++ 
cocoon/trunk/src/blocks/javaflow/java/org/apache/cocoon/components/flow/javascript/JavaScriptCompilingClassLoader.java
Tue Nov  2 15:20:30 2004
@@ -104,7 +104,8 @@
 cx.setErrorReporter(reporter);
  cx.setGeneratingSource(true);
-cx.setTargetPackage("");
+// doesn't compile with Rhino 1.6 +// 
cx.setTargetPackage("");
 
 //ClassNameHelper nameHelper = ClassNameHelper.get(cx);
 String filename = ((String) sources.get(classname))+".js";
@@ -124,7 +125,9 @@
 //String out = f.getParent() == null ? className : 
f.getParent() + File.separator + className;
 String out = System.getProperty("java.io.tmpdir") + 
File.separator + className;
 //nameHelper.setTargetClassFileName(out);*/
-cx.setTargetClassFileName(out);
++// doesn't compile with Rhino 1.6 +// 
cx.setTargetClassFileName(out);
 
 System.out.println("out=" + out);
 

Torsten,
hope my comment is correct ...
forgot to mention that Javaflow doesn't work for me at the moment but I can't 
imagine that this is due to my change:

FlowNode: Couldn't obtain a flow interpreter for 'java' at 
file:/F:/os/cocoon/trunk/build/webapp/samples/blocks/javaflow/sitemap.xmap:33:28 
(Key='java')

org.apache.avalon.framework.service.ServiceException: FlowNode: Couldn't obtain 
a flow interpreter for 'java' at 
file:/F:/os/cocoon/trunk/build/webapp/samples/blocks/javaflow/sitemap.xmap:33:28 
(Key='java')
	at 
org.apache.cocoon.components.treeprocessor.sitemap.FlowNode.service(FlowNode.java:68)
	at 
org.apache.cocoon.components.LifecycleHelper.setupComponent(LifecycleHelper.java:152)
	at 
org.apache.cocoon.components.LifecycleHelper.setupComponent(LifecycleHelper.java:106)
	at 
org.apache.cocoon.components.treeprocessor.DefaultTreeBuilder.setupNode(DefaultTreeBuilder.java:369)
	at 
org.apache.cocoon.components.treeprocessor.sitemap.FlowNodeBuilder.buildNode(FlowNodeBuilder.java:38)
...

--
Reinhard

Re: svn commit: rev 56438 - cocoon/trunk/src/blocks/javaflow/java/org/apache/cocoon/components/flow/javascript

[Reinhard Poetz]

[EMAIL PROTECTED] wrote:
Author: reinhard
Date: Tue Nov  2 15:20:30 2004
New Revision: 56438
Modified:
   
cocoon/trunk/src/blocks/javaflow/java/org/apache/cocoon/components/flow/javascript/JavaScriptCompilingClassLoader.java
Log:
Because of switching to rhino-1.6 it doesn't compile any more - had to comment out two 
lines to make code compile again. Due to Torsten the compiling classloader doesn't 
work anyway
Modified: cocoon/trunk/src/blocks/javaflow/java/org/apache/cocoon/components/flow/javascript/JavaScriptCompilingClassLoader.java
==
--- cocoon/trunk/src/blocks/javaflow/java/org/apache/cocoon/components/flow/javascript/JavaScriptCompilingClassLoader.java	(original)
+++ cocoon/trunk/src/blocks/javaflow/java/org/apache/cocoon/components/flow/javascript/JavaScriptCompilingClassLoader.java	Tue Nov  2 15:20:30 2004
@@ -104,7 +104,8 @@
 cx.setErrorReporter(reporter);
 
 cx.setGeneratingSource(true);
-cx.setTargetPackage("");
+// doesn't compile with Rhino 1.6 
+// cx.setTargetPackage("");
 
 //ClassNameHelper nameHelper = ClassNameHelper.get(cx);
 String filename = ((String) sources.get(classname))+".js";
@@ -124,7 +125,9 @@
 //String out = f.getParent() == null ? className : f.getParent() + File.separator + className;
 String out = System.getProperty("java.io.tmpdir") + File.separator + className;
 //nameHelper.setTargetClassFileName(out);*/
-cx.setTargetClassFileName(out);
+
+// doesn't compile with Rhino 1.6 
+// cx.setTargetClassFileName(out);
 
 System.out.println("out=" + out);
 

Torsten,
hope my comment is correct ...
--
Reinhard

Re: [lazy vote] cforms request processing

[Sylvain Wallez]

Antonio Gallardo wrote:
Hi Tim:
As I told before I am not sure. I really want to see what the other people
will said here. I also already saw that Sylvain voted +1 for the changes.
But I am not sure if this is correct or not. That is all.
 

Yes, I'm +1. Or +10, +100 and even +1000 :-)
This issue has raised a number of questions from users seeing some 
fields unexpectedly loosing their values, and has been discussed at length.

The only visible change, as stated by Tim, is the need for boolean 
fields to be accompanied by a "presence notifier" input, whose purpose 
is to indicate that a boolean field is present in the form. This is 
required to circumvent the fact that HTML sends nothing for an unchecked 
checkbox, and therefore doesn't allow to know if the chekbox is present 
but unchecked, or is absent in the page.

This has absolutely no impact on the fact that only widgets present in 
the form read request parameters, and that therefore no one can input 
value that doesn't match a widget.

Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: [lazy vote] cforms request processing

[Sylvain Wallez]

Nuno Santos wrote:
The Request interface has a method to get an enumeration of parameter
names( getParameterNames), so just check the existence of the widget
Request parameter name and process only if exist!
 

We don't need to enumerate parameters, as each widget knows which 
parameters it should consider. The discussion here is about widgets 
whose request parameters are *not* present, and who therefore see their 
value reset to null. We want to avoid this.

Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: [lazy vote] cforms request processing

[Sylvain Wallez]

Jason Johnston wrote:
On Tue, 2004-11-02 at 13:55, Tim Larson wrote:
 

We would still perform validation.  The only thing we would not do
is automatically reset a widget's value to null when its request
parameter is missing.  Because we would still validate the widget,
"required" widgets would still catch empty values like they do now.
   

Thanks for the clarification.  I was under the impression that the main
use-case for this new behavior was to be able to have a single form
split up across multiple views (multi-page forms) and not have a single
view fail validation if there is a required field not present in that
view (as is currently the case).  I can infer from your answer that this
is not the use-case you're tackling with this change.
 

You're right, but the use case you outline is now possible with the new 
widget states I committed today: a form can be split into several groups 
(fd:struct widgets), each representing the contents of a page.

At first, only one group is in state "active" and all others in state 
"invisible". Each group contains navigation actions that will validate 
the current group and, if successful, set the current group invisible 
and the next one active (or the previous one, to handle both prev/next 
navigation).

Simple and efficient way to build wizards.
Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: [lazy vote] cforms request processing

[Jason Johnston]

On Tue, 2004-11-02 at 13:55, Tim Larson wrote:
> 
> We would still perform validation.  The only thing we would not do
> is automatically reset a widget's value to null when its request
> parameter is missing.  Because we would still validate the widget,
> "required" widgets would still catch empty values like they do now.

Thanks for the clarification.  I was under the impression that the main
use-case for this new behavior was to be able to have a single form
split up across multiple views (multi-page forms) and not have a single
view fail validation if there is a required field not present in that
view (as is currently the case).  I can infer from your answer that this
is not the use-case you're tackling with this change.

Thanks again
--Jason

Re: Implementation of the Continuations checker

[Giacomo Pati]

Ok, guys, lets see if we can find a consensus for this issue.
The issues have been:
- Excalibur Event package is deprecated. We need a replacement of those
  functionalities we are in need for the core (scheduling Runnables once,
  with delays, periodically)
- Some stated that the cron block seems too heavy for that (I take that as
  a veto :-)
- I'd like to have Thread spawning in one single component so that users
  of "sophisticated" EAS can write their own implementation of the
  following proposed interfaces.
A BackgroundManager/AsyncManager (name it as you like) manages ThreadPools 
(named and anonymous ones) and executions of Runnables using them:

  interface ThreadPool {
void execute( Runnable command );
TYPE getPROPERTY(); // what ever values should be exposed
  }
  interface BackgroundManager {
void execute( Runnable command );   *1 *a
void execute( Runnable command,
  long delay ); *1 *b
void execute( Runnable command,
  long delay,
  long period );*1 *c
void execute( String threadPoolName,
  Runnable command );   *2 *a
void execute( String threadPoolName,
  Runnable command,
  long delay ); *2 *b
void execute( String threadPoolName,
  Runnable command,
  long delay,
  long period );*2 *c
ThreadPool createPool( String name, ... ) *3
ThreadPool createPool( ... ) *4
  }
  *1 runs a Runnable in the default ThreadPool
  *2 runs a Runnable in a named ThreadPool
  *3 creates a named ThreadPool (shared usage of ThreadPools)
  *4 creates a anonymous ThreadPool (private usage by some client)
  *a runs command once
  *b runs command after a delay
  *c runs command periodically after a delay
A DefaultBackgroundManager implementation will create ThreadPools based on 
one of concurrent-utils Executors depending on the configuration (this is 
ready to use code from the cron block).

The settings of the default ThreadPool will be based on the current 
CommandManager configuration. The configuration of the default ThreadPool 
can be overwritten using normal configuration methods (see 
src/blocks/cron/conf/cron.xconf adding a name attribute). Named 
ThreadPools can be created at strartup by configuration.

What do you think about this as a replacement for the Event package?
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com

Re: the multipartparser

[Micah Dubinko]

I want to get involved in Cocoon more, and wonder if this would be a 
good project to cut my teeth on.

So, provided nobody objects, I'd like to volunteer to take on this 
little project. I'm sure I'll have some questions along the way, but 
nothing the fine folks on IRC or this list can't handle.

.micah
Ugo Cei wrote:
Il giorno 02/nov/04, alle 15:29, Jorg Heymans ha scritto:
Is there a reason why we have our own multipart parser instead of 
using commons-fileupload? This has come up already about 1.5 years 
ago [1].

Maybe when the multipart parser was invented, commons-fileupload 
wasn't yet there, or maybe it wasn't known or it was just a case of 
NIH syndrome. Anyway, if we can get the same functionality with 
commons-upload, let's drop this other reinvented wheel. +1 if you 
volunteer to do it.

Ugo

Re: Persisting SimpleLuceneQuery [Long]

[Antonio Gallardo]

Hi Jeremy:

I was suddenly busy again. Sorry for that.

But, I don't forgot about this mail. In the last weekend, I tried to see
at the Lucene sample, but it was not working. :-(

Fortunately, Sylvain fixed the small bug. Now it working again! I will
update OJB to 1.0.1 and then we will be ready to start this "game". OK?
;-)

Best Regards,

Antonio Gallardo

Re: [GUMP@brutus]: Project cocoon-block-proxy (in module cocoon) failed

[Antonio Gallardo]

Stefano Mazzocchi dijo:
> Antonio Gallardo wrote:
>
>> Stefano Mazzocchi dijo:
>>
>>>Gump wrote:
>>>
>>>
cocoon-block-proxy-compile:
[javac] Compiling 4 source files to
/home/gump/workspaces2/public/workspace/cocoon/build/cocoon-02112004/blocks/proxy/dest
[javac]
/home/gump/workspaces2/public/workspace/cocoon/src/blocks/proxy/java/org/apache/cocoon/generation/HttpProxyGenerator.java:294:
cannot resolve symbol
[javac] symbol  : method getRequestBodyAsString ()
[javac] location: class
org.apache.commons.httpclient.methods.PostMethod
[javac] String body = ((PostMethod)
this.method).getRequestBodyAsString();
[javac]   ^
[javac] 1 error
>>>
>>>I don't know how to fix this one from the gump side, it needs some code
>>>changes since httpclient change a lot since this code was created.
>>>
>>>Any ideas?
>>
>>
>> I saw the code of httpclient 2.0.x and 3.0 and it is quite diferent.
>> They
>> are changing a lot in the new 3.0.x release. If we want gump compile
>> this
>> block, we need to add a dependency to our own distributed jar version
>> 2.0.2.
>>
>> I know this is a hack. The other way is to see more in depth and find a
>> way to compile code using both httpclient 2.0.2 and 3.0 too.
>>
>> WDYT?
>
> That build is against the 2.0.x branch.

Its posible in the CVS version.

In the javadocs for release 2.0.2, the PostMethod. Because is direct
derived from EntityEnclosingMethod:

http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/methods/PostMethod.html

Now go to the CVS. in the HTTPCLIENT_2_0_BRANCH We still see the
method getRequestBodyAsString() inside:

http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/methods/EntityEnclosingMethod.java?rev=1.18.2.5&only_with_tag=HTTPCLIENT_2_0_BRANCH&view=markup

...

I am not a CVS guru, but in the HEAD (3.0 release) there is not the method.

Seems like they broke a contract? I mean removing a method without
deprecate it first?

Best Regards,

Antonio Gallardo

Re: Switching rhino implementation

[Antonio Gallardo]

Reinhard Poetz dijo:
> Igor explains the differences here:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109528520325331&w=2

Please wikify that! ;-)

Best Regards,

Antonio Gallardo

Re: [lazy vote] cforms request processing

[Antonio Gallardo]

Hi Tim:

As I told before I am not sure. I really want to see what the other people
will said here. I also already saw that Sylvain voted +1 for the changes.
But I am not sure if this is correct or not. That is all.

Tim Larson dijo:
> On Tue, Nov 02, 2004 at 02:38:24PM -0600, Antonio Gallardo wrote:
>> I see the point.I am more convinced that we are pushing HTTP to the
>> maximum and we need more well, can we implement that only for
>> stateless forms? Why we need to cut all with the same scissors? This is
>> only a thought. ;-)
>
> If necessary, we could implement an in-form config that would
> choose between the two missing-request-parameter behaviors.

that will be better, I guess.

>> >> This can open some posible security concerns at all?
>> >
>> > The form model would still be in control of which request
>> > parameters get processed.  The only change is that a missing
>> > request parameter would cause no change to the corresponding
>> > widget instead of causing it to be reset to null.
>>
>> Somebody else on this thread mentioned about the @required. How we will
>> manage that, if we don't get back the required field? I answered below
>> this question ;-)
>
> Please see my other email for the @required answer.
> Summary: we still validate, the only change is we do not
> automatically reset to null, so @required widgets should
> still work as they do now.
>
>> > Can you
>> > think of any way for this to be exploited?  A client could
>> > change a value that was not made visible by the current page
>> > view, but it would still be subject to the normal validation
>> > rules.
>>
>> Exploited? Not sure, but you can do pretty funny thing with the forms.
>> For
>> example:
>>
>> Given a form that first allow you to select a quantity discount: Said
>> you
>> get 0% discount is you buy 1-10 items, 5% if you buy 11-20 items and 10%
>> if you buy 21 or more items.
>>
>> Suppose the form first ask for the quantity to be buyed and then based
>> on
>> this select a discount. Then you change the quantity to 1 and the
>> discount
>> is already set. I know this is a very dumb sample, but the point I want
>> to
>> show is:
>
> I don't see how this change affects that scenario.
>
>> Under some condition this could allow to hack the form.
>
> Could you give such a sample condition?
>
>> Or what if I sent back an authentication form with empty fields? It hard
>> to think in a sample. And we know we never can trust on the client. This
>> is a basic web development rule. But in this caseI see we are trusting
>> on
>> the client.maybe we need to think a little bit more to see a sample.
>
> Please see the @require answer.
>
>> >> What is the performance impact of that???
>> >
>> > For each checkbox, we would send the client two widgets
>> > instead of one, and on POST we would get two widgets back
>> > instead of one.  This only affects checkboxes, not other
>> > widgets such as fields, repeaters, etc.
>>
>> Remember on the repeaters we have the select boxes. If we are showing 20
>> rows on the repeater we are adding 20 new request params. I remember a
>> system that did that and then they fixed on the next release by allowing
>> users to define wich parameters need to return to the server to improve
>> the performance I just expect this could not be our bottleneck
>> later.
>> More hidden parameters also mean bigger responses (pages).
>
> If it is that bad, we could make a config for it, as mentioned above.
>
>> >> > What do we want to do?
>> >> > [ ] leave as is
>> >> > [ ] make the changes described above
>>
>> Please think about that. I am sure you have the best intentions to
>> improve
>> the cforms-fw. To be honest I am not sure how to vote in this case, so
>> is
>> this is a big problem. I can put a -0 (this is not a VETO) for that.
>> Let's
>> see what the other people has to said about that. ;-)
>
> I do not mean to railroad this issue.  The lazy vote is just to
> get attention put on the issue so we can finally resolve it.
> I am not in a hurry, so let's make sure everybody is comfortable
> with whatever solution(s) we settle on :)
>

All in all, lets believe in our cforms-fw gurus: ;-)

[-0] make the changes described above

Best Regards,

Antonio Gallardo.

Re: [rant] please backport bugfixes to 2.1!

[Tim Larson]

On Tue, Nov 02, 2004 at 11:29:28AM +0100, Sylvain Wallez wrote:
> Unusual for me, but time for a rant: I wrote the new CForms widget state 
> feature in 2.1 and tried to port it to 2.2.
> 
> WHAT A PITA!
> 
> There are a number or *bug fixes* or minor new features that only exist 
> in 2.2. Why aren't they ported also to 2.1?
> 
> Please, please, consider upgrading both branches at the same time. There 
> will be some time before 2.2 is out and not everybody runs a snapshot of 
> trunk.

> Grmbl... lost 2 hours this morning to do the merge, and finally reverted 
> all :-(

Very sorry that you lost time :(  I had not ported my changes
to 2_1_x yet because I was not sure they were ready, but
addmittedly there were some bugfixes included that I should
have ported immediately.

I am working on the port now and have it almost finished,
but I have a few questions about some recent changes that
the commit comments did not make clear to me:

  AbstractWidget.java
From: public Widget getParent()
To:   public final Widget geParent()
  Field.java
From: super validate
To:   super validate && widget != null
  Repeater.java
In inner class RepeaterRow
  From: getParent() returns Repeater.this and
setParent() throws a RuntimeException
  To:   setParent(Repeater.this)
  (This seems to be caused by the AbstractWidget
  change above.)

Could you explain what these changes are for, and then
I can finish the porting.

> Going to port Tim's swan to widget states so that cforms in 2.2 and 2.1 
> can be *identical*.

>From a very quick look at the widget states implementation,
I suspect a few problems will come up while doing this,
but I am sure we can resolve them without too much trouble.

--Tim Larson

Re: [RT] Attribute Rendering and CForms Convertors (was: Templating Engine - Next steps?)

[Jonas Ekstedt]

On Tue, 2004-11-02 at 19:21 +0100, Daniel Fagerstrom wrote:

> Ok, the idea is as follows: we have a converter component, that is like 
> the renderer component above, but bidirectional. I.e. both rendering: 
> data type -> displayable string and input conversion: input string -> 
> data type. The converter is configured in the same way as described for 
> the renderer above.
> 

I've been working along the same line [1] (it's about a widget framework
but contains elements that are relevant to your idea as well). The idea
is that data is wrapped by a model that works directly on my data but
that can perform any conversions, validations etc through its
getValue/setValue functions:

public interface Model {
  public String getValue(String path);
  public void setValue(String path, String value);
}

For example if my data is a bean containing a Date then a
ConvertingBeanModel wrapping my bean would have a getValue function
performing the Date->String conversion (according to whatever locale is
chosen). And vice versa with setValue. The benefit with having an
abstract view of the model would be that you can implement any type of
conversion in the setValue/getValue functions. You could have a generic
set of conversions for the basic types as well as special conversions
unique to your application. Eg. if your underlying data is a resultset
then you can convert values to SQL types rather than java types. 

[1] http://www.mail-archive.com/[EMAIL PROTECTED]/msg23293.html

Cheers Jonas

Re: [lazy vote] cforms request processing

[Tim Larson]

On Tue, Nov 02, 2004 at 02:38:24PM -0600, Antonio Gallardo wrote:
> I see the point.I am more convinced that we are pushing HTTP to the
> maximum and we need more well, can we implement that only for
> stateless forms? Why we need to cut all with the same scissors? This is
> only a thought. ;-)

If necessary, we could implement an in-form config that would
choose between the two missing-request-parameter behaviors.

> >> This can open some posible security concerns at all?
> >
> > The form model would still be in control of which request
> > parameters get processed.  The only change is that a missing
> > request parameter would cause no change to the corresponding
> > widget instead of causing it to be reset to null.
> 
> Somebody else on this thread mentioned about the @required. How we will
> manage that, if we don't get back the required field? I answered below
> this question ;-)

Please see my other email for the @required answer.
Summary: we still validate, the only change is we do not
automatically reset to null, so @required widgets should
still work as they do now.

> > Can you
> > think of any way for this to be exploited?  A client could
> > change a value that was not made visible by the current page
> > view, but it would still be subject to the normal validation
> > rules.
> 
> Exploited? Not sure, but you can do pretty funny thing with the forms. For
> example:
> 
> Given a form that first allow you to select a quantity discount: Said you
> get 0% discount is you buy 1-10 items, 5% if you buy 11-20 items and 10%
> if you buy 21 or more items.
> 
> Suppose the form first ask for the quantity to be buyed and then based on
> this select a discount. Then you change the quantity to 1 and the discount
> is already set. I know this is a very dumb sample, but the point I want to
> show is:

I don't see how this change affects that scenario.

> Under some condition this could allow to hack the form.

Could you give such a sample condition?

> Or what if I sent back an authentication form with empty fields? It hard
> to think in a sample. And we know we never can trust on the client. This
> is a basic web development rule. But in this caseI see we are trusting on
> the client.maybe we need to think a little bit more to see a sample.

Please see the @require answer.

> >> What is the performance impact of that???
> >
> > For each checkbox, we would send the client two widgets
> > instead of one, and on POST we would get two widgets back
> > instead of one.  This only affects checkboxes, not other
> > widgets such as fields, repeaters, etc.
> 
> Remember on the repeaters we have the select boxes. If we are showing 20
> rows on the repeater we are adding 20 new request params. I remember a
> system that did that and then they fixed on the next release by allowing
> users to define wich parameters need to return to the server to improve
> the performance I just expect this could not be our bottleneck later.
> More hidden parameters also mean bigger responses (pages).

If it is that bad, we could make a config for it, as mentioned above.

> >> > What do we want to do?
> >> > [ ] leave as is
> >> > [ ] make the changes described above
> 
> Please think about that. I am sure you have the best intentions to improve
> the cforms-fw. To be honest I am not sure how to vote in this case, so is
> this is a big problem. I can put a -0 (this is not a VETO) for that. Let's
> see what the other people has to said about that. ;-)

I do not mean to railroad this issue.  The lazy vote is just to
get attention put on the issue so we can finally resolve it.
I am not in a hurry, so let's make sure everybody is comfortable
with whatever solution(s) we settle on :)

--Tim Larson

Re: [lazy vote] cforms request processing

[Tim Larson]

On Tue, Nov 02, 2004 at 12:33:48PM -0700, Jason Johnston wrote:
> On Mon, 2004-11-01 at 22:08, Tim Larson wrote:
> > > This can open some posible security concerns at all?
> > 
> > The form model would still be in control of which request
> > parameters get processed.  The only change is that a missing
> > request parameter would cause no change to the corresponding
> > widget instead of causing it to be reset to null.  Can you
> > think of any way for this to be exploited?  A client could
> > change a value that was not made visible by the current page
> > view, but it would still be subject to the normal validation
> > rules.  And if this is an important issue for your use-case,
> > then your page-splitting is a data model (form model)
> > concern rather than a pure view concern and you should have
> > used a union/choose or other *model* means to control it.
> 
> I'm concerned about a particular scenario; perhaps you can explain how
> this would work in the proposed behavior...
> 
> It seems to me that implementing the proposal would make required="true"
> on widget definitions pretty much useless.  IIUC, such widgets would not
> be validated as required if their request parameters were not present. 
> So it would be possible to successfully submit (i.e. encounter no
> validation errors and pass successfully through the form.showForm()
> loop) a single-page form with a blank required field by simply removing
> that field's name from the request.
> 
> This creates a problem where it's no longer guaranteed that the values
> in the form model post-validation are all valid; required widgets can
> have null values (assuming their initial values from form.load() were
> null).
> 
> Is this actually the case in the proposal?  Thoughts on how this can be
> avoided?

We would still perform validation.  The only thing we would not do
is automatically reset a widget's value to null when its request
parameter is missing.  Because we would still validate the widget,
"required" widgets would still catch empty values like they do now.

--Tim Larson

Re: [lazy vote] cforms request processing

[Antonio Gallardo]

Tim Larson dijo:
> On Mon, Nov 01, 2004 at 06:13:21PM -0600, Antonio Gallardo wrote:
>> Tim Larson dijo:
>> > We have talked several times about changing the request
>> > processing in cforms to not touch any widget whose
>> > request parameter is missing (to prevent these widgets'
>> > values from being reset to null,) the end result being
>> > that it would be easier for the view to decide how to
>> > split a form across multiple pages without breaking the
>> > SoC between the form model and the view.
>>
>> Is not posible to do that before sending the page? IMO given blind
>> truting
>> to what the client is sending back is not good at all.
>
> (Please see further down the page for a discussion on the
> security aspects.)
>
> An alternative that has been suggested in the past is to
> collect a list of the widgets present in the view, and to
> use this list to filter which widgets would get to process
> their request parameters upon a POST.  The drawback to
> this approach is that it would not work for stateless
> forms, which is one of the use cases supported by cforms.
>
> Since with stateless forms the form model gets recreated
> on each POST, where would you store the view's widget
> list?  And if the view is dynamic (uses union, choose,
> if, etc.) then you would have to store the list per form
> instance, clearly preventing stateless form semantics.
>
> In contrast, the design presented in this lazy vote would
> cause no problems for stateless form support because it
> does not require storing the list of widgets currently
> present in the view.

I see the point.I am more convinced that we are pushing HTTP to the
maximum and we need more well, can we implement that only for
stateless forms? Why we need to cut all with the same scissors? This is
only a thought. ;-)

>> This can open some posible security concerns at all?
>
> The form model would still be in control of which request
> parameters get processed.  The only change is that a missing
> request parameter would cause no change to the corresponding
> widget instead of causing it to be reset to null.

Somebody else on this thread mentioned about the @required. How we will
manage that, if we don't get back the required field? I answered below
this question ;-)

> Can you
> think of any way for this to be exploited?  A client could
> change a value that was not made visible by the current page
> view, but it would still be subject to the normal validation
> rules.

Exploited? Not sure, but you can do pretty funny thing with the forms. For
example:

Given a form that first allow you to select a quantity discount: Said you
get 0% discount is you buy 1-10 items, 5% if you buy 11-20 items and 10%
if you buy 21 or more items.

Suppose the form first ask for the quantity to be buyed and then based on
this select a discount. Then you change the quantity to 1 and the discount
is already set. I know this is a very dumb sample, but the point I want to
show is:

Under some condition this could allow to hack the form.

Or what if I sent back an authentication form with empty fields? It hard
to think in a sample. And we know we never can trust on the client. This
is a basic web development rule. But in this caseI see we are trusting on
the client.maybe we need to think a little bit more to see a sample.

We (programmers) are not perfect. I remember the infamous non-preemtive
windows 3.1 when you wrote a bad a application you could freeze all the
system.

> And if this is an important issue for your use-case,
> then your page-splitting is a data model (form model)
> concern rather than a pure view concern and you should have
> used a union/choose or other *model* means to control it.
>
> In other words, excess request parameters would still be
> ignored just like they are now, so this would _not_ open
> a security hole like we had with xmlforms, so I do not
> see a case of blind trust being given to the client.

This is good.

>> > As discussed before, this change would involve sending
>> > a hidden field along with every checkbox to indicate
>> > the presence of the checkbox, because an unchecked
>> > checkbox does not generate a request parameter on POST.
>> > This would allow to distinguish between a checkbox that
>> > is unchecked versus a checkbox that is not on the page.
>>
>> What is the performance impact of that???
>
> For each checkbox, we would send the client two widgets
> instead of one, and on POST we would get two widgets back
> instead of one.  This only affects checkboxes, not other
> widgets such as fields, repeaters, etc.

Remember on the repeaters we have the select boxes. If we are showing 20
rows on the repeater we are adding 20 new request params. I remember a
system that did that and then they fixed on the next release by allowing
users to define wich parameters need to return to the server to improve
the performance I just expect this could not be our bottleneck later.
More hidden parameters also mean bigger responses (page

Re: [GUMP@brutus]: Project cocoon-block-proxy (in module cocoon) failed

[Stefano Mazzocchi]

Antonio Gallardo wrote:
Stefano Mazzocchi dijo:
Gump wrote:

cocoon-block-proxy-compile:
   [javac] Compiling 4 source files to
/home/gump/workspaces2/public/workspace/cocoon/build/cocoon-02112004/blocks/proxy/dest
   [javac]
/home/gump/workspaces2/public/workspace/cocoon/src/blocks/proxy/java/org/apache/cocoon/generation/HttpProxyGenerator.java:294:
cannot resolve symbol
   [javac] symbol  : method getRequestBodyAsString ()
   [javac] location: class
org.apache.commons.httpclient.methods.PostMethod
   [javac] String body = ((PostMethod)
this.method).getRequestBodyAsString();
   [javac]   ^
   [javac] 1 error
I don't know how to fix this one from the gump side, it needs some code
changes since httpclient change a lot since this code was created.
Any ideas?

I saw the code of httpclient 2.0.x and 3.0 and it is quite diferent. They
are changing a lot in the new 3.0.x release. If we want gump compile this
block, we need to add a dependency to our own distributed jar version
2.0.2.
I know this is a hack. The other way is to see more in depth and find a
way to compile code using both httpclient 2.0.2 and 3.0 too.
WDYT?
That build is against the 2.0.x branch.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Expression languages (was Re: [RT] StringTemplate: The answer to our templating needs?)

[Antonio Gallardo]

Daniel Fagerstrom dijo:
> I agree with Sylvain. I mainly use expression languages for accessing
> DOM trees, and we write a lot of XSLT at my company, so for us JXPath
> (or other XPath based expression languages) is the natural choice. For
> people who mainly work in Java, and use Cocoon as a view layer for Java
> beans, JEXL is probably a much more natural choice.
>
> So even if I think that JEXL support is FS as I never use it ;) I still
> think that we should support both.

Thats the point, dude! ;-)

Best Regards,

Antonio Gallardo

Re: [lazy vote] cforms request processing

[Jason Johnston]

On Mon, 2004-11-01 at 22:08, Tim Larson wrote:
> > This can open some posible security concerns at all?
> 
> The form model would still be in control of which request
> parameters get processed.  The only change is that a missing
> request parameter would cause no change to the corresponding
> widget instead of causing it to be reset to null.  Can you
> think of any way for this to be exploited?  A client could
> change a value that was not made visible by the current page
> view, but it would still be subject to the normal validation
> rules.  And if this is an important issue for your use-case,
> then your page-splitting is a data model (form model)
> concern rather than a pure view concern and you should have
> used a union/choose or other *model* means to control it.

I'm concerned about a particular scenario; perhaps you can explain how
this would work in the proposed behavior...

It seems to me that implementing the proposal would make required="true"
on widget definitions pretty much useless.  IIUC, such widgets would not
be validated as required if their request parameters were not present. 
So it would be possible to successfully submit (i.e. encounter no
validation errors and pass successfully through the form.showForm()
loop) a single-page form with a blank required field by simply removing
that field's name from the request.

This creates a problem where it's no longer guaranteed that the values
in the form model post-validation are all valid; required widgets can
have null values (assuming their initial values from form.load() were
null).

Is this actually the case in the proposal?  Thoughts on how this can be
avoided?

--Jason

Re: [GUMP@brutus]: Project cocoon-block-proxy (in module cocoon) failed

[Antonio Gallardo]

Stefano Mazzocchi dijo:
> Gump wrote:
>
>> cocoon-block-proxy-compile:
>> [javac] Compiling 4 source files to
>> /home/gump/workspaces2/public/workspace/cocoon/build/cocoon-02112004/blocks/proxy/dest
>> [javac]
>> /home/gump/workspaces2/public/workspace/cocoon/src/blocks/proxy/java/org/apache/cocoon/generation/HttpProxyGenerator.java:294:
>> cannot resolve symbol
>> [javac] symbol  : method getRequestBodyAsString ()
>> [javac] location: class
>> org.apache.commons.httpclient.methods.PostMethod
>> [javac] String body = ((PostMethod)
>> this.method).getRequestBodyAsString();
>> [javac]   ^
>> [javac] 1 error
>
> I don't know how to fix this one from the gump side, it needs some code
> changes since httpclient change a lot since this code was created.
>
> Any ideas?

I saw the code of httpclient 2.0.x and 3.0 and it is quite diferent. They
are changing a lot in the new 3.0.x release. If we want gump compile this
block, we need to add a dependency to our own distributed jar version
2.0.2.

I know this is a hack. The other way is to see more in depth and find a
way to compile code using both httpclient 2.0.2 and 3.0 too.

WDYT?

Best Regards,

Antonio Gallardo

Re: [lazy vote] cforms request processing

[Nuno Santos]

The Request interface has a method to get an enumeration of parameter
names( getParameterNames), so just check the existence of the widget
Request parameter name and process only if exist!

On Tue, 2004-11-02 at 05:08, Tim Larson wrote:
> On Mon, Nov 01, 2004 at 06:13:21PM -0600, Antonio Gallardo wrote:
> > Tim Larson dijo:
> > > We have talked several times about changing the request
> > > processing in cforms to not touch any widget whose
> > > request parameter is missing (to prevent these widgets'
> > > values from being reset to null,) the end result being
> > > that it would be easier for the view to decide how to
> > > split a form across multiple pages without breaking the
> > > SoC between the form model and the view.
> > 
> > Is not posible to do that before sending the page? IMO given blind truting
> > to what the client is sending back is not good at all.
> 
> (Please see further down the page for a discussion on the
> security aspects.)
> 
> An alternative that has been suggested in the past is to
> collect a list of the widgets present in the view, and to
> use this list to filter which widgets would get to process
> their request parameters upon a POST.  The drawback to
> this approach is that it would not work for stateless
> forms, which is one of the use cases supported by cforms.
> 
> Since with stateless forms the form model gets recreated
> on each POST, where would you store the view's widget
> list?  And if the view is dynamic (uses union, choose,
> if, etc.) then you would have to store the list per form
> instance, clearly preventing stateless form semantics.
> 
> In contrast, the design presented in this lazy vote would
> cause no problems for stateless form support because it
> does not require storing the list of widgets currently
> present in the view.
> 
> > This can open some posible security concerns at all?
> 
> The form model would still be in control of which request
> parameters get processed.  The only change is that a missing
> request parameter would cause no change to the corresponding
> widget instead of causing it to be reset to null.  Can you
> think of any way for this to be exploited?  A client could
> change a value that was not made visible by the current page
> view, but it would still be subject to the normal validation
> rules.  And if this is an important issue for your use-case,
> then your page-splitting is a data model (form model)
> concern rather than a pure view concern and you should have
> used a union/choose or other *model* means to control it.
> 
> In other words, excess request parameters would still be
> ignored just like they are now, so this would _not_ open
> a security hole like we had with xmlforms, so I do not
> see a case of blind trust being given to the client.
>
> > > As discussed before, this change would involve sending
> > > a hidden field along with every checkbox to indicate
> > > the presence of the checkbox, because an unchecked
> > > checkbox does not generate a request parameter on POST.
> > > This would allow to distinguish between a checkbox that
> > > is unchecked versus a checkbox that is not on the page.
> > 
> > What is the performance impact of that???
> 
> For each checkbox, we would send the client two widgets
> instead of one, and on POST we would get two widgets back
> instead of one.  This only affects checkboxes, not other
> widgets such as fields, repeaters, etc.
> 
> > > What do we want to do?
> > > [ ] leave as is
> > > [ ] make the changes described above
> > 
> > Hmm.. I am still not sure. Can you explain a little bit about the above
> > first or just point to some links?
> 
> Please let me know whether the above explanation makes
> sense or has holes in it, or if anybody has better ideas.
> 
> > Many thanks in advance. ;-)
> 
> No problem :)
> 
> --Tim Larson
-- 
Nuno Santos <[EMAIL PROTECTED]>
Electroplus, lda

[RT] Attribute Rendering and CForms Convertors (was: Templating Engine - Next steps?)

[Daniel Fagerstrom]

Bart Molenkamp wrote:
I've also been thinking about a simple method for displaying object
instances of different classes. E.g. I get an object from the flow
layer, I need to decide how to format it. Instances of class "A" are
formatted differently than instances from class "B". Now, this could be
done using , but that doesn't make the code more readable:


Even worse when you want to check if it is instanceof an interface:


test="${java.lang.Class.forName('com.MyInterface').isAssignableFrom(
object.getClass())}">
 

I don't know your use cases, so maybe not the following is applicable at 
all, anyway:

In the (often cited on this list) article: Enforcing Strict Model View 
Separation in Template Engines, by Terence Parr 
http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf, a number of 
rules for strict separation between model and view are given. One of 
them is that the view shouldn't make any assumptions about data types of 
the model data. The view should only get displayable strings. If one 
start to depend on data types as in your code above, the template files 
must be supported by programmers rather than web designers. And the 
separation of concern between view and model start to get entangeled. 
Ok, knowing what Terence Parr _don't_ want us to do is not very helpfull ;)

As a solution to the problem he sugests MVCR 
(Model-View-Controller-Renderer), where the renderer is responsible for 
converting (Java) data types to displayable strings. The renderer can be 
responsible for localization of numbers etc as well. The renderer is an 
extra step between model and view.

The simplest possible renderer is to just implement toString() in the 
classes one is going to access in the view. But a better SoC is to have 
a separate rendering component. In this case the object from the model 
is first accessed by an expression in a suitable expression language and 
then the object is rendered to a displayable string by the rendering 
component and at last the displayable string is emited by the template 
engine.

So, how would the rendering component work? I think that we basically 
could reuse and extend the Convertor idea from CForms. The renderer 
check the type of the input object (and possibly the locale) and applies 
the apropriate convertor. The coupling between object type and convertor 
is decribed in a configuration file, much as in the form definition in 
CForms. It should also be easy to use custom converters, for own data types.

Typically one can reuse the same rendering configuration file for all 
templates.

  ---o0o---
I think the renderer component idea could give a better SoC in CForms as 
well. I have had a feeling that data type convertion is not a natural 
part of the model (form definition) for a while. A problem is that 
conversion configuration must be repeated each time the data type is used.

Ok, the idea is as follows: we have a converter component, that is like 
the renderer component above, but bidirectional. I.e. both rendering: 
data type -> displayable string and input conversion: input string -> 
data type. The converter is configured in the same way as described for 
the renderer above.

The convertor is used as a step between the form instance and the view 
for rendering the data types. And between the request object and the 
form instance during the population of the form instance.

Typically only one convertor configuration is needed for all ones forms. 
And we could distribute a localized default convertor configuration with 
Cocoon.

   ---o0o---
So, the basic idea is to factor out the type conversion functionallity 
from CForms and make it available for all rendering and input handling 
needs in Cocoon.

WDYT?
/Daniel

Re: latest Moin

[Pier Fumagalli]

On 2 Nov 2004, at 11:54, Upayavira wrote:
http://wiki.apache.org/cocoon-test/

IOError[Errno 13] Permission denied:  
'/www/wiki.apache.org/data/cocoon-test/data/user/ 
1093422431.38.32457.trail'
Try now.
+1, make the switch! :-P
Pier


smime.p7s
Description: S/MIME cryptographic signature

Re: [rant] please backport bugfixes to 2.1!

[Antonio Gallardo]

Sylvain Wallez dijo:
> Carsten Ziegeler wrote:
>
>>Sylvain Wallez wrote:
>>
>>
There are other changes as well - internal processing etc. But the good
 news is: you can use the ExtendedComponentSelector in the
 configuration, although the class doesn't exist. ECM++ will
 automatically use the CocoonServiceSelector. This is for compatibility.


>>>Mmmh... looks like a big hack. Why not simply reinstalling
>>>ExtendedComponentSelector as I suggested?
>>>
>>>
>>Sorry, but I don't understand where your real problem here is.
>>If you think that you can't merge the two branches because of different
>>configuration files, then simply use ExtendedComponentSelector
>>in 2.2 as well - it works and solves your problem.
>>
>>
>
> It won't solve the problem (if it was just that, it would be easy), but
> could ease having the exact same files for many blocks in both branches.
>
>>If you think that you need this class as well, add it.
>>
>>
>
> I'll consider that after syncing the code in CForms.
>
>>But I think, the real problem is that people forget to keep the branches
>>in sync :(
>>
>>
>
> Yep, this is the real problem.

No sure. Remember, the migration from CVS to SVN? IMO this was the real
problem. This is the reason of this page:

http://wiki.apache.org/cocoon/MergingBranches

... given the status of this page, the cforms block is already merged with
this note:

forms (some new features added by Tim are kept in 2.2 only for now).

Best Regards,

Antonio Gallardo

Re: how to get the xml serializer

[BURGHARD Éric]

Luigi Bai wrote:

> You need to make sure there is a serializer with the name "xml" declared
> in your sitemap.xmap file (or a parent sitemap) before you use your source
> module.
>

thanks for your answer,

the xml serializer is effectively declared in my main sitemap ;-(. It's not
the default one, but it is declared as xml.

i use the source module in a pipeline, say test
i can view the test url in a browser. When i debug, the xml serializer is
correctly selected, everything seems to be ok.
but when i  into another document, the exception
is thrown ???.

I can instantiate directly an XMLSerializer, configure it, and recycle it at
the end and it work everytime (url and cinclude). But i think it's ugly.
isn't it ?

regards

Re: Templating Engine - Next steps?

[Daniel Fagerstrom]

Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
 

E.) Use Jelly: http://jakarta.apache.org/commons/jelly/
AFAIK Jelly allready solve most of the requirements above. 
More specifically it uses JEXL or Jaxen as expression 
language, and you can use expressions both in attributes and 
in text with the syntax "${expr}". The expression engine is 
pluggable, so one can implement an Expression interface and 
use another expression language, JXPath e.g.

In Jelly there are simple mechanisms for writing own tag 
libs. And a large number of tag libs are already implemented. 
It read and writes SAX. It also have mechanisms for compiling 
the template so that id doesn't need to be parsed again, if 
used several times.
   

Jelly has imho a very awkward design that has several problems
when used in Cocoon - I looked at it some months ago and had some
discussions with Jelly developers. I don't remember any details,
but the result was that it isn't suitable to be used inside
Cocoon. Ok, this is a very general statement without any proof,
but that's all I can currently say. Other projects, like Maven,
aren't happy with Jelly either.
But you're right that it is a potential candidate to consider.
Now, whoever does this job is free to decide :)
Carsten
 

I have done some work on implementing a Jelly generator. Basically my 
own versions of the JellyGenerator in scratchpad and your 
TemplateObjectModelHelper, didn't know the existence of either of them :/

The most irritating problem that I have found this far is that it uses 
java.net.URL for uri handling which doesn't work that well together with 
the Excialibur Sources in Cocoon.

After some searching I found that you didn't find it suitable for multi 
threaded environment: 
http://www.osoco.net/weblogs/rael/archives/000202.html, do you remember 
what was the problem? Other problems?

/Daniel

Re: [GUMP@brutus]: Project cocoon-block-mail (in module cocoon) failed

[Stefano Mazzocchi]

Gump wrote:
cocoon-block-asciiart-compile:
cocoon-block-velocity-compile:
cocoon-block-cron-compile:
cocoon-block-batik-compile:
cocoon-block-xsp-compile:
cocoon-block-forms-compile:
cocoon-block-databases-compile:
main:
cocoon-block-ojb-compile:
this is very weird. the 'mail' block does not depend on ojb, so why is 
the cocoon build system trying to build it?

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [GUMP@brutus]: Project cocoon-block-proxy (in module cocoon) failed

[Stefano Mazzocchi]

Gump wrote:
cocoon-block-proxy-compile:
[javac] Compiling 4 source files to 
/home/gump/workspaces2/public/workspace/cocoon/build/cocoon-02112004/blocks/proxy/dest
[javac] 
/home/gump/workspaces2/public/workspace/cocoon/src/blocks/proxy/java/org/apache/cocoon/generation/HttpProxyGenerator.java:294:
 cannot resolve symbol
[javac] symbol  : method getRequestBodyAsString ()
[javac] location: class org.apache.commons.httpclient.methods.PostMethod
[javac] String body = ((PostMethod) 
this.method).getRequestBodyAsString();
[javac]   ^
[javac] 1 error
I don't know how to fix this one from the gump side, it needs some code 
changes since httpclient change a lot since this code was created.

Any ideas?
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: how to get the xml serializer

[Luigi Bai]

You might also consider making the name of the serializer a parameter, 
which defaults to the value "xml". Otherwise, it's this "magic" name that 
must be understood as a silent dependency.

Luigi
On Tue, 2 Nov 2004, Luigi Bai wrote:
You need to make sure there is a serializer with the name "xml" declared in 
your sitemap.xmap file (or a parent sitemap) before you use your source 
module.

Luigi
On Tue, 2 Nov 2004, BURGHARD [ISO-8859-15] Éric wrote:
Hi !
I'm writing a new source module.
I set-up some new pipelines with this module in the generator and 
everything
is working correctly, ... well not exactly

When i try to cinclude the xml from these pipelines in another pipeline i
get an exception (unable to find the xml serializer component from the
serializer selector component).
The problem comes from the getInputStream() method. I took the one that 
came
with XMLDBSource.java so i guess that xmldb: module has the same problem.

The serializer is to be selected by
manager = (ServiceManager)
this.context.get(ContextHelper.CONTEXT_SITEMAP_SERVICE_MANAGER);
serializerSelector = (ServiceSelector) manager.lookup(Serializer.ROLE +
"Selector");
serializer = (Serializer)serializerSelector.select("xml");
which throw the exception
The only components (related to serialization) i could find in the manager
is the org.apache.cocoon.components.sax.XMLSerializer and the
org.apache.cocoon.components.sax.XMLDeSerializer, but it seems complicated
for my purposes.
Any idea ?
regards

Re: the multipartparser

[Luigi Bai]

I concer with Ugo. Please also see 
http://issues.apache.org/bugzilla/show_bug.cgi?id=24289

for a patch to the current MultipartParser to handle multipar/mixed.
On Tue, 2 Nov 2004, Ugo Cei wrote:
Il giorno 02/nov/04, alle 15:29, Jorg Heymans ha scritto:
Is there a reason why we have our own multipart parser instead of using 
commons-fileupload? This has come up already about 1.5 years ago [1].
Maybe when the multipart parser was invented, commons-fileupload wasn't yet 
there, or maybe it wasn't known or it was just a case of NIH syndrome. 
Anyway, if we can get the same functionality with commons-upload, let's drop 
this other reinvented wheel. +1 if you volunteer to do it.

Ugo
--
Ugo Cei - http://beblogging.com/

Re: how to get the xml serializer

[Luigi Bai]

You need to make sure there is a serializer with the name "xml" declared 
in your sitemap.xmap file (or a parent sitemap) before you use your source 
module.

Luigi
On Tue, 2 Nov 2004, BURGHARD [ISO-8859-15] Éric wrote:
Hi !
I'm writing a new source module.
I set-up some new pipelines with this module in the generator and everything
is working correctly, ... well not exactly
When i try to cinclude the xml from these pipelines in another pipeline i
get an exception (unable to find the xml serializer component from the
serializer selector component).
The problem comes from the getInputStream() method. I took the one that came
with XMLDBSource.java so i guess that xmldb: module has the same problem.
The serializer is to be selected by
manager = (ServiceManager)
this.context.get(ContextHelper.CONTEXT_SITEMAP_SERVICE_MANAGER);
serializerSelector = (ServiceSelector) manager.lookup(Serializer.ROLE +
"Selector");
serializer = (Serializer)serializerSelector.select("xml");
which throw the exception
The only components (related to serialization) i could find in the manager
is the org.apache.cocoon.components.sax.XMLSerializer and the
org.apache.cocoon.components.sax.XMLDeSerializer, but it seems complicated
for my purposes.
Any idea ?
regards

RE: Templating Engine - Next steps?

[Carsten Ziegeler]

 
Daniel Fagerstrom wrote:

> E.) Use Jelly: http://jakarta.apache.org/commons/jelly/
> 
> AFAIK Jelly allready solve most of the requirements above. 
> More specifically it uses JEXL or Jaxen as expression 
> language, and you can use expressions both in attributes and 
> in text with the syntax "${expr}". The expression engine is 
> pluggable, so one can implement an Expression interface and 
> use another expression language, JXPath e.g.
> 
> In Jelly there are simple mechanisms for writing own tag 
> libs. And a large number of tag libs are already implemented. 
> It read and writes SAX. It also have mechanisms for compiling 
> the template so that id doesn't need to be parsed again, if 
> used several times.
> 
Jelly has imho a very awkward design that has several problems
when used in Cocoon - I looked at it some months ago and had some
discussions with Jelly developers. I don't remember any details,
but the result was that it isn't suitable to be used inside
Cocoon. Ok, this is a very general statement without any proof,
but that's all I can currently say. Other projects, like Maven,
aren't happy with Jelly either.

But you're right that it is a potential candidate to consider.
Now, whoever does this job is free to decide :)

Carsten

Re: Templating Engine - Next steps?

[Daniel Fagerstrom]

Reinhard Poetz wrote:
After a lot of mails talking about expression languages and templating 
enginges I try to summarize the current state of our discussion.  I 
see following requirements so far (in brackets you find the name of 
the person that brought up the requirement):

 - control structures like for/each, if, choose (RP)
 - call methods in a _simple/natural_ way on passed objects (RP)
 - stream objects (DOM, XMLizable, ...?) (RP)
 - define macros/taglibs (see cForm macros) (RP)
 - works as a Transformer (SAX pipeline) (GP)
 - Ability to directly produce SAX events, for efficency reasons. (SW)
 - one default expression language (CZ)
   it thing most people prefer the "dotted" JEXL syntax
I prefer Xpath and would prefer to make the choice of default expression 
language configurable.

 - support for additional expression languages (SW)
 - use the TemplateObjectModelHelper as Cocoon wide object model (CZ)
and not to forget
 - cacheability (RP)
   (BTW, has caching been implemented to everybodies satisfaction or
   are there open issues or possible improvements? Leszek?)
and one issue that bugs me for a long time ...
 - add support for dynamic attributes - similar to xsl:attribute (RP)
  - o -
So, how do we continue to meet all these requirements?
 A.) Rewrite/refactor JXTemplate
 - break it up in smaller, easier understandable/maintainable pieces
 - deprecate #{} syntax and make expression languages plugable as
   Sylvain suggested
 - investigate the performance problems (I guess there are only
   problems if macros are used)
 - add the missing things from above
 B.) use Garbage
 C.) talk with Carsten about Tempo
 D.) completly new templating engine
E.) Use Jelly: http://jakarta.apache.org/commons/jelly/
AFAIK Jelly allready solve most of the requirements above. More 
specifically it uses JEXL or Jaxen as expression language, and you can 
use expressions both in attributes and in text with the syntax 
"${expr}". The expression engine is pluggable, so one can implement an 
Expression interface and use another expression language, JXPath e.g.

In Jelly there are simple mechanisms for writing own tag libs. And a 
large number of tag libs are already implemented. It read and writes 
SAX. It also have mechanisms for compiling the template so that id 
doesn't need to be parsed again, if used several times.

In my opinion we should write JXTemplate 2.0 which would be from the 
user's POV as similar as possible to 1.0.
Technically this could be a complete rewrite (use garbage, tempo or 
really from scratch) or at least a major refactoring.
IIUC, JXTemplate 1.0, except for the "#{expr}" sytax can be implemented 
in Jelly. So we would keep it (almost) back compatible, and would get a 
lot of new template libraries and good mechanisms for writing our own, 
for free.

Calling it JXTemplate is better for marketing reasons because it shows 
more stability than telling our user base that they should use 
something completly different in the future. Calling it differently 
gives another impression than incrementing version numbers.

WDOT ...
 * are there any missing requirments?
Not IMO, but I would like to emphazise the need for writing tag libs. We 
have a lot of transformers, e.g. the SQLTransformer, that basically 
implements a tag lib. IMO all these custom transformers that are written 
more or less directly in terms of SAX, are quite hard to write, 
understand and support. I think it would be much better to write such 
tag libs in something that is a little bit more high level e.g. as Jelly 
tag libs.

 * or is it too much (FS)?
In one way I agree with the ideas behind StringTemplate, among other 
things, that a template language should be side effect free. But on the 
other hand we need both an expression language and the ability to define 
own tag libraries, and that makes it nearly impossible to enforce 
freeness from side effects.

 * which alternative do you prefer?
JXTemplate 2.0 implemented in Jelly.
Don't forget, this is no vote ;-)
+1 ;)
/Daniel

DO NOT REPLY [Bug 32011] - [PATCH] buildList in AbstractDatabaseAction generates incorrect parameter list

[bugzilla]

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://issues.apache.org/bugzilla/show_bug.cgi?id=32011

[PATCH] buildList in AbstractDatabaseAction generates incorrect parameter list





--- Additional Comments From [EMAIL PROTECTED]  2004-11-02 14:45 ---
The choice of the database does not matter. It is very very basic SQL. 
Basically any use of DatabaseAddAction causes the problem. DatabaseAddAction 
inherits from AbstractDatabaseAction, which has a bad buildList(Configuration
[] values, int begin) method. I unfortunately am not familiar with HSQLDB. I 
am using PostgreSQL, but the test case should work with any database once you 
get the DDL correct (the create table statements). I think you might have to 
change the double precision data type in the create statements to whatever 
HSQLDB uses for doubles, but otherwise the other data types are most likely 
exactly the same in the DDL.

Re: the multipartparser

[Ugo Cei]

Il giorno 02/nov/04, alle 15:29, Jorg Heymans ha scritto:
Is there a reason why we have our own multipart parser instead of 
using commons-fileupload? This has come up already about 1.5 years ago 
[1].
Maybe when the multipart parser was invented, commons-fileupload wasn't 
yet there, or maybe it wasn't known or it was just a case of NIH 
syndrome. Anyway, if we can get the same functionality with 
commons-upload, let's drop this other reinvented wheel. +1 if you 
volunteer to do it.

Ugo
--
Ugo Cei - http://beblogging.com/


smime.p7s
Description: S/MIME cryptographic signature

Re: Expression languages (was Re: [RT] StringTemplate: The answer to our templating needs?)

[Daniel Fagerstrom]

Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
XPath is a must-have when you deal with XML documents while Jexl is 
mostly useless in that case but is straightforward when you deal 
with JavaBeans. I also agree that understanding the difference 
between "${continuation.id}" and "#{$continuation/id}" is less than 
evident.

So what about a unified syntax for expansion tokens, within which 
different languages could be used. Example:
- ${continuation.id} // Jexl, default syntax
- ${xpath:$continuation/id} // xpath
- ${im:defaults:skin} // input-module
- ${ognl:$continuation.id} // OGNL [1]

For plugable expression languages, JEX: 
http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/jex/ and 
http://www.plotnix.com/jex/index.html, might be worth looking at. It 
provides intefaces for pluggable expression languages. It supports the 
"expression-engine:path" syntax that you use above and have default 
implementations for jexl, jxpath, bexl and javascript.

The project seem like it never took off and consists of a 2 year old 
initial submission from Dmitri Plotnikov (the main author of JXPath). 
But we could get ideas and meybe steal code from JEX, if we would like 
to have pluggable expression languages in Cocoon.

  
Hmm, one of the things I really don't like with JXTG is that you
have to different expression languages. You never know which to
use and some things work only with one specific language.
And for me this comes near to FS :)
 

Agree, but considering the wide variety of applications contexts where 
Cocoon is used, I don't think there can be a single 
"one-size-fits-all" language.

There are also a number of places in Cocoon where we need to evaluate 
expressions: templates, sitemap, form validators, form bindings, etc, 
which are currently implemented separately with different syntaxes. We 
need a common expression evaluation component.

So, let's decide on one language that we think is the best, but
let's provide a hook so others can plugin their language if *they*
want to.
 

That's exactly what I suggest above: we choose a standard default 
language, but open the possibility to plug in new ones. XPath is a 
must-have, Jexl and IM have very valid use cases which IMO justify 
them to be provided by Cocoon. Other languages are just a possibility 
that we offer _if_ people want to add their own language.

Sylvain
I agree with Sylvain. I mainly use expression languages for accessing 
DOM trees, and we write a lot of XSLT at my company, so for us JXPath 
(or other XPath based expression languages) is the natural choice. For 
people who mainly work in Java, and use Cocoon as a view layer for Java 
beans, JEXL is probably a much more natural choice.

So even if I think that JEXL support is FS as I never use it ;) I still 
think that we should support both.

/Daniel

Re: Switching rhino implementation

[Ralph Goers]

Reinhard Poetz wrote:
Thank you guys.
I'm going to replace the old implementation by the new one in trunk. 
In branch I will wait for the new release and rename the old language 
"javascript-2.1.6" which indicates that this is the former 
implementation. The new implementation will be called "javascript". 
This way most of our users will switch to the new implementation 
without noticing it. If they have problems they can either rewrite 
their catch() statements or change the language to "javascript-2.1.6".

Don't forget to publish something in the release notes for 2.1.6.

the multipartparser

[Jorg Heymans]

Hi,
Is there a reason why we have our own multipart parser instead of using 
commons-fileupload? This has come up already about 1.5 years ago [1].

I have a problem with the multipart parser in IE and Opera (not in 
Firefox), reproduceable with the following form





results in
o.a.c.s.m.MultipartException: Malformed stream
at o.a.c.s.m.MultipartParser.parseMultiPart(MultipartParser.java:132)
at o.a.c.s.m.MultipartParser.getParts(MultipartParser.java:101)
at o.a.c.s.m.MultipartParser.getParts(MultipartParser.java:107)
at o.a.c.s.m.RequestFactory.getServletRequest(RequestFactory.java:94)
at o.a.c.s.CocoonServlet.service(CocoonServlet.java:1004)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
There is at least one other issue with it [2], and parsePart() in 
MultiPartParser contains "// FIXME: multipart/mixed parts are untested."

Just wanted to get a few opinions before i attempt to implement this.
Regards
Jorg
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105363507529701&w=2
[2] http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24289

DO NOT REPLY [Bug 32011] - [PATCH] buildList in AbstractDatabaseAction generates incorrect parameter list

[bugzilla]

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://issues.apache.org/bugzilla/show_bug.cgi?id=32011

[PATCH] buildList in AbstractDatabaseAction generates incorrect parameter list





--- Additional Comments From [EMAIL PROTECTED]  2004-11-02 14:02 ---
Without looking at provided test case - wouldn't it possible to write test case
against sample hsqldb database? we could extend it with necessary info if needed.

how to get the xml serializer

[BURGHARD Éric]

Hi !

I'm writing a new source module.

I set-up some new pipelines with this module in the generator and everything
is working correctly, ... well not exactly

When i try to cinclude the xml from these pipelines in another pipeline i
get an exception (unable to find the xml serializer component from the
serializer selector component).

The problem comes from the getInputStream() method. I took the one that came
with XMLDBSource.java so i guess that xmldb: module has the same problem. 

The serializer is to be selected by

manager = (ServiceManager)
this.context.get(ContextHelper.CONTEXT_SITEMAP_SERVICE_MANAGER);
serializerSelector = (ServiceSelector) manager.lookup(Serializer.ROLE +
"Selector");
serializer = (Serializer)serializerSelector.select("xml");

which throw the exception

The only components (related to serialization) i could find in the manager
is the org.apache.cocoon.components.sax.XMLSerializer and the
org.apache.cocoon.components.sax.XMLDeSerializer, but it seems complicated
for my purposes.

Any idea ?

regards

DO NOT REPLY [Bug 32011] - [PATCH] buildList in AbstractDatabaseAction generates incorrect parameter list

[bugzilla]

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://issues.apache.org/bugzilla/show_bug.cgi?id=32011

[PATCH] buildList in AbstractDatabaseAction generates incorrect parameter list





--- Additional Comments From [EMAIL PROTECTED]  2004-11-02 13:29 ---
ok, thanks - i'll give this a spin.

DO NOT REPLY [Bug 24289] - MultipartParser cannot handle multibyte character in uploaded file name correctly

[bugzilla]

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://issues.apache.org/bugzilla/show_bug.cgi?id=24289

MultipartParser cannot handle multibyte character in uploaded file name correctly





--- Additional Comments From [EMAIL PROTECTED]  2004-11-02 13:03 ---
Thanks for your contribution.

Could you provide a small isolated testcase so we can easily test this behaviour
and the proposed fix?

Also: providing a patch in unified diff format makes it easier to work out what
the patch actually does. If you have a checked out copy of 2.1.x trunk, you can
just do "svn diff yourfilename.java" and attach the output to this bugzilla entry.

DO NOT REPLY [Bug 32011] - [PATCH] buildList in AbstractDatabaseAction generates incorrect parameter list

[bugzilla]

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://issues.apache.org/bugzilla/show_bug.cgi?id=32011

[PATCH] buildList in AbstractDatabaseAction generates incorrect parameter list





--- Additional Comments From [EMAIL PROTECTED]  2004-11-02 12:57 ---
I have attached the test case application. Bear in mind that you have to install
a JDBC database driver in Tomcat's common/lib directory and also that you have
to configure web.xml and cocoon.xconf in the WEB-INF directory of the cocoon web
directory. You also need to run the SQL setup scripts in the db subdirectory of
abc. You should unpack abc into the cocoon web directory.

Then try running abc/support/newticket. You will need to log in with username
BigCorp and password secret.

Here is the unified diff (which I will use in the future as well):

--- AbstractDatabaseAction.java~Fri Jul  9 04:03:11 2004
+++ AbstractDatabaseAction.java Mon Nov  1 21:21:28 2004
@@ -728,6 +728,9 @@
 buffer.append(", ");
 }
 buffer.append(values[i].getAttribute("dbcol"));
+   if (i < length - 1) {
+   buffer.append(", ");
+   }
 }
 return buffer;
 }

DO NOT REPLY [Bug 32011] - [PATCH] buildList in AbstractDatabaseAction generates incorrect parameter list

[bugzilla]

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://issues.apache.org/bugzilla/show_bug.cgi?id=32011

[PATCH] buildList in AbstractDatabaseAction generates incorrect parameter list





--- Additional Comments From [EMAIL PROTECTED]  2004-11-02 12:53 ---
Created an attachment (id=13308)
Test case Cocoon application

Re: Switching rhino implementation

[Igor Bukanov]

> Leszek Gawron wrote:
> From what I see in this mail new implementation still allows for
> cleanup code after continuation has been created but does not allow for
> automatic resource fetching ( catch( continue ) ).
>
> 
> var pool = ...;
>
> function someFunction() {
>
>   var conn = pool.getConnection();
>   ...
>
>   catch (break) {
>   conn.close();
>   conn = null;
>   }
>
>   catch (continue) {
>   conn = pool.getConnection();
>   }
> }
>
> with the patch would like:
>
> var pool = ...;
>
> function someFunction() {
>
>   var conn = null;
>   try {
>   if (conn == null) {
>   conn = pool.getConnection();
>   }
>   ...
>   } finally {
>   conn.close();
>   conn = null;
>   }
> }
> 
>
> so now you have to fetch the connection yourself each time the 
continuation is
> resumed right?

But you have to "fetch the connection" each time even with old code! The 
new implementation has the same number of lines and avoids duplication 
of calls to pool.getConnection() so it is hard to see why it could be 
any significantly worse.

> Is there any chance for porting that feature into new
> implementation?
Not with the old syntax: the problem with the catch extensions is that 
its behavior is undefined if an exception is thrown or a continuation is 
caught/restored inside such catch block. "Undefined" here means that 
depending on the situation it would either throw NullPointerException 
and friends or go to the infinite loop.

A better idea IMO is to allow to write something like:
try initially {
var conn = pool.getConnection();
} try {
use connection
} finally {
conn.close();
}
where "try initially" would always be executed on continuation restore. 
Alternative syntax suggestions are welcome but keep in mind that they 
should be 100% compatible with the current JS.

But again, there are too many cases to worry about on the runtime part 
=> takes time to implement.

Regards, Igor

Re: latest Moin

[Upayavira]

Pier Fumagalli wrote:
On 2 Nov 2004, at 08:32, Upayavira wrote:
Leszek Gawron wrote:
Upayavira wrote:
Ralph Goers wrote:
Is it possible to have the site bar on the left?

:-)
The option I found was for a theme called 'rightsidebar'. I have 
not  heard mention of a 'leftsidebar' theme, so, unless someone 
wants to  do some HTML coding, we're stuck with a right hand one!

AFAIK there is a leftsidebar skin - but not in the distro. it can 
be  downloaded from moin website.

Well, whether or not we go leftside or rightside, I've managed to  
install Moin 1.2.4 onto an Apache server. Go to:

http://wiki.apache.org/cocoon-test/

IOError[Errno 13] Permission denied:  
'/www/wiki.apache.org/data/cocoon-test/data/user/ 
1093422431.38.32457.trail'
Try now.
I should have copied the data across maintaining file permissions, which 
would have prevented that.

Upayavira

Re: latest Moin

[Pier Fumagalli]

On 2 Nov 2004, at 08:32, Upayavira wrote:
Leszek Gawron wrote:
Upayavira wrote:
Ralph Goers wrote:
Is it possible to have the site bar on the left?

:-)
The option I found was for a theme called 'rightsidebar'. I have not  
heard mention of a 'leftsidebar' theme, so, unless someone wants to  
do some HTML coding, we're stuck with a right hand one!
AFAIK there is a leftsidebar skin - but not in the distro. it can be  
downloaded from moin website.
Well, whether or not we go leftside or rightside, I've managed to  
install Moin 1.2.4 onto an Apache server. Go to:

http://wiki.apache.org/cocoon-test/
IOError[Errno 13] Permission denied:  
'/www/wiki.apache.org/data/cocoon-test/data/user/ 
1093422431.38.32457.trail'

	Pier


smime.p7s
Description: S/MIME cryptographic signature

Re: Switching rhino implementation

[Leszek Gawron]

Reinhard Poetz wrote:
Leszek Gawron wrote:
Reinhard Poetz wrote:
Thank you guys.
I'm going to replace the old implementation by the new one in trunk. 
In branch I will wait for the new release and rename the old language 
"javascript-2.1.6" which indicates that this is the former 
implementation. The new implementation will be called "javascript". 
This way most of our users will switch to the new implementation 
without noticing it. If they have problems they can either rewrite 
their catch() statements or change the language to "javascript-2.1.6".

Is there any replacement for catch() functionality in new implementation?
Igor explains the differences here: 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109528520325331&w=2

Thank you. From what I see in this mail new implementation still allows for 
cleanup code after continuation has been created but does not allow for 
automatic resource fetching ( catch( continue ) ).


var pool = ...;
function someFunction() {
 var conn = pool.getConnection();
 ...
 catch (break) {
 conn.close();
 conn = null;
 }
 catch (continue) {
 conn = pool.getConnection();
 }
}
with the patch would like:
var pool = ...;
function someFunction() {
 var conn = null;
 try {
 if (conn == null) {
 conn = pool.getConnection();
 }
 ...
 } finally {
 conn.close();
 conn = null;
 }
}

so now you have to fetch the connection yourself each time the continuation is 
resumed right? Is there any chance for porting that feature into new 
implementation?

--
Leszek Gawron  [EMAIL PROTECTED]
Project ManagerMobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: [rant] please backport bugfixes to 2.1!

[Sylvain Wallez]

Carsten Ziegeler wrote:
Sylvain Wallez wrote:
 

There are other changes as well - internal processing etc. But the good news is: you can use the ExtendedComponentSelector in the configuration, although the class doesn't exist. ECM++ will automatically use the CocoonServiceSelector. This is for compatibility.
 

Mmmh... looks like a big hack. Why not simply reinstalling 
ExtendedComponentSelector as I suggested?
   

Sorry, but I don't understand where your real problem here is.
If you think that you can't merge the two branches because of different
configuration files, then simply use ExtendedComponentSelector
in 2.2 as well - it works and solves your problem.
 

It won't solve the problem (if it was just that, it would be easy), but 
could ease having the exact same files for many blocks in both branches.

If you think that you need this class as well, add it.
 

I'll consider that after syncing the code in CForms.
But I think, the real problem is that people forget to keep the branches
in sync :(
 

Yep, this is the real problem.
Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: Switching rhino implementation

[Reinhard Poetz]

Leszek Gawron wrote:
Reinhard Poetz wrote:
Thank you guys.
I'm going to replace the old implementation by the new one in trunk. 
In branch I will wait for the new release and rename the old language 
"javascript-2.1.6" which indicates that this is the former 
implementation. The new implementation will be called "javascript". 
This way most of our users will switch to the new implementation 
without noticing it. If they have problems they can either rewrite 
their catch() statements or change the language to "javascript-2.1.6".

Is there any replacement for catch() functionality in new implementation?
Igor explains the differences here: 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109528520325331&w=2

--
Reinhard

Re: latest Moin

[Upayavira]

Leszek Gawron wrote:
Upayavira wrote:
This is a Moin 1.2.4 installation, running off a copy of the main 
Wiki site. There's more that needs to be done before we can upgrade, 
for example ensuring we can still do notification mails and central 
configurations for the whole wiki farm. Then, whether others like the 
rightsidebar or not, we can configure it for our own wiki. 
It can be also configured in user preferences so it's up to user to 
decide which skin he/she likes best.
Yes, that too. We can have farm-wide settings, settings specific to our 
own wiki, and user specific ones.

Upayavira

Re: Switching rhino implementation

[Leszek Gawron]

Reinhard Poetz wrote:
Thank you guys.
I'm going to replace the old implementation by the new one in trunk. In 
branch I will wait for the new release and rename the old language 
"javascript-2.1.6" which indicates that this is the former 
implementation. The new implementation will be called "javascript". This 
way most of our users will switch to the new implementation without 
noticing it. If they have problems they can either rewrite their catch() 
statements or change the language to "javascript-2.1.6".

Is there any replacement for catch() functionality in new implementation?
--
Leszek Gawron  [EMAIL PROTECTED]
Project ManagerMobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: latest Moin

[Leszek Gawron]

Upayavira wrote:
This is a Moin 1.2.4 installation, running off a copy of the main Wiki 
site. There's more that needs to be done before we can upgrade, for 
example ensuring we can still do notification mails and central 
configurations for the whole wiki farm. Then, whether others like the 
rightsidebar or not, we can configure it for our own wiki. 
It can be also configured in user preferences so it's up to user to decide 
which skin he/she likes best.

--
Leszek Gawron  [EMAIL PROTECTED]
Project ManagerMobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

RE: [rant] please backport bugfixes to 2.1!

[Carsten Ziegeler]

Sylvain Wallez wrote:
> >>
> >There are other changes as well - internal processing etc. 
> But the good 
> >news is: you can use the ExtendedComponentSelector in the 
> >configuration, although the class doesn't exist. ECM++ will 
> >automatically use the CocoonServiceSelector. This is for 
> compatibility.
> >  
> >
> 
> Mmmh... looks like a big hack. Why not simply reinstalling 
> ExtendedComponentSelector as I suggested?
> 
Sorry, but I don't understand where your real problem here is.
If you think that you can't merge the two branches because of different
configuration files, then simply use ExtendedComponentSelector
in 2.2 as well - it works and solves your problem. 

If you think that you need this class as well, add it.

But I think, the real problem is that people forget to keep the branches
in sync :(

Carsten

Re: [rant] please backport bugfixes to 2.1!

[Torsten Curdt]

Carsten Ziegeler wrote:
Sylvain Wallez wrote:
I remember a time where 2.2 contained only the Cocoon core 
and no blocks. Is it no more possible? Ah no: the cforms 
xconf files now reference ECM++ selectors. G... What 
about reinstalling in 2.2 an ExtendedComponentSelector that 
would simply be a subclass of CocoonServiceSelector. That 
would allow to share config files between branches.

There are other changes as well - internal processing etc. But
the good news is: you can use the ExtendedComponentSelector
in the configuration, although the class doesn't exist. ECM++
will automatically use the CocoonServiceSelector. This is
for compatibility. 
BTW:
the build of 2.2 failed for me last night.
missing LifecycleHelper.
do you guys see the same?
cheers
--
Torsten

[GUMP@brutus]: Project cocoon-block-mail (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-mail has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-mail :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-mail/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [mail-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-mail/gump_work/build_cocoon_cocoon-block-mail.html
Work Name: build_cocoon_cocoon-block-mail (Type: Build)
Work ended in a state of : Failed
Elapsed: 6 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=02112004 -Dblock-name=mail gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-02112004.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-02112004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-02112004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-02112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-02112004.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-1.2.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-02112004/checkstyle-02112004.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-02112004.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-02112004.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-02112004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-02112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logk

[GUMP@brutus]: Project cocoon-block-scratchpad (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-scratchpad has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Configuration Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-scratchpad :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-scratchpad/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [scratchpad-block.jar] identifier set to project name
 -INFO- Failed with reason configuration failed
 -ERROR- Bad Dependency. Project: commons-beanutils-core unknown to *this* workspace
 -INFO- Failed to extract fallback artifacts from Gump Repository

To subscribe to this information via syndicated feeds:
- RSS: http://brutus.apache.org/gump/public/cocoon/cocoon-block-scratchpad/rss.xml
- Atom: http://brutus.apache.org/gump/public/cocoon/cocoon-block-scratchpad/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.1.0-alpha-0003.
Gump Run 2602112004, brutus:brutus-public:2602112004
Gump E-mail Identifier (unique within run) #59.

--
Apache Gump
http://gump.apache.org/ [Instance: brutus]

[GUMP@brutus]: Project cocoon-block-cron (in module cocoon) success

[Gump]

To whom it may satisfy...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-cron *no longer* has an issue.
The current state of this project is 'Success'.

Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-cron/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [cron-block.jar] identifier set to project name
 -INFO- No license on redistributable project with outputs.



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-cron/gump_work/build_cocoon_cocoon-block-cron.html
Work Name: build_cocoon_cocoon-block-cron (Type: Build)
Work ended in a state of : Success
Elapsed: 5 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=02112004 -Dblock-name=cron gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-02112004.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-02112004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-02112004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-02112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-02112004.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-1.2.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-02112004/checkstyle-02112004.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-02112004.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-02112004.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-02112004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-02112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-02112004.jar:/usr/local/gump/public/workspace/excalibur/components/xmlutil/target/excalibur-xmlutil-1.2.jar:/usr/local/gump/public/workspace/excalibur/components/store/target/excalibur-store-1.2.jar:/usr/local/gump/public/workspace/exc

[GUMP@brutus]: Project cocoon-block-faces (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-faces has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Configuration Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-faces :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-faces/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [faces-block.jar] identifier set to project name
 -INFO- Failed with reason configuration failed
 -ERROR- Bad Dependency. Project: commons-beanutils-core unknown to *this* workspace
 -INFO- Failed to extract fallback artifacts from Gump Repository

To subscribe to this information via syndicated feeds:
- RSS: http://brutus.apache.org/gump/public/cocoon/cocoon-block-faces/rss.xml
- Atom: http://brutus.apache.org/gump/public/cocoon/cocoon-block-faces/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.1.0-alpha-0003.
Gump Run 2602112004, brutus:brutus-public:2602112004
Gump E-mail Identifier (unique within run) #57.

--
Apache Gump
http://gump.apache.org/ [Instance: brutus]

[GUMP@brutus]: Project cocoon-block-proxy (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-proxy has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 7 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-proxy :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-proxy/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [proxy-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-proxy/gump_work/build_cocoon_cocoon-block-proxy.html
Work Name: build_cocoon_cocoon-block-proxy (Type: Build)
Work ended in a state of : Failed
Elapsed: 4 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=02112004 -Dblock-name=proxy gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-02112004.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-02112004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-02112004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-02112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-02112004.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-1.2.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-02112004/checkstyle-02112004.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-02112004.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-02112004.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-02112004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-02112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runti

Re: [rant] please backport bugfixes to 2.1!

[Sylvain Wallez]

Carsten Ziegeler wrote:
Sylvain Wallez wrote:
 

I remember a time where 2.2 contained only the Cocoon core 
and no blocks. Is it no more possible? Ah no: the cforms 
xconf files now reference ECM++ selectors. G... What 
about reinstalling in 2.2 an ExtendedComponentSelector that 
would simply be a subclass of CocoonServiceSelector. That 
would allow to share config files between branches.
   

There are other changes as well - internal processing etc. But
the good news is: you can use the ExtendedComponentSelector
in the configuration, although the class doesn't exist. ECM++
will automatically use the CocoonServiceSelector. This is
for compatibility.
 

Mmmh... looks like a big hack. Why not simply reinstalling 
ExtendedComponentSelector as I suggested?

Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

[GUMP@brutus]: Project cocoon-block-portal (in module cocoon) success

[Gump]

To whom it may satisfy...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-portal *no longer* has an issue.
The current state of this project is 'Success'.

Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-portal/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [portal-block.jar] identifier set to project name
 -INFO- No license on redistributable project with outputs.



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-portal/gump_work/build_cocoon_cocoon-block-portal.html
Work Name: build_cocoon_cocoon-block-portal (Type: Build)
Work ended in a state of : Success
Elapsed: 11 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=02112004 -Dblock-name=portal gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-02112004.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-02112004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-02112004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-02112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-02112004.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-1.2.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-02112004/checkstyle-02112004.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-02112004.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-02112004.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-02112004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-02112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-02112004.jar:/usr/local/gump/public/workspace/excalibur/components/xmlutil/target/excalibur-xmlutil-1.2.jar:/usr/local/gump/public/workspace/excalibur/components/store/target/excalibur-store-1.2.jar:/usr/local/gump/publi

[GUMP@brutus]: Project cocoon-block-jms (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-jms has an issue affecting its community integration.
This issue affects 5 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-eventcache :  Java XML Framework
- cocoon-block-jms :  Java XML Framework
- cocoon-block-repository :  Java XML Framework
- cocoon-block-slide :  Java XML Framework
- cocoon-block-webdav :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-jms/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [jms-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-jms/gump_work/build_cocoon_cocoon-block-jms.html
Work Name: build_cocoon_cocoon-block-jms (Type: Build)
Work ended in a state of : Failed
Elapsed: 5 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=02112004 -Dblock-name=jms gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-02112004.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-02112004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-02112004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-02112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-02112004.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-1.2.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-02112004/checkstyle-02112004.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-02112004.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-02112004.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-02112004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jd

[GUMP@brutus]: Project cocoon-block-bsf (in module cocoon) success

[Gump]

To whom it may satisfy...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-bsf *no longer* has an issue.
The current state of this project is 'Success'.

Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-bsf/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [bsf-block.jar] identifier set to project name
 -INFO- No license on redistributable project with outputs.



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-bsf/gump_work/build_cocoon_cocoon-block-bsf.html
Work Name: build_cocoon_cocoon-block-bsf (Type: Build)
Work ended in a state of : Success
Elapsed: 4 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=02112004 -Dblock-name=bsf gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-02112004.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-02112004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-02112004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-02112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-02112004.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-1.2.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-02112004/checkstyle-02112004.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-02112004.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-02112004.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-02112004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-02112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-02112004.jar:/usr/local/gump/public/workspace/excalibur/components/xmlutil/target/excalibur-xmlutil-1.2.jar:/usr/local/gump/public/workspace/excalibur/components/store/target/excalibur-store-1.2.jar:/usr/local/gump/public/workspace/excalibur/

[GUMP@brutus]: Project cocoon-block-forms (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-forms has an issue affecting its community integration.
This issue affects 7 projects,
 and has been outstanding for 3 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-apples :  Java XML Framework
- cocoon-block-forms :  Java XML Framework
- cocoon-block-javaflow :  Java XML Framework
- cocoon-block-lucene :  Java XML Framework
- cocoon-block-ojb :  Java XML Framework
- cocoon-block-petstore :  Java XML Framework
- cocoon-block-tour :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-forms/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [forms-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-forms/gump_work/build_cocoon_cocoon-block-forms.html
Work Name: build_cocoon_cocoon-block-forms (Type: Build)
Work ended in a state of : Failed
Elapsed: 11 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=02112004 -Dblock-name=forms gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/blocks/forms/test:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-02112004.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-02112004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-02112004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-02112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-02112004.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-1.2.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-02112004/checkstyle-02112004.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-02112004.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-02112004.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-colle

[GUMP@brutus]: Project cocoon-block-woody (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-woody has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 3 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-woody :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-woody/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [woody-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-woody/gump_work/build_cocoon_cocoon-block-woody.html
Work Name: build_cocoon_cocoon-block-woody (Type: Build)
Work ended in a state of : Failed
Elapsed: 10 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=02112004 -Dblock-name=woody gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/blocks/woody/test:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-02112004.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-02112004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-02112004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-02112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-02112004.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-1.2.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-02112004/checkstyle-02112004.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-02112004.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-02112004.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-02112004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-veloc

[GUMP@brutus]: Project cocoon-block-midi (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-midi has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 7 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-midi :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-midi/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [midi-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-midi/gump_work/build_cocoon_cocoon-block-midi.html
Work Name: build_cocoon_cocoon-block-midi (Type: Build)
Work ended in a state of : Failed
Elapsed: 5 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=02112004 -Dblock-name=midi gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-02112004.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-02112004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-02112004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-02112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-02112004.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-1.2.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-02112004/checkstyle-02112004.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-02112004.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-02112004.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-02112004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-02112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/logki

RE: [rant] please backport bugfixes to 2.1!

[Carsten Ziegeler]

Sylvain Wallez wrote:
> 
> I remember a time where 2.2 contained only the Cocoon core 
> and no blocks. Is it no more possible? Ah no: the cforms 
> xconf files now reference ECM++ selectors. G... What 
> about reinstalling in 2.2 an ExtendedComponentSelector that 
> would simply be a subclass of CocoonServiceSelector. That 
> would allow to share config files between branches.
> 
There are other changes as well - internal processing etc. But
the good news is: you can use the ExtendedComponentSelector
in the configuration, although the class doesn't exist. ECM++
will automatically use the CocoonServiceSelector. This is
for compatibility. 

Carsten

[GUMP@brutus]: Project cocoon-block-hsqldb (in module cocoon) success

[Gump]

To whom it may satisfy...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-hsqldb *no longer* has an issue.
The current state of this project is 'Success'.

Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-hsqldb/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [hsqldb-block.jar] identifier set to project name
 -INFO- No license on redistributable project with outputs.



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-hsqldb/gump_work/build_cocoon_cocoon-block-hsqldb.html
Work Name: build_cocoon_cocoon-block-hsqldb (Type: Build)
Work ended in a state of : Success
Elapsed: 4 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=02112004 -Dblock-name=hsqldb gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-02112004.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-02112004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-02112004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-02112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-02112004.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-1.2.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-02112004/checkstyle-02112004.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-02112004.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-02112004.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-02112004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-02112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-02112004.jar:/usr/local/gump/public/workspace/excalibur/components/xmlutil/target/excalibur-xmlutil-1.2.jar:/usr/local/gump/public/workspace/excalibur/components/store/target/excalibur-store-1.2.jar:/usr/local/gump/public

[GUMP@brutus]: Project cocoon-block-chaperon (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-chaperon has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 3 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-chaperon :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-chaperon/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [chaperon-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-chaperon/gump_work/build_cocoon_cocoon-block-chaperon.html
Work Name: build_cocoon_cocoon-block-chaperon (Type: Build)
Work ended in a state of : Failed
Elapsed: 6 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=02112004 -Dblock-name=chaperon gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/blocks/chaperon/dest:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/blocks/chaperon/test:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-02112004/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-02112004.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-02112004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-02112004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-02112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-02112004.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-1.2.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-02112004/checkstyle-02112004.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-02112004.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-02112004.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-02112004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-loggin

[rant] please backport bugfixes to 2.1!

[Sylvain Wallez]

Unusual for me, but time for a rant: I wrote the new CForms widget state 
feature in 2.1 and tried to port it to 2.2.

WHAT A PITA!
There are a number or *bug fixes* or minor new features that only exist 
in 2.2. Why aren't they ported also to 2.1?

Please, please, consider upgrading both branches at the same time. There 
will be some time before 2.2 is out and not everybody runs a snapshot of 
trunk.

I remember a time where 2.2 contained only the Cocoon core and no 
blocks. Is it no more possible? Ah no: the cforms xconf files now 
reference ECM++ selectors. G... What about reinstalling in 2.2 an 
ExtendedComponentSelector that would simply be a subclass of 
CocoonServiceSelector. That would allow to share config files between 
branches.

Grmbl... lost 2 hours this morning to do the merge, and finally reverted 
all :-(

Going to port Tim's swan to widget states so that cforms in 2.2 and 2.1 
can be *identical*.

Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

CForms: widget states added

[Sylvain Wallez]

Hi all,
I finally added widget states to CForms. All widgets can have a "state" 
attribute withe the values "active" (the default), "disabled" or 
"invisible", which are defined in a new WidgetState class.

In disable state, values are displayed, but are not read from the 
request. In invisible state, nothing is displayed (not even labels) and 
values are of course not read from the request. The stylesheets have 
been updated so that disabled widgets are displayed using disabled html 
inputs (eh!).

Tim, this new widget state feature conflicts with your 
"getProcessingRequests()" stuff in 2.2, and I think your "swan" 
experiment could be updated to use widget states.

Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: [lazy vote] cforms request processing

[Sylvain Wallez]

Tim Larson wrote:
We have talked several times about changing the request
processing in cforms to not touch any widget whose
request parameter is missing (to prevent these widgets'
values from being reset to null,) the end result being
that it would be easier for the view to decide how to
split a form across multiple pages without breaking the
SoC between the form model and the view.
As discussed before, this change would involve sending
a hidden field along with every checkbox to indicate
the presence of the checkbox, because an unchecked
checkbox does not generate a request parameter on POST.
This would allow to distinguish between a checkbox that
is unchecked versus a checkbox that is not on the page.
What do we want to do?
[ ] leave as is
[+1] make the changes described above
 

Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

ESQL, Oracle CLOB and encoding

[george georgovassilis]

Good morning Dear All
This is a re-post from the users list where unluckily I didn't find a 
solution to my question.
So, appologies for cross-posting.

I've run into trouble with my ESQL page. In detail:
I'm running an Oracle database pool and a few tables in there with CLOBs 
which contain UTF-8 strings.
The following code extracts the data quite nicely:

oracle.sql.CLOB body =  (oracle.sql.CLOB);
String xmlbody = (body.length()>0? body.getSubString(1, 
(int)body.length()):"");

which returns correctly

ÎÎ ÎÎÏÏÎÏÎ ÎÏÎÏÎ ÏÏÎÎ ÎÎÏÎÎÎÏÎÎ 'ÎÎÎÏÎ / ÎÎ'

The much more elegant
String stripped = ;
however returns garbage:

ÂÎ ÎÂÎÎÂÎÎ Â ÎΠÎÂÎÂÂÎÎâ 'âÂÎΠ/ âÂÂÂÎÂ'

Is there any way I still can use the esql?
Looking forward to your comments
George Georgovassilis

Re: latest Moin

[Upayavira]

Reinhard Poetz wrote:

Well, whether or not we go leftside or rightside, I've managed to 
install Moin 1.2.4 onto an Apache server. Go to:

http://wiki.apache.org/cocoon-test/
This is a Moin 1.2.4 installation, running off a copy of the main 
Wiki site. There's more that needs to be done before we can upgrade, 
for example ensuring we can still do notification mails and central 
configurations for the whole wiki farm. Then, whether others like the 
rightsidebar or not, we can configure it for our own wiki. So, this 
shows that Moin 1.2.4 can work. Now I just need to see if it is a lot 
of work or not. Hmm.

Regards, Upayavira

Col!
Is the content of the right-side bar customizable so that we get our 
former menu back?
What you mean you want a customisable right side bar? Not just a right 
side bar? Fussy eh? ;-)

More seriously, I believe there is a way to configure the options, 
somewhere behind the scenes, but not via the wiki interface.

Regards, Upayavira

DO NOT REPLY [Bug 31312] - [PATCH] Forms without continuation

[bugzilla]

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://issues.apache.org/bugzilla/show_bug.cgi?id=31312

[PATCH] Forms without continuation





--- Additional Comments From [EMAIL PROTECTED]  2004-11-02 09:46 ---
Created an attachment (id=13307)
Form template for sample without continuations. Location: 
src\blocks\forms\samples\forms

DO NOT REPLY [Bug 31312] - [PATCH] Forms without continuation

[bugzilla]

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://issues.apache.org/bugzilla/show_bug.cgi?id=31312

[PATCH] Forms without continuation





--- Additional Comments From [EMAIL PROTECTED]  2004-11-02 09:44 ---
Created an attachment (id=13306)
Flow for sample without continuations. Location: src\blocks\forms\samples\flow

DO NOT REPLY [Bug 31312] - [PATCH] Forms without continuation

[bugzilla]

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://issues.apache.org/bugzilla/show_bug.cgi?id=31312

[PATCH] Forms without continuation





--- Additional Comments From [EMAIL PROTECTED]  2004-11-02 09:43 ---
Created an attachment (id=13305)
Patch for Form.js, sitemap.xmap and welcome.xml for the trunk

DO NOT REPLY [Bug 31312] - [PATCH] Forms without continuation

[bugzilla]

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://issues.apache.org/bugzilla/show_bug.cgi?id=31312

[PATCH] Forms without continuation





--- Additional Comments From [EMAIL PROTECTED]  2004-11-02 09:43 ---
Created an attachment (id=13304)
Patch for Form.js, sitemap.xmap and welcome.xml for the 2.1 branch

DO NOT REPLY [Bug 31312] - [PATCH] Forms without continuation

[bugzilla]

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://issues.apache.org/bugzilla/show_bug.cgi?id=31312

[PATCH] Forms without continuation

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Forms without continuation  |[PATCH] Forms without
   ||continuation



--- Additional Comments From [EMAIL PROTECTED]  2004-11-02 09:42 ---
I needed this too and I was able to implement it. The changes were not 
difficult, but I only changed Cocoon Forms v1. I expect that the changes to v2 
and v3 won't be difficult either. If someone can take a look at v2 and v3 that 
would be great.

I also included a sample which shows how to use Cocoon Forms without 
continuations from Flow.

Re: latest Moin

[Reinhard Poetz]

Upayavira wrote:
Leszek Gawron wrote:
Upayavira wrote:
Ralph Goers wrote:
Is it possible to have the site bar on the left?
 

:-)
The option I found was for a theme called 'rightsidebar'. I have not 
heard mention of a 'leftsidebar' theme, so, unless someone wants to 
do some HTML coding, we're stuck with a right hand one!

AFAIK there is a leftsidebar skin - but not in the distro. it can be 
downloaded from moin website.

Well, whether or not we go leftside or rightside, I've managed to 
install Moin 1.2.4 onto an Apache server. Go to:

http://wiki.apache.org/cocoon-test/
This is a Moin 1.2.4 installation, running off a copy of the main Wiki 
site. There's more that needs to be done before we can upgrade, for 
example ensuring we can still do notification mails and central 
configurations for the whole wiki farm. Then, whether others like the 
rightsidebar or not, we can configure it for our own wiki. So, this 
shows that Moin 1.2.4 can work. Now I just need to see if it is a lot of 
work or not. Hmm.

Regards, Upayavira

Col!
Is the content of the right-side bar customizable so that we get our former menu 
back?

--
Reinhard

Re: latest Moin

[Upayavira]

Leszek Gawron wrote:
Upayavira wrote:
Ralph Goers wrote:
Is it possible to have the site bar on the left?
 

:-)
The option I found was for a theme called 'rightsidebar'. I have not 
heard mention of a 'leftsidebar' theme, so, unless someone wants to 
do some HTML coding, we're stuck with a right hand one!
AFAIK there is a leftsidebar skin - but not in the distro. it can be 
downloaded from moin website.
Well, whether or not we go leftside or rightside, I've managed to 
install Moin 1.2.4 onto an Apache server. Go to:

http://wiki.apache.org/cocoon-test/
This is a Moin 1.2.4 installation, running off a copy of the main Wiki 
site. There's more that needs to be done before we can upgrade, for 
example ensuring we can still do notification mails and central 
configurations for the whole wiki farm. Then, whether others like the 
rightsidebar or not, we can configure it for our own wiki. So, this 
shows that Moin 1.2.4 can work. Now I just need to see if it is a lot of 
work or not. Hmm.

Regards, Upayavira

DO NOT REPLY [Bug 32011] - [PATCH] buildList in AbstractDatabaseAction generates incorrect parameter list

[bugzilla]

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://issues.apache.org/bugzilla/show_bug.cgi?id=32011

[PATCH] buildList in AbstractDatabaseAction generates incorrect parameter list

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|buildList in|[PATCH] buildList in
   |AbstractDatabaseAction  |AbstractDatabaseAction
   |generates incorrect |generates incorrect
   |parameter list  |parameter list



--- Additional Comments From [EMAIL PROTECTED]  2004-11-02 09:12 ---
Thanks for the patch. 

a)Can you provide a small testcase so we can quickly verify that this is
actually a bug?
b)Minor: could you next time use unified diff format (diff -u)? It makes it
easier to work out from the patch itself what it actually changes.

RE: Templating Engine - Next steps?

[Bart Molenkamp]

> -Original Message-
> From: Leszek Gawron [mailto:[EMAIL PROTECTED]
> Reinhard Poetz wrote:
> 
> >
> >  - control structures like for/each, if, choose (RP)
> what bugs me is the verbosity of choose/when/otherwise to implement
> if/else semantics. 

I've also been thinking about a simple method for displaying object
instances of different classes. E.g. I get an object from the flow
layer, I need to decide how to format it. Instances of class "A" are
formatted differently than instances from class "B". Now, this could be
done using , but that doesn't make the code more readable:




Even worse when you want to check if it is instanceof an interface:





Maybe it's a good idea to think some more powerful ways of presenting
(object oriented?) data, so that the statements above could be written
easier? Maybe some form of inheritance when defining macro's, as there
may be some inheritance structure in the data you provide? E.g.

class Vehicle {
  int numberOfWheels;
}

class Car extends Vehicle {
  int fuelType;
}

class Bike extends Vehicle {
  ...
}

(This is obviously a dumb example). Instances of cars and bikes are
formatted differently, except for the numberOfWheels that is defined in
the base class Vehicle (so I want to define the formatting of that
property only once).

This all could be done with the basic JXTemplate building blocks, but it
doesn't make it much more readible in some cases. Also the code is very
verbose, as Leszek says. Maybe it's good to think about some more
powerful methods of formatting data?

Bart.

RE: Release 2.1.6 (was: Re: Switching rhino implementation)

[Carsten Ziegeler]

Antonio Gallardo wrote:
> 
> The task is "easy", we need to merge only few files before 
> the release:
> 
> http://wiki.apache.org/cocoon/MergingBranches
> 
> I think after that we can finally release. ;-)
> 
> WDYT?
> 
Exactly my thoughts - although I have the feeling that some things
have only been added to trunk which should also have gone to 2.1.x...

Anyways, it seems that we are not that interested in merging everything
back from the trunk to the branch, so we can even release without
merging everything. I will have some time next friday to prepare
a release candidate, so I suggest we use whatever is available next
friday.
If noone objects I will put it up to a public place next friday, 
we can test it and then release one week later.

Carsten

Re: Switching rhino implementation

[Reinhard Poetz]

Bertrand Delacretaz wrote:
Le 1 nov. 04, à 19:28, Reinhard Poetz a écrit :
...I would wait with switching to the new flowscript implementation 
until the release of 2.1.6 Then we have a few months to test it in 
branch and trunk and if everything goes well I would deprecate the old 
one and rename it to "javascript-legacy" and the new impl should be 
the default language

In 2.2 I would remove the old implementation completly...

+1, there's no hurry I think, better switch after the release to test 
the new implementation a bit more.

Except maybe using "javascript-2.1.6" instead of "javascript-legacy", in 
order to avoid "javascript-legacy-square" if there is another such move 
down the road ;-)

Thank you guys.
I'm going to replace the old implementation by the new one in trunk. In branch I 
will wait for the new release and rename the old language "javascript-2.1.6" 
which indicates that this is the former implementation. The new implementation 
will be called "javascript". This way most of our users will switch to the new 
implementation without noticing it. If they have problems they can either 
rewrite their catch() statements or change the language to "javascript-2.1.6".

--
Reinhard