[GUMP@lsd]: cocoon-2.1/cocoon failed

[Gump]

To whom it may engage...

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

Project cocoon has an issue affecting its community integration. This issue affects 72 
projects. The current state is 'Failed', for reason 'Build Failed'

Full details are available at: 
http://lsd.student.utwente.nl/gump/cocoon-2.1/cocoon.html, however some snippets 
follow:

-  -  -  -  - -- --  G U M P

Gump provided these annotations:

 - Warning - Jar [cocoon.jar] identifier set to jar basename: [cocoon]
 - Warning - Jar [cocoon-tests.jar] identifier set to jar basename: [cocoon-tests]
 - Warning - Jar [cocoon-deprecated.jar] identifier set to jar basename: 
[cocoon-deprecated]
 - Info - Dependency on avalon-framework exists, no need to add for property 
avalonapi.jar.
 - Info - Enable "debug" output, due to a sequence of 33 previous errors.
 - Error - Failed with reason build failed


-  -  -  -  - -- --  G U M P
Gump performed this work:

Work Name: build_cocoon-2.1_cocoon (Type: Build)
State: Failed
Elapsed: 0 hours, 0 minutes, 40 seconds
Command Line: java -Djava.awt.headless=true -Dbuild.clonevm=true 
-Xbootclasspath/p:/data3/gump/xml-xerces2/java/build/xercesImpl.jar:/data3/gump/xml-xerces2/java/build/xmlParserAPIs.jar:/data3/gump/xml-xalan/java/build/xalan-unbundled.jar:/data3/gump/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -debug -Dgump.merge=/data3/gump/gump-install/work/merge.xml 
-Dbuild.sysclasspath=only 
-Davalonapi.jar=/data3/gump/avalon/framework/api/target/avalon-framework-api-20040324.jar
 -Dlogkit.jar=/data3/gump/avalon-logkit/build/lib/logkit.jar -Dversion=20040324 
gump-core 
[Working Directory: /data3/gump/cocoon-2.1]
-
[javac] private boolean getNullable(Configuration conf, Configuration cons) {
[javac] ^
[javac] 
/data3/gump/cocoon-2.1/src/java/org/apache/cocoon/acting/AbstractValidatorAction.java:831:
 cannot resolve symbol
[javac] symbol  : class Configuration 
[javac] location: class org.apache.cocoon.acting.AbstractValidatorAction
[javac] private String getDefault(Configuration conf, Configuration cons) {
[javac]   ^
[javac] 
/data3/gump/cocoon-2.1/src/java/org/apache/cocoon/acting/AbstractValidatorAction.java:831:
 cannot resolve symbol
[javac] symbol  : class Configuration 
[javac] location: class org.apache.cocoon.acting.AbstractValidatorAction
[javac] private String getDefault(Configuration conf, Configuration cons) {
[javac]   ^
[javac] 
/data3/gump/cocoon-2.1/src/java/org/apache/cocoon/acting/AbstractValidatorAction.java:859:
 cannot resolve symbol
[javac] symbol  : class Configuration 
[javac] location: class org.apache.cocoon.acting.AbstractValidatorAction
[javac] private Long getAttributeAsLong(Configuration conf, String name, Long 
dflt)
[javac] ^
[javac] 
/data3/gump/cocoon-2.1/src/java/org/apache/cocoon/acting/AbstractValidatorAction.java:880:
 cannot resolve symbol
[javac] symbol  : class Configuration 
[javac] location: class org.apache.cocoon.acting.AbstractValidatorAction
[javac] private Double getAttributeAsDouble(Configuration conf, String name, 
Double dflt)
[javac] ^
[javac] 
/data3/gump/cocoon-2.1/src/java/org/apache/cocoon/acting/AbstractValidatorAction.java:896:
 cannot resolve symbol
[javac] symbol  : class Configuration 
[javac] location: class org.apache.cocoon.acting.AbstractValidatorAction
[javac] protected Map indexConfiguration(Configuration[] descriptor) {
[javac]  ^
[javac] 
/data3/gump/cocoon-2.1/src/java/org/apache/cocoon/acting/AbstractValidatorAction.java:1045:
 cannot resolve symbol
[javac] symbol  : class Parameters 
[javac] location: class org.apache.cocoon.acting.AbstractValidatorAction
[javac] Parameters parameters) {
[javac] ^
[javac] 100 errors

BUILD FAILED
/data3/gump/cocoon-2.1/tools/targets/compile-build.xml:60: Compile failed; see the 
compiler error output for details.
at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:938)
at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:758)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:268)
at org.apache.tools.ant.Task.perform(Task.java:363)
at org.apache.tools.ant.Target.execute(Target.java:301)
at org.apache.tools.ant.Target.performTasks(Target.java:328)
at org.apache.tools.ant.Project.executeTarget(Project.java:1214)
at org.apache.t

Re: [RT] On building on stone

[Bertrand Delacretaz]

Le 24 mars 04, à 08:27, Carsten Ziegeler a écrit :

David Crossley wrote:
Pier Fumagalli wrote:
...if this
community at large
wants to see more of the implementation and what I'm talking about,
just speak up, and I'll get a formal authorization from my manager
(until now, confirmation is only verbal).
Okay, here is one person speaking up. How many do you need?

Yes, let's give it a try! So, Pier, please speak to your manager :)
+1 from out here. That's three, and counting...

-Bertrand

RE: [RT] On building on stone

[Carsten Ziegeler]

David Crossley wrote:
> 
> Pier Fumagalli wrote:
> 
> > 
> > With the invaluable help of Stefano and his vision on blocks, I'm 
> > pretty close to a release of the code, and if this 
> community at large 
> > wants to see more of the implementation and what I'm talking about, 
> > just speak up, and I'll get a formal authorization from my manager 
> > (until now, confirmation is only verbal).
> 
> Okay, here is one person speaking up. How many do you need?
> 
Yes, let's give it a try! So, Pier, please speak to your manager :)

Carsten

Re: Last cocoon-2.1.5-dev does not build

[Oscar Picasso]

Follow-up

I think I have a problem in my src/java and that CVS is correct.

Oscar

__
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

Re: Last cocoon-2.1.5-dev does not build

[Oscar Picasso]

Follow-up.

I think I have a problem in my src/java and the CVS seems correct.

__
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

Re: Last cocoon-2.1.5-dev does not build

[Oscar Picasso]

Whether I exclude the velocity block or not, I get the same result:

[EMAIL PROTECTED] cocoon-2.1]$ ./build.sh 
Buildfile: build.xml

prepare:
==
 Apache Cocoon 2.1.5-dev [1999-2004]
==
 Building with Apache Ant version 1.6.1 compiled on February 12 2004
--
 Using build file /mnt/desktop/home/jboss/workspace/cocoon-2.1/build.xml
--
 Compiler options:
   - debug . [on]
   - optimize .. [on]
   - deprecation ... [off]
==
Created dir:
/mnt/desktop/home/jboss/workspace/cocoon-2.1/build/cocoon-2.1.5-dev

compile-core:
Copying 16 files to
/mnt/desktop/home/jboss/workspace/cocoon-2.1/build/cocoon-2.1.5-dev/classes
Copied 59 empty directories to 32 empty directories under
/mnt/desktop/home/jboss/workspace/cocoon-2.1/build/cocoon-2.1.5-dev/classes
Created dir:
/mnt/desktop/home/jboss/workspace/cocoon-2.1/build/cocoon-2.1.5-dev/mocks
Compiling 1 source file to
/mnt/desktop/home/jboss/workspace/cocoon-2.1/build/cocoon-2.1.5-dev/mocks
Compiling 508 source files to
/mnt/desktop/home/jboss/workspace/cocoon-2.1/build/cocoon-2.1.5-dev/classes
/mnt/desktop/home/jboss/workspace/cocoon-2.1/src/java/org/apache/cocoon/generation/VelocityGenerator.java:55:
package org.apache.velocity does not exist
import org.apache.velocity.VelocityContext;
   ^
/mnt/desktop/home/jboss/workspace/cocoon-2.1/src/java/org/apache/cocoon/generation/VelocityGenerator.java:56:
package org.apache.velocity.app does not exist
import org.apache.velocity.app.VelocityEngine;
   ^
/mnt/desktop/home/jboss/workspace/cocoon-2.1/src/java/org/apache/cocoon/generation/VelocityGenerator.java:57:
package org.apache.velocity.context does not exist
import org.apache.velocity.context.Context;
   ^
/mnt/desktop/home/jboss/workspace/cocoon-2.1/src/java/org/apache/cocoon/generation/VelocityGenerator.java:58:
package org.apache.velocity.runtime does not exist
import org.apache.velocity.runtime.RuntimeConstants;
   ^
/mnt/desktop/home/jboss/workspace/cocoon-2.1/src/java/org/apache/cocoon/generation/VelocityGenerator.java:59:
package org.apache.velocity.runtime does not exist
import org.apache.velocity.runtime.RuntimeServices;
   ^
/mnt/desktop/home/jboss/workspace/cocoon-2.1/src/java/org/apache/cocoon/generation/VelocityGenerator.java:60:
package org.apache.velocity.runtime.log does not exist
import org.apache.velocity.runtime.log.LogSystem;
   ^
/mnt/desktop/home/jboss/workspace/cocoon-2.1/src/java/org/apache/cocoon/generation/VelocityGenerator.java:61:
package org.apache.velocity.runtime.resource does not exist
import org.apache.velocity.runtime.resource.Resource;
^
/mnt/desktop/home/jboss/workspace/cocoon-2.1/src/java/org/apache/cocoon/generation/VelocityGenerator.java:62:
package org.apache.velocity.util.introspection does not exist
import org.apache.velocity.util.introspection.Info;
  ^
/mnt/desktop/home/jboss/workspace/cocoon-2.1/src/java/org/apache/cocoon/generation/VelocityGenerator.java:63:
package org.apache.velocity.util.introspection does not exist
import org.apache.velocity.util.introspection.UberspectImpl;
  ^
/mnt/desktop/home/jboss/workspace/cocoon-2.1/src/java/org/apache/cocoon/generation/VelocityGenerator.java:64:
package org.apache.velocity.util.introspection does not exist
import org.apache.velocity.util.introspection.VelMethod;
  ^
/mnt/desktop/home/jboss/workspace/cocoon-2.1/src/java/org/apache/cocoon/generation/VelocityGenerator.java:65:
package org.apache.velocity.util.introspection does not exist
import org.apache.velocity.util.introspection.VelPropertyGet;
  ^
/mnt/desktop/home/jboss/workspace/cocoon-2.1/src/java/org/apache/cocoon/generation/VelocityGenerator.java:66:
package org.apache.velocity.util.introspection does not exist
import org.apache.velocity.util.introspection.VelPropertySet;
  ^
/mnt/desktop/home/jboss/workspace/cocoon-2.1/src/java/org/apache/cocoon/generation/VelocityGenerator.java:158:
cannot resolve symbol
symbol  : class LogSystem 
location: class org.apache.cocoon.generation.VelocityGenerator
implements Initializable, Configurable, LogSystem {
^
/mnt/desktop/home/jboss/workspace/cocoon-2.1/src/java/org/apache/cocoon/generation/VelocityGenerator.java:731:
cannot resolve sym

Re: current CVS: XSP broken

[Joerg Heinicke]

On 20.03.2004 21:42, leo leonid wrote:

Exactly, nobody, neither I did, that was not my concern.
Please take a moment and try to see it from my perspective.
I did not expect that you or anybody specific answers on this temporary 
problem, but *that* anybody answers.

I use the CVS version for developing, and I'm aware of the implications, 
that things can change or even break by the ongoing development process. 
May be it is just a coincidence, or it may be due to the fact that you 
are one of the most active committers - anyhow -  your last commits put 
my projects in a fine mess.
Sorry for that.

Well, this happens, it's not the point, 
absolutely no problem, in general.

Whereas I do have some objections, but these only concern the avoidable 
parts of the mess. That's when you _see_ your patch isn't mature at all 
 and it breaks core parts of cocoon,
This was the reason that I sent a mail to the list. I assume that people 
living from CVS also read the developers list. Therefore I would not 
update my Cocoon if I knew that something is broken. Of course we avoid 
non-working as far as possible, but there also must be some time to 
discuss about things. If something is broken this highers the need for 
discussion while maybe somebody would not answer if it's not broken 
(lazy ass syndrom, "let it as it is").

or spoils users project directories 
(as with bug 27600)
Huh? Sorry, but here I feel innocently accused. *I* added the behaviour 
that the source directory is not touched at all until you choose 
otherwise after the complete update worked. Furthermore this helper 
target was only a few days old, it's not something that breaks anything 
(i.e. is needed at run time) and was easily changeable by the developer 
using the target by putting the xslt part into comments. Here the need 
to revert was very much lower than for the above XSP problem IMO.

and you still don't consider to revert it.
Why? Are you still not satisfied with the current solution making the 
xslt part optional? (You wrote the above two days after I added this.)

Anyway, glad to hear you fixed it. Thanks.
No problem.

Joerg

Re: Include XML string into the pipline via transformer

[Vadim Gritsenko]

Stephan Coboos wrote:

Hello,

I need to include xml coming from a database as string into the 
pipline via my own transformer. (Please do not ask why writing my own 
transformer. I need it..). I had seen, including xml coming form 
sources (xml files) is very easy using the SourceUtil. But how can I 
include xml which exists not as source but as string? Is there already 
a tool avaiable which makes it easy like the SourceUtil?

Any examples?


XSPUtil.java:
   public static void includeString(String string, ComponentManager 
manager, ContentHandler contentHandler)
   throws RuntimeException {
   XSPUtil.includeInputSource(new InputSource(new 
StringReader(String.valueOf(string))), manager,
  contentHandler);
   }

Vadim

Using Saxon 7.9 with Cocoon?

[Andrzej Jan Taramina]

I've been trying to switch our Cocoon (2.1.4) application from using the 
latest Xalan over to using Saxon 7.9 to try and improve XSLT performance.

The problem I am running into is that I keep getting a Saxon exception being 
thrown saying that the Saxon DOM implementation cannot be updated (it's read-
only).

Has anyone managed to get around this and get Cocoon 2.1.4 working using 
Saxon 7.9 as the default XSLT processor?

If so, how did you do this?  Did you replace the Saxon DOM implementation 
(and if so, how)?

Thanks!

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

Re: Last cocoon-2.1.5-dev does not build

[Joerg Heinicke]

On 24.03.2004 03:35, Oscar Picasso wrote:
The build fail on 'compile-core'.

It needs various velocity packages which are located in
'./src/blocks/velocity/lib/velocity-1.4-rc1.jar' but are not in the classpath.
Approx. check-out time: Wed Mar 24 02:34:52 UTC 2004
I can not confirm it. I can build Cocoon though having the velocity 
block excluded. Can you provide more details?

Joerg

Re: Internet Explorer, XHTML, and CForms

[Steve Krulewitz]

Pier Fumagalli wrote:

I hear you, the serializers for plain XHTML are quite nasty... I  
noticed some odd behavior also on the 

Last cocoon-2.1.5-dev does not build

[Oscar Picasso]

The build fail on 'compile-core'.

It needs various velocity packages which are located in
'./src/blocks/velocity/lib/velocity-1.4-rc1.jar' but are not in the classpath.

Approx. check-out time: Wed Mar 24 02:34:52 UTC 2004

Oscar

__
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

Re: woody2.js: custom validation issue in cocoon-2.1.2 to 2.1.4

[Joerg Heinicke]

On 19.03.2004 06:43, Alex Kovacs wrote:

Tested and it behaves the same way, i.e. does not show any custom
validation errors until all other fields are validated correctly.
However, this is not the change that I was hoping for ;-). 

I think the test "if (finished)" is the problem. It only allows for
custom validation just after the form is finished. The finished variable
comes from some lines above in woody2.js:
finished = this.form.process(formContext);
So it seems the form is validated (i.e. finished) only if the built-in
validation is completed. And my understanding is that the form is not
finished until there are no errors, regardless if they are coming from
the custom validation or not. Therefore, I still think the fix above
does not solve my issues. I my code above I've actually removed the "if
(finished ...)" statement to make the fix working ok.
What do you think?
Ah, sorry for that. I hadn't the finished in mind and did not thought 
that you removed this first completely from your snippet. I will have a 
look on it.

Joerg

Re: The XML declaration may only appear at the very beginning of the document

[Joerg Heinicke]

On 23.03.2004 23:48, Lyteck Lynhiavu wrote:

I am trying to publish xml to pdf. the process is established and works most
of the time.
Would someone know why I sometimes get the cocoon error "The XML declaration
may only appear at the very beginning of the document." on perfecly valid
XML?
Unfortunately that's very unspecific, so I also can you only tell 
unspecificly that for what ever reason sometimes you have some trash in 
front of the XML declaration. I guess you first have to make it 
reproducable and after this do some debugging what exactly comes in.

I hope this is a common enough error with a resolution?
No, I heard the first time of it. Of course the error message itself is 
known, but that is normally caused by the developer. I don't know of an 
error that occurs only sporadically.

The cocoon server is Windows to which I am supplying zipped xml/jpgs
remotely via the browser. I don't have much information beyond that.
You upload the files and process them in the pipeline? How does the 
sitemap look like?

Joerg

The SCO stolen code on Linux

[Antonio Gallardo]

Hi:

Here is the link to the stolen code: :-D

http://www.linuxstolescocode.com/

Best Regards,

Antonio Gallardo

Re: [RT] On building on stone

[David Crossley]

Pier Fumagalli wrote:

> 
> All they asked me for for is some form of "recognition" if the code 
> ends up in Cocoon land (quick quick, go back and modify the @author 
> fields in the classes to include VNU Publications), so that they  can 
> prepare a nice "press release" to please our investors, and they can 
> have better discounts when asking for something to be developed by 
> Orixo :-) (hi guys! :-P)

Just like anybody else that contributes, the status.xml file
(i.e. Changes) and the CREDITS.txt provide plenty of exposure.
Documentation and examples of use could provide even more.

> My _personal_ requirement, is that I wouldn't want a clean-cut fork to 
> happen, because at the end of the day, I'd have to abandon the Cocoon 
> fork and get back to the VNU's fork (doh, they pay me).
> 
> A directory on the CVS repository which I can check out and build 
> without requiring too many dependancies on Cocoon's main "publication 
> core" will be more than enough, I can build my own "Ant" build files. 
> That would make my (working) life _so_ much easier...

You could just add it to cocoon-2.2 and do whatever you want.

--David

Re: [RT] On building on stone

[David Crossley]

Pier Fumagalli wrote:

> 
> With the invaluable help of Stefano and his vision on blocks, I'm 
> pretty close to a release of the code, and if this community at large 
> wants to see more of the implementation and what I'm talking about, 
> just speak up, and I'll get a formal authorization from my manager 
> (until now, confirmation is only verbal).

Okay, here is one person speaking up. How many do you need?

--David

The XML declaration may only appear at the very beginning of the document

[Lyteck Lynhiavu]

Title: Message



I am trying to 
publish xml to pdf. the process is 
established and works most of the time.

Would someone know why 
I sometimes get the cocoon error "The XML declaration may only appear at 
the very beginning of the document." on perfecly valid XML?

  Description:org.apache.cocoon.ProcessingException: 
  Could not read resource 
  file:/D:/Publisher/jakarta-tomcat-4.0.1/webapps/cocoon/test/test.xml: org.xml.sax.SAXParseException: The 
  XML declaration may only appear at the very beginning of the 
  document.
The XML declaration is indeed at the top and a sample fragment is 
below:

  []>
I hope this is 
a common enough error with a resolution?
The cocoon server is Windows to which I 
am supplying zipped xml/jpgs 
remotely via the browser. I 
don't have much information beyond that.
Thanks very 
much, Lyteck

Re: cvs commit: cocoon-2.1/tools/src blocks-build.xsl

[Joerg Heinicke]

On 24.03.2004 01:53, Geoff Howard wrote:

This was the reason for the common classpath, wasn't it? I wanted to 
have a look on it after having reverted the common classpath, but I 
guess that's no longer needed. Thanks for it. BTW, which block depends 
on other block's samples?


Not sure if this is what you mean, but there are some interdependencies 
between block samples involving (I think) database, hsql, eventcache, 
jms, and maybe repository.  No block depends outright on samples, but 
samples do depend on other blocks where the dependency disappears 
without the samples.
I hope no block's core code is depending on another block's samples code 
and we will not introduce such a dependency as this would break 
compiling if one excludes the samples from the build. What I meant was 
one block's samples dependent on another block's samples (all about 
compiling Java files).

I would prefer to see some conditional build steps 
to allow "soft" dependencies for samples and even optional pieces of 
code.  IOW, some bits are included if the dependency is met, otherwise not.
Indeed. At the moment in gump.xml both sample and compiling dependencies 
are mixed and sometimes not specified at all (e.g. OJB samples depend on 
CForms). AFAIK there is no strict handling of gump.xml and Gump does not 
stumble about additional attributes, so we might add an @type to the 
dependency element. This can be used for better dependency information 
in blocks.properties and maybe also for blocks-build.xsl

Joerg

Re: [Cforms] Minor errors in JavaScriptJXPathBinding*.java

[Joerg Heinicke]

On 23.03.2004 21:20, [EMAIL PROTECTED] wrote:

Hi guys,

On studying the code in the JavaScriptJXPathBinding files I noticed that the
comments (both error comments and javadoc) still use the old namespace
convention (i.e. wb instead of fb).
Just wanted to let you know.
Fixed, thanks for reporting.

Joerg

Re: Internet Explorer, XHTML, and CForms

[Pier Fumagalli]

On 23 Mar 2004, at 23:26, Steve Krulewitz wrote:

Tim Larson recently brought up the issue of the serialized  
representation of empty tags when using the XMLSerializer for serving  
XHTML [1].  This was sparked from a thread I had started on the users  
list about this issue.  I've done some considerable hair pulling over  
the past day, and I think I finally nailed it down.
I thought I fixed it into the XHTML serializers I put in the scratchpad  
with the old Garbage implmentation, but looking at the code right now,  
err, no I didn't...

I hear you, the serializers for plain XHTML are quite nasty... I  
noticed some odd behavior also on the 

Re: Internet Explorer, XHTML, and CForms

[Antonio Gallardo]

Steve Krulewitz dijo:
> What do you think?


Looks to me as a ugly hack. Why we need to hack to patch a buggie browser
that not meet the specifications? I think this is a not a good idea?
Another solution is tell your users the browser they use is buggie and ask
them to download a better browser :-D


Seriously, first of all, thanks for digging in this problem and point out
the problem.

It will be very hard if not imposible adding a special hack for a bug in a
current release of a browser. AFAIK a  allow you to know
what kind of browser sent the request and based on this info you can use a
customized serializer to workaround the problem.

Best Regards,

Antonio Gallardo

Re: cvs commit: cocoon-2.1/tools/src blocks-build.xsl

[Geoff Howard]

Joerg Heinicke wrote:
On 23.03.2004 20:23, [EMAIL PROTECTED] wrote:

stephan 2004/03/23 11:23:07

  Modified:tools/src blocks-build.xsl
  Log:
  Allow to share codebase to other blocks.


   
  +
  +
   
 
   


This was the reason for the common classpath, wasn't it? I wanted to 
have a look on it after having reverted the common classpath, but I 
guess that's no longer needed. Thanks for it. BTW, which block depends 
on other block's samples?
Not sure if this is what you mean, but there are some interdependencies between 
block samples involving (I think) database, hsql, eventcache, jms, and maybe 
repository.  No block depends outright on samples, but samples do depend on 
other blocks where the dependency disappears without the samples.  I would 
prefer to see some conditional build steps to allow "soft" dependencies for 
samples and even optional pieces of code.  IOW, some bits are included if the 
dependency is met, otherwise not.

Geoff

Re: [RT] On building on stone

[Pier Fumagalli]

On 23 Mar 2004, at 18:22, Sylvain Wallez wrote:

Please, Stefano - *do not* under any circumstances (despite Sylvain's 
suggestion) take your underwear off while coding.  :)
Hey Geoff, he doesn't have a webcam, so let him code the way he likes 
;-)
Note to self: given that I have a webcam pointed at me at all time when 
I'm at work, remember not to pick nose and to shave in the morning! :-P

	Pier

Re: [RT] On building on stone

[Pier Fumagalli]

I keep forgetting to add something...

On 23 Mar 2004, at 13:45, Bertrand Delacretaz wrote:

... 4) keep the framework and container *MINIMAL* to our own needs. 
[we WILL NOT redistribute the framework independently]..
Sure. But if the next Cocoon Core is sufficiently small (and 
*perceived* as such) and powerful, people might want to use it "just" 
as a container, even for simple things...
My employer doesn't care really about what happens to the code, we're 
going to use it anyway as our foundation, whether it's donated to 
Cocoon and we maintain our own "fork", whether you guys want it at all 
or not... All that VNU cares about is that we deliver a platform  based 
on _OUR_ blocks (lots of which you will never see in a million years, 
because they're core of our business! :-)

BTW, not to scare anyone, I work for a news company 
 , not a software company. OUR blocks will be 
those blocks linking our websites to our backends (Oracle Databases, 
Navision Financials, QuarkDMS publishing environments, and yada yada 
yada).

All they asked me for for is some form of "recognition" if the code 
ends up in Cocoon land (quick quick, go back and modify the @author 
fields in the classes to include VNU Publications), so that they  can 
prepare a nice "press release" to please our investors, and they can 
have better discounts when asking for something to be developed by 
Orixo :-) (hi guys! :-P)

My _personal_ requirement, is that I wouldn't want a clean-cut fork to 
happen, because at the end of the day, I'd have to abandon the Cocoon 
fork and get back to the VNU's fork (doh, they pay me).

A directory on the CVS repository which I can check out and build 
without requiring too many dependancies on Cocoon's main "publication 
core" will be more than enough, I can build my own "Ant" build files. 
That would make my (working) life _so_ much easier...

	Pier

Re: [RT] On building on stone

[Pier Fumagalli]

On 23 Mar 2004, at 13:45, Bertrand Delacretaz wrote:

 2) create an avalon emulation layer for the legacy components that 
would allow avalon components to run unmodified [this allows users to 
have a smooth migration path and no immediate impact on their 
development/mainteinance costs]
Both sound very good assuming someone is able and willing to do the 
work. But I understand you and Pier would have (or already have had) 
energy to contribute.
I had quite a lot of time to spare on it as my employer (as the members 
of the PMC know) asked me to lay down the groundwork for our next 
back-end platform. And basically, I had to come up with a framework 
satisfying certain requirements.

With the invaluable help of Stefano and his vision on blocks, I'm 
pretty close to a release of the code, and if this community at large 
wants to see more of the implementation and what I'm talking about, 
just speak up, and I'll get a formal authorization from my manager 
(until now, confirmation is only verbal).

I am sorry for those who are not on the PMC (on the PMC I keep a more 
detailed status update, and occasionally post some code snapshots), but 
it's not _MY_ code. Yes, I wrote it, but it's my EMPLOYER's code, and 
legally I personally don't own it.

  - O -

Back from the working bench, right now all I can say is that some of 
the contracts WILL HAVE to change in the root container, and Stefano's 
100% right, we cannot use the contracts outlined by Avalon4.

That said, I am sure that on an individual block level (forgetting 
about infra-block contracts) compatibility can be provided quite easily 
by re-wrapping some of the interfaces, providing some extensions, and 
doing some sh***y glue-work.

"Old" blocks can (IMVHO) work just fine in the new container, "New" 
blocks will work a bazillion times better! :-P

	Pier

Internet Explorer, XHTML, and CForms

[Steve Krulewitz]

Tim Larson recently brought up the issue of the serialized 
representation of empty tags when using the XMLSerializer for serving 
XHTML [1].  This was sparked from a thread I had started on the users 
list about this issue.  I've done some considerable hair pulling over 
the past day, and I think I finally nailed it down.

The problem I ran into is this.  I want to serve my pages as XHTML, so 
I've been using the XMLSerializer with XHTML doctypes similar to the way 
it is set up in the stock root sitemap.  It is also well known that 
standards-compliant browsers like Mozilla will only render XHTML 
properly if sent with the "application/xhtml+xml" content type, where 
Internet Explorer will not accept this, and requires you to send it as 
"text/html".  This is easily solvable with some pipeline magic I posted 
about [2] -- I have another solution to this using a Tomcat Filter that 
I will post shorty.

Next I was trying to use a textarea on cforms.  No matter what I did, 
this would render incorrectly on Internet Explorer when the textarea is 
empty.  Because I'm using the XMLSerializer, an empty textarea gets 
rendered as:



And this is why: no combination of doctypes, content types, filename 
extensions, etc, will make this work... because Internet Explorer just 
does not understand XHTML!  When Internet Explorer encounters an XHTML 
page, it still parses in "tag soup" mode and just discards XHTML-isms. 
Ian Hickson does a good job explaining this in his "Sending XHTML as 
text/html Considered Harmful." [3]  This strategy works pretty well, but 
fails miserably on the empty textarea element.

So as things stand right now, if someone wants to use a textarea in 
their forms and serve them as XHTML, they will run into problems on 
Internet Explorer.  I think this is a problem since it is *possible* to 
do this -- a textarea rendered with an explicit closing tag will render 
properly on Internet Explorer and will be valid XHTML.  However, I do 
not believe this is currently possible with Cocoon.

I believe the solution lies in extending the default XML stream writer 
that comes with Xalan (org.apache.xml.serializer.ToXMLStream).  A new 
output setting could be added that provides a list of element names that 
should never be minimized when they are empty.  This would allow the 
same XHTML pages that work on standards-compliant browsers to render 
properly in Internet Explorer.

It isn't clear to me if a new XML stream writer can be added to Xalan 
without modifying the Xalan source, but the actual coding does not look 
very hard.

What do you think?

cheers,
-steve
[1] http://marc.theaimsgroup.com/?m=107999114518402
[2] http://marc.theaimsgroup.com/?m=108001750400120
[3] http://www.hixie.ch/advocacy/xhtml

Re: Visualisation tree

[Tim Larson]

On Tue, Mar 23, 2004 at 10:31:08PM +0100, [EMAIL PROTECTED] wrote:
> Has anyone a idea how to present the tree structure of a xml in cocoon.
> I have a DOM, out of the DOM I want to get all the element nodes
> (done by a helperclass, integrated in a xsp).
> Further I want to set a new position for a existing node and give
> the information to the DOM ...
> 
> thx for your incitation,

If you are slightly brave, take a look at the Woody/Cocoon Forms
"Form Model GUI" sample: (Cocoon 2.1.4)
  http://127.0.0.1:/samples/woody/form_model_gui.flow
or current CVS
  http://127.0.0.1:/samples/forms/form_model_gui.flow

It takes an XML document, in this case it happens to be a cforms
model file, and presents it as input fields/etc.  Perhaps you could
adapt the concepts to suit your needs.

--Tim Larson

Visualisation tree

[[EMAIL PROTECTED]]

Has anyone a idea how to present the tree structure 
of a xml in cocoon. I have a DOM, out of the DOM I want to get all the element 
nodes (done by a helperclass, integrated in a xsp).
Further I want to set a new position for a existing 
node and give the information to the DOM ...
 
thx for your incitation,
 
Dietmar
 

[Cforms] Minor errors in JavaScriptJXPathBinding*.java

[H . vanderLinden]

Hi guys,

On studying the code in the JavaScriptJXPathBinding files I noticed that the
comments (both error comments and javadoc) still use the old namespace
convention (i.e. wb instead of fb).

Just wanted to let you know.

Bye, Helma

DO NOT REPLY [Bug 27875] - Profiling data not saved with internal pipelines

[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=27875

Profiling data not saved with internal pipelines

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-03-23 19:51 ---
Thanks, for the snippet, To be true, I not really sure how it works. 
It's a long time ago, since I know enough of the internals.

So, please cross check.
Stephan Michels.

Re: cvs commit: cocoon-2.1/tools/src blocks-build.xsl

[Stephan Michels]

Am Di, den 23.03.2004 schrieb Joerg Heinicke um 20:37:
> On 23.03.2004 20:23, [EMAIL PROTECTED] wrote:
> > stephan 2004/03/23 11:23:07
> > 
> >   Modified:tools/src blocks-build.xsl
> >   Log:
> >   Allow to share codebase to other blocks.
> 
> >
> >   +
> >   +
> >
> >  
> >
> 
> This was the reason for the common classpath, wasn't it? 

One reason ;-)

> I wanted to 
> have a look on it after having reverted the common classpath, but I 
> guess that's no longer needed. Thanks for it. BTW, which block depends 
> on other block's samples?

I think at moment none, but will come next ;-)

Stephan.

Re: cvs commit: cocoon-2.1/tools/src blocks-build.xsl

[Joerg Heinicke]

On 23.03.2004 20:23, [EMAIL PROTECTED] wrote:
stephan 2004/03/23 11:23:07

  Modified:tools/src blocks-build.xsl
  Log:
  Allow to share codebase to other blocks.

   
  +
  +
   
 
   
This was the reason for the common classpath, wasn't it? I wanted to 
have a look on it after having reverted the common classpath, but I 
guess that's no longer needed. Thanks for it. BTW, which block depends 
on other block's samples?

Joerg

DO NOT REPLY [Bug 27878] - XMLResourceBundleFactory is missing catalogs

[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=27878

XMLResourceBundleFactory is missing catalogs





--- Additional Comments From [EMAIL PROTECTED]  2004-03-23 19:05 ---
Created an attachment (id=10930)
Patch to correct this defect

DO NOT REPLY [Bug 27878] New: - XMLResourceBundleFactory is missing catalogs

[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=27878

XMLResourceBundleFactory is missing catalogs

   Summary: XMLResourceBundleFactory is missing catalogs
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


_select in XMLResourceBundleFactory loops through the directories and locales
locating resource bundles. However, it stops when it encounters the first bundle
name that doesn't have a locale, missing those that might be in one of the other
locations.  The provided patch fixes that.

Re: [RT] On building on stone

[Hamilton Verissimo de Oliveira (Engenharia - SPO)]

-Mensagem original-
De: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]

> Sure. But if the next Cocoon Core is sufficiently small (and 
> *perceived* as such) and powerful, people might want to use it "just" 
> as a container, even for simple things...

As an ex-avaloner I second that. :-)

The last attempt to get a consensus over avalon was to create a simple,
lightweight container that would be the basis for the current one. Please
refer to http://cvs.apache.org/viewcvs.cgi/avalon-sandbox/aspect

...By the end of last year I would suggest that these effort follow together
with avalon team efforts, but now I encourage Cocoon to develop his own
rock-solid container.

sad but true.

But don't loose your faith over Avalon. Things can change... 
"Who knows what the tide will bring?"


--
hammett

Re: [RT] On building on stone

[Sylvain Wallez]

Geoff Howard wrote:

Sylvain Wallez wrote:

Stefano Mazzocchi wrote:

Fire at will: I have my abstesto underwear on.


Put it off: it doesn't help to get code written (see point 6)!


Please, Stefano - *do not* under any circumstances (despite Sylvain's 
suggestion) take your underwear off while coding.  :)


Hey Geoff, he doesn't have a webcam, so let him code the way he likes ;-)

Sylvain

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

DO NOT REPLY [Bug 27875] - Profiling data not saved with internal pipelines

[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=27875

Profiling data not saved with internal pipelines





--- Additional Comments From [EMAIL PROTECTED]  2004-03-23 18:21 ---
Hello Stephan,
I've added the following methods to the ProfilingNonCachingProcessingPipeline
and the ProfilingCachingProcessingPipeline classes (Testing was only done using
the noncaching class):



/**
 * Process the SAX event pipeline
 */
protected boolean processXMLPipeline(Environment environment)
throws ProcessingException {
this.index = 0;
if (this.data!=null) {
// Capture environment info
this.data.setEnvironmentInfo(new EnvironmentInfo(environment));

// Execute pipeline
long time = System.currentTimeMillis();
boolean result = super.processXMLPipeline(environment);

this.data.setTotalTime(System.currentTimeMillis()-time);

// Report
profiler.addResult(environment.getURI(), this.data);
return result;
} else {
getLogger().warn("Profiler Data havn't any components to measure");
return super.processXMLPipeline(environment);
}
}

/**
 * Process the pipeline using a reader.
 * @throws ProcessingException if
 */
protected boolean processReader(Environment environment)
throws ProcessingException {
this.index = 0;
 if (this.data!=null) {
 // Capture environment info
 this.data.setEnvironmentInfo(new EnvironmentInfo(environment));

 // Execute pipeline
 long time = System.currentTimeMillis();
 boolean result = super.processReader(environment);

 this.data.setTotalTime(System.currentTimeMillis()-time);

 // Report
 profiler.addResult(environment.getURI(), this.data);
 return result;
 } else {
 getLogger().warn("Profiler Data havn't any components to measure");
 return super.processReader(environment);
 }
}
   

DO NOT REPLY [Bug 27875] - Profiling data not saved with internal pipelines

[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=27875

Profiling data not saved with internal pipelines

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Additional Comments From [EMAIL PROTECTED]  2004-03-23 17:58 ---
If you have already done it, you can perhaps provide us a patch?!

DO NOT REPLY [Bug 25934] - [PATCH] LuceneIndexContentHandler.java produces CLOBs

[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=25934

[PATCH] LuceneIndexContentHandler.java produces CLOBs





--- Additional Comments From [EMAIL PROTECTED]  2004-03-23 17:51 ---
Applies to both patches:

@@ -130,6 +129,8 @@
...
+text.append(' ');
This doen't look like it's necesarry: "text" contains only the concatenated
children text-nodes of the current node. It's only used when the current node is
closed, where the text is passed for indexing or storing.

+bodyText.append(' ');
I think this is the relevant line and it looks correct.

After thinking more and more about this problem, I'm no longer sure that adding
spaces is always the right solution to the problem. You already posted two
examples where adding spaces is wrong, while I posted an example where adding
spaces looks like a good idea. So either make adding spaced configurable or
document the facts and mention that the user has to do an extra transformation
step before indexing his XML data, when he heeds extra spaces.

DO NOT REPLY [Bug 27875] New: - Profiling data not saved with internal pipelines

[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=27875

Profiling data not saved with internal pipelines

   Summary: Profiling data not saved with internal pipelines
   Product: Cocoon 2
   Version: 2.1.4
  Platform: PC
OS/Version: All
Status: NEW
  Severity: Minor
  Priority: Other
 Component: blocks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When processing an internal pipeline, the 'processXMLPipeline' or
'processReader' methods of the AbstractProcessingPipeline are invoked instead of
the 'process' method. These methods are not oberwritten by the
Profiling...Pipeline classes and therefore no profiling data will be saved. The
fix is straightforward: Copy the 'process' method, rename it and replace the
calls to super.process with super.processXMLPipeline resp. super.processReader.
I've done it within my testing environment and it works fine.

Re: [RT] On building on stone

[Geoff Howard]

Sylvain Wallez wrote:

Stefano Mazzocchi wrote:

Fire at will: I have my abstesto underwear on.
 >
Put it off: it doesn't help to get code written (see point 6)!
Please, Stefano - *do not* under any circumstances (despite Sylvain's 
suggestion) take your underwear off while coding.  :)

Geoff

Re: [RT] On building on stone

[Sylvain Wallez]

Stefano Mazzocchi wrote:

I want Cocoon to last long and to be able to stand the pressure of a 
big user community, a diverse development community and that of 
companies built on top of it.




So, here is my detailed proposal:

 1) implement our own framework and container in order to implement 
cocoon blocks [this creates the solid foundation that we control]

 2) create an avalon emulation layer for the legacy components that 
would allow avalon components to run unmodified [this allows users to 
have a smooth migration path and no immediate impact on their 
development/mainteinance costs]

 3) operate as incrementally as possible and work to change as little 
code as possible [this makes the community transition smoother, 
reduces enthropy and bugs introduced by the new code]

 4) keep the framework and container *MINIMAL* to our own needs. [we 
WILL NOT redistribute the framework independently]

 5) the name for our framework+container will be simply Cocoon Core

 6) I volunteer to help directly in writing code


Although this means that we enter a long road before having 2.2, I think 
this is the way to go. The Cocoon house is big, and it must have solid 
foundations that it controls in order to continue growing.

Now point 2 is important, as lots of people have invested in Cocoon and 
would be very confused if we abruptly changed the way Cocoon works. 
Fortunately, we stayed on ECM and avoided the migration to more complex 
containers, which should ease the writing of this compatibility layer.

It's also the occasion to consider what we can learn from the good, the 
bad and the ugly in existing containers while building our own, 
specifically adapted to our needs. As Steven said, so many people write 
their own containers nowadays that it's certainly not rocket science, 
although it requires clever ideas, an area in which Pier and you have 
proved your abilities ;-)



Fire at will: I have my abstesto underwear on.


Put it off: it doesn't help to get code written (see point 6)!

Sylvain

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

RE: Transform runs twice

[Hunsberger, Peter]

Vadim Gritsenko <[EMAIL PROTECTED]> comes through once more:
 
> 
> Hunsberger, Peter wrote:
> 
> >I've got a straight forward pipeline where it appears that a 
> transform 
> >runs twice:
> >
> >
> >
> > src="stylesheets/resolve_sysInfo.xsl"/>
> >
> >
> >
> >
> >If I look at the pipeline output after the generator I have the 
> >expected data.  If I capture that data and feed it into the 
> >resolve...xsl (using Stylus or Xslerator) things work as 
> expected.  If 
> >I capture the output of the pipeline after the resolve...xsl 
> I see two 
> >copies of the output XML  The next transform then runs 
> twice and I 
> >get the output XHTML twice (complete with two top level  tags, 
> >which IE happily accepts).
> >
> >I'm running Cocoon 2.1.4 with Saxon.  Any ideas on how to track this 
> >down or what to look for?
> >  
> Saxon can do this when endDocument() is sent twice. Insert log 
> transformer in between - check that generated SAX events are ok
> 

Many thanks, that was indeed it; sub-class and super class both did a
start/endDocument()...

DO NOT REPLY [Bug 27871] - [XSP] logicsheet-util.xsl causes XSP Java class not to be compilable

[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=27871

[XSP] logicsheet-util.xsl causes XSP Java class not to be compilable





--- Additional Comments From [EMAIL PROTECTED]  2004-03-23 15:30 ---
Created an attachment (id=10923)
patch for logicsheet-util.xsl (links to above comment)

DO NOT REPLY [Bug 27871] New: - [XSP] logicsheet-util.xsl causes XSP Java class not to be compilable

[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=27871

[XSP] logicsheet-util.xsl causes XSP Java class not to be compilable

   Summary: [XSP] logicsheet-util.xsl causes XSP Java class not to
be compilable
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: blocks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi,
actually, I am addressing two issues found in logicsheet-util.xsl (that is 
usualy used in xsp logicsheets):

1. Empty parameter 'default' is not tested correctly, because when used as

  fooparam
  false
  


then the test 
  xsl:if string-length($default) = 0 
obviously returns true but it should not.

2. template get-nested-string produces invalid string literals because it 
doesn't always translate LF to single space as it should when converting 
 to Java string.
For example, 

  
request.getParameter("foo")
  


produces expression simmilar to:

"" 
+ "
  "
+ request.getParameter("foo")

I am providing patch for these changes and they both changes should be backward 
compatible.

RE: [RT] On building on stone

[Carsten Ziegeler]

Stefano Mazzocchi wrote:
> 
>
> So, here is my detailed proposal:
> 
>   1) implement our own framework and container in order to 
> implement cocoon blocks [this creates the solid foundation 
> that we control]
> 
>   2) create an avalon emulation layer for the legacy 
> components that would allow avalon components to run 
> unmodified [this allows users to have a smooth migration path 
> and no immediate impact on their development/mainteinance costs]
> 
>   3) operate as incrementally as possible and work to change 
> as little code as possible [this makes the community 
> transition smoother, reduces enthropy and bugs introduced by 
> the new code]
> 
>   4) keep the framework and container *MINIMAL* to our own 
> needs. [we WILL NOT redistribute the framework independently]
> 
>   5) the name for our framework+container will be simply Cocoon Core
> 
>   6) I volunteer to help directly in writing code
> 
+100 for all points ,especially for point 2)

The container is our core and it is much easier and also safer to
maintain our own container than to rely on someone else. In the past
years we always had to struggle each time the used container changed
in an unforseeable way. With our own container, our core is 
independent. Great!

Carsten

Re: [RT] On building on stone

[Steven Noels]

On 23 Mar 2004, at 14:25, Stefano Mazzocchi wrote:

Thus the proposal to write and maintain our own, in order to finally, 
once and for all, build on stone and escape the social quicksands in 
core depenendies.
Makes perfect sense to me. I guess we should look at our current 
investment in ECM knowledge & code, look at Pier's alternative, and 
basically decide and JFDI. We gave Avalon a loyal "customer" to deal 
with in the past, but there never was a life-time engagement contract. 
We already missed various new container efforts over @ Avalon, and I'm 
confident we now know what we need and are able to build it ourselves 
in the (new) core of Cocoon. Given the flurry of new containers out 
there, I think people are demonstrating that container development is 
not rocket science - and since it's core to Cocoon's operations, it's 
sensible to deal with that ourselves.

There will be aspects of backward-compatibility to deal with, which we 
can deal with by providing compatibility layers, or by just going for 
Cocoon 3.0. 2.1 is there, it's solid and used a lot, and if there's 
consensus that innovation should not be hindered by compatibility, we 
can simply vote and start 3.0. I would humbly suggest not to change the 
syntax of the sitemap into Lisp, though. ;-)

Fire at will: I have my abstesto underwear on.
I honestly see no reason why. Thanks for biting the bullet, and even 
more thanks to step up and agree to do part of the coding effort. I 
hope many will join you.


--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source Java & XMLAn Orixo Member
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org

Re: [RT] On building on stone

[Geoff Howard]

Stefano Mazzocchi wrote:
I want Cocoon to last long and to be able to stand the pressure of a big 
user community, a diverse development community and that of companies 
built on top of it.
...

This leads to a rather difficult choice:

 1) avoid implementing real blocks
 2) change our foundation framework
I would go for #2, since I consider real blocks vital for the evolution 
of this project.

Now, if we go #2 there are three choices:

 1) patch avalon
 2) change framework
 3) do our own
Here my choice would not be technologically driven but rather socially 
driven: I would do our own.

Why? because Avalon's communities are not healthy. The turnover rate is 
incredily high and the burn-out period is amazingly short. Its simply 
too fragile to build cocoon on something like this.
I'd add a parallel reason which may also be understood by people who may be less 
convinced about the health of that community or its importance (alas, I am no 
longer one).  We cannot trust this core to a separate entity who have many other 
needs to consider in parallel.  Why?  We have specific needs, and need them 
quick.  Also, we've found in practice that our container needs don't always have 
a lot of overlap with others' needs.  We are far simpler in some ways, more 
complicated in others.  If in some hypothetical future scenario others share a 
good deal of our needs, we can decide at that time if we should enable others to 
use our core by packaging separately - but I would be surprised if we ever would 
a) want this core managed elsewhere, or b) want to have to answer to users with 
different needs totally unrelated to Cocoon.

Fire at will: I have my abstesto underwear on.
Hopefully you will not need it.  Your proposal needs to be tested by fire, but 
not you - let's get that out here early.  Personally, knowing that there is 
already some "code on disk" makes this seem very attainable.  If it means we 
have blocks sooner than later, I am 100% behind it.

Geoff

Re: [RT] On building on stone

[Bertrand Delacretaz]

Le 23 mars 04, à 14:25, Stefano Mazzocchi a écrit :



...So, here is my detailed proposal:

 1) implement our own framework and container in order to implement 
cocoon blocks [this creates the solid foundation that we control]

 2) create an avalon emulation layer for the legacy components that 
would allow avalon components to run unmodified [this allows users to 
have a smooth migration path and no immediate impact on their 
development/mainteinance costs]
Both sound very good assuming someone is able and willing to do the 
work. But I understand you and Pier would have (or already have had) 
energy to contribute.

I think the "in order to implement cocoon blocks" bit is key: although 
Avalon is obviously shaky at the moment, the current ECM stuff used 
here is very stable and took a lot of work to polish. There must be a 
very good reason to replace it, and if it's Real Blocks combined with 
pouring concrete where needed, great!

... 4) keep the framework and container *MINIMAL* to our own needs. 
[we WILL NOT redistribute the framework independently]..
Sure. But if the next Cocoon Core is sufficiently small (and 
*perceived* as such) and powerful, people might want to use it "just" 
as a container, even for simple things...

...Fire at will: I have my abstesto underwear on.
No need for it as far as I'm concerned. Thanks for your realistic and 
respectful point of view.

-Bertrand

Re: submit-widget validate="false"

[Joerg Heinicke]

Leszek Gawron  wlkp.org> writes:

> As ins subject: the button defined this way submits the form and ATTEMPTS
> validation. Can anybody confirm this in current CVS head?

Yes, see bug 27785 [1] for more information. For submit widget with
@validate="false" the validation should happen, but not be evaluated as the form
processing is ended. Does this match your observations? What do you hint at with
your "attempts" in upper case?

Joerg

[1] http://issues.apache.org/bugzilla/show_bug.cgi?id=27785

Re: [GUMP][PATCH] Add avalon-framework impl classes

[Joerg Heinicke]

Stefan Bodewig  apache.org> writes:

> The build fails since Cocoon only states a dependency on the
> avalon-framework API but uses implementation classes as well[2].
> 
> The appended patch should fix that.

Patch applied. Thanks. Please report back if it works.

Joerg

[RT] On building on stone

[Stefano Mazzocchi]

I want Cocoon to last long and to be able to stand the pressure of a big 
user community, a diverse development community and that of companies 
built on top of it.

For this reason, we must identify in advance all moves that lead to 
making the cocoon project weaker.

There are three things that provide foundation for a project:

 1) its technology
 2) its community
 3) its license
The three things are not so unrelated as some people think, but this is 
not the topic for today.

Gump indicates that Cocoon has 205 dependencies on external projects. 
Gump has been able to do a clean cocoon run only *once* in its entire 
three-years-long existance.

This is not good. It shows that we are building on sand.

There are two ways to get out of this:

 1) better modularity (to reduce dependencies)
 2) more solid dependencies for our core (to increase solidity of our 
foundations)

As for better modularity, we designed the Cocoon Blocks.

We now have to finish #2.

- 0 -

I've been helping Pier write a block-like container for his employer and 
found out that no matter how hard we try, the Avalon interfaces cannot 
allow to implement Cocoon Blocks the way we designed them.

In short: if we want to have hot-deployable, polymorphically dependent 
high-level cocoon web application components, we can't use Avalon4.

- o -

This leads to a rather difficult choice:

 1) avoid implementing real blocks
 2) change our foundation framework
I would go for #2, since I consider real blocks vital for the evolution 
of this project.

Now, if we go #2 there are three choices:

 1) patch avalon
 2) change framework
 3) do our own
Here my choice would not be technologically driven but rather socially 
driven: I would do our own.

Why? because Avalon's communities are not healthy. The turnover rate is 
incredily high and the burn-out period is amazingly short. Its simply 
too fragile to build cocoon on something like this.

From a community perspective, Avalon is sand. Avalon's biggest problem 
is that technology is more important than the community. Purity that 
leads to forks is more important than compromises that keep the 
community together.

This is such a strong cultural clash which impact was for long 
underestimated.

Not so anymore and since now we need to make a choice, my choice would 
be to design our own framework and container.

   - o -

So, here is my detailed proposal:

 1) implement our own framework and container in order to implement 
cocoon blocks [this creates the solid foundation that we control]

 2) create an avalon emulation layer for the legacy components that 
would allow avalon components to run unmodified [this allows users to 
have a smooth migration path and no immediate impact on their 
development/mainteinance costs]

 3) operate as incrementally as possible and work to change as little 
code as possible [this makes the community transition smoother, reduces 
enthropy and bugs introduced by the new code]

 4) keep the framework and container *MINIMAL* to our own needs. [we 
WILL NOT redistribute the framework independently]

 5) the name for our framework+container will be simply Cocoon Core

 6) I volunteer to help directly in writing code

- 0 -

Now, before everybody and their dog replies to this and wishes to 
convince us to use their framework, the only measure of judgement would 
nto be technological but community and its culture.

Cocoon needs a rock solid core.

Solid in both technical, social and legal way.

I believe that social and legal solidity build technical one. The 
opposite is not true. Cocoon and Avalon (both highly considered from a 
technical perspective) demonstrate this pretty well.

I see no potential cocoon core out there that is not a one-man show and 
that allows us to do what we want to achieve with real blocks.

Thus the proposal to write and maintain our own, in order to finally, 
once and for all, build on stone and escape the social quicksands in 
core depenendies.

Fire at will: I have my abstesto underwear on.

--
Stefano.



smime.p7s
Description: S/MIME Cryptographic Signature

submit-widget validate="false"

[Leszek Gawron]

As ins subject: the button defined this way submits the form and ATTEMPTS
validation. Can anybody confirm this in current CVS head?
lg

-- 
__
 | /  \ |Leszek Gawron//  \\
\_\\  //_/   [EMAIL PROTECTED]   _\\()//_
 .'/()\'. Phone: +48(501)720812 / //  \\ \
  \\  //  recursive: adj; see recursive  | \__/ |

Re: Include XML string into the pipline via transformer

[Jorg Heymans]

in transform(Document doc) you can access the document in a DOM like 
fashion ie

Element a = document.createElement("myelement");
Element b = document.createElement("myelementchild");
Element addedParameter = document.createElement("parameter");
addedParameter.setAttribute("name", "output");
Element addedParameterValue = document.createElement("value");
addedParameterValue.appendChild(document.createTextNode("some text here"));
addedParameter.appendChild(addedParameterValue);
b.appendChild(addedParameter);
a.appendChild(reqparams);
document.appendChild(req);
I don't know if there is an "easier" way than this.

HTH
Jorg
Stephan Coboos wrote:

Hello,

I need to include xml coming from a database as string into the pipline 
via my own transformer. (Please do not ask why writing my own 
transformer. I need it..). I had seen, including xml coming form sources 
(xml files) is very easy using the SourceUtil. But how can I include xml 
which exists not as source but as string? Is there already a tool 
avaiable which makes it easy like the SourceUtil?

Any examples?

Thank you very much.

Regards
Stephan

Include XML string into the pipline via transformer

[Stephan Coboos]

Hello,

I need to include xml coming from a database as string into the pipline 
via my own transformer. (Please do not ask why writing my own 
transformer. I need it..). I had seen, including xml coming form sources 
(xml files) is very easy using the SourceUtil. But how can I include xml 
which exists not as source but as string? Is there already a tool 
avaiable which makes it easy like the SourceUtil?

Any examples?

Thank you very much.

Regards
Stephan

[Help]Any change due to this database action error or just getConfiguration?

[roy huang]

I use database action to save data into database ,the pipeline looks like:
   

 
 
 


   

the cocoon:raw:/forms/{1}/define_data.xml looks like
 


 
   

   

the formdefine transformer is writter by myself to get the corret xml file from the 
defien_data.xml(all config save in this file).
It works fine in 2.1.4,but in current cvs version ,it will produce an error:

Original Exception: org.apache.avalon.framework.configuration.ConfigurationException: 
Error trying to load configurations for resource: 
cocoon://gtt/apps/app1/forms/test/define_data.xml

at 
org.apache.cocoon.acting.AbstractComplementaryConfigurableAction.getConfiguration(AbstractComplementaryConfigurableAction.java:102)

at org.apache.cocoon.acting.modular.DatabaseAction.act(DatabaseAction.java:614)

I try to find why this error occour,so:
1.I use an pipeline to get the xml file in the same way to 
cocoon:raw:/forms/{1}/define_data.xml,and save it in define_data.xml
2.I change   to 
 


   
 It works fine,so my transformer did generate the correct xml
3.In my Transformer(extends AbstractSAXTransformer),I insert some println
  in startTransformingElement(String uri,String name,String raw,Attributes attributes)

  System.out.println("name:"+name);//

DO NOT REPLY [Bug 27709] - Problem with national chars submitted with form

[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=27709

Problem with national chars submitted with form





--- Additional Comments From [EMAIL PROTECTED]  2004-03-23 10:54 ---
I tried also Tomcat 4.1.27 (as suggested), tested with sample forms included 
with Cocoon - no positive results. I can comfirm that problem is about wrong 
escaping (like Ł).

RE: FYI: New Sitemap Treeprocessor for 2.2

[Carsten Ziegeler]

Hi,

it seems that when you have vacation that you even have less time than
when you go to work :(
I'm very sorry, but I can't continue the work on the tree processor
this week, there are "more important" things to do. Unfortunately,
the version I currently have is worse than what we have in 2.2 
anyway (apart that it's not that tied to Fortress anymore and it
supports different sitemap versions, but it provides less functionality).
So, I will not commit it.

Sorry,
Carsten
 

> -Original Message-
> From: Sylvain Wallez [mailto:[EMAIL PROTECTED] 
> Sent: Monday, March 22, 2004 12:10 PM
> To: [EMAIL PROTECTED]
> Subject: Re: FYI: New Sitemap Treeprocessor for 2.2
> 
> Carsten Ziegeler wrote:
> 
> >Sylvain Wallez wrote: 
> >  
> >
> >>>Hi,
> >>>
> >>>to avoid double efforts in the same area, I just wanted to 
> inform you that I will try to write a new tree processor for 
> 2.2 in the next few days.
> >>>  
> >>>
> >>>Why? There are several reasons:
> >>>- Reverting to ECM in 2.2 requires some changes to the 
> tree processor 
> >>>used in 2.1.x anyway
> >>>  
> >>>
> >>Curious : are these changes those related to the changes on 
> Environment, or are there more?
> >>
> >>
> >Not only, we removed some of the deprecated component stuff in 2.2 
> >(excalibur component selector etc.)
> >  
> >
> 
> Ah yeah. But we still need ServiceSelector.
> 
> >>>- Implementing Virtual Sitemap Components
> >>>- Implementing Inheritance of Views
> >>>  
> >>>
> >>I do have some ideas about this and am willing to 
> participate. Where do we start?
> >>
> >>
> >Here on my PC :)
> >
> 
> Ah, so please commit your PC in the CVS :-)
> 
> 
> 
> >>With all features? That's quick!
> >>
> >>
> >:) - Ehm,...,hmmhok, perhaps not with all features, but 
> >some of them :)
> >  
> >
> 
> :-P
> 
> Sylvain
> 
> -- 
> Sylvain Wallez  Anyware Technologies
> http://www.apache.org/~sylvain   http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
> 
>