Re: [GT 2004] PGP key signing?

[David Crossley]

Torsten Curdt wrote:
> > 
> > So that people can verify the integrity of our releases.
> 
> ...because not everyone knows our keys
> are at pgp.mit.edu we ship them ...I see

There is a thread on [EMAIL PROTECTED] recently about that.
The KEYS file is just a convenience. There are probably better
ways to do it, but that gets people going quickly.

Another thing we did at Forrest was for more than one
of us to sign each release in the accompanying *.asc file.

-- 
David Crossley

DO NOT REPLY [Bug 31862] New: - XSP Doesn't work in current head version

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

XSP Doesn't work in current head version

   Summary: XSP Doesn't work in current head version
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: PC
OS/Version: Other
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: blocks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


wiped out cache and temp directories, cleaned, rebuilt and XSP no longer work, 
samples are broken and generator gives null pointer exception in current head 
of 2.1.  

Version:   55353.

org.apache.cocoon.ProcessingException: java.lang.NullPointerException

cause: java.lang.NullPointerException

full exception chain stacktrace[show] 

org.apache.cocoon.ProcessingException: java.lang.NullPointerException
at org.apache.cocoon.generation.ServerPagesGenerator.setup
(ServerPagesGenerator.java:181)
at 
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline
(AbstractProcessingPipeline.java:359)
at 
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.se
tupPipeline(AbstractCachingProcessingPipeline.java:606)
at 
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.preparePipelin
e(AbstractProcessingPipeline.java:480)
at 
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process
(AbstractProcessingPipeline.java:430)
at 
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke
(SerializeNode.java:134)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
odes(AbstractParentProcessingNode.java:54)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke
(PreparableMatchNode.java:112)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
odes(AbstractParentProcessingNode.java:76)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke
(PipelineNode.java:138)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
odes(AbstractParentProcessingNode.java:76)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke
(PipelinesNode.java:95)
at 
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process
(ConcreteTreeProcessor.java:265)
at 
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process
(ConcreteTreeProcessor.java:208)
at org.apache.cocoon.components.treeprocessor.TreeProcessor.process
(TreeProcessor.java:230)
at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke
(MountNode.java:111)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
odes(AbstractParentProcessingNode.java:54)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke
(PreparableMatchNode.java:112)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
odes(AbstractParentProcessingNode.java:76)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke
(PipelineNode.java:138)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
odes(AbstractParentProcessingNode.java:76)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke
(PipelinesNode.java:95)
at 
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process
(ConcreteTreeProcessor.java:265)
at 
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process
(ConcreteTreeProcessor.java:208)
at org.apache.cocoon.components.treeprocessor.TreeProcessor.process
(TreeProcessor.java:230)
at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke
(MountNode.java:111)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
odes(AbstractParentProcessingNode.java:54)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke
(PreparableMatchNode.java:112)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
odes(AbstractParentProcessingNode.java:76)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke
(PipelineNode.java:138)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
odes(AbstractParentProcessingNode.java:76)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke
(PipelinesNode.java:95)
at 
org.apache.cocoon.component

Re: [GT 2004] PGP key signing?

[Torsten Curdt]

Excellent, that will strengthen the ties to the crowd
via Carsten.
http://www.apache.org/~henkp/trust/apache.html
Carsten, Sylvain ...looks like you did not
yet sign and/or update the keys on pgp.mit.edu?
What is it for?

So that people can verify the integrity of our releases.
...because not everyone knows our keys
are at pgp.mit.edu we ship them ...I see
Oh no! I just realised that the Cocoon download page does
not promote the use of keys or md5sum at all.
See Forrest download for explanation. We investigated lots
of other Apache projects to then build our download facility.
http://forrest.apache.org/mirrors.cgi
Henk's pages use each project's KEYS file:
[1] http://www.apache.org/~henkp/trust/apache.html
[2] http://www.apache.org/~henkp/ => Integrity
ah... ok!
Thanks for the explanation :)
--
Torsten

webdav block, davmap, binaries PUT, request reader

[Frédéric Glorieux]

Hi,
Sorry to disturb you for a so specific question, but I evaluate and 
understood today the block webdav/davmap

really amazing how it's a pretty way to have a quite full implementation 
of webdav, except,

PUT binary files.
Do someone plan to write the reader needed for that ?
Are there some blocking issues ?
I can't stop myself to try tomorrow, but I'm not the best guy to do the job.
Help welcome, but thanks anymore for all work already done.
--
Frédéric Glorieux (ingénieur documentaire, AJLSM)

Re: [GT 2004] PGP key signing?

[David Crossley]

Torsten Curdt wrote:
> > So how did the key signing go at the GetTogether?
> 
> Did go well :-)
> 
> At least Bertrand, Carsten, Marcus, Sylvain and me signed keys.

Excellent, that will strengthen the ties to the crowd
via Carsten.
http://www.apache.org/~henkp/trust/apache.html

> > Did you also update the KEYS file in our cocoon SVN?
> 
> Ups ...didn't know we have such a file :-)
> 
> What is it for?

So that people can verify the integrity of our releases.

Oh no! I just realised that the Cocoon download page does
not promote the use of keys or md5sum at all.

See Forrest download for explanation. We investigated lots
of other Apache projects to then build our download facility.
http://forrest.apache.org/mirrors.cgi

Henk's pages use each project's KEYS file:

[1] http://www.apache.org/~henkp/trust/apache.html
[2] http://www.apache.org/~henkp/ => Integrity

-- 
David Crossley

Re: [GT 2004] PGP key signing?

[David Crossley]

Bertrand Delacretaz wrote:
> David Crossley a écrit :
> 
> > Did you also update the KEYS file in our cocoon SVN?
> 
> my key's in there already.

If my understanding is correct, then it needs to be
updated each time your key is signed.

-- 
David Crossley

DO NOT REPLY [Bug 31857] - [PATCH] Portal - Page Labels

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

[PATCH] Portal - Page Labels





--- Additional Comments From [EMAIL PROTECTED]  2004-10-22 21:12 ---
Created an attachment (id=13196)
Patch that provides page label support to the portal

DO NOT REPLY [Bug 31857] New: - [PATCH] Portal - Page Labels

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

[PATCH] Portal - Page Labels

   Summary: [PATCH] Portal - Page Labels
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: blocks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


This patch adds support for page labels in the portal. See Portal Page Labels in
the wiki for documentation.

DO NOT REPLY [Bug 31760] - Handle / Semaphore Leak?

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

Handle / Semaphore Leak?





--- Additional Comments From [EMAIL PROTECTED]  2004-10-22 20:51 ---
I have two cocoon processes running on a NT production system with the 
configuration cocoon 2.1.5 / tomcat 5.0.28 / java 1.4.2_05. the number of 
handles increases as described, but is stable at the level of +/- 11% of the 
amount of RAM in KB used by the java VM. In my case this means around 11000 
handles with 100MB of RAM used. from the tests with 2.1.6-dev / java 1.4.2_06 I 
suppose there will be an improvement. I will report the results here.

DO NOT REPLY [Bug 31854] - [PATCH] Javaflow JavaInterpreter is not thread safe

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

[PATCH] Javaflow JavaInterpreter is not thread safe





--- Additional Comments From [EMAIL PROTECTED]  2004-10-22 20:09 ---
Created an attachment (id=13195)
Patch to synchronize initialization method.

DO NOT REPLY [Bug 31854] New: - [PATCH] Javaflow JavaInterpreter is not thread safe

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

[PATCH] Javaflow JavaInterpreter is not thread safe

   Summary: [PATCH] Javaflow JavaInterpreter is not thread safe
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: blocks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


If a page causes two cocoon pipelines to be invoked, each of which contains
javaflow, a null pointer exception may occur.  This occurs because there is a
race condition checking the initialized flag.

Re: Making tests suck less (was Re: ECM++)

[Ugo Cei]

Il giorno 22/ott/04, alle 19:40, Reinhard Poetz ha scritto:
Have you considered using Easymock? IMHO its usage is more intuitive 
than jMock.
(see BlockDeployer test cases)
After perusing the documentation and samples, I decided that I liked 
jMock more, but I didn't try EasyMock in practice. If you are familiar 
with it, you might try doing a version of the 
ResourceExistsActionTestCase that I just refactored, so we can do a 
comparison and decide which is better. However, I suspect it's more a 
matter of taste than anything else.

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


smime.p7s
Description: S/MIME cryptographic signature

RE: ECM++

[Carsten Ziegeler]

The replacement for the ExtendedComponentSelector is the
CocoonServiceSelector-
I planned to add our own Testcase base class in the next days. 
But if someone is faster than me ... :)

Carsten 

> -Original Message-
> From: Ugo Cei [mailto:[EMAIL PROTECTED] 
> Sent: Friday, October 22, 2004 4:42 PM
> To: [EMAIL PROTECTED]
> Subject: Re: ECM++
> 
> Currently, all the unit tests involving sitemap components 
> fail because the class 
> org.apache.cocoon.components.ExtendedComponentSelector, which 
> is referenced by *.xtest files, has been removed.
> 
> Now, those tests depend on the deprecated ExcaliburTestcase 
> class and it would be nice to get rid of that dependency, but 
> as a stopgap measure, is there a class in ECM++ that can take 
> its place just by substituting the classname in its place?
> 
>   Ugo
> 

Re: [cron block] dependency question

[Torsten Curdt]

Wow, you propose using maven?

apparently ;-)

Ok.
hehe ...here we go again :o)
cheers
--
Torsten

Re: [cron block] dependency question

[Giacomo Pati]

On Fri, 22 Oct 2004, Stefano Mazzocchi wrote:
Giacomo Pati wrote:
The simplest possible thing would be to have a block descriptor extend 
a maven POM and use maven to build them.
Wow, you propose using maven?
apparently ;-)
Ok.
blocks are very simple things and don't require special treatment so 
they could be built with maven easily. As for the whole thing, I'm still 
not sure.
Yes. And those blocks can be deployed on remote repositories to allow 
other projects to depend on them. That's how we do since months. We've 
developed our own Maven plugin to manage Cocoon projects outside the hole 
cocoon tree. Cocoon for us is not more part of the project, just an 
infrastructure as is httpd.

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

Re: Making tests suck less (was Re: ECM++)

[Reinhard Poetz]

Ugo Cei wrote:
I wrote:

Using the jMock library, the test looks like this (slightly edited to 
simplify):
Have you considered using Easymock? IMHO its usage is more intuitive than jMock.
(see BlockDeployer test cases)
--
Reinhard

Re: Making tests suck less (was Re: ECM++)

[Reinhard Poetz]

Ugo Cei wrote:
I wrote:

Using the jMock library, the test looks like this (slightly edited to 
simplify):
Have you considered using Easymock? IMHO its usage is more intuitive than jMock.
--
Reinhard

Re: cronjob leak memory

[Vadim Gritsenko]

arnaud DANEELS wrote:
I have tested with cocoon 2.1.5.1 final
If I was not clear; it was a hint: you supposed to read status.xml, see that 
this bug is fixed some time ago, download 2.1.6-dev, test it, see that is is 
really fixes the issue (or not), and report back with results ("thanks, it 
works", "no, it still does not work").

Vadim

-Message d'origine-
De : Vadim Gritsenko [mailto:[EMAIL PROTECTED] 
Envoyé : vendredi 22 octobre 2004 17:58
À : [EMAIL PROTECTED]
Objet : Re: cronjob leak memory

arnaud DANEELS wrote:
Hello,

   I notice that cronjob crash tomcat 5.0.19 with an outofmemory in the 
cron.log


   When I call “hellojob”,  memory is quite stable…

   If you add an xslstylesheet in your pipeline, memory increase by 5 
Mb on average each time cron do his job…


   I use xalan 2.6.0.

   Have you any information about this problem

Have you tested this with current SVN snapshot of 2.1 branch? See also
status 
file in 2.1 branch:
   http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/status.xml

Vadim

Re: VMWare host for us @apache.org

[Rogier Peters]

Rogier Peters wrote:
Bertrand Delacretaz wrote:
Le 22 oct. 04, à 13:29, Rogier Peters a écrit :
...Although I agree completely that it's the accessability, not the 
quality of the documentation that is lacking, i can't help but 
hearing echoes of the GT cms-shootout ( bag of docs; heavy on search ).
Why use forrest and not daisy or hippo?

I wanted to put Forrest as the first option for "loyalty" reasons, as 
the Forrest team has helped us a lot until now. But there are many 
options of course.

But at this point we should be careful not to fall into the trap of 
discussing tools before agreing on the problem.

-Bertrand
You're right, actually I replied before reading
oops, and then I pressed send before completing.
before reading the whole discussion that is.
Rogier

Re: VMWare host for us @apache.org

[Rogier Peters]

Bertrand Delacretaz wrote:
Le 22 oct. 04, à 13:29, Rogier Peters a écrit :
...Although I agree completely that it's the accessability, not the 
quality of the documentation that is lacking, i can't help but hearing 
echoes of the GT cms-shootout ( bag of docs; heavy on search ).
Why use forrest and not daisy or hippo?

I wanted to put Forrest as the first option for "loyalty" reasons, as 
the Forrest team has helped us a lot until now. But there are many 
options of course.

But at this point we should be careful not to fall into the trap of 
discussing tools before agreing on the problem.

-Bertrand
You're right, actually I replied before reading

Re: [cron block] dependency question

[Stefano Mazzocchi]

Giacomo Pati wrote:
The simplest possible thing would be to have a block descriptor extend 
a maven POM and use maven to build them.
Wow, you propose using maven?
apparently ;-)
blocks are very simple things and don't require special treatment so 
they could be built with maven easily. As for the whole thing, I'm still 
not sure.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Making tests suck less (was Re: ECM++)

[Ugo Cei]

I wrote:
Currently, all the unit tests involving sitemap components fail because 
the class org.apache.cocoon.components.ExtendedComponentSelector, which 
is referenced by *.xtest files, has been removed.

Now, those tests depend on the deprecated ExcaliburTestcase class and it 
would be nice to get rid of that dependency, but as a stopgap measure, 
is there a class in ECM++ that can take its place just by substituting 
the classname in its place?
Well, after thinking about the issue some more, I decided to rewrite all 
the sitemap components' testcases following a different approach. I 
intend to drop the SitemapComponentTestCase altogether and its 
dependency on ExcaliburTestCase with it. First, what are the problems 
with it?

1. Dependency on a deprecated class.
2. Writing tests is harder than it should be, with all those *.xtest files.
3. LAST BUT NOT THE LEAST: mostly we are not testing what we should be 
testing. An example will clarify what I mean:

== ResourceExistsActionTestCase.java ==
public void testExistAction() throws Exception {
String src = 
"resource://org/apache/cocoon/acting/ResourceExistsActionTestCase.xtest";
Parameters parameters = new Parameters();

Map result = act("exist", src, parameters);
assertNotNull("Test if resource exists", result);
src = 
"resource://org/apache/cocoon/acting/ResourceExistsActionTestCase.abc";

...
}
=
This testcase is supposed to test the following method:
== ResourceExistsAction.java ==
public Map act(Redirector redirector, SourceResolver resolver, Map 
objectModel, String src, Parameters parameters) throws Exception {
String resourceURI = parameters.getParameter("url", src);
Source source = null;
try {
source = resolver.resolveURI(resourceURI);
if (source.exists()) {
return EMPTY_MAP;
}
} catch (SourceNotFoundException e) {
// Do not log
} catch (Exception e) {
getLogger().warn("Exception resolving resource " + 
resourceURI, e);
} finally {
if (source != null) {
resolver.release(source);
}
}
return null;
}


But does it? What it does is test the SourceResolver.resolveURI method! 
I would expect that the SourceResolver class was already bug-free and 
had its own tests. There's no point testing that.

What should we be testing instead? Everything that can possibly go 
wrong. What can go wrong here? Well, for instance, the programmer might 
have forgotten to relase the source. We should be testing that the 
source is always released. There's not much else here that can go wrong.

How do we test for that? One possibility is to use mock objects and set 
expectations on them. We will give our action a mock SourceResolver 
which returns a mock source. On those objects, we set an expectation 
that the release method is indeed called, and verify that expectation.

Using the jMock library, the test looks like this (slightly edited to 
simplify):

String src = "don't care";
ResourceExistsAction action = new ResourceExistsAction();
Mock resolver = new Mock(SourceResolver.class);
Mock source = new Mock(Source.class);
resolver.expects(once()).method("resolveURI").with(same(src)).
will(returnValue(source.proxy()));
resolver.expects(once()).method("release").with(same(source.proxy()));
source.expects(atLeastOnce()).method("exists").will(returnValue(true));
Map result = action.act(null, (SourceResolver) resolver.proxy(),
objectModel, src, parameters);
assertSame("Test if resource exists", AbstractAction.EMPTY_MAP, 
result);
resolver.verify();
source.verify();

If we forget to call the release method, the "resolver.verify()" call 
will fail. You will notice also that the value of the "src" parameter is 
totally irrelevant. We don't need the resolver to actually resolve the 
URI. We just need it to return any implementation of the Source 
interface and call "release" on that. One less test fixture to care of.

What we have gained is a less fragile, more relevant testcase.
In the coming days, I plan to rewrite all tests depending on 
ExcaliburTestCase so that we can forget about it. Stay tuned.

	Ugo

RE: cronjob leak memory

[arnaud DANEELS]

I have tested with cocoon 2.1.5.1 final


-Message d'origine-
De : Vadim Gritsenko [mailto:[EMAIL PROTECTED] 
Envoyé : vendredi 22 octobre 2004 17:58
À : [EMAIL PROTECTED]
Objet : Re: cronjob leak memory

arnaud DANEELS wrote:
> Hello,
> 
>  
> 
> I notice that cronjob crash tomcat 5.0.19 with an outofmemory in the 
> cron.log
> 
>  
> 
> When I call “hellojob”,  memory is quite stable…
> 
>  
> 
> If you add an xslstylesheet in your pipeline, memory increase by 5 
> Mb on average each time cron do his job…
> 
>  
> 
> I use xalan 2.6.0.
> 
>  
> 
> Have you any information about this problem

Have you tested this with current SVN snapshot of 2.1 branch? See also
status 
file in 2.1 branch:
   http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/status.xml


Vadim

Re: VMWare host for us @apache.org

[Tony Collen]

David Crossley wrote:
So i gather that you are saying that we, Cocoon,
need a group of us who are committed to maintain
the operating system and supporting applications.
I am keen to help and learn.
I'm more than willing to lend a hand -- I have a ton of experience 
adminning a couple FreeBSD boxes.  You haven't lived until you've 
compiled the native JVM on FreeBSD overnight ;)

Tony

Re: VMWare host for us @apache.org

[Tony Collen]

David Crossley wrote:
Bertrand Delacretaz wrote:
But at this point we should be careful not to fall into the trap of 
discussing tools before agreing on the problem.

Yes, it is a strong magnet.
Let's just use the simplest solution for now and see how that works 
(IMO, Forrest).  I think we can get by with committing docs to a "live" 
svn repository and have them show up immediately -- in fact it could be 
such an amazing improvement over the current system, we might not care 
about having anything more.

Tony

Re: cronjob leak memory

[Vadim Gritsenko]

arnaud DANEELS wrote:
Hello,
 

I notice that cronjob crash tomcat 5.0.19 with an outofmemory in the 
cron.log

 

When I call “hellojob”,  memory is quite stable…
 

If you add an xslstylesheet in your pipeline, memory increase by 5 
Mb on average each time cron do his job…

 

I use xalan 2.6.0.
 

Have you any information about this problem
Have you tested this with current SVN snapshot of 2.1 branch? See also status 
file in 2.1 branch:
  http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/status.xml

Vadim

Re: VMWare host for us @apache.org

[Tony Collen]

Rogier Peters wrote:
Bertrand Delacretaz wrote:
Le 22 oct. 04, à 12:23, David Crossley a écrit :

What's needed IMHO is the "big bag of docs with powerful search 
functions" that we talked about before 
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106586497031048&w=2 
for example).
I like the idea, but let's make sure we end up with very usable URIs. 
IMNSHO we *have* to have URIs of words, and not something like 
/docs/foo/3446521.html.  It's just not good.  I propose we try to 
"correctly" reorganize the docs before resorting to BBOD with crazy 
URIs.  I have some decent experience with organizing and reorganizing 
site docs from previous jobs, so it can't be all that hard, can it? :)

If we agree on this, the next step would be to evaluate Forrest 
against our needs and find out the simplest thing that would work. 
Maybe Forrest using a live SVN repository, live Lucene indexing and 
mod_cache in front would be all what we need?
Having "live docs" would be a boon to the documentation.  The biggest 
hurdle I face when I work on docs is the fact that I have to edit the 
original xdocs, commit those, and (re- generating the site and 
committing a second set.  A live Forrest would be awesome.

Although I agree completely that it's the accessability, not the quality 
of the documentation that is lacking, i can't help but hearing echoes of 
the GT cms-shootout ( bag of docs; heavy on search ).
Why use forrest and not daisy or hippo?


Rogier

Tony

DO NOT REPLY [Bug 31760] - Handle / Semaphore Leak?

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

Handle / Semaphore Leak?





--- Additional Comments From [EMAIL PROTECTED]  2004-10-22 15:36 ---
I agree, but you need also try to run java 1.4.2_06 and comment your results.
The posted tests show there is a problem with java 1.4.2_05 and/or cocoon
2.1.5.x. The 2.1.6-dev version seems to be better. Please try this version as we
are planning a release soon.

Re: [GT 2004] PGP key signing?

[Torsten Curdt]

So how did the key signing go at the GetTogether?

We did check some keys, I have signed the ones that I checked and 
updated pgp.mit.edu accordingly.

Could the other people who verified keys at the GT also sign and upload 
accordingly?
yepp ...did that already
cheers
--
Torsten

Re: [GT 2004] PGP key signing?

[Torsten Curdt]

So how did the key signing go at the GetTogether?
Did go well :-)
At least Bertrand, Carsten, Marcus, Sylvain and me signed keys.
Did you also update the KEYS file in our cocoon SVN?
Ups ...didn't know we have such a file :-)
What is it for?
cheers
--
Torsten

Re: Compiling ClassLoader

[Torsten Curdt]

Vadim Gritsenko wrote:
Heya,
Was looking at the flow, "found" CompilingClassLoader. Seems to me that 
this piece is a bit out of place sitting deep in the flow implementation.

Does it make sense to move it a bit up, to the level of sitemap's 
component manager? This way, all sitemap components can benefit from 
dynamic compilation.
It definitly makes sense :-)
Unfortunately with the new eclipse jdt jar the
CompilingClassLoader is broken anyway.
But I hope fix that within the next few days.
Unfortunately the eclipse API has changed.
cheers
--
Torsten

Re: [GT 2004] PGP key signing?

[Bertrand Delacretaz]

Le 22 oct. 04, à 16:46, David Crossley a écrit :
So how did the key signing go at the GetTogether?
We did check some keys, I have signed the ones that I checked and 
updated pgp.mit.edu accordingly.

Could the other people who verified keys at the GT also sign and upload 
accordingly?
See http://www.cryptnet.net/fdp/crypto/gpg-party.html for info if 
needed ("signing others' keys").

Did you also update the KEYS file in our cocoon SVN?
my key's in there already.
-Bertrand


smime.p7s
Description: S/MIME cryptographic signature

cronjob leak memory

[arnaud DANEELS]

Hello,

 

    I notice that cronjob crash tomcat 5.0.19 with an
outofmemory in the cron.log

 

    When I call “hellojob”,  memory is
quite stable…

 

    If you add an xslstylesheet in your pipeline,
memory increase by 5 Mb on average each time cron do his job…

 

    I use xalan 2.6.0.

 

    Have you any information about this problem

 

   Thank you for your answers

 

 

Arnaud.

 

RE: Questions to be answered for link request - V2

[H . vanderLinden]

Hi,

> Would an "Intranet applications" section also make sense?  As 
> I see it, this list would be a list of organizations and 
> applications with a brief description of the application.  
> Perhaps a screen shot or two would also be encouraged or even 
> required?

I'd love to see this, yes with some screenshots to make it more "real".

Bye, Helma

Re: [GT 2004] PGP key signing?

[David Crossley]

So how did the key signing go at the GetTogether?

Did you also update the KEYS file in our cocoon SVN?

--David

Dirk-Willem van Gulik wrote:
> Bertrand Delacretaz wrote:
> 
> > I've never organized a signing party, but if everyone comes with
> > several printed copies of their key, with their name on it, I think
> > it's fairly easy to swap them and validate at least the people that we
> > know well.
> 
> Easiest way to do this is:
> 
> Ask people to go to a wiki page:
> 
>   http://wiki.apache.org/cocoon/CocoonGetTogether2004PGP
> 
> or someting like that.
> 
> Then on that page have something like
> 
> - Ensure your fingerprint is at a keyserver (See
>   http://pgp.mit.edu/) for details.
> 
> - Please add your fingerprint+email to this page; e.g.
>   the output 'gpg --fingerprint [EMAIL PROTECTED]' or
>   'pgpk -ll [EMAIL PROTECTED]'
> 
>   pub  1024R/EC140B81 1997-04-10 Dirk-Willem van Gulik
>   <[EMAIL PROTECTED]>
>   Key fingerprint = A5 EC 78 D5 BB DE FE ED  50 55 DA 6D C6 E0 E7 85
> 
> And ask people to do this before the first day of the event. Then at the
> event print out N copies of this page. Then whenever you meet (or you just
> all meet) you each verify with each other that *your* on *their* printout
> is correct. And then 'they' put an OK next to your name.
> 
> Once you get home you can add/sign each of the fingerprints you have made
> a mark against.
> 
> Dw

Re: ECM++

[Ugo Cei]

Currently, all the unit tests involving sitemap components fail because 
the class org.apache.cocoon.components.ExtendedComponentSelector, which 
is referenced by *.xtest files, has been removed.

Now, those tests depend on the deprecated ExcaliburTestcase class and it 
would be nice to get rid of that dependency, but as a stopgap measure, 
is there a class in ECM++ that can take its place just by substituting 
the classname in its place?

	Ugo

Re: Compiling ClassLoader

[Tim Larson]

On Fri, Oct 22, 2004 at 10:24:48AM -0400, Vadim Gritsenko wrote:
> Heya,
> 
> Was looking at the flow, "found" CompilingClassLoader. Seems to me that 
> this piece is a bit out of place sitting deep in the flow implementation.
> 
> Does it make sense to move it a bit up, to the level of sitemap's component 
> manager? This way, all sitemap components can benefit from dynamic 
> compilation.
> 
> WDYT?
> 
> Vadim

+1000 (While of course retaining the ability to configure it on/off.)

--Tim Larson

Compiling ClassLoader

[Vadim Gritsenko]

Heya,
Was looking at the flow, "found" CompilingClassLoader. Seems to me that this 
piece is a bit out of place sitting deep in the flow implementation.

Does it make sense to move it a bit up, to the level of sitemap's component 
manager? This way, all sitemap components can benefit from dynamic compilation.

WDYT?
Vadim

Re: Questions to be answered for link request

[Bertrand Delacretaz]

Le 22 oct. 04, à 16:10, David Crossley a écrit :
...How do other people determine that a site is actually
based on Cocoon?
I don't think there's much more than what you suggest. Looking at the 
way the HTML is serialized can help a bit but it's really getting into 
forensics at this point ;-)

The configuration of a website can make it very hard to find out that 
it's running Cocoon, I guess we'll have to believe the people at some 
point, maybe after asking some details as we've done in the past.

-Bertrand


smime.p7s
Description: S/MIME cryptographic signature

Re: Questions to be answered for link request

[David Crossley]

David Crossley wrote:
> H.vanderLinden wrote:
> 
> > How can we verify this site is actually built with Cocoon?
> 
> I think it is good to ask them to tell us. Then we review it
> and we would verify behind the scenes. I do various tests like
> view-source and especially do 'head http://them.com/' which
> usually shows cocoon version. Sometimes however, you just cannot
> verify.

How do other people determine that a site is actually
based on Cocoon?

-- 
David Crossley

Re: Questions to be answered for link request - V2

[Bertrand Delacretaz]

Le 22 oct. 04, à 15:49, Hunsberger, Peter a écrit :
...Would an "Intranet applications" section also make sense?  As I see 
it,
this list would be a list of organizations and applications with a 
brief
description of the application.  Perhaps a screen shot or two would 
also
be encouraged or even required?...
+1, having more success stories is certainly good.
Requiring an image (screenshot, architecture, whatever makes the thing 
more real to outsiders) is a good idea IMHO.

-Bertrand


smime.p7s
Description: S/MIME cryptographic signature

Re: Questions to be answered for link request - V2

[Upayavira]

Hunsberger, Peter wrote:
[EMAIL PROTECTED] <[EMAIL PROTECTED]> writes:
 

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
   

proposed form details
 

   

All of this makes sense and I don't see any real problem with it.  A
related issue is whether you also want people to submit descriptions of
intranet sites?  

We use Cocoon for an internal application that would be pretty much
impossible without something like Cocoon.  The whole application has a
very unusual architecture but there is currently no easy way for us to
show anyone the results or allow them to verify it (medical clinical
trials data management as you may recall).  

Would an "Intranet applications" section also make sense?  As I see it,
this list would be a list of organizations and applications with a brief
description of the application.  Perhaps a screen shot or two would also
be encouraged or even required?
 

I see no reason why not. There can be some large Cocoon installations 
out there that aren't internet facing (or public facing, at least). And 
to show that Cocoon is used in such scenarios will do no harm. I'd just 
go for a description, with typical number of users, etc.

Regards, Upayavira

RE: Questions to be answered for link request - V2

[Hunsberger, Peter]

[EMAIL PROTECTED] <[EMAIL PROTECTED]> writes:
> 
> 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
>
proposed form details
>  

All of this makes sense and I don't see any real problem with it.  A
related issue is whether you also want people to submit descriptions of
intranet sites?  

We use Cocoon for an internal application that would be pretty much
impossible without something like Cocoon.  The whole application has a
very unusual architecture but there is currently no easy way for us to
show anyone the results or allow them to verify it (medical clinical
trials data management as you may recall).  

Would an "Intranet applications" section also make sense?  As I see it,
this list would be a list of organizations and applications with a brief
description of the application.  Perhaps a screen shot or two would also
be encouraged or even required?

Re: VMWare host for us @apache.org

[David Crossley]

Bertrand Delacretaz wrote:
> Rogier Peters a écrit :
> 
> > ...Although I agree completely that it's the accessability, not the 
> > quality of the documentation that is lacking, i can't help but hearing 
> > echoes of the GT cms-shootout ( bag of docs; heavy on search ).
> > Why use forrest and not daisy or hippo?
> 
> I wanted to put Forrest as the first option for "loyalty" reasons, as 
> the Forrest team has helped us a lot until now. But there are many 
> options of course.

Thanks, we are grateful for that loyalty. Don't feel bound by it.

> But at this point we should be careful not to fall into the trap of 
> discussing tools before agreing on the problem.

Yes, it is a strong magnet.

-- 
David Crossley

Re: VMWare host for us @apache.org

[David Crossley]

Upayavira wrote:
> David Crossley wrote:
>
> >The docs aspect needs lots of consideration. If Cocoon wants to
> >continue using Forrest, then we would like help to implement
> >our plans for the Forrestbot and staging server for reviewing
> >docs prior to publication.
> >
> >We had a huge discussion on this at infrastructure.at.a.o a few
> >months ago. That needs to be summarised and brought into the open.
>
> I think this is the sort of thing I was referring to. If we can clarify 
> what we have in mind, and get a number of us behind it, then I could see 
> it as being possible.
> 
> But there's a lot to clarify/understand. Would you be willing to explain 
> here what you had in mind for your Forrestbot setup? Presumably this 
> setup would still use CVS/SVN as the versioning system for the actual 
> xdoc files?

Yes it does.

Well i will try. It is a big task. Did anyone see the
infrastructure@ discussion to which i refer. It was not
just about "forrestbot", rather the whole situation of
publishing of documentation at Apache. There are
so many aspects: oversight of content, staging, workflow,
recoverability, quick turnaround, secure access,
Forrestbot, Lenya, Doco, ...

The thread finished with the feeling that we had solutions,
just in need of implementation.

Anyway, going off to dig through mail archives again ...

-- 
David Crossley

Re: [cron block] dependency question

[Vadim Gritsenko]

Unico Hommes wrote:
Vadim Gritsenko wrote:
I don't like renaming jars... Can we just extend gump.xml with the 
info we need? In this case, for a block, we need a list of jar files 
it requires from lib/optional.

The way I have it now is that for each  I add an  to the  . We could add a library 
attribute that overides the project attribute. For instance:


 
On the other hand, I think there are also cases (actually perhaps 
xml-axis it one) where one project delivers more than one jar. In that 
case perhaps library attribute must become a comma separated list. On 
second thought it may be better to create a  child element.

Thoughts?
+1 to latter.
Vadim

PropagatorAction broken?

[Tuomo L]

Hi,
Could someone please check, if the PrpagatorAction is functional? I'm 
trying to propagate some values to session-attr and/or request-attr, but cannot read 
them back (Cocoon 2.1.5)! :(

-Tuomo

Re: [cron block] dependency question

[Unico Hommes]

Vadim Gritsenko wrote:
Unico Hommes wrote:
Vadim Gritsenko wrote:
Unico Hommes wrote:
I'd like to add the ability to use an excalibur DataSourceComponent 
as the ConnectionProvider for the QuartzJobScheduler's JobStore. 
However the solution I had in mind results in an additional 
dependency on the cocoon databases block. Not because of a 
compilation dependency on the source code of that block but on a 
jar in its lib directory. Am I correct in assuming that the policy 
on this is that I move the excalibur-datasource jar to lib/optional?


Just an idea; can we move ALL libraries to lib/optional, and copy 
them into the WEB-INF/lib on as-needed basis, i.e. if block included 
which needs a library, only then librariy is copied over? This 
should be possible using the info from gump.xml...

OK, I started working on this. Actually the changes to the build 
system were a breeze. The only difficulty I am currently having is 
with gump.xml because I am not very familiar with it. A lot of blocks 
project declarations have missing dependency information. In those 
cases I need to find out the project's gump name. How do I do that?

Another thing is that some external project names may not correspond 
to the name of the jar in our repository. Should I rename the jar in 
that case or is there a way to specify an alternative jar name in the 
descriptor?

I don't like renaming jars... Can we just extend gump.xml with the 
info we need? In this case, for a block, we need a list of jar files 
it requires from lib/optional.

The way I have it now is that for each  I add an  to the  . We could add a library 
attribute that overides the project attribute. For instance:


 
On the other hand, I think there are also cases (actually perhaps 
xml-axis it one) where one project delivers more than one jar. In that 
case perhaps library attribute must become a comma separated list. On 
second thought it may be better to create a  child element.

Thoughts?
--
Unico

Re: [cron block] dependency question

[Vadim Gritsenko]

Unico Hommes wrote:
Vadim Gritsenko wrote:
Unico Hommes wrote:
I'd like to add the ability to use an excalibur DataSourceComponent 
as the ConnectionProvider for the QuartzJobScheduler's JobStore. 
However the solution I had in mind results in an additional 
dependency on the cocoon databases block. Not because of a 
compilation dependency on the source code of that block but on a jar 
in its lib directory. Am I correct in assuming that the policy on 
this is that I move the excalibur-datasource jar to lib/optional?

Just an idea; can we move ALL libraries to lib/optional, and copy them 
into the WEB-INF/lib on as-needed basis, i.e. if block included which 
needs a library, only then librariy is copied over? This should be 
possible using the info from gump.xml...

OK, I started working on this. Actually the changes to the build system 
were a breeze. The only difficulty I am currently having is with 
gump.xml because I am not very familiar with it. A lot of blocks project 
declarations have missing dependency information. In those cases I need 
to find out the project's gump name. How do I do that?

Another thing is that some external project names may not correspond to 
the name of the jar in our repository. Should I rename the jar in that 
case or is there a way to specify an alternative jar name in the 
descriptor?
I don't like renaming jars... Can we just extend gump.xml with the info we need? 
In this case, for a block, we need a list of jar files it requires from 
lib/optional.

Vadim

Re: [cron block] dependency question

[Unico Hommes]

Vadim Gritsenko wrote:
Unico Hommes wrote:
I'd like to add the ability to use an excalibur DataSourceComponent 
as the ConnectionProvider for the QuartzJobScheduler's JobStore. 
However the solution I had in mind results in an additional 
dependency on the cocoon databases block. Not because of a 
compilation dependency on the source code of that block but on a jar 
in its lib directory. Am I correct in assuming that the policy on 
this is that I move the excalibur-datasource jar to lib/optional?

Just an idea; can we move ALL libraries to lib/optional, and copy them 
into the WEB-INF/lib on as-needed basis, i.e. if block included which 
needs a library, only then librariy is copied over? This should be 
possible using the info from gump.xml...

OK, I started working on this. Actually the changes to the build system 
were a breeze. The only difficulty I am currently having is with 
gump.xml because I am not very familiar with it. A lot of blocks project 
declarations have missing dependency information. In those cases I need 
to find out the project's gump name. How do I do that?

Another thing is that some external project names may not correspond to 
the name of the jar in our repository. Should I rename the jar in that 
case or is there a way to specify an alternative jar name in the descriptor?

--
Unico

Re: VMWare host for us @apache.org

[Bertrand Delacretaz]

Le 22 oct. 04, à 13:29, Rogier Peters a écrit :
...Although I agree completely that it's the accessability, not the 
quality of the documentation that is lacking, i can't help but hearing 
echoes of the GT cms-shootout ( bag of docs; heavy on search ).
Why use forrest and not daisy or hippo?
I wanted to put Forrest as the first option for "loyalty" reasons, as 
the Forrest team has helped us a lot until now. But there are many 
options of course.

But at this point we should be careful not to fall into the trap of 
discussing tools before agreing on the problem.

-Bertrand


smime.p7s
Description: S/MIME cryptographic signature

Re: VMWare host for us @apache.org

[Rogier Peters]

Bertrand Delacretaz wrote:
Le 22 oct. 04, à 12:23, David Crossley a écrit :

What's needed IMHO is the "big bag of docs with powerful search 
functions" that we talked about before 
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106586497031048&w=2 
for example).

If we agree on this, the next step would be to evaluate Forrest against 
our needs and find out the simplest thing that would work. Maybe Forrest 
using a live SVN repository, live Lucene indexing and mod_cache in front 
would be all what we need?
Although I agree completely that it's the accessability, not the quality 
of the documentation that is lacking, i can't help but hearing echoes of 
the GT cms-shootout ( bag of docs; heavy on search ).
Why use forrest and not daisy or hippo?

Rogier

Re: VMWare host for us @apache.org

[Bertrand Delacretaz]

Le 22 oct. 04, à 12:23, David Crossley a écrit :
...The docs aspect needs lots of consideration. If Cocoon wants to
continue using Forrest, then we would like help to implement
our plans for the Forrestbot and staging server for reviewing
docs prior to publication
I think our docs are much better than people generally believe, but 
their *accessibility* is the big problem. Having dynamic structured 
queries on their content would make all the difference.

Storing the content in a database, or having a structured (meaning 
using database-like fields) Lucene index would make all the difference 
in the accessibility of the content, allowing for example queries like 
"show me documents which talk about sitemap and matchers at the 
configuration level".

Such queries can be hidden behind links so that the docs 
"auto-organize" provided the appropriate attributes (topic, audience, 
document role, etc.) are set on the documents, in an iterative process 
for existing docs.

What's needed IMHO is the "big bag of docs with powerful search 
functions" that we talked about before 
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106586497031048&w=2 
for example).

If we agree on this, the next step would be to evaluate Forrest against 
our needs and find out the simplest thing that would work. Maybe 
Forrest using a live SVN repository, live Lucene indexing and mod_cache 
in front would be all what we need?

-Bertrand



smime.p7s
Description: S/MIME cryptographic signature

RE: Questions to be answered for link request - V2

[H . vanderLinden]

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:
Title of the website (to be used on the Livesites page):
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)?

Thank you for helping spread the word about Cocoon!

--
Bye, Helma

Re: VMWare host for us @apache.org

[Upayavira]

David Crossley wrote:
[EMAIL PROTECTED] wrote:
 

Upayavira wrote:
   

While we can start thinking about where to host, I think 
we've first got 
to clarify what we want to host. As yet, I've only as yet got a vague 
idea of what we want - "a machine to run Cocoon, possibly doing its 
docs". What does that actually mean? What would we install? 
How would we 
do docs? Is it pure Cocoon, or Forrest? If Forrest, what about Cocoon 
samples? Will we want additional mini webapps? What sort of 
things? Etc, 
etc, etc. I think we should get these things sorted before we mention 
anything to infrastructure, in order for our case to sound convincing.
 

+1
I'd say: docs and samples and, in future, "administrative" webapps like e.g.
a form for link requests.
I'm not sure what you mean by "additional mini webapps", but I'd say
anything that would go in the "samples" section of Cocoon.
   

I reckon the Cocoon Samples, plus make the new Link Submission
part of that. That way developers can have that as a local app too.
 

Yup, that's the easy bit.
The docs aspect needs lots of consideration. If Cocoon wants to
continue using Forrest, then we would like help to implement
our plans for the Forrestbot and staging server for reviewing
docs prior to publication.
We had a huge discussion on this at infrastructure.at.a.o a few
months ago. That needs to be summarised and brought into the open.
 

I think this is the sort of thing I was referring to. If we can clarify 
what we have in mind, and get a number of us behind it, then I could see 
it as being possible.

But there's a lot to clarify/understand. Would you be willing to explain 
here what you had in mind for your Forrestbot setup? Presumably this 
setup would still use CVS/SVN as the versioning system for the actual 
xdoc files?

Regards, Upayavira

RE: VMWare host for us @apache.org

[David Crossley]

[EMAIL PROTECTED] wrote:
> Upayavira wrote:
> > While we can start thinking about where to host, I think 
> > we've first got 
> > to clarify what we want to host. As yet, I've only as yet got a vague 
> > idea of what we want - "a machine to run Cocoon, possibly doing its 
> > docs". What does that actually mean? What would we install? 
> > How would we 
> > do docs? Is it pure Cocoon, or Forrest? If Forrest, what about Cocoon 
> > samples? Will we want additional mini webapps? What sort of 
> > things? Etc, 
> > etc, etc. I think we should get these things sorted before we mention 
> > anything to infrastructure, in order for our case to sound convincing.
> 
> +1
> 
> I'd say: docs and samples and, in future, "administrative" webapps like e.g.
> a form for link requests.
> I'm not sure what you mean by "additional mini webapps", but I'd say
> anything that would go in the "samples" section of Cocoon.

I reckon the Cocoon Samples, plus make the new Link Submission
part of that. That way developers can have that as a local app too.

The docs aspect needs lots of consideration. If Cocoon wants to
continue using Forrest, then we would like help to implement
our plans for the Forrestbot and staging server for reviewing
docs prior to publication.

We had a huge discussion on this at infrastructure.at.a.o a few
months ago. That needs to be summarised and brought into the open.

-- 
David Crossley

Re: Questions to be answered for link request

[David Crossley]

H.vanderLinden wrote:
> Guys,
> 
> I tend to enter the result of this discussion in Bugzilla, or maybe someone
> takes over and puts it directly in the docs, we'll see. For now I just want
> to do an inventory of questions we'd like to be answered in a link request.
> Here's a proposal for the text, [[ my comments between brackets ]]:
> 
> 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:
> 
> [[which options to select?]]
> 
> - Enter a summary like this: [Link] NameOfYourSite
> 
> - In the comments, please answer the following questions:
> 
> URL of the website:
> Cocoon version used:

Also explicitly the Name for the link anchor.

Also a short one-or-two-line description.

> Short summary of your site:

Is this to go on the web page? If so that is what i meant
by the above comment.

However, it might be good to have a description
where they provide more detail about their app.
How it works, how they built it, etc.

The act of them sending their contribution via Bugzilla
could be considered as a type of announcement to the
community. Their chance to show off and pay back.

> How can we verify this site is actually built with Cocoon?

I think it is good to ask them to tell us. Then we review it
and we would verify behind the scenes. I do various tests like
view-source and especially do 'head http://them.com/' which
usually shows cocoon version. Sometimes however, you just cannot
verify.

I too think we should only encourage the rest of the info, not insist.

--David

> How much time did it take to build the site from design to publish?
> 
> How many people were involved in the project?
> 
> How many page hits per [[ what's a reasonable unit here? ]] does the site
> handle?
> 
> What made you choose Cocoon to build the site?
> 
> 
> We would like to see this list grow bigger every day :-)
> 
> [[ we should fit in the line above, but it's in great contrast with the
> first lines :-( ]]
> 
> WDYT?
> 
> Bye, Helma

interface parameter for fb:insert-bean binding?

[Bart Molenkamp]

Hi all,

Is is possible to specify an interface for fb:insert-bean? Without this,
the binding is not able to find the correct method. E.g.

addProduct(Product product);// Product is an interface

...



Now, the insert bean binding tries to find a method matching
"addProduct(ProductImpl)", but it can't be found. So, is it possible to
specify the interface, e.g.



Or, am I doing something wrong?

Thanks,
Bart.

Re: Questions to be answered for link request

[Bertrand Delacretaz]

Le 21 oct. 04, à 23:56, [EMAIL PROTECTED] a écrit :
- Create an entry in Bugzilla following these instructions:
[[which options to select?]]
Same as for a patch
- Enter a summary like this: [Link] NameOfYourSite

How can we verify this site is actually built with Cocoon?

Here I'd like to add "if you agree, answering the following questions 
helps potential Cocoon users 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 many page hits per [[ what's a reasonable unit here? ]] does the 
site
handle?
I'd be more vague, like "how much traffic does your site handle 
(visitors per month or pages per second depending on the scale...)"

What made you choose Cocoon to build the site?
We would like to see this list grow bigger every day :-)
[[ we should fit in the line above, but it's in great contrast with the
first lines :-( ]]
Maybe: "thanks for helping spread the word about Cocoon!"
WDYT?
I like the idea, and once this text is stabilized, creating an example 
in bugzilla and linking it from the docs would be the best.

-Bertrand


smime.p7s
Description: S/MIME cryptographic signature

DO NOT REPLY [Bug 31813] - [Sample] DreamTeam (dependent widgets in a repeater)

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

[Sample] DreamTeam (dependent widgets in a repeater)





--- Additional Comments From [EMAIL PROTECTED]  2004-10-22 09:07 ---
Reinhard,

I checked out the sample from the trunk and looked at the changes you've made. 
- All of them are ok, except one:

in team.js you removed the comment to add the first player. I'd like to leave
that in as an extra example on how to "preset" the team.

- when running the sample it crashes on 
\cocoon\build\webapp\samples\common\style\xsl\html\adding-header.xsl (The
system cannot find the file specified)

I've looked in both "trunk" and "branches" but couldn't find the
"adding-header.xsl" file. When replacing it with one of the existing XSL files,
the link to my CSS file is lost and on the "buildteam" page the entire content
is lost. :-(

I suppose your "adding-header.xsl" simply added the "usual Cocoon samples" top
part, so could you add that file to the trunk?

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-10-22 08:28 ---
Created an attachment (id=13181)
Patch to disable invoker optimization when using Rhino from 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-10-22 08:27 ---
Reinhard Poetz  wrote:

> Could you give me a hint, how I can switch off InvokerImpl usage by API?
> IMO this is the only safe way because if others build Rhino the chance 
> is high that the removal will be forgotten.

With Rhino from mozilla.org the following patch should disable the invoker
optimization. With Rhino from cocoondev.org the only way to disable it is to
either remove org.mozilla.javascript.optimizer.InvokerImpl.class from the jar or
remove src/org/mozilla/javascript/optimizer/InvokerImpl.java from the repository.

If you can reliably see that the optimization is only slow thinks down on JDK
1.4 or later, I will disable it by default in Rhino: Cocoon usage is a good test
for this.

> Finally a last question: I always use "ant jar" to build Rhino. Is this the
> right build target or do we have to use another one, which might strip down
> Rhino to a minimum for our needs?

With Rhino from mozilla.org there is "smalljar" ant target that generates
minimalistic jar. But that can not be used with Cocoon as it uses a few classes
that smalljar does not include. And in any case if you distribute Rhino classes,
please use the full version!

Re: FilesystemStore broken???

[Pier Fumagalli]

On 22 Oct 2004, at 01:34, Vadim Gritsenko wrote:
Corin Moss wrote:
Hiya,
This probably works for the FilesystemStore, but both the JCS and
EHCache stores use their own store file - so everything is cached 
within
one big binary file - which means that something else has to take over
the deleting cycle.
True. This thread though was about FS store :)
You'll have to monitor last access timestamp to implement similar for 
jcs/ehcache/whatever.


Also add to this that when you use event based
caching you can't rely on time stamps - something could be 3 months 
old
in the cache but still be valid.
My point is; if it was not used in a week - you could easily delete it 
and it will be re-created when it is needed next time. But if resource 
is frequently accessed, then its access timestamp will be updated and 
so it will not be removed.

This approach should work just fine in 90% - or even 99% - of cases. 
Think of it as an analogue to LRU cleanup policy, but with preset time 
limit instead of preset cache size.

That's what I'm doing on the Apache side of things to actually wipe out 
the content of the cache after one day

But now I kinda understand why JCS crashed on me after 6/8 hours being 
put on live... It's a grow-only mechanism, and given that I probably 
restart Cocoon on live once every 3/4 weeks (maybe longer) and we have 
something like 1.5 million valid URLs (150.000 articles on 11 sites), I 
can see why the baby can't handle it...

Time to write some code, then...
Pier



smime.p7s
Description: S/MIME cryptographic signature

DO NOT REPLY [Bug 31760] - Handle / Semaphore Leak?

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

Handle / Semaphore Leak?





--- Additional Comments From [EMAIL PROTECTED]  2004-10-22 07:49 ---
Please let me clarify what I mean:
In any case Cocoon needs to consume a lot of handles. If you do Cocoon going to 
work by surfing on it, it will increase the heandlesize. 1 are OK when they 
a really nedded. There is no other way.
But my intension for this Bug report is the increasing without a reason. If you 
start Tomcat/Cocoon, it will have an amount lower than 1000. When it is 
running - nothing more, the handle size will increase by about 50 every minute. 
Is there a limit and where is the limit? I tested an invoking of the GC with no 
decreasing and its still growing up.
If there is a leak, it should be fixed. Regardless of critical or not. Lets try 
to figure out the reason. Think about a production environment that’s running 
months without restart. System handle are not unlimited. I don't know what will 
happen, but I think it will not be an improvement.

RE: VMWare host for us @apache.org

[H . vanderLinden]

> While we can start thinking about where to host, I think 
> we've first got 
> to clarify what we want to host. As yet, I've only as yet got a vague 
> idea of what we want - "a machine to run Cocoon, possibly doing its 
> docs". What does that actually mean? What would we install? 
> How would we 
> do docs? Is it pure Cocoon, or Forrest? If Forrest, what about Cocoon 
> samples? Will we want additional mini webapps? What sort of 
> things? Etc, 
> etc, etc. I think we should get these things sorted before we mention 
> anything to infrastructure, in order for our case to sound convincing.

+1

I'd say: docs and samples and, in future, "administrative" webapps like e.g.
a form for link requests.
I'm not sure what you mean by "additional mini webapps", but I'd say
anything that would go in the "samples" section of Cocoon.

Bye, Helma

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-10-22 07:02 ---
Running some tests shows that speed increase between Chris' and your
implementation is indeed only minimal. However, removing InvokerImpl.class speed
up my testcase by 7-8%.

Could you give me a hint, how I can switch off InvokerImpl usage by API? IMO
this is the only safe way because if others build Rhino the chance is high that
the removal will be forgotten.

Finally a last question: I always use "ant jar" to build Rhino. Is this the
right build target or do we have to use another one, which might strip down
Rhino to a minimum for our needs?