On Tue, 11 Dec 2001, Stefano Mazzocchi wrote:

> Some suggestions for the CVS
>
> 1) stylebook is no longer used nor supported. We should remove it from
> our /lib directory

+1

> 2) having binary files in CVS is bad, but having 'compressed jars'
> inside the /lib directory is even worse because it both slows down CVS
> downloads (gzip doesn't work on compressed jars as it does on
> uncompressed ones) and slows Cocoon starting phase.
>
> The price to pay is some disk space, but given the price per MB of HD,
> this should be a resonable price.

Ok.

> 3) since we'll be including a bunch of software under different
> licenses, we should come up with a /legal directory where we place all
> this stuff.

+1

> 4) we have three webapp directories 'webapp', webapp.site and
> webapp.tutorial, should we have only one?
>
> 5) the build file contains a number of properties, should we move them
> out into a property file which is flatter and easier to update?

+1

> 6) the code contains a number of things that I found.... well.... let's
> me look for a polite way of saying this.... hmmm, ehmmmm, errrr, .....
> fucked.
>
>             if (this.getLogger().isDebugEnabled()) {
>                 incRequestCount();
>                 if (this.getLogger().isDebugEnabled()) {
>                     this.debug(environment, null, null);
>                 }
>             }
>
> do you know where this code is? it's executed every single request
> (Cocoon.java:623). Ok, it doesn't decrease performance, but let's look
> into the code after we apply some automatic search/replace tools, ok?

I've started to spend some of my spare free time to check every single
java file to polish it up (javadocs, coding conventions, logging and
unused imports) with logging usage highest in priority (only in the
HEAD branch). I'll commit them file after file. I'd also like to
restructure the CVS according to the structure Avalon uses.

> [well, I *hope* the above came after S&R or we have some serious
> problems]
>
> Moreover, there are classes (Main.java for example) where logging is
> still not wrapped by channel cheching code. This *does* decrease
> performance on command line operations.

See above. But as I'll only do it slowly (because of small time frames).

> 7) still looking into Cocoon.java:748
>
>     /**
>      * Increment active request count for incoming requests, and save
> this
>      * result if it's the maximum.
>      */
>     private static synchronized void incRequestCount() {
>         if (++activeRequestCount > maxRequestCount) {
>             maxRequestCount = activeRequestCount;
>         }
>     }
>
>     /**
>      * Decrement active request count.
>      */
>     private static synchronized void decRequestCount() {
>         --activeRequestCount;
>     }
>
> what are these for? are you aware of the fact that adding a synchronized
> methods to the front door might create a *huge* bottleneck on high
> load!?!?!
>
> Enough for now
>
> [Carsten, I think you can resurrect your directory-cleaning suggestions
> now]

?? What do you mean?

Giacomo


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to