date:20040528

Sylvain Wallez wrote:
 
 Carsten Ziegeler wrote:
 
  Sylvain Wallez wrote:
 
  Ok, that's a good point. Now log4j always claims to be 
 the fastest 
  logging system, so I guess this isn't an issue anymore.
 
  Well, they claimed it at that time also. Log4J has some very good 
  marketing ;-)
 
  :) Marketing is everything!
 
  Ok, I just checked the code. It seems that logkit is doing 
 one check 
  (testing ints) for isDebugEnabled() while log4j is doing two. Now 
  this shouldn't really affect the performance I think.
 
 
 Look further in the code: there's actually mch more code 
 behind it.
 
 public boolean isDebugEnabled() {
 if (repository.isDisabled(Level.DEBUG_INT)) {
 return false;
 }
 return Level.DEBUG.isGreaterOrEqual(this.getEffectiveLevel());
 }
 
 Yep, two tests. reposorit.isDisabled() is an interface call 
 (slower than a class call) which leads to a simple test (see 
 Hierarchy). Now let's dig deeper:
 
 public Level getEffectiveLevel() {
 for (Category c = this; c != null; c = c.parent) {
 if (c.level != null) {
 return c.level;
 }
 }
 }
 
 This crawls up the category tree up to finding one that has a 
 level explicitely set! And for each call!!
 
 This reveals what is IMO an important design flaw in Log4J: 
 logger priorities are checked a bazillion more times than 
 they are changed.
 
 LogKit, on the other hand, takes into account the fact that 
 logger priorities are checked a bazillion more times than 
 they are changed. 
 Therefore, it propagates priority changes on child loggers, 
 meaning the crawl isn't needed and code required to check the 
 priority is really
 minimal:
 
 public final boolean isDebugEnabled() {
 return m_priority.isLowerOrEqual( Priority.DEBUG ); }
 
 IMO, this makes a big difference when debug is disabled, 
 especially with deep hierarchies as we have in Cocoon (need 
 to take some of my copious free time to setup performance test cases).
 
 I consider this as an important design flaw in Log4J, which 
 would require a good amount of work to be fixed.
 
Ok, this is all true - but considering performance it's imho neglectable
even if you consider that heavy xml parsing and stylesheet transformations
happen at the same time.

Carsten

Re: [RT] Extending Dreamweaver (Was: Re: [RT] Tapestry or the value of multi-channel forms?)

2004-05-28 Thread Reinhard Poetz

Tony Collen wrote:
So, I started playing with Dreamweaver, reading a couple PDFs to see 
exactly what we can add to DW to make doing things like creating 
CForms a lot simpler.   I haven't done a ton yet, but from what I can 
see, I'm getting very excited.

You can hook into pretty much anything and create a menu using their 
XML format:

menu name=C_ocoon id=cocoon-2.2
menuitem name=C_Form Editor enabled=true 
command=dw.toggleFloater('cocoon') id=/
menuitem name=CForm _Bindings enabled=true command= id=/
menuitem name=_Pipeline Editor enabled=true command= id=/
/menu

Produces the following menu:
http://manero.org/images/dw-menu.gif
The command attribute is simply a JavaScript command to do something.  
As you can see, I toggle the floater named cocoon which is what 
opens the following:
   http://manero.org/images/dw-floater.gif

The definition of the floaters (and the other panels) is just HTML.  
All you basically do it write up a form, code a little bit of 
JavaScript and pow, instant functionality.  You can even define 
multiple floaters and tab them together.  Very useful, and exciting.

Ideally, we would have something for ceating a basic CForms 
definition, and then create new elements in the document DOM.

Sylvain mentioned he did some stuff using custom tags, and it looks 
like we can easily create a tag library for CForms.

So my question is: what would people want to see in a GUI CForms editor?
Obviously we have to not only edit the form instance, but also the 
form template as well.  Still not sure how we'd handle the templates 
yet.. perhaps once I start playing with it a little more, it will come 
to me.

There's an absolute ton of API reference for DW out there.  I'm 
surprised at how much customizability DW actually has.  You can even 
go so far as to define your own server model. Imagine being able to 
connect to a Cocoon server and remotely edit forms, Flowscript, etc, 
all from the comfort of Dreamweaver.

Thanks Tony for digging into this. It seems to be a very promising way! :-)
(I will comment on the details in a separate mail as soon as I have 
enough time thinking more about this!)

I know, Dreamweaver is commercial but is there any way putting your work 
into an opensource CVS/SVN?

--
Reinhard

Re: Fed up with build discussions: proposed deal

Stefano Mazzocchi wrote:
Nicola Ken Barozzi wrote:
...
Deal?
No, first somebody has to explain to me what's the problem with the 
current build system.
The current version is actually quite well structured, especially with 
the main build.

The main problems are with:
1 - blocks build
2 - customized forrest usage
3 - no jar download system
1 - using import and subant this can be made much easier to change and 
debug, and have each block be able to customize the build

2 - there are an impressive number of targets just to do what Forrest 
does automatically... gotta investigate

3 - some really see it as an issue
Also, the build of Cocoon can be made much better using macrodefs and 
top level tasks.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

Re: Fed up with build discussions: proposed deal

Stefano Mazzocchi wrote:
Steven Noels wrote:
I say that nicola works on his version and if somebody wants 
(antonio?) they can work on the maven version and then we decide.
Seems fair to me. Do Depot  Maven agree on repository layout and 
artefact distribution?
I would be surprised if they did.
There is a common list, [EMAIL PROTECTED], where discussion does 
happen, and a wiki spec. Can't say what the real intentions of Maven 
developers as a community are though, but there is still intrest and 
good dialogue on this list.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

Re: Fed up with build discussions: proposed deal

Steven Noels wrote:
On 26 May 2004, at 23:39, Stefano Mazzocchi wrote:
Steven Noels wrote:
Care to comment about the other points? I cannot help myself thinking 
that Cocoon's adoption of Depot is more important for them than for us.
I share that perception.
We had a similar thing with Centipede and Forrest a long time ago. It 
was good to have it, but in the end we went our own way (or that's at 
least what I remember from it, and it's been a long time since I checked).
Well, Forrest is still here, and now TLP.
As for Centipede, you are using some of the features now in Ant (import 
for example).

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

RE: New Cocoon block: ValidatorTransformer

2004-05-28 Thread Perez Carmona, David


Have you copied also to the same directory any needed entity, referenced from the DTD?

 -Mensaje original-
 De: David Crossley [mailto:[EMAIL PROTECTED]
 Enviado el: jueves, 27 de mayo de 2004 11:58
 Para: [EMAIL PROTECTED]
 Asunto: Re: New Cocoon block: ValidatorTransformer



 Perez Carmona, David wrote:
  
  I've created a new transformer that can perform validation
 in any step
  of a XML pipeline.  It is described in
  http://wiki.cocoondev.org/Wiki.jsp?page=ValidationTransformer
  I think it may be interesting to create a new block.

 Mmmm, i am having trouble. I get a completely blank page and
 this in WEB-INF/logs/handled-errors.log ... do you have any tips?
 My test sitemap refers to the xhtml1-transitional.dtd by filename
 in the same directory as the sitemap.

 ERROR   (2004-05-27) 19:32.18:413   [sitemap.handled-errors]
 (/samples/hello-world/validate.html) PoolThread-4/PipelineNode:
 unable to parse the schema
 org.apache.cocoon.ProcessingException: unable to parse the schema:
 org.iso_relax.verifier.VerifierConfigurationException: unable to parse
 the schema
   at
 fcc.ima.cocoon.ValidatorTransformer.setup(ValidatorTransformer
 .java:102)
 ...



 *
 Este correo ha sido procesado por el antivirus del Grupo FCC.
 *


*
Este correo ha sido procesado por el Antivirus del Grupo FCC
*

Re: [RT] Logging in Cocoon

2004-05-28 Thread Sylvain Wallez

Carsten Ziegeler wrote:
Sylvain Wallez wrote:
 

snip/
IMO, this makes a big difference when debug is disabled, 
especially with deep hierarchies as we have in Cocoon (need 
to take some of my copious free time to setup performance test cases).

I consider this as an important design flaw in Log4J, which 
would require a good amount of work to be fixed.

   

Ok, this is all true - but considering performance it's imho neglectable
even if you consider that heavy xml parsing and stylesheet transformations
happen at the same time.
 

Maybe ;-)
I'll try to come up with real numbers soon!
Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

RE: New Cocoon block: ValidatorTransformer

2004-05-28 Thread Perez Carmona, David


Jing only supports RelaxNG.

Here is the license of MSV (I don't know too much about licenses, but it doesn't seem 
too restrictive):

Copyright (c) 2001-2003 Sun Microsystems, Inc. All Rights Reserved.

Redistribution and  use in  source and binary  forms, with  or without
modification, are permitted provided that the following conditions are
met:

- Redistributions  of  source code  must  retain  the above  copyright
  notice, this list of conditions and the following disclaimer.

- Redistribution  in binary  form must  reproduct the  above copyright
  notice, this list of conditions  and the following disclaimer in the
  documentation and/or other materials provided with the distribution.

Neither  the  name   of  Sun  Microsystems,  Inc.  or   the  names  of
contributors may be  used to endorse or promote  products derived from
this software without specific prior written permission.

This software is provided AS IS, without a warranty of any kind. ALL
EXPRESS  OR   IMPLIED  CONDITIONS,  REPRESENTATIONS   AND  WARRANTIES,
INCLUDING  ANY  IMPLIED WARRANTY  OF  MERCHANTABILITY,  FITNESS FOR  A
PARTICULAR PURPOSE  OR NON-INFRINGEMENT, ARE HEREBY  EXCLUDED. SUN AND
ITS  LICENSORS SHALL  NOT BE  LIABLE  FOR ANY  DAMAGES OR  LIABILITIES
SUFFERED BY LICENSEE  AS A RESULT OF OR  RELATING TO USE, MODIFICATION
OR DISTRIBUTION OF  THE SOFTWARE OR ITS DERIVATIVES.  IN NO EVENT WILL
SUN OR ITS  LICENSORS BE LIABLE FOR ANY LOST  REVENUE, PROFIT OR DATA,
OR  FOR  DIRECT,   INDIRECT,  SPECIAL,  CONSEQUENTIAL,  INCIDENTAL  OR
PUNITIVE  DAMAGES, HOWEVER  CAUSED  AND REGARDLESS  OF  THE THEORY  OF
LIABILITY, ARISING  OUT OF  THE USE OF  OR INABILITY TO  USE SOFTWARE,
EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

You acknowledge that Software is not designed,licensed or intended for
use  in the  design,  construction, operation  or  maintenance of  any
nuclear facility.

 -Mensaje original-
 De: David Crossley [mailto:[EMAIL PROTECTED]
 Enviado el: jueves, 27 de mayo de 2004 12:01
 Para: [EMAIL PROTECTED]
 Asunto: Re: New Cocoon block: ValidatorTransformer



 Perez Carmona, David wrote:
 
  I've created a new transformer that can perform validation
 in any step
  of a XML pipeline.  It is described in
  http://wiki.cocoondev.org/Wiki.jsp?page=ValidationTransformer
  I think it may be interesting to create a new block.

 I know that it is proof-of-concept. I see that you are
 using Sun Multi-Schema Validator. That could have licensing
 problems for Cocoon to redistribute. It would need
 investigation. The guidelines are that each *.jar must have
 a license and it is not any more restrictive than the
 Apache License 2.0

 Is it possible that this can be a framework for adding
 other validators? For example, we already have Jing in the
 Cocoon distribution.

 --David


 *
 Este correo ha sido procesado por el antivirus del Grupo FCC.
 *


*
Este correo ha sido procesado por el Antivirus del Grupo FCC
*

RE: New Cocoon block: ValidatorTransformer

Perez Carmona, David dijo:

 Jing only supports RelaxNG.

 Here is the license of MSV (I don't know too much about licenses, but it
 doesn't seem too restrictive):

snip
 You acknowledge that Software is not designed,licensed or intended for
 use  in the  design,  construction, operation  or  maintenance of  any
 nuclear facility.

Of course I am not working in any similar. But, this a restriction that
AFAIK any AL have. In that way it breaks our license.

WDYT?

Best Regards,

Antonio Gallardo

Re: [CVS-SVN] Cocoon switching to SVN

Someone please cc [EMAIL PROTECTED] I'm on a cell connection 
and am having problems sending email, and this ius going through gmane.

Brian W. Fitzpatrick wrote:
...
Thanks for the fantastic roadmap!  Can we plan on doing this sometime on
Monday the 31st?  I'd like to do a test-run sometime between now and
then to make sure that the conversion on Monday runs smoothly (and that
you get exactly what you want in your repository).
Wow, that's *early*! :-)
What about Wednesday (a week) or later, so that everyone gets a 
reasonable heads-up about learning SVN and getting it installed?

BTW, again TIA.
--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

DO NOT REPLY [Bug 27260] - Stackoverflow using xslt from subsitemap with cocoon://-protocol

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=27260.
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=27260

Stackoverflow using xslt from subsitemap with cocoon://-protocol

[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|[EMAIL PROTECTED]   |[EMAIL PROTECTED]
 Status|ASSIGNED|NEW



--- Additional Comments From [EMAIL PROTECTED]  2004-05-28 08:12 ---
Confirmed, too - this bug is in 2.1.5 as well. It's fixed in 2.2-dev due to the 
rewriting of the internal processing.
As soon as we can start working on 2.1.6 (hopefully next week) I will look into 
this again.

RE: [CVS-SVN] Cocoon switching to SVN

Nicola Ken Barozzi wrote:
 
 Someone please cc [EMAIL PROTECTED] I'm on a cell 
 connection and am having problems sending email, and this ius 
 going through gmane.
 
 Brian W. Fitzpatrick wrote:
 ...
  Thanks for the fantastic roadmap!  Can we plan on doing 
 this sometime 
  on Monday the 31st?  I'd like to do a test-run sometime between now 
  and then to make sure that the conversion on Monday runs 
 smoothly (and 
  that you get exactly what you want in your repository).
 
 Wow, that's *early*! :-)
 
 What about Wednesday (a week) or later, so that everyone gets 
 a reasonable heads-up about learning SVN and getting it installed?
 
I think we all know enough about SVN :), so I'm +1 on this monday!!
This will help us working on 2.1.6 without creating a branch in cvs
now. So the sooner the better.

Many thanks for the help!!!

Carsten

RE: New Cocoon block: ValidatorTransformer

2004-05-28 Thread David Crossley

David Perez Carmona wrote:
 David Crossley wrote:
  Is it possible that this can be a framework for adding
  other validators? For example, we already have Jing in the
  Cocoon distribution.

 Jing only supports RelaxNG.

The home page says that it supports others:

quote
Jing also has experimental support for schema languages
other than RELAX NG; specifically
* W3C XML Schema
* Schematron
* Namespace Routing Language
/quote
http://www.thaiopensource.com/relaxng/jing.html

--David

RE: New Cocoon block: ValidatorTransformer

2004-05-28 Thread David Crossley

Perez Carmona, David wrote:
 Have you copied also to the same directory any needed entity, referenced from the 
 DTD?

Ah, that was it.

Instead of copying them, i referenced the DTD like this:

map:transform type='validate' 
src='context://WEB-INF/entities/w3c/xhtml1-transitional.dtd'

That seems to work. I can now see the Hello world page.

I presume that the next is to make some deliberate errors
in the xml2html transformation and watch the error.log

--David

RE: New Cocoon block: ValidatorTransformer

2004-05-28 Thread David Crossley

Antonio Gallardo wrote:
 Perez Carmona, David dijo:
 
  Here is the license of MSV (I don't know too much about licenses, but it
  doesn't seem too restrictive):
 
 snip
  You acknowledge that Software is not designed,licensed or intended for
  use  in the  design,  construction, operation  or  maintenance of  any
  nuclear facility.
 
 Of course I am not working in any similar. But, this a restriction that
 AFAIK any AL have. In that way it breaks our license.
 
 WDYT?

That was the clause that made me worried.

David showed us the license.txt that comes with the distribution.
There is also the copyright.txt which looks to me like it prevents.

It is the usual stuff about their patents, suppliers patents,
not reproducing without written permission, includes stuff licensed
from their suppliers, ...

So it seems to me that we cannot re-distribute MSV.

--David

RE: New Cocoon block: ValidatorTransformer

David Crossley dijo:
 So it seems to me that we cannot re-distribute MSV.

Unfortunately, yes. We cannot redistribute. :-(

Best Regards,

Antonio Gallardo

Re: invalid content length

I'm no longer the only one having problem with the issues mentioned
below: http://marc.theaimsgroup.com/?t=10855844831r=1w=4.

What's interesting about this case is the correct recognition of an
internal request in PipelineUtil.processPipelineToDOM(), but not for the
older cocoon.processPipelineTo(). Shouldn't this give hints on the root
of the problem?

Joerg
On 21.05.2004 21:36, Joerg Heinicke wrote:
On 18.05.2004 23:56, Joerg Heinicke wrote:
Can anybody tell me what can cause the invalid content length? The
first one is html serializer, the latter ones text serializer.

Found at least the reason: A stylesheet is imported via cocoon:/ and in
this pipeline the stylesheet is *read* from disk, the ResourceReader
also sets the content-length header, the 919 bytes are the length of the
stylesheet.

23:45:18.000 WARN!! Invalid length: Content-Length=919 written=186
for
http://127.0.0.1:/xfaces/css/html/mozilla/skin/simple/step80-pages/simple/html/common/css.css

Now the question how to fix it. Referencing the stylesheet in the same
way directly from the sitemap would result in a ProcessingException:
Streaming of an internal pipeline is not possible with a reader.
(AbstractProcessingPipeline, line 678).

1st issue: That this exception is not thrown when the stylesheet is
imported by another stylesheet via cocoon:/ is 1.) somewhat inconsistent
and 2.) hints on a bigger problem (why is this internal request not
recognized as an internal request?).

On the one hand we could for simplification throw an exception for this
case too - however this case will be recognized as internal request. On
the other hand there is no need for it as transformers don't need to be
streamed - otherwise it would not work using the reader as it did. This
would allow to write partly shorter sitemaps, but I don't know if it's
worth the effort to recognize internal requests sent by transformer steps.

2nd issue: Letting the reader set the headers unasked does not sound
like IoC. The SitemapOutputComponent has a method
shouldSetContentLength(), the AbstractReader implements it by returning
false, but the ResourceReader sets it? Thinking in code smells [1] this
stinks :)

WDYT?
Joerg
[1] http://c2.com/cgi/wiki?CodeSmell

Re: [RT] Logging in Cocoon

2004-05-28 Thread Unico Hommes

Carsten Ziegeler cziegeler at s-und-n.de writes:

 So, my suggestion is to:
 - deprecate the use of LogKit

-0.5

I have been a great fan of LogKit since I first started using it through Cocoon.
Its slim feature set attains the admirable goal of keeping things simple, yet
it's powerful enough for most of Cocoon's usage scenarios. I think it is more
intuitive to configure than is Log4j. It's very well designed and it's
specifically designed with the kind of IoC log enabling in mind that we will
continue to use in the future.

I understand the Avalon community argument and it is good to have alternative
logging solutions in Cocoon but I feel bad about throwing out something I
consider to be the best fit logging package for Cocoon ATM. BTW I am not
following Avalon developement very closely anymore, does anyone know what the
status of LogKit is in Avalon itself (did they deprecate it?).

It is true that Log4j configuration is familiar to most people and LogKit's just
isn't. But that argument just applies to new users of Cocoon. The ones that have
been using Cocoon are familiar with LogKit and may not be with Log4j. Not that
it is very difficult to learn to configure either of them anyway ;-)

--
Unico

RE: [RT] Logging in Cocoon

Unico Hommes wrote:
 
 Carsten Ziegeler cziegeler at s-und-n.de writes:
 
  So, my suggestion is to:
  - deprecate the use of LogKit
 
 -0.5
 
 I have been a great fan of LogKit since I first started using 
 it through Cocoon.
 Its slim feature set attains the admirable goal of keeping 
 things simple, yet it's powerful enough for most of Cocoon's 
 usage scenarios. I think it is more intuitive to configure 
 than is Log4j. It's very well designed and it's specifically 
 designed with the kind of IoC log enabling in mind that we 
 will continue to use in the future.
 
 I understand the Avalon community argument and it is good to 
 have alternative logging solutions in Cocoon but I feel bad 
 about throwing out something I consider to be the best fit 
 logging package for Cocoon ATM. BTW I am not following Avalon 
 developement very closely anymore, does anyone know what the 
 status of LogKit is in Avalon itself (did they deprecate it?).
 
 It is true that Log4j configuration is familiar to most 
 people and LogKit's just isn't. But that argument just 
 applies to new users of Cocoon. The ones that have been using 
 Cocoon are familiar with LogKit and may not be with Log4j. 
 Not that it is very difficult to learn to configure either of 
 them anyway ;-)
 
Yes, that's true. My initial post was a little bit unclear :)
The basic idea is to use log4j as default and provide perhaps
a little bit more support for configuration of log4j - whatever
that require. Of course you still will be able to use logkit
if you want (so deprecating was a wrong term, sorry).

For the status of logkit, well, currently it's called legacy at
Avalon (please correct me, if I'm telling something wrong here).
As far as I remember, the idea is to not continue the development
of Logkit anymore. But I think this is not a problem as Logkit
is working well and is finished. There is no real need for 
further development.

Carsten

Re: [RT] Logging in Cocoon

2004-05-28 Thread Unico Hommes

Carsten Ziegeler cziegeler at s-und-n.de writes:

 
 Unico Hommes wrote:
  
  Carsten Ziegeler cziegeler at s-und-n.de writes:
  
   So, my suggestion is to:
   - deprecate the use of LogKit
  
  -0.5
  

snip to make gmane happy/

  
 Yes, that's true. My initial post was a little bit unclear :)
 The basic idea is to use log4j as default and provide perhaps
 a little bit more support for configuration of log4j - whatever
 that require. Of course you still will be able to use logkit
 if you want (so deprecating was a wrong term, sorry).
 

I am very happy to hear that :-) Thanks for clarifying. Having better support
for log4j is definately a pro. And I am interested to see once more people start
using it more how it compares to Logkit in Cocoon.

 For the status of logkit, well, currently it's called legacy at
 Avalon (please correct me, if I'm telling something wrong here).
 As far as I remember, the idea is to not continue the development
 of Logkit anymore. 

I see, and I understand the decision since there is now a logging TLP and
logging should not be Avalon's concern anyway. Perhaps there is a place for
Logkit at logging.apache.org.

 But I think this is not a problem as Logkit
 is working well and is finished. There is no real need for 
 further development.

Exactly my point. I don't remember ever having any problems with it. If people
want a feature not supported by LogKit they can use Log4j.

--
Unico

Re: cvs commit: cocoon-2.1/src/blocks/tour/samples/flow/docs number-guess.xml

On 28.05.2004 08:04, Tony Collen wrote:
Hmm, they both seem to work:
pcocoon.continuation.id: ${cocoon.continuation.id}/p
pcontinuation.id: ${continuation.id}/p
yields:
p 
xmlns:c=http://apache.org/cocoon/templates/jx/1.0;cocoon.continuation.id: 
542e3f295f3162016f200b848d47811573151082/p
pcontinuation.id: 542e3f295f3162016f200b848d47811573151082/p

But that does not explain why the tutorial wasn't working, unless 
cocoon.continuation.id was not supported back in January when the 
message was sent.

So which do we recommend?

n/m:
http://cocoon.apache.org/2.1/userdocs/flow/jxtemplate.html
org.apache.cocoon.components.flow.WebContinuation continuation
The current Web Continuation (deprecated: use cocoon.continuation instead)
Guess cocoon.continuation is the preferred way.
The JXTemplateGenerator suggest to use ${continuation.id}, nothing about 
the cocoon prefix. Maybe we should ask Christopher what his plan was. Or 
we simply decide it here.

Joerg

Re: [CVS-SVN] Cocoon switching to SVN

On 28.05.2004 10:14, Carsten Ziegeler wrote:
Thanks for the fantastic roadmap!  Can we plan on doing this 
sometime on Monday the 31st?  I'd like to do a test-run sometime 
between now and then to make sure that the conversion on Monday 
runs smoothly (and that you get exactly what you want in your
repository).
Wow, that's *early*! :-)
What about Wednesday (a week) or later, so that everyone gets a 
reasonable heads-up about learning SVN and getting it installed?
I think we all know enough about SVN :), so I'm +1 on this monday!! 
This will help us working on 2.1.6 without creating a branch in cvs 
now. So the sooner the better.
+1 for the fast way.
Joerg

Re: Configuration of SearchGenerator

On 27.05.2004 14:04, Harald Wehr wrote:
I have a search index that needs to be processed by a german analyzer. 
So I tried to configure the cocoon SearchGenerator in the sitemap:

map:generator name=search
   src=org.apache.cocoon.generation.SearchGenerator
   analyzer
org.apache.lucene.analysis.de.GermanAnalyzer
   /analyzer
/map:generator
Without success as SearchGenerator was always using the 
StandardAnalyser. I looked into the source code and found within the 
configure-method following commented code:

// get the analyzer
//Analyzer analyzer =
//LuceneCocoonHelper.getAnalyzer(org.apache.lucene.analysis.standard.StandardAnalyzer); 

//lcs.setAnalyzer(analyzer);
Later I found in the method buildHits() the static class loading of the 
StandardAnalyzer:

.
lcs = (LuceneCocoonSearcher)
   this.manager.lookup(LuceneCocoonSearcher.ROLE);
Analyzer analyzer =
   LuceneCocoonHelper.getAnalyzer(
 org.apache.lucene.analysis.standard.StandardAnalyzer);
lcs.setAnalyzer(analyzer);
.
So it seems to me that the SearchGenerator is not as configurable as the 
documentation says. It seems to me that it is always using the 
StandardAnalyzer.
Vadim moved this code around, nearly two and half a year ago:
http://cvs.apache.org/viewcvs.cgi/cocoon-2-historical/src/java/org/apache/cocoon/generation/Attic/SearchGenerator.java?r1=1.1r2=1.2diff_format=h
But obviously it did not work before too. From the comment in 
buildHits() I guess once there was the aim to make this configurable.

Joerg

RE: cvs commit: cocoon-2.1/src/blocks/tour/samples/flow/docs number-guess.xml

 
Joerg Heinicke wrote:
  
  Guess cocoon.continuation is the preferred way.
 
 The JXTemplateGenerator suggest to use ${continuation.id}, 
 nothing about the cocoon prefix. Maybe we should ask 
 Christopher what his plan was. Or we simply decide it here.
 
The old way continuation.id has been deprecated. The correct way
should be cocoon.* to use the same syntax as in flow script.
So whereever just continuation.id is documented, this has to be
fixed.

Carsten

Re: cvs commit: cocoon-2.1/src/blocks/tour/samples/flow/docs number-guess.xml

Joerg Heinicke dijo:
 Guess cocoon.continuation is the preferred way.

 The JXTemplateGenerator suggest to use ${continuation.id}, nothing about
 the cocoon prefix. Maybe we should ask Christopher what his plan was. Or
 we simply decide it here.

For long time the use of ${continuation.id} is the standard. I think it is
shorter and clear:

In http://wiki.cocoondev.org/Wiki.jsp?page=JXTemplateGenerator we found:

snip
Provides a generic page template with embedded JSTL and XPath expression
substitution to access data sent by Cocoon Flowscripts, eg. web
continuation.

* Accessing through JSTL(Apache Jexl): ${continuation.id}
* Accessing through XPath(Apache JXPath): #{$continuation/id}
/snip

And the original in Javadocs (search for the continuation word):
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/generation/JXTemplateGenerator.html

It is clear there is no cocoon prefix. Please don't break this.

Best Regards,

Antonio Gallardo

RE: cvs commit: cocoon-2.1/src/blocks/tour/samples/flow/docs number-guess.xml

Carsten Ziegeler dijo:

 Joerg Heinicke wrote:
 
  Guess cocoon.continuation is the preferred way.

 The JXTemplateGenerator suggest to use ${continuation.id},
 nothing about the cocoon prefix. Maybe we should ask
 Christopher what his plan was. Or we simply decide it here.

 The old way continuation.id has been deprecated. The correct way
 should be cocoon.* to use the same syntax as in flow script.
 So whereever just continuation.id is documented, this has to be
 fixed.

Why? It cannot be a fixed variable? In Rhino we borrow the continuation
from scheme language. That is the cause why we use it directly and not
with with a cocoon prefix. My fault, I don't saw when we changed our
mind to use cocoon.continuation. :-(

Best Regards,

Antonio Gallardo

Re: [RT] Logging in Cocoon

Unico Hommes dijo:
Since my firsts steps in Cocoon I wondered why it use LogKit and not the
award winning log4j. I understand we need to support it because lot of
code was written using it, but maybe the solution is to create a block
for Logkit? That way people that want to use it, can include it.

WDYT?

Best Regard,

Antonio Gallardo

 --
 Unico

RE: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom FOM_Cocoon.java

Vadim Gritsenko wrote: 
 
 vgritsenko2004/05/28 05:20:20
 
   Modified:
 src/blocks/forms/java/org/apache/cocoon/forms/flow/javascript
 Form.js

 src/java/org/apache/cocoon/components/flow/javascript/fom
 FOM_Cocoon.java
   Log:
   CocoonComponentManager was moved, but source was not refactored.
   Correcting package name. Forms still do not work - required method
   was removed.
   
Which method is needed?

Carsten

Re: [RT] Logging in Cocoon

2004-05-28 Thread Unico Hommes

Antonio Gallardo agallardo at agssa.net writes:

 
 Unico Hommes dijo:
 Since my firsts steps in Cocoon I wondered why it use LogKit and not the
 award winning log4j. 

Without a doubt log4j is popular. But popularity is mostly only marginally based
on merit. It proves good marketing, wide adoption and a large community. But it
doesn't prove a it to be the best in terms of code quality, ease of use, or the
most appropriate solution for any given system.

 I understand we need to support it because lot of
 code was written using it, 

Actually there is very little code in Cocoon that depends on LogKit directly.
When you use an Avalon Logger in your code this is not part of LogKit. Currently
the default implementation *is* a LogKitLogger but you can also setup your
system to use Log4jLogger, JDK14Logger, etc.

 but maybe the solution is to create a block
 for Logkit? 

It is important to distinguish between aspects of a system and its components.
Logging clearly is an aspect as opposed to SPI level services like blocks.
Although making Logkit support optional is possible, its not typically
accomplished by making it into a block.

--
Unico

DO NOT REPLY [Bug 26456] - First Xindice DB is created in current directory (instead of WEB-INF?)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=26456.
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=26456

First Xindice DB is created in current directory (instead of WEB-INF?)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-05-28 12:47 ---
Deployed Xindice as a XML-RPC server using XindiceServlet. Database location now
is WEB-INF/db (see WEB-INF/xindice.xml).

Vadim

DO NOT REPLY [Bug 26456] - First Xindice DB is created in current directory (instead of WEB-INF?)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=26456.
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=26456

First Xindice DB is created in current directory (instead of WEB-INF?)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

DO NOT REPLY [Bug 13479] - Cocoon fails to compile sitemap and XSP in JBoss 3.0.3 with embedded Tomcat 4.1.12 and 4.0.5

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=13479.
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=13479

Cocoon fails to compile sitemap and XSP in JBoss 3.0.3 with embedded Tomcat 4.1.12 and 
4.0.5

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2004-05-28 12:53 ---
Due to the fact that (a) Cocoon 2.0.x branch is (de facto) frozen (no
maintenance happening or planned), and (b) it is working in standalone Tomcat,
I'm marking this bug as WONTFIX.

DO NOT REPLY [Bug 13479] - Cocoon fails to compile sitemap and XSP in JBoss 3.0.3 with embedded Tomcat 4.1.12 and 4.0.5

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=13479.
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=13479

Cocoon fails to compile sitemap and XSP in JBoss 3.0.3 with embedded Tomcat 4.1.12 and 
4.0.5

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED



--- Additional Comments From [EMAIL PROTECTED]  2004-05-28 12:54 ---
Forgot to mention: Cocoon 2.1 does not have compiled sitemap anymore, and uses
Eclipse's compiler for XSPs, so this should not be an issue for Cocoon 2.1

Re: [RT] Logging in Cocoon

2004-05-28 Thread Stephen McConnell

Unico Hommes wrote:
BTW I am not
following Avalon developement very closely anymore, does anyone know what the
status of LogKit is in Avalon itself (did they deprecate it?).
Version 2.0.0 of LogKit has recently been released.
It is not deprecated.
Cheers, Stephen.

Re: New Cocoon block: ValidatorTransformer

2004-05-28 Thread Daniel Fagerstrom

The licensing problems can be solved by writing the validation 
transformer in terms of the JARV api, 
http://iso-relax.sourceforge.net/JARV/. Then JARV have a run time 
discovery mechanism for finding the actual implementation of the schema 
language, http://iso-relax.sourceforge.net/JARV/JARV.html#discovery.

There are a couple of different implementations of JARV 
http://iso-relax.sourceforge.net/JARV/JARV.html#download, MSV (RELAX 
NG/Core/Namespace, TREX, W3C XML Schema, XML DTD) and Jing (RELAX NG) 
has built in JARV support and there is an external JARV driver 
http://www.kohsuke.org/jarv/xerces/ for Xerces2 (W3C XML Schema). JARV 
and the Xerces2 driver has AFAIU MIT License.

So by using JARV we get validation with Jing, Xerces2 and Jing without 
licensing problems and people who want to use MSV, just need to download 
it and change the configuration.

J2SE 1.5 contains a validation api javax.xml.validation that is a 
superset of JARV and there is a adaptor from JARV to that interface 
http://www.kohsuke.org/jarv/tiger/.

Still it is a bad if we not can include MSV. It contains a schema data 
type library with validation and Java conversion for all XML Schema data 
types, that IMO would be useful in CForms for adding XML Schema data 
types as well.

/Daniel
Antonio Gallardo wrote:
David Crossley dijo:
So it seems to me that we cannot re-distribute MSV.

Unfortunately, yes. We cannot redistribute. :-(
Best Regards,
Antonio Gallardo

Re: [RT] Logging in Cocoon

2004-05-28 Thread Vadim Gritsenko

Stephen McConnell wrote:
Unico Hommes wrote:
BTW I am not
following Avalon developement very closely anymore, does anyone know 
what the
status of LogKit is in Avalon itself (did they deprecate it?).

Version 2.0.0 of LogKit has recently been released.

What's new in 2.0? I don't see any changelogs at 
http://avalon.apache.org/logkit/ ...

Vadim

Re: [RT] Logging in Cocoon

2004-05-28 Thread Berin Loritsch

Vadim Gritsenko wrote:
Stephen McConnell wrote:
Unico Hommes wrote:
BTW I am not
following Avalon developement very closely anymore, does anyone know 
what the
status of LogKit is in Avalon itself (did they deprecate it?).

Version 2.0.0 of LogKit has recently been released.

What's new in 2.0? I don't see any changelogs at 
http://avalon.apache.org/logkit/ ...
Mostly (from what I recall) cleaning out all the deprecated stuff (hense
the 2.0 designation because it is not 100% backwards compatible with
users who have not migrated off of the deprecated classes).  The removal
of the deprecated stuff should not in any way affect Cocoon.
--
Programming today is a race between software engineers striving to 
build bigger and better idiot-proof programs, and the Universe trying to 
produce bigger and better idiots. So far, the Universe is winning.
- Rich Cook

Re: Large xml's in cocoon

2004-05-28 Thread Stefano Mazzocchi

Antonio Gallardo wrote:
Stefano Mazzocchi dijo:
Hmmm, Anna is right to report the problem though. I mean, why in hell an
OutOfMemoryException get swollen like that?

Not sure. I don't think we are swollen the exception in this case. But I
am not the best knowledge to tell that. ;-)
What I can said is: we have an application running since Cocoon 2.0.3 and
has being updated on each Cocoon version to 2.1..5 and it works fine. We
render some reports to excel, html and pdf with more than 5,000 rows.
I did experience the same white page error before and I feel that was 
an OutOfMemoryException due to the JPEG thumbnail code (I was creating 
20 thumbnails at the same time from 4 megapixel images... I guess the 
JVM heap was going insane).

So, let's use heuristics here: did anybody ever see an 
OutOfMemoryException in an cocoon error page? I haven't.

Did you ever get a white page in cocoon that went away after one or two 
reloads? I did.

thoughts?
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Large xml's in cocoon

2004-05-28 Thread Stefano Mazzocchi

Ugo Cei wrote:
Il giorno 28/mag/04, alle 03:26, Stefano Mazzocchi ha scritto:
Hmmm, Anna is right to report the problem though. I mean, why in hell 
an OutOfMemoryException get swollen like that?

Swollen? I think you mean swallowed here. 
eheh, right :-) [maybe my mind thought of swollen because of too much 
memory used ;-)]

Anyway, I think it has to do 
more with Tomcat than with Cocoon. It happens (particularly when you 
frequently reload applications) that Tomcat outputs a blank page and 
logs a simple java.lang.OutOfMemoryException without a stacktrace to 
catalina.out.

I can understand this, what else can you do when you're out of memory? 
You're not guaranteed to be able to log a stacktrace or send anything to 
the client. Actually, I'd rather wish Tomcat crashed in this 
circumstance, so we might at least restart it automatically.
what if I'm using jetty?
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Fed up with build discussions: proposed deal

2004-05-28 Thread Stefano Mazzocchi

Nicola Ken Barozzi wrote:
Stefano Mazzocchi wrote:
Nicola Ken Barozzi wrote:
...
Deal?

No, first somebody has to explain to me what's the problem with the 
current build system.

The current version is actually quite well structured, especially with 
the main build.

The main problems are with:
1 - blocks build
2 - customized forrest usage
3 - no jar download system
1 - using import and subant this can be made much easier to change and 
debug, and have each block be able to customize the build

2 - there are an impressive number of targets just to do what Forrest 
does automatically... gotta investigate

3 - some really see it as an issue
Also, the build of Cocoon can be made much better using macrodefs and 
top level tasks.
All of this sounds good. Be my guest if you want to volunteer ;-)
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Large xml's in cocoon

2004-05-28 Thread Ugo Cei

Stefano Mazzocchi wrote:
what if I'm using jetty?
I don't know. We're currently using the bundled Jetty for development 
and Tomcat for staging/production. But my point still remains: it's 
better to crash and burn rather than try to survive if you get an 
OOMException.

Ugo

Re: [CVS-SVN] Cocoon switching to SVN

2004-05-28 Thread Vadim Gritsenko

Nicola Ken Barozzi wrote:
Someone please cc [EMAIL PROTECTED] I'm on a cell 
connection and am having problems sending email, and this ius going 
through gmane.

Brian W. Fitzpatrick wrote:
...
Thanks for the fantastic roadmap!  Can we plan on doing this sometime on
Monday the 31st?  I'd like to do a test-run sometime between now and
then to make sure that the conversion on Monday runs smoothly (and that
you get exactly what you want in your repository).

Wow, that's *early*! :-)

I don't think it's early... We already need to start 2.1.6...
Vadim

Re: Large xml's in cocoon

On Fri, 2004-05-28 at 16:28, Stefano Mazzocchi wrote:
 Antonio Gallardo wrote:
 
  Stefano Mazzocchi dijo:
  
 Hmmm, Anna is right to report the problem though. I mean, why in hell an
 OutOfMemoryException get swollen like that?
  
  
  Not sure. I don't think we are swollen the exception in this case. But I
  am not the best knowledge to tell that. ;-)
  
  What I can said is: we have an application running since Cocoon 2.0.3 and
  has being updated on each Cocoon version to 2.1..5 and it works fine. We
  render some reports to excel, html and pdf with more than 5,000 rows.
 
 I did experience the same white page error before and I feel that was 
 an OutOfMemoryException due to the JPEG thumbnail code (I was creating 
 20 thumbnails at the same time from 4 megapixel images... I guess the 
 JVM heap was going insane).
 
 So, let's use heuristics here: did anybody ever see an 
 OutOfMemoryException in an cocoon error page? I haven't.
 
 Did you ever get a white page in cocoon that went away after one or two 
 reloads? I did.
 
 thoughts?

It is because it is an OutOfMemoryError, not an Exception. Currently
Errors are not catched by Cocoon.

There has been a discussion thread about this in the past, I don't
remember if any consensus was reached about what how we want to treat
Errors.

-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java  XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: Fed up with build discussions: proposed deal

2004-05-28 Thread Vadim Gritsenko

Nicola Ken Barozzi wrote:
Stefano Mazzocchi wrote:
Nicola Ken Barozzi wrote:
...
Deal?

No, first somebody has to explain to me what's the problem with the 
current build system.

The current version is actually quite well structured, especially with 
the main build.

The main problems are with:
1 - blocks build
2 - customized forrest usage
3 - no jar download system
1 - using import and subant this can be made much easier to change 
and debug, and have each block be able to customize the build

Please try to avoid adding build.xml for each block...

2 - there are an impressive number of targets just to do what Forrest 
does automatically... gotta investigate

3 - some really see it as an issue

I don't ;-)

Also, the build of Cocoon can be made much better using macrodefs and 
top level tasks.

As long as it is fast. Once we removed usage of (IIRC) ant/ task build 
became orders of magnitude faster.

Vadim

Re: Large xml's in cocoon

On 28.05.2004 16:42, Bruno Dumon wrote:
It is because it is an OutOfMemoryError, not an Exception. Currently
Errors are not catched by Cocoon.
There has been a discussion thread about this in the past, I don't
remember if any consensus was reached about what how we want to treat
Errors.
There are also samples about exception and error handling and Antonio 
mentioned immediately before the release that the error results in a 
blank page. AFAIK that was the consensus of that discussion thread.

Joerg

Revisiting SVN support in Eclipse...

Hi:

In march 2004, when forrest moved to SVN. I found the RFE in Eclipse
related to SVN:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=37154

Maybe your vote can accelerate the process! ;-)

Best Regards,

Antonio Gallardo

Re: Large xml's in cocoon

2004-05-28 Thread Sylvain Wallez

Bruno Dumon wrote:
On Fri, 2004-05-28 at 16:28, Stefano Mazzocchi wrote:
 

Antonio Gallardo wrote:
   

Stefano Mazzocchi dijo:
 

Hmmm, Anna is right to report the problem though. I mean, why in hell an
OutOfMemoryException get swollen like that?
   

Not sure. I don't think we are swollen the exception in this case. But I
am not the best knowledge to tell that. ;-)
What I can said is: we have an application running since Cocoon 2.0.3 and
has being updated on each Cocoon version to 2.1..5 and it works fine. We
render some reports to excel, html and pdf with more than 5,000 rows.
 

I did experience the same white page error before and I feel that was 
an OutOfMemoryException due to the JPEG thumbnail code (I was creating 
20 thumbnails at the same time from 4 megapixel images... I guess the 
JVM heap was going insane).

So, let's use heuristics here: did anybody ever see an 
OutOfMemoryException in an cocoon error page? I haven't.

Did you ever get a white page in cocoon that went away after one or two 
reloads? I did.

thoughts?
   

It is because it is an OutOfMemoryError, not an Exception. Currently
Errors are not catched by Cocoon.
There has been a discussion thread about this in the past, I don't
remember if any consensus was reached about what how we want to treat
Errors.
 

IIRC, we found that OutOfMemoryError was special and could be catched by 
Cocoon, as it can potentially occur in the processing of pipelines that 
normally succeed, either will smaller documents or less concurrent users.

Other errors (NoClassDefFound, StackOverflow etc) should not be handled 
by Cocoon

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

Re: Large xml's in cocoon

2004-05-28 Thread Pier Fumagalli

On 28 May 2004, at 15:28, Stefano Mazzocchi wrote:
Antonio Gallardo wrote:
Stefano Mazzocchi dijo:
Hmmm, Anna is right to report the problem though. I mean, why in 
hell an
OutOfMemoryException get swollen like that?
Not sure. I don't think we are swollen the exception in this case. 
But I
am not the best knowledge to tell that. ;-)
What I can said is: we have an application running since Cocoon 2.0.3 
and
has being updated on each Cocoon version to 2.1..5 and it works fine. 
We
render some reports to excel, html and pdf with more than 5,000 rows.
I did experience the same white page error before and I feel that 
was an OutOfMemoryException due to the JPEG thumbnail code (I was 
creating 20 thumbnails at the same time from 4 megapixel images... I 
guess the JVM heap was going insane).

So, let's use heuristics here: did anybody ever see an 
OutOfMemoryException in an cocoon error page? I haven't.

Did you ever get a white page in cocoon that went away after one or 
two reloads? I did.

thoughts?
Ste, it's easy... I noticed several times that in OOMEs the stacktraces 
were all wrong as well... And I started to ask myself why...

Any time you do a catch (Throwable e) which (in theory) should also 
catch the OOME, you'll create an object, even maybe a silly one, like 
an exception wrapping the OOME, but, hey, you're out of memory, so, 
ANYTHING you do with that exception, apart from probably 
e.printStackTrace() will inevitably trigger another OOME...

I got around the problem by doing something like this:
try {
  
} catch (OutOfMemoryException exception) {
  System.gc();
  Thread.currentThread().sleep(1000);
  // handle the OOME
}
but it doesn't always work...
I solved the problem by always piping my java standard output and error 
to a file, because being handled in the C code, that exception falls 
back to the bottom and (at the end) is dumped on your console...

But (for example) Tomcat's default startup scripts (or Jetty's for that 
matter) completely ignore the console (and that's why I always use my 
own builds of everything, most of the code out there is simply not 
ready as is to be deployed on production).

I mean, don't get me wrong, it's all very well written code, but until 
you don't hit a problem like a OOME on a real server, well, noone seems 
to care! :-P

	Pier


smime.p7s
Description: S/MIME cryptographic signature

Re: [RT] Logging in Cocoon

2004-05-28 Thread Stephen McConnell

Vadim Gritsenko wrote:
Stephen McConnell wrote:
Unico Hommes wrote:
BTW I am not
following Avalon developement very closely anymore, does anyone know 
what the
status of LogKit is in Avalon itself (did they deprecate it?).

Version 2.0.0 of LogKit has recently been released.

What's new in 2.0? I don't see any changelogs at 
http://avalon.apache.org/logkit/ ...
Nothing new in terms of features.
The changes the prompted the the bump to 2.0.0 were related to removal 
of the AvalonFormatter class that tied the LogKit implementation to 
Avalon Framework (and the exposure of an operation to pass a specific 
formatter instance to LogKit LogTarget).  End result - LogKit is now 
independent of Framework.

Other changes to LogKit include some minor bug fixes and some small 
implementation improvements.

Cheers, Stephen.

Re: Large xml's in cocoon

2004-05-28 Thread Pier Fumagalli

On 28 May 2004, at 15:34, Ugo Cei wrote:
Stefano Mazzocchi wrote:
what if I'm using jetty?
I don't know. We're currently using the bundled Jetty for development 
and Tomcat for staging/production. But my point still remains: it's 
better to crash and burn rather than try to survive if you get an 
OOMException.
Yeah, the problem is that you never crash and burn on OOMEs. The JVM 
doesn't itself exit.

You could (for instance) do something like:
try {
   ...
} catch (OutOfMemoryError e) {
  System.exit(0);
}
I've seen a lot of OOMEs happening just because the machine was simply 
overloaded, and in those situation doing a System.exit() was more 
harmful than simply letting that thread die.

When a thread (a request thread, for instance) dies because of an OOME, 
is _definitely_ going to free up a couple of objects, and having the 
JVM that bit of millisecond to re-sort itself out and clean up some 
memory after thread death...

Oh, on a side note, Ugo, I'd seriously switch your 
development/production environments... I'm not going into performance 
details (I don't want to raise a can of worms), but at least on my 
tests Tomcat is using 3x the memory that Jetty is using per single 
request, so it's more likely for you to have OOMEs on Tomcat rather 
than Jetty.

	Pier


smime.p7s
Description: S/MIME cryptographic signature

Re: [RT] Extending Dreamweaver (Was: Re: [RT] Tapestry or the value of multi-channel forms?)

2004-05-28 Thread Tony Collen

Reinhard Poetz wrote:
Thanks Tony for digging into this. It seems to be a very promising way! :-)
(I will comment on the details in a separate mail as soon as I have 
enough time thinking more about this!)

I know, Dreamweaver is commercial but is there any way putting your work 
into an opensource CVS/SVN?
There's no functionality yet, it's a completely hollow GUI mockup :)  I think the first step might 
be to create a tag library for the CForms stuff, so I'll start looking into a CForms grammar somewhere.

Tony

Re: Large xml's in cocoon

2004-05-28 Thread Ugo Cei

Pier Fumagalli wrote:
Oh, on a side note, Ugo, I'd seriously switch your 
development/production environments... I'm not going into performance 
details (I don't want to raise a can of worms), but at least on my tests 
Tomcat is using 3x the memory that Jetty is using per single request, so 
it's more likely for you to have OOMEs on Tomcat rather than Jetty.
I couldn't agree more with this, Pier, but until my boss gets me a new 
engineer, I'm not going to learn how to properly configure Jetty for 
vhosts, authentication, logging and HTTPS and switch over. I don't want 
to do this job anymore, so they stay where they are ;-).

Ugo

Re: [RT] Logging in Cocoon

2004-05-28 Thread Ceki Gülcü

 Ok, this is all true - but considering performance it's imho neglectable
 even if you consider that heavy xml parsing and stylesheet transformations
 happen at the same time.
 
 

 Maybe ;-)

 I'll try to come up with real numbers soon!

 Sylvain
Sylvain,
Although there is some overhead in the way log4j does its lookup, you
should discover that the overhead is in the nano-second range.
Thus, for many applications the difference should be so small as to be
unmeasurable. However, there are situations where the overhead makes a
difference. In particular, when the logging is done at the OS or
container level. We are aware of the problem. It will be addressed in
future versions of log4j.
In any case, I would be quite interested in the numbers you come up
with.
--
Ceki Gülcü
 For log4j documentation consider The complete log4j manual
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp

Re: [RT] Logging in Cocoon

Ceki Gülcü dijo:
 At 02:43 PM 5/28/2004, Unico Hommes wrote:

Without a doubt log4j is popular. But popularity is mostly only
 marginally
based
on merit. It proves good marketing, wide adoption and a large community.
But it
doesn't prove a it to be the best in terms of code quality, ease of use,
or the
most appropriate solution for any given system.

 Good marketing? Hmm, log4j was never marketed. Sure, we have a
 web-site but we don't market log4j at all, and never have. What is
 this good marketing we've supposedly been doing? I'm interested...

 I apologize if this is way out off topic, but I had to react to this
 myth of the log4j marketing steam-roller.

log4j was on the right place at the right time. Before log4j was nothing.
After the log4j success, on each corner you find a clone. ;)

Best Regards,

Antonio Gallardo

Re: [RT] Logging in Cocoon

2004-05-28 Thread Ceki Gülcü

At 02:43 PM 5/28/2004, you wrote:
Antonio Gallardo agallardo at agssa.net writes:
Without a doubt log4j is popular. But popularity is mostly only marginally 
based
on merit. It proves good marketing, wide adoption and a large community. 
But it
doesn't prove a it to be the best in terms of code quality, ease of use, 
or the
most appropriate solution for any given system.

Good marketing? Hmm, log4j was never marketed. Sure, we have a
web-site but we don't market log4j at all, and never have. What is
this good marketing we've supposedly been doing? I'm interested.
I apologize if this is way out off topic, but so is the myth of the
log4j marketing steam-roller.

--
Unico
--
Ceki Gülcü
 For log4j documentation consider The complete log4j manual
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp

Re: [RT] Logging in Cocoon

2004-05-28 Thread peter royal

On May 27, 2004, at 9:05 AM, Carsten Ziegeler wrote:
So, my suggestion is to:
- deprecate the use of LogKit
- switch to log4j as default
- make it possible to configure log4j from within Cocoon (like the
  current logkit.xml for LogKit).
+1
As long as Cocoon is based on a non-static logging abstraction, I'm 
happy.
-pete

Mounting problem in CVS head, something environment related

I stumbled across a problem with map:mount with an empty uri-prefix
attribute. I've made a minimalistic test case to illustrate the problem,
just extract the attached file in cocoon's webapp dir and try to surf to
eg:
http://localhost:/test/a/test2/abc

which will give the following exception:

org.apache.cocoon.ProcessingException: The current URI (a/test2/abc) doesn't start 
with given prefix (test/)
at 
org.apache.cocoon.environment.internal.EnvironmentHelper.changeContext(EnvironmentHelper.java:170)
at 
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:80)
...


This worked fine in 2.1.5. Not urgent for me since I'll reorganize my
sitemap anyway.

-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java  XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]


test.tgz
Description: application/compressed-tar

Re: Mounting problem in CVS head, something environment related

On Fri, 2004-05-28 at 20:28, Tony Collen wrote:
 Bruno Dumon wrote:
  I stumbled across a problem with map:mount with an empty uri-prefix
  attribute. I've made a minimalistic test case to illustrate the problem,
  just extract the attached file in cocoon's webapp dir and try to surf to
  eg:
  http://localhost:/test/a/test2/abc
  
  which will give the following exception:
  
  org.apache.cocoon.ProcessingException: The current URI (a/test2/abc) doesn't start 
  with given prefix (test/)
  at 
  org.apache.cocoon.environment.internal.EnvironmentHelper.changeContext(EnvironmentHelper.java:170)
  at 
  org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:80)
  ...
  
  
  This worked fine in 2.1.5. Not urgent for me since I'll reorganize my
  sitemap anyway.
  
 
 I'm not too sure if this is related (probably not)

it might be though...

 , but do you see the problem exhibited in [1], as 
 well?

trying... yes

 
 Maybe my problem described isn't actually a problem...
 
 Tony
 
 [1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=108561977804373w=2
-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java  XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

RE: [CVS-SVN] Cocoon switching to SVN

On Fri, 2004-05-28 at 10:14, Carsten Ziegeler wrote:
 Nicola Ken Barozzi wrote:
  
  Someone please cc [EMAIL PROTECTED] I'm on a cell 
  connection and am having problems sending email, and this ius 
  going through gmane.
  
  Brian W. Fitzpatrick wrote:
  ...
   Thanks for the fantastic roadmap!  Can we plan on doing 
  this sometime 
   on Monday the 31st?  I'd like to do a test-run sometime between now 
   and then to make sure that the conversion on Monday runs 
  smoothly (and 
   that you get exactly what you want in your repository).
  
  Wow, that's *early*! :-)
  
  What about Wednesday (a week) or later, so that everyone gets 
  a reasonable heads-up about learning SVN and getting it installed?
  
 I think we all know enough about SVN :), so I'm +1 on this monday!!

+1 too

 This will help us working on 2.1.6 without creating a branch in cvs
 now. So the sooner the better.
 
 Many thanks for the help!!!
 
 Carsten
-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java  XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: Adding a global validation message to a form?

Moving this to dev list. Find the original thread at 
http://marc.theaimsgroup.com/?t=10855910974r=1w=4.

On 28.05.2004 20:13, Bruno Dumon wrote:
I'm not sure if this is a good
solution, since those messages are not specifically recognized as being
validation errors, and so this wouldn't work together with
fi:validation-errors. Maybe the best would be to allow adding validation
errors (multiple ones) on the form itself.
The form itself becomes ValidationErrorAware? I searched for it when 
thinking about a solution, but unfortunately the form is not 
implementing the interface.

So +1.
fi:validation-errors would
then better be replaced with a ft:validation-errors (which can crawl the
widget tree), since otherwise it wouldn't find the errors attached to
the form.
Hmm, I guess it is also possible to add a fi:validation-message to the 
form widget as it is done for all other widgets. It must be possible to 
differ between form widget (= global) validation errors, collected 
somewhere and widget specific errors. In other words I do not want to 
be forced to collect all errors at one place just because of using 
ft:validation-errors for the global errors.

But +1 for the idea in general.
Joerg

Re: cvs commit: cocoon-2.1/src/blocks/tour/samples/flow/docs number-guess.xml