[GUMP] Build Failure - Tomcat 4.0

[Craig McClanahan]

This email is autogenerated from the output from:



Buildfile: build.xml

deploy-prepare:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/build

deploy-static:

deploy-main:
 [echo] Target: Catalina - Deploy...

build-prepare:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/bin
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/classes
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/conf
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/lib
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common
[mkdir] Created dir: 
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/lib
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/server
[mkdir] Created dir: 
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/server/lib

copy-jaxp-jar:
 [copy] Copying 1 file to 
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/server/lib

build-static:
 [copy] Copying 9 files to 
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/bin
 [copy] Copying 5 files to 
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/conf
 [copy] Copying 1 file to 
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/lib
 [copy] Copying 1 file to 
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/lib
 [copy] Copying 1 file to 
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/server/lib
 [copy] Copying 1 file to 
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/server/lib

build-main:
[javac] Compiling 4 source files to 
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/classes
[javac] Compiling 278 source files to 
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/classes
[javac] Note: 13 files use or override a deprecated API.  Recompile with 
"-deprecation" for details.
[javac] 1 warning
 [copy] Copying 26 files to 
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/classes
  [jar] Building jar: 
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/bin/bootstrap.jar
  [jar] Building jar: 
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/lib/naming.jar
  [jar] Building jar: 
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/lib/resources.jar
  [jar] Building jar: 
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/lib/namingfactory.jar

deploy-prepare:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/build/bin
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/build/conf
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/build/lib
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/build/logs
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/build/common
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/build/common/lib
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/build/server
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/build/server/lib
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/build/work

deploy-static:
 [copy] Copying 10 files to /home/rubys/jakarta/jakarta-tomcat-4.0/build/bin
 [copy] Copying 5 files to /home/rubys/jakarta/jakarta-tomcat-4.0/build/conf
 [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-4.0/build/lib
 [copy] Copying 4 files to /home/rubys/jakarta/jakarta-tomcat-4.0/build/common/lib
 [copy] Copying 3 files to /home/rubys/jakarta/jakarta-tomcat-4.0/build/server/lib

deploy-main:
  [jar] Building jar: 
/home/rubys/jakarta/jakarta-tomcat-4.0/build/server/lib/catalina.jar
  [jar] Building jar: 
/home/rubys/jakarta/jakarta-tomcat-4.0/build/server/lib/warp.jar

deploy:
 [echo] Target: Jasper - Deploy...

build-prepare:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/jasper/build
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/jasper/build/bin
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/jasper/build/classes
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/jasper/build/lib

copy-jaxp-jar:
 [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-4.0/jasper/build/lib

build-static:
 [copy] Copying 5 files to /home/rubys/jakarta/jakarta-tomcat-4.0/jasper/build/bin
 [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-4.0/jasper/build/lib

build-main:
[javac] Compiling 91 source files to 
/home/rubys/jakarta/jakarta-tomcat-4.0/jasper/build/classes
 [copy] Copying 3 files to 
/home/rubys/jakarta/jakarta-tomcat-4.0/jasper/build/classes

deploy-prepare:
[mkdir] C

Re: [GUMP] Build Failure - Tomcat 4.0

[Craig R. McClanahan]

Sam,

Tomcat 4 has just added a new dependency on jakarta-site2 (for the doc
templates).  Specifically, it needs a "site2.home" property in the
build.properties file containing the pathname to this directory.

Thanks,
Craig


On 28 Jul 2001, Craig McClanahan wrote:

> 
> This email is autogenerated from the output from:
> 
> 
> 
> Buildfile: build.xml
> 
> deploy-prepare:
> [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/build
> 
> deploy-static:
> 
> deploy-main:
>  [echo] Target: Catalina - Deploy...
> 
> build-prepare:
> [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build
> [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/bin
> [mkdir] Created dir: 
>/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/classes
> [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/conf
> [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/lib
> [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common
> [mkdir] Created dir: 
>/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/lib
> [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/server
> [mkdir] Created dir: 
>/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/server/lib
> 
> copy-jaxp-jar:
>  [copy] Copying 1 file to 
>/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/server/lib
> 
> build-static:
>  [copy] Copying 9 files to 
>/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/bin
>  [copy] Copying 5 files to 
>/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/conf
>  [copy] Copying 1 file to 
>/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/lib
>  [copy] Copying 1 file to 
>/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/lib
>  [copy] Copying 1 file to 
>/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/server/lib
>  [copy] Copying 1 file to 
>/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/server/lib
> 
> build-main:
> [javac] Compiling 4 source files to 
>/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/classes
> [javac] Compiling 278 source files to 
>/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/classes
> [javac] Note: 13 files use or override a deprecated API.  Recompile with 
>"-deprecation" for details.
> [javac] 1 warning
>  [copy] Copying 26 files to 
>/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/classes
>   [jar] Building jar: 
>/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/bin/bootstrap.jar
>   [jar] Building jar: 
>/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/lib/naming.jar
>   [jar] Building jar: 
>/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/lib/resources.jar
>   [jar] Building jar: 
>/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/lib/namingfactory.jar
> 
> deploy-prepare:
> [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/build/bin
> [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/build/conf
> [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/build/lib
> [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/build/logs
> [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/build/common
> [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/build/common/lib
> [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/build/server
> [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/build/server/lib
> [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/build/work
> 
> deploy-static:
>  [copy] Copying 10 files to /home/rubys/jakarta/jakarta-tomcat-4.0/build/bin
>  [copy] Copying 5 files to /home/rubys/jakarta/jakarta-tomcat-4.0/build/conf
>  [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-4.0/build/lib
>  [copy] Copying 4 files to 
>/home/rubys/jakarta/jakarta-tomcat-4.0/build/common/lib
>  [copy] Copying 3 files to 
>/home/rubys/jakarta/jakarta-tomcat-4.0/build/server/lib
> 
> deploy-main:
>   [jar] Building jar: 
>/home/rubys/jakarta/jakarta-tomcat-4.0/build/server/lib/catalina.jar
>   [jar] Building jar: 
>/home/rubys/jakarta/jakarta-tomcat-4.0/build/server/lib/warp.jar
> 
> deploy:
>  [echo] Target: Jasper - Deploy...
> 
> build-prepare:
> [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/jasper/build
> [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/jasper/build/bin
> [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/jasper/build/classes
> [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/jasper/build/lib
> 
> copy-jaxp-jar:
>  [copy] Copying 1 file to /home/rubys/jakarta/jakarta

Re: [GUMP] Build Failure - Tomcat 4.0

[Sam Ruby]

Craig R. McClanahan
>
> Tomcat 4 has just added a new dependency on jakarta-site2 (for the doc
> templates).  Specifically, it needs a "site2.home" property in the
> build.properties file containing the pathname to this directory.

Already fixed, see below.  ;-)

- Sam Ruby

P.S.  You might consider updating build.properties.sample?



rubys   01/07/28 04:54:35

  Modified:proposal/gump/project jakarta-tomcat-40.xml
  Log:
  Tomcat 4.0 now uses XSLT and jakarta-site2 to produce its site

  Revision  ChangesPath
  1.10  +3 -0
jakarta-alexandria/proposal/gump/project/jakarta-tomcat-40.xml

  Index: jakarta-tomcat-40.xml
  ===
  RCS file:
/home/cvs/jakarta-alexandria/proposal/gump/project/jakarta-tomcat-40.xml,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- jakarta-tomcat-40.xml   2001/06/16 16:20:51  1.9
  +++ jakarta-tomcat-40.xml   2001/07/28 11:54:35  1.10
  @@ -26,6 +26,8 @@

   

  +
  +
   
   

 
  +  
 
 
 




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

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/appdev - New directory

[craigmcc]

craigmcc01/07/28 08:55:06

  jakarta-tomcat-4.0/webapps/tomcat-docs/appdev - New directory

Re: Apache 1.3.20 hangs when warp-connecting to Tomcat4b6

[Pier P. Fumagalli]

Eryq at [EMAIL PROTECTED] wrote:

> webapp-module-1.0-tc40b6
> SunOS clin5 5.8 Generic_108528-07 sun4u sparc SUNW,Ultra-60
> Apache 1.3.20
> gcc 2.95.2
> --
> 
> My apache works great; I load mod_webapp,
> and I even get the "info" page.
> 
> My standalone Tomcat4 works great, serving
> WebAppInfo my webapp and its files.
> 
> But when I add in a directive to WebAppDeploy
> a webapp in my httpd.conf, apache starts but then
> hangs forever on a request. No log file entries
> are made.
> 
> Also, libhttpd.ep keeps leaving little core files
> around.  That seems bad.
> 
> I'm using "localhost" as the ServerName in both
> httpd.conf and server.xml.
> 
> Ideas?  TIA,

Can you upgrade to the last CVS version? Thanks to Brian P. Millet we fixed
a lot of bugs on SunOS 5.8 since B6.

Pier

Non-graceful shutdown a problem? (3.2.3)

[Ken Grigg]

I am running Tomcat 3.2.3 on NT/IIS with the Jikes compiler,
and noticed if the server is reset (i.e. power glitch) without
a normal shutdown, Tomcat comes back up non-operational. The
symptoms are that the JSPs can't be accessed until the class
files from the previous run are deleted from the work directory.

The log I get is:
2001-07-26 11:33:06 - Ctx( /admin ): JasperException: R( /admin +
/contextAdmin/contextAdmin.jsp + null) Unable to compile class for JSP

The beginning of the root cause trace is:
java.lang.ArrayIndexOutOfBoundsException
at
org.apache.jasper.compiler.ClassName.processClassData(ClassName.java:89)
at
org.apache.jasper.compiler.ClassName.getClassName(ClassName.java:191)
at
org.apache.jasper.compiler.JspCompiler.getRealClassName(JspCompiler.java:136
)

I was concerned it might be something to do with Jikes, but
there is no problem when I manually recompile the .java source
that Tomcat creates but can't compile.

I can fix this with a startup script that deletes the class
files, but I assume if this is a real problem someone would
have logged it at least (and I don't like patchy solutions!)

I couldn't find any discussion on this problem in the archives
or the web, except for the possibly related discussion at:

http://www.javaclue.org/tomcat/patch32b6/letspatch.html#step5

I was surprised to see that this patch (against 3.2.1) hadn't
been applied to 3.2.3, but it didn't work for me anyway.

Does any have any ideas?

...Ken.
---
Ken Grigg
AmikaNow! Corporation
mailto:[EMAIL PROTECTED]

Issue/bug with jasper Mangler in tomcat33

[Angel Aray]

Jasper currently uses the name of the folder where a jsp is found to
compute the package name for the java class to be generated, this
raises some issues when the folder"s name is not a valid java identifier
i.e it start with some digits.

So, if for example we have a  /4you/code.jsp jasper will generate some
java containing a line like "package 4you.code_1.java;" which would fail
to compile.

This issue is present in tomcat33b1 but not on tomcat-3.2.3 or tomcat40b6

Regards,
Angel Aray.

RE: Issue/bug with jasper Mangler in tomcat33

[Ignacio J. Ortega]

Hola Angel:

Please File a bug with this report at
 using this link
 

Thanks for the feedback..

Saludos ,
Ignacio J. Ortega


> -Mensaje original-
> De: Angel Aray [mailto:[EMAIL PROTECTED]]
> Enviado el: sábado 28 de julio de 2001 2:49
> Para: [EMAIL PROTECTED]
> Asunto: Issue/bug with jasper Mangler in tomcat33
> 
> 
> 
> Jasper currently uses the name of the folder where a jsp is found to
> compute the package name for the java class to be generated, this
> raises some issues when the folder"s name is not a valid java 
> identifier
> i.e it start with some digits.
> 
> So, if for example we have a  /4you/code.jsp jasper will generate some
> java containing a line like "package 4you.code_1.java;" which 
> would fail
> to compile.
> 
> This issue is present in tomcat33b1 but not on tomcat-3.2.3 
> or tomcat40b6
> 
> Regards,
>   Angel Aray.
> 

Re: [FAQ] jGuru FAQ Update

[guru]

As I said in my original post, I had it daily for a few days so I
could work out the kinks.  It's weekly now (and has been for over a
week).  Sorry for the confusion.

 - A

On Sat, Jul 21, 2001 at 01:40:26AM +0100, Pier P. Fumagalli wrote:
> [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote:
> 
> > Sure, it could, but (a) I don't think one message a week will be
> > enough traffic to bother anyone, and (b) sometimes developer-related
> > FAQs show up on the Tomcat list.
> 
> It's pretty cool, but check your scripts, as it's coming once a day, not
> once a week...
> 
> Pier (again on the floor laughing for that MTV ad: gotta MPG it)

-- 
Alex Chaffee   mailto:[EMAIL PROTECTED]
jGuru - Java News and FAQs http://www.jguru.com/alex/
Creator of Gamelan http://www.gamelan.com/
Founder of Purple Technology   http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/

build mod_jk.so on aix4.3

[Vibanu]

 problem on aix4.3.3, apache  1.3 and tomcat 3.2  I will really appreciate if 
anyone could help...

I issued the following command:

make -f Makefile.linux mod_jk.so

and it ended with the following error:
.. something
.. something
..
..
"../jk/jk_uri_worker_map.c", line 62.65: 1506-342 (W) "/*" detected in 
comment.
"../jk/jk_uri_worker_map.c", line 242.77: 1506-342 (W) "/*" detected in 
comment.
"../jk/jk_uri_worker_map.c", line 243.44: 1506-342 (W) "/*" detected in 
comment.
ld -H512 -T512 -bhalt:4 -bM:SRE -bnoentry 
-bl:/usr/local/apache/libexec/httpd.exp -lc -o mod_jk.so jk_uri_worker_map.o 
jk_map.o jk_sockbuf.o jk_lb_worker.o jk_ajp13_worker.o jk_worker.o jk_pool.o 
jk_jni_worker.o jk_ajp13.o jk_util.o jk_msg_buff.o jk_connect.o 
jk_ajp12_worker.o mod_jk.o 
id:0711-244 ERROR: NO CSECTS OR EXPORTED SYMBOLS HAVE BEEN SAVED.
APXS:BREAK: COMMAND FAILED WITH RC=8
MAKE: 1254-004 THE ERROR CODE FROM THE LAST COMMAND IS 1.

STOP.


.

cvs commit: jakarta-tomcat-4.0 build.xml

[craigmcc]

craigmcc01/07/28 15:47:10

  Modified:.build.xml
  Log:
  Remove "dist" dependency on "tomcat-docs" for now, until we stabilize the
  documentation production process.  If you want to create this web app,
  execute "ant tomcat-docs" explicitly.
  
  Revision  ChangesPath
  1.33  +4 -1  jakarta-tomcat-4.0/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/build.xml,v
  retrieving revision 1.32
  retrieving revision 1.33
  diff -u -r1.32 -r1.33
  --- build.xml 2001/07/28 01:35:38 1.32
  +++ build.xml 2001/07/28 22:47:10 1.33
  @@ -166,7 +166,10 @@
   
   
 
  -  
  +
  +  
   

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs build.xml

[craigmcc]

craigmcc01/07/28 15:47:42

  Modified:webapps/tomcat-docs build.xml
  Log:
  Update the tomcat-docs build procedure to copy the relevant Javadocs
  directories.
  
  Revision  ChangesPath
  1.2   +41 -0 jakarta-tomcat-4.0/webapps/tomcat-docs/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/build.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- build.xml 2001/07/28 01:35:39 1.1
  +++ build.xml 2001/07/28 22:47:42 1.2
  @@ -45,12 +45,40 @@
 
   
   
  +
  +
  +  
  +
  +
  +  
  +
  +
  +
  +
  +
  +
  +  
  +
  +
   
   
   
 
   
   
  +
  +
  +
  +  
  +
  +
  +
  +
  +
  +  
  +
  +
   
   
   
  @@ -72,6 +100,9 @@
 
 
   
  +
  +  
  +
   
   
   
  +  
  +
  +
  +
  +
 
   
  
  
  

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/appdev/sample - New directory

[craigmcc]

craigmcc01/07/28 15:49:55

  jakarta-tomcat-4.0/webapps/tomcat-docs/appdev/sample - New directory

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/appdev/sample/docs - New directory

[craigmcc]

craigmcc01/07/28 15:50:08

  jakarta-tomcat-4.0/webapps/tomcat-docs/appdev/sample/docs - New directory

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/appdev/sample/src - New directory

[craigmcc]

craigmcc01/07/28 15:50:08

  jakarta-tomcat-4.0/webapps/tomcat-docs/appdev/sample/src - New directory

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/appdev/sample/web - New directory

[craigmcc]

craigmcc01/07/28 15:50:08

  jakarta-tomcat-4.0/webapps/tomcat-docs/appdev/sample/web - New directory

RE: Sources in Binary Distributions

[Rob S.]

> For Tomcat 4, what do folks think of omitting the sources from the binary
> distribution?  This would knock the size of the binary distributions down
> by around 2 megabytes (which I'm sure people would also appreciate).

...exactly why I emailed about it in the first place =)  I have an old
laptop with a paltry 2GB HD and with Windows, every OUNCE of space I can
free up is worth it.  Also, I think 3.x still includes them and I'm kind of
surprised to see "src" in there.  Whenever I want to see src, I always go to
web cvs anyways.

I think it's good to have the source for the version you're running if you
ever need to snoop around, but we could save the world some bandwidth and
time for the very few instances this occurs =)

- r

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/appdev/sample/web/images - New directory

[craigmcc]

craigmcc01/07/28 15:51:51

  jakarta-tomcat-4.0/webapps/tomcat-docs/appdev/sample/web/images - New directory

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/appdev/sample/web/WEB-INF - New directory

[craigmcc]

craigmcc01/07/28 15:52:04

  jakarta-tomcat-4.0/webapps/tomcat-docs/appdev/sample/web/WEB-INF - New directory

Re: [GUMP] Build Failure - Tomcat 4.0

[Craig R. McClanahan]

On Sat, 28 Jul 2001, Sam Ruby wrote:

> Craig R. McClanahan
> >
> > Tomcat 4 has just added a new dependency on jakarta-site2 (for the doc
> > templates).  Specifically, it needs a "site2.home" property in the
> > build.properties file containing the pathname to this directory.
> 
> Already fixed, see below.  ;-)
> 
> - Sam Ruby
> 
> P.S.  You might consider updating build.properties.sample?
> 

For the moment, the default Tomcat 4 build targets do *not* build the
"tomcat-docs" web app, so they don't have to worry about this
dependency.  We need to settle on the documentation generation technology,
and it's not clear that the stylesheets (either Anakia's or XSLT's) in the
"jakarta-site2" repository make a very good starting point.

In the mean time, if you have a "site2.home" property defined, you can run
"ant tomcat-docs" from the top-level directory to create this webapp.

Craig

RE: [DOC] TC4 xdocs

[Rob S.]

> the same look and feel.  Additions to the overall stylesheet are welcomed,
> and can be discussed on the GENERAL@ mailing list (since they would affect
> all projects that use this).

As well, for the sake of time I should *probably* be spending it on actual
documentation rather than dicussing fonts and colours on the -general list
=)

> Also, I'm about 95% done with an XSLT stylesheet that behaves equivalent
> to the current site.vsl macros -- for those of us (like me) who prefer to

Either way works for me.  I used to hax0r quite a bit of XSL and it was a
pain to get the hang of.  Then there's VTL... either way, the doc authors
shouldn't have to worry about it and can just stick to the xhtml-ish
examples in there, right?  Should we agree on a set of standard tags (e.g.
the ones Alex suggested) so we can keep/start working?

- r

cvs commit: jakarta-tomcat-4.0/webapps/examples/jsp/security/protected index.jsp

[craigmcc]

craigmcc01/07/28 16:29:12

  Modified:webapps/examples/jsp/security/protected index.jsp
  Log:
  Add an option so that the user can request a logoff (which, with form
  based login configured, should cause a new session to be created and the
  user returned to the login page).
  
  Revision  ChangesPath
  1.4   +14 -1 
jakarta-tomcat-4.0/webapps/examples/jsp/security/protected/index.jsp
  
  Index: index.jsp
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/webapps/examples/jsp/security/protected/index.jsp,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- index.jsp 2001/07/26 19:42:44 1.3
  +++ index.jsp 2001/07/28 23:29:12 1.4
  @@ -1,10 +1,18 @@
  +<%
  +  if (request.getParameter("logoff") != null) {
  +session.invalidate();
  +response.sendRedirect("index.jsp");
  +return;
  +  }
  +%>
   
   
   Protected Page for Examples
   
   
   
  -You are logged in as remote user <%= request.getRemoteUser() %>
  +You are logged in as remote user <%= request.getRemoteUser() %>
  +in session <%= session.getId() %>
   
   <%
 if (request.getUserPrincipal() != null) {
  @@ -41,6 +49,11 @@
   
   
   
  +
  +
  +If you have configured this app for form-based authentication, you can log
  +off by clicking here.  This should cause
  +you to be returned to the logon page after the redirect that is performed.
   
   
   
  
  
  

cvs commit: jakarta-tomcat/bin servlet23.jar

[costin]

costin  01/07/28 17:37:46

  Removed: bin  servlet23.jar
  Log:
  Removed old 2.3 binary.

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config ServerXmlReader.java

[costin]

costin  01/07/28 17:43:28

  Modified:src/share/org/apache/tomcat/modules/config
ServerXmlReader.java
  Log:
  Fix for the fix.
  
  The original fix allowed modules to be defined in server.xml ( or equivalent ).
  If the modules are loaded from modules.xml, the loader will automatically
  add the new rules.
  If the cached properties files are used - we need to add the rules explicitely.
  
  The "modules" note is also used by ContextXmlReader, to avoid parsing the
  same file multiple times.
  
  Revision  ChangesPath
  1.16  +2 -1  
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ServerXmlReader.java
  
  Index: ServerXmlReader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ServerXmlReader.java,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- ServerXmlReader.java  2001/07/28 03:09:32 1.15
  +++ ServerXmlReader.java  2001/07/29 00:43:28 1.16
  @@ -129,7 +129,7 @@
setPropertiesRules( cm, xh );
setTagRules( xh );
addDefaultTags(cm, xh);
  - addTagRules( cm, xh );
  + //addTagRules( cm, xh );
setBackward( xh );
   
// load the config file(s)
  @@ -284,6 +284,7 @@
cachedM.lastModified() > f.lastModified() ) {
// XXX check the other modules-foo.xml
loadCachedModules(cachedM, modules );
  + addTagRules( cm, xh );
return;
} else {
loadConfigFile( xh, f, cm );
  
  
  

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config TrustedLoader.java

[costin]

costin  01/07/28 17:45:53

  Modified:src/share/org/apache/tomcat/modules/config
TrustedLoader.java
  Log:
  One more fix in trusted loader: when the server is initializing we
  create the modules from trusted apps. This allows modules to have access to
  addContext callbacks and fix the classpaths.
  
  When the server is stable it'll start adding/initializing modules. We
  remove all previously loaded interceptors, the same as for a reload.
  
  Note that reloading for modules is mostly untested, it'll be provided by a
  standalone module, we want only the basic functionality in the core set of
  modules.
  
  Revision  ChangesPath
  1.3   +57 -2 
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/TrustedLoader.java
  
  Index: TrustedLoader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/TrustedLoader.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- TrustedLoader.java2001/07/27 04:03:29 1.2
  +++ TrustedLoader.java2001/07/29 00:45:53 1.3
  @@ -88,6 +88,8 @@
   //  Properties 
   
   //  Hooks 
  +Vector allModules=new Vector();
  +
   /** Called when the server is configured - all base modules are added,
some contexts are added ( explicitely or by AutoDeploy/AutoAdd ).
No addContext callback has been called.
  @@ -104,7 +106,6 @@
throws TomcatException
   {
if( state!=ContextManager.STATE_CONFIG ) return;
  - Vector modV=new Vector();
   
Enumeration ctxsE= cm.getContexts();
while( ctxsE.hasMoreElements() ) {
  @@ -131,19 +132,73 @@
loaderHelper.addContext( cm, context );
loaderHelper.contextInit( context );
   
  - modV=new Vector();
  + Vector modV=new Vector();
loadInterceptors( context, modules, modV );
cm.setNote( "trustedLoader.currentContext", context );
  +
// Now add all modules to cm
for( int i=0; i< modV.size(); i++ ) {
BaseInterceptor bi=(BaseInterceptor)modV.elementAt( i );
cm.addInterceptor( bi );
  + allModules.addElement( bi );
}   
cm.setNote(  "trustedLoader.currentContext", null );
  + context.setClassLoader( null );
  + }
  +}
  +
  +
  +public void contextInit( Context ctx )
  + throws TomcatException
  +{
  + // like a reload, the modules will be removed and added back
  + if( ! ctx.isTrusted() ) return;
  +
  + File modules=getModuleFile( ctx );
  + if( modules==null ) return;
  +
  + reInitModules( ctx, modules );
  +}
  +
  +private  void reInitModules( Context ctx, File modules )
  + throws TomcatException
  +{
  + // remove modules
  + for( int i=0; i< allModules.size(); i++ ) {
  + BaseInterceptor bi=(BaseInterceptor)allModules.elementAt( i );
  + cm.removeInterceptor( bi );
}
  + 
   
  + // The real loader is set. 
  + Vector modV=new Vector();
  + loadInterceptors( ctx, modules, modV );
  + cm.setNote( "trustedLoader.currentContext", ctx );
  +
  + // Now add all modules to cm
  + for( int i=0; i< modV.size(); i++ ) {
  + BaseInterceptor bi=(BaseInterceptor)modV.elementAt( i );
  + cm.addInterceptor( bi );
  + }   
  + cm.setNote(  "trustedLoader.currentContext", null );
   }
   
  +/** Again, remove and add back
  + */
  +public void reload( Request req, Context context) throws TomcatException {
  + if( ! context.isTrusted() ) return;
  +
  + File modules=getModuleFile( context );
  + if( modules==null ) return;
  +
  + if( debug > 0 )
  + log( "Reload modules " + context.getPath() );
  +
  + reInitModules( context , modules);
  +}
  +
  +
  +
   public void loadInterceptors( Context ctx, File modulesF, Vector modulesV )
throws TomcatException
   {
  
  
  

RE: Funny thought about version numbering...

[Deacon Marcus]

Hi,

> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
>
>
> On Sat, 28 Jul 2001, Deacon Marcus wrote:
>
> > Hi,
> > I'm using (very ligthly) modified Tomcat 4.0 b5 for almost as
> long as it was
> > out (b3 before, but I'm not sure), and found it rock-stable so
> far, not a
> > single failure on neither development or deployment servers.
> While there're
> > much features I would like Tomcat to have, what's already in is
> perfectly
> > stable for me. So why have 6th beta in a row, instead of
> declaring b5 final
> > and naming b6 4.1? That would definitely encourage more people to use it
> > instead of out-dated 3.2/3.3. Hell, I have now Tomcat _beta_ running for
> > about a month now (on RedHat 7.1, if you want to know), while my Windows
> > _final_ with every possible service pack and security patches
> crashes about
> > every 4 hours on average. I love you guys :) If such
> programmers would work
> > in M$ since its begging we would had (stable) Windows XP in 1985-1990.
> >
>
> The main reason for not going final, IMHO, has been the fact that the
> underlying specifications (Servlet 2.3, JSP 1.2) are not final.  Indeed,
> I'm going to be spending time this weekend implementing a fairly recent
> clarification to the servlet spec's handling of "single sign on".  It
> doesn't make much sense to create a final release that claims conformance
> to specifications that are not themselves final yet.
>
> We're down to weeks now ... I personally consider Tomcat 4.0 to be in
> maintenance mode (with a need to improve the documentation that there are
> already volunteers working on, and continued work on the web connectors
> which are vital to many users).  We'll open a way to begin development for
> 4.1 shortly.

Great news. But what exactly is shortly ? Weeks ? 2-3 months ?

>
> > Greetings, deacon Marcus
> >
> >
>
> Craig
>
> PS:  I hear you about Linux :-).  A while back, I had the pleasure of
> running an "uptime" command on a server (running Apache+JServ+other
> stuff) that had been up for over a *year* with no reboots.  We finally had
> to take it down because the ISP was remodelling their facility.  And
> RedHat Linux 7.1 is my personal primary development environment for both
> Tomcat and Struts.

Personally I could _think_ about using Linux for development, for me it's
(current versions - I agree it's changing slowly) a synonym of user-bashing
and masochism, but whatever to say about it's lack of user-friendliness and
comercial-quality docs, it's rock stable compared to every single version of
Windows from 3.11 to XP Server. Once I tried Linux for the first time for
deployment, I couldn't think of using Win32 for deployment servers again.
Probably once I learn how to do on Linux every thing I do on Win32 I'll
switch to it entirely (except for my gaming machine ;) ), but there's a long
way ahead for me ;/ .

>
> PPS:  What modifications to Tomcat 4.0-beta-5 did you find
> necessary?  Anything that would be useful to the general community?

I believe I posted it here, but I don't think it made it's way to CVS. It
was a dirty patch to StandardHost allowing v-host aliases in form of
'name="company.com : www.company.com , company.co.uk"', I wrote it days
before I commited another patch concerning this problem and it turned out
there's also missing stuff in xml-configurator, which I was unable to crack
since I exclusively use JDOM for XML.
Are aliases working finally in b6 ? If they are, I could just del my patch
and download b6, but I'm a bit behind the schedule and don't have the time
to check it myself.

I'm also working on making next "context" in Tomcat allowing binding objects
to all loaded web-apps at once - clear specification violation, so I don't
think it's something to share ;) , besides, it's early beta and I'm
evalutaing another options for attaining the goals it was meant to solve.

Greetings, deacon Marcus

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session StandardSession.java

[craigmcc]

craigmcc01/07/28 20:43:54

  Modified:catalina/src/share/org/apache/catalina HttpRequest.java
Session.java
   catalina/src/share/org/apache/catalina/authenticator
AuthenticatorBase.java FormAuthenticator.java
SingleSignOn.java
   catalina/src/share/org/apache/catalina/connector
HttpRequestBase.java
   catalina/src/share/org/apache/catalina/core
ContainerBase.java
   catalina/src/share/org/apache/catalina/session
StandardSession.java
  Added:   catalina/src/share/org/apache/catalina SessionEvent.java
SessionListener.java
  Log:
  Enhance support for "single sign on" to also support "single sign off" in
  conformance to the additional spec requirements listed in Servlet Spec 2.3
  PFD3, Section 12.5.3.1, page 90.  In particular, under the following
  circumstances:
  
  - Administrator has configured SingleSignOnValve on a virtual host
  
  - Web applications on this virtual host are configured for form-based
login
  
  - User has logged in to one of the apps (which also grants them access
to the protected areas of the other apps, because of the single sign
on support)
  
  - A session in one of the logged-on-to apps is invalidated or times out
  
  then, all sessions in all apps to which the user has been logged on will
  be invalidated.  The next request from this user for a protected resource
  in any of the apps will cause the user to be reauthenticated.
  
  Rationale:  Consider a Yahoo-like portal server, with multiple
  applications (such as mail and chat) implemented as separate web apps
  under management of the single sign on facility.  If the user accesses
  both mail and chat, and then logs out of mail, he or she will expect the
  login to the chat application to be terminated as well.  Otherwise, the
  next person to use this browser (say, at an Internet cafe) would have
  access to the previous user's session in the chat application -- and, by
  virtue of single sign on, access to all their other applications as well.
  
  Revision  ChangesPath
  1.3   +18 -4 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/HttpRequest.java
  
  Index: HttpRequest.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/HttpRequest.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- HttpRequest.java  2000/09/25 21:46:30 1.2
  +++ HttpRequest.java  2001/07/29 03:43:54 1.3
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/HttpRequest.java,v 
1.2 2000/09/25 21:46:30 craigmcc Exp $
  - * $Revision: 1.2 $
  - * $Date: 2000/09/25 21:46:30 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/HttpRequest.java,v 
1.3 2001/07/29 03:43:54 craigmcc Exp $
  + * $Revision: 1.3 $
  + * $Date: 2001/07/29 03:43:54 $
*
* 
*
  @@ -76,7 +76,7 @@
* produce the corresponding HttpResponse.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.2 $ $Date: 2000/09/25 21:46:30 $
  + * @version $Revision: 1.3 $ $Date: 2001/07/29 03:43:54 $
*/
   
   public interface HttpRequest extends Request {
  @@ -147,6 +147,12 @@
   
   
   /**
  + * Return the single sign on identifier this request is associated with.
  + */
  +public String getSsoId();
  +
  +
  +/**
* Set the authentication type used for this request, if any; otherwise
* set the type to null.  Typical values are "BASIC",
* "DIGEST", or "SSL".
  @@ -239,6 +245,14 @@
* @param path The servlet path
*/
   public void setServletPath(String path);
  +
  +
  +/**
  + * Set the single sign on identifier this request is associated with.
  + *
  + * @param ssoId The new SSO identifier (if any)
  + */
  +public void setSsoId(String ssoId);
   
   
   /**
  
  
  
  1.4   +32 -5 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Session.java
  
  Index: Session.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Session.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- Session.java  2001/04/08 07:55:46 1.3
  +++ Session.java  2001/07/29 03:43:54 1.4
  @@ -1,13 +1,13 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Session.java,v 1.3 
2001/04/08 07:55:46 kief Exp $
  - * $Revision: 1.3 $
  - * $Date: 2001/04/08 07:55:46 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina

Re: Funny thought about version numbering...

[Pier P. Fumagalli]

Deacon Marcus at [EMAIL PROTECTED] wrote:
> 
>> We're down to weeks now ... I personally consider Tomcat 4.0 to be in
>> maintenance mode (with a need to improve the documentation that there are
>> already volunteers working on, and continued work on the web connectors
>> which are vital to many users).  We'll open a way to begin development for
>> 4.1 shortly.
> 
> Great news. But what exactly is shortly ? Weeks ? 2-3 months ?

Let's get 4.0 out of the door, before starting to scream at 4.1 :) And I
believe neither Craig neither anyone else in particular can say "let's make
a 4.1"... Should be a community decision, let's throw stuff on a table and
see what we come out :)

Pier

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup ContextConfig.java

[craigmcc]

craigmcc01/07/28 21:34:17

  Modified:catalina/src/share/org/apache/catalina Context.java
   catalina/src/share/org/apache/catalina/core
StandardContext.java StandardHost.java
   catalina/src/share/org/apache/catalina/startup
ContextConfig.java
  Log:
  Correct handling of web application startup so that parsing errors in the
  web.xml file cause the application to be marked unavailable.  Previously,
  the application was started anyway, which could cause security issues (for
  example, confidential information might be visible because of an incorrect
  security constraint definition that was therefore not installed at all).
  
  PR: Bugzilla #2870
  Submitted by: Remy Maucherat <[EMAIL PROTECTED]>
  
  Revision  ChangesPath
  1.17  +20 -4 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Context.java
  
  Index: Context.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Context.java,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- Context.java  2001/04/05 19:30:39 1.16
  +++ Context.java  2001/07/29 04:34:17 1.17
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Context.java,v 
1.16 2001/04/05 19:30:39 craigmcc Exp $
  - * $Revision: 1.16 $
  - * $Date: 2001/04/05 19:30:39 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Context.java,v 
1.17 2001/07/29 04:34:17 craigmcc Exp $
  + * $Revision: 1.17 $
  + * $Date: 2001/07/29 04:34:17 $
*
* 
*
  @@ -96,7 +96,7 @@
* 
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.16 $ $Date: 2001/04/05 19:30:39 $
  + * @version $Revision: 1.17 $ $Date: 2001/07/29 04:34:17 $
*/
   
   public interface Context extends Container {
  @@ -152,6 +152,22 @@
* @param mapper The new mapper
*/
   public void setCharsetMapper(CharsetMapper mapper);
  +
  +
  +/**
  + * Return the "correctly configured" flag for this Context.
  + */
  +public boolean getConfigured();
  +
  +
  +/**
  + * Set the "correctly configured" flag for this Context.  This can be
  + * set to false by startup listeners that detect a fatal configuration
  + * error to avoid the application from being made available.
  + *
  + * @param configured The new correctly configured flag
  + */
  +public void setConfigured(boolean configured);
   
   
   /**
  
  
  
  1.73  +49 -8 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java
  
  Index: StandardContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
  retrieving revision 1.72
  retrieving revision 1.73
  diff -u -r1.72 -r1.73
  --- StandardContext.java  2001/07/26 00:15:58 1.72
  +++ StandardContext.java  2001/07/29 04:34:17 1.73
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
 1.72 2001/07/26 00:15:58 remm Exp $
  - * $Revision: 1.72 $
  - * $Date: 2001/07/26 00:15:58 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
 1.73 2001/07/29 04:34:17 craigmcc Exp $
  + * $Revision: 1.73 $
  + * $Date: 2001/07/29 04:34:17 $
*
* 
*
  @@ -142,7 +142,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.72 $ $Date: 2001/07/26 00:15:58 $
  + * @version $Revision: 1.73 $ $Date: 2001/07/29 04:34:17 $
*/
   
   public class StandardContext
  @@ -208,6 +208,12 @@
   
   
   /**
  + * The "correctly configured" flag for this Context.
  + */
  +private boolean configured = false;
  +
  +
  +/**
* The security constraints for this web application.
*/
   private SecurityConstraint constraints[] = new SecurityConstraint[0];
  @@ -626,6 +632,34 @@
   
   
   /**
  + * Return the "correctly configured" flag for this Context.
  + */
  +public boolean getConfigured() {
  +
  +return (this.configured);
  +
  +}
  +
  +
  +/**
  + * Set the "correctly configured" flag for this Context.  This can be
  + * set to false by startup listeners that detect a fatal configuration
  + * error to avoid the application from being made available.
  + *
  + * @param configured The new correctly configured flag
  + */
  +public void setConfigured(boolean configured) {
  +
  +boolean oldConfigured = this.conf