You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by "Craig R. McClanahan" <cr...@apache.org> on 2001/10/17 04:08:23 UTC

failure notice (fwd)

Sign ... sometimes 100k is too small.

I just did a pretty good-sized commit to switch our XML parsing activity
over to the Digester package from jakarta-commons, with a very noticeable
improvement in startup performance.  Here's the summary of the changes.

Craig McClanahan


---------- Forwarded message ----------
Date: 17 Oct 2001 00:54:12 -0000
From: MAILER-DAEMON@apache.org
To: craigmcc@apache.org
Subject: failure notice

Hi. This is the qmail-send program at apache.org.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<to...@jakarta.apache.org>:
ezmlm-reject: fatal: Sorry, I don't accept messages larger than 100000 bytes (#5.2.3)

--- Below this line is a copy of the message.

Return-Path: <cr...@apache.org>
Received: (qmail 86841 invoked by uid 500); 17 Oct 2001 00:54:12 -0000
Delivered-To: apmail-jakarta-tomcat-4.0-cvs@apache.org
Received: (qmail 86708 invoked from network); 17 Oct 2001 00:53:50 -0000
Received: from unknown (HELO icarus.apache.org) (64.125.133.21)
  by 64.125.133.20 with SMTP; 17 Oct 2001 00:53:50 -0000
Received: (qmail 16302 invoked by uid 1059); 17 Oct 2001 00:44:03 -0000
Date: 17 Oct 2001 00:44:03 -0000
Message-ID: <20...@icarus.apache.org>
From: craigmcc@apache.org
To: jakarta-tomcat-4.0-cvs@apache.org
Subject: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/xml PathMatch.java SaxContext.java XmlAction.java XmlMapper.java XmlMatch.java
X-Spam-Rating: 64.125.133.20 1.6.2 0/1000/N

craigmcc    01/10/16 17:44:03

  Modified:    .        BUILDING.txt build.properties.sample
               catalina build.xml
               catalina/src/share/org/apache/catalina/realm
                        MemoryRealm.java RealmBase.java
               catalina/src/share/org/apache/catalina/startup Catalina.java
                        CatalinaService.java ContextConfig.java
               catalina/src/share/org/apache/catalina/util/xml
                        PathMatch.java SaxContext.java XmlAction.java
                        XmlMapper.java XmlMatch.java
  Added:       catalina/src/share/org/apache/catalina/realm
                        MemoryRuleSet.java
               catalina/src/share/org/apache/catalina/startup
                        ContextRuleSet.java CopyParentClassLoaderRule.java
                        EngineRuleSet.java HostRuleSet.java
                        LifecycleListenerRule.java TldRuleSet.java
                        WebRuleSet.java
  Log:
  Migrate XML parsing performed by Tomcat from the Tomcat-specific XmlMapper
  code to the Commons Digester project that is used across a bunch of
  Jakarta and non-Jakarta code.  This will allow us to take advantage of
  it's ability to handle namespace-sensitive parsing, to be shared (in
  /common/lib) if appropriate, as well as the ability
  to reuse Digester instances (Tomcat now starts up noticeably faster --
  I've got a pretty fast box, but its less than 3 seconds for the default
  set of webapps).

  The BUILDING.txt instructions have been updated for the new dependencies
  on commons-digester, commons-collections, and commons-beanutils.

  NOTE:  The configuration rules reflect the refactor that Remy just
  committed for DefaultContext.



Re: failure notice

Posted by Jon Stevens <jo...@latchkey.com>.
on 10/16/01 9:23 PM, "Craig R. McClanahan" <cr...@apache.org> wrote:

> Nah, I bought him off ... I actually fixed a Javadoc warning message on
> commons-digester.  :-)

That just validates my cause.

-jon


Re: failure notice (fwd)

Posted by "Craig R. McClanahan" <cr...@apache.org>.

On Tue, 16 Oct 2001, Remy Maucherat wrote:

>
> > Besides, quick-and-easy grabbing of dependencies was what the
> > so-far-incomplete CJAN/JJAR/whatever type projects were supposed to solve.
> > I'd prefer to wait for the real solution.
>
> Ok, ok, but in the meatime, Jon's going to complain ;-)
>

Nah, I bought him off ... I actually fixed a Javadoc warning message on
commons-digester.  :-)

> Remy
>
>

Craig



Re: failure notice (fwd)

Posted by Remy Maucherat <rm...@home.com>.
> On Tue, 16 Oct 2001, Remy Maucherat wrote:
>
> > > Sign ... sometimes 100k is too small.
> > >
> > > I just did a pretty good-sized commit to switch our XML parsing
activity
> > > over to the Digester package from jakarta-commons, with a very
noticeable
> > > improvement in startup performance.  Here's the summary of the
changes.
> >
> > It does seem faster indeed.
> >
> > Would it be acceptable if we just committed the appropriate version of
each
> > library in the CVS ?
> > Thay're small, and there's 3 of them ...
> >
>
> In case anybody doesn't know how I feel about JARs in CVS ... YUCK.
>
> :-)
>
> IMHO, it's not an issue of size, or even where they come from.  JARs in
> CVS cause people to lose track of what they really depend on, and (more
> particularly) the *version* of things you depend on.  It just gets worse
> when you check in things that were built from mutually-incompatible common
> dependents.  If Gump has taught us anything, this should be one of the key
> insights.
>
> And, if you've ever tried to update jakarta-site2, or other repositories
> that store lots of JARs, when you're dialed in at 56k you won't think much
> of the idea either.
>
> Besides, quick-and-easy grabbing of dependencies was what the
> so-far-incomplete CJAN/JJAR/whatever type projects were supposed to solve.
> I'd prefer to wait for the real solution.

Ok, ok, but in the meatime, Jon's going to complain ;-)

Remy


Re: failure notice

Posted by Jon Stevens <jo...@latchkey.com>.
on 10/16/01 7:48 PM, "Craig R. McClanahan" <cr...@apache.org> wrote:

> And, if you've ever tried to update jakarta-site2, or other repositories
> that store lots of JARs, when you're dialed in at 56k you won't think much
> of the idea either.

Please talk facts. There are a total of 4 jar's in there.

 408 -rw-r--r--   1 jon      staff      416389 Sep  3 03:47 ant-1.4.jar
 104 -rw-r--r--   1 jon      staff      106416 Jul  3 13:17 jdom-b7.jar
 388 -rw-rw-r--   1 jon      wheel      393733 Aug 23 09:36
velocity-1.2-dev.jar
1768 -rw-r--r--   1 jon      staff     1808885 Aug 20 12:35 xerces-1.4.3.jar

The two largest .jar files (Ant and Xerces) could be removed, but I don't
want all the whiny bitchy wimpy people to complain about having to install
Ant in order to build jakarta-site2.

> Besides, quick-and-easy grabbing of dependencies was what the
> so-far-incomplete CJAN/JJAR/whatever type projects were supposed to solve.
> I'd prefer to wait for the real solution.

Then help make it happen.

-jon


Re: failure notice (fwd)

Posted by "Craig R. McClanahan" <cr...@apache.org>.

On Tue, 16 Oct 2001, Remy Maucherat wrote:

> Date: Tue, 16 Oct 2001 19:47:21 -0700
> From: Remy Maucherat <rm...@home.com>
> Reply-To: tomcat-dev@jakarta.apache.org
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: failure notice (fwd)
>
> > Sign ... sometimes 100k is too small.
> >
> > I just did a pretty good-sized commit to switch our XML parsing activity
> > over to the Digester package from jakarta-commons, with a very noticeable
> > improvement in startup performance.  Here's the summary of the changes.
>
> It does seem faster indeed.
>
> Would it be acceptable if we just committed the appropriate version of each
> library in the CVS ?
> Thay're small, and there's 3 of them ...
>

In case anybody doesn't know how I feel about JARs in CVS ... YUCK.

:-)

IMHO, it's not an issue of size, or even where they come from.  JARs in
CVS cause people to lose track of what they really depend on, and (more
particularly) the *version* of things you depend on.  It just gets worse
when you check in things that were built from mutually-incompatible common
dependents.  If Gump has taught us anything, this should be one of the key
insights.

And, if you've ever tried to update jakarta-site2, or other repositories
that store lots of JARs, when you're dialed in at 56k you won't think much
of the idea either.

Besides, quick-and-easy grabbing of dependencies was what the
so-far-incomplete CJAN/JJAR/whatever type projects were supposed to solve.
I'd prefer to wait for the real solution.

> Remy
>
>

Craig (who's thinking about ways to get out of the circular dependency
trap on the JARs we already have checked in)



Re: failure notice (fwd)

Posted by Remy Maucherat <rm...@home.com>.
> Sign ... sometimes 100k is too small.
>
> I just did a pretty good-sized commit to switch our XML parsing activity
> over to the Digester package from jakarta-commons, with a very noticeable
> improvement in startup performance.  Here's the summary of the changes.

It does seem faster indeed.

Would it be acceptable if we just committed the appropriate version of each
library in the CVS ?
Thay're small, and there's 3 of them ...

Remy