WebDAV interoperability report

[Remy Maucherat]

Hi,

I've been attending a WebDAV interoperability event today. There was a lot
of people, and it was very interesting.
The results for the Tomcat 4 WebDAV servlet were relatively bad. Apparently
there has been a few areas where there has been some regressions, but it
resulted in quite a number of failures (and of course I was so confident in
the robustness of my code that I didn't even bother to make a special debug
build ;-) OTOH, the code which *did* have some debug didn't break nearly as
much).

I filed the problems I've found in Bugzilla.

Tomcat 4.0 interoperated well in the HTTP area with the HTTP/1.1 connector.

I have a proposal to make regarding all these interop issues, but that will
have to wait for another mail.

Remy

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core ContextManager.java

[larryi]

larryi  01/07/20 21:04:46

  Modified:src/share/org/apache/tomcat/core ContextManager.java
  Log:
  Set version to "Beta 1"
  
  Revision  ChangesPath
  1.185 +1 -1  
jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java
  
  Index: ContextManager.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java,v
  retrieving revision 1.184
  retrieving revision 1.185
  diff -u -r1.184 -r1.185
  --- ContextManager.java   2001/07/19 05:55:30 1.184
  +++ ContextManager.java   2001/07/21 04:04:46 1.185
  @@ -148,7 +148,7 @@
   public final class ContextManager {
   /** Official name and version
*/
  -public static final String TOMCAT_VERSION = "3.3 Milestone 4";
  +public static final String TOMCAT_VERSION = "3.3 Beta 1";
   public static final String TOMCAT_NAME = "Tomcat Web Server";
   
   /** System property used to set the base directory ( tomcat home ).
  
  
  

Re: Compiler API Features [Was: sun.tools.javac.Main will beremovedfrom JDK1.4}

[Pier P. Fumagalli]

Glenn Nielsen at [EMAIL PROTECTED] wrote:
> 
> Hmm.  I wonder how much optimization is needed in the generated byte code for
> something that will get profiled and optimized to native opcodes by HotSpot
> server.  Of course things other than Jasper, like Ant, might want to use it
> with a great deal of optimization.  Inclusion/use of the optimization should
> be optional.  I would rather have a small footprint fast JSP java source
> compile and let HotSpot server do the profiling and optimization.

Now, I didn't believe it myself until I got the proof, but, IT SEEMS, that
with HotSpot interpreting something like JSPs is actually FASTER than
compiling them...

It was applied to an XSP derivate by some Italian weirdos, and maybe Gianugo
can enlighten us on what he found out... Gianugo?

Pier

Re: Compiler API Features [Was: sun.tools.javac.Main will beremoved from JDK1.4}

[Pier P. Fumagalli]

Craig R. McClanahan at [EMAIL PROTECTED] wrote:
> 
> As an absolute minimum, Jasper doesn't need much -- just a way to invoke
> the compiler in a multi-threaded server environment without multiple
> instances clashing with each other.  Even external processes work, albeit
> much more slowly than one would like.

Creating processes is _always_ a pain...

> I'm interested in accumulating a list of nicer features that we'd like to
> see in a compiler API.  Here's some of my initial thoughts:
> 
> - Small, fast, lightweight, but generates good (optimized)
> bytecodes.  (Who says goals can't conflict with each other?  :-).

Well, jikes is not big, but how's the bytecode it generates? Dunno myself.

> - Full support for all the features currently in, and about to be
> added to, the Java Language Specification (i.e. assertions and
> generics as soon as possible).

Jikes doesn't have a good past on this... Remember nesting classes in
classes when JDK 1.2 came out? It was broken/unsupported for almost 1 year.

> - Written in Java (and so embeddable in the Tomcat JVM) or accessible
> easily and reliably via JNI on lots of platforms.

At least Jikes is portable :)

> - Published, stable, and supported invocation API.

The C++ API is very nice in Jikes. Don't know how much stable (as I don't
have comparisons available) but definitely good.

Regarding this, javax.compiler could be a reality pretty soon, soo...
And maybe Jikes could be embedded in that API... (Seen a couple of proposals
- public ones - from Neal and the NetBeans guys, with a bunch of other
people)

> - Packaged in such a way that multiple compiles can be initiated
> simultaneously (on different threads) with no conflicts.

Thread-safe :) I don't know, that goes beyond my tonight investigations.

> - Accepts source input from configurable-per-class input stream,
> not just files.
> - Writes the bytecodes of its output to a configurable-per-class
> output stream, not just files.

Jikes does it... (the API is good, I told you!)

> - Accepts its notion of a "class path" for looking up dependencies by
> handing it a class loader, instead of a CLASSPATH-type environment.

That might be a problem, as from loadClass() you can't get back to a
byte[]... I believe you could do something like checking classes as
resources (as URLClassLoader does), but for some really weird class loaders
that could be broken...

> - Generates debugging information usable to map lines of Java code back
> to a non-Java language that the Java code was generated from (i.e.
> the outcome of JSR-045).

That's _TRICKY_, because the mapping is external to the source, so, who
actually generates that source should keep track of
orig.file+orig.line=dest.file+dest.line maps... You always read the source
from an inputStream, and what you're proposing is more like a SAX XML
Handler or something like it :)

> What did I miss?

Should start coffee machine if expected compilation time >= 5 mins.

Pier

Re: Compiler API Features [Was: sun.tools.javac.Main will be removedfrom JDK1.4}

[Glenn Nielsen]

"Craig R. McClanahan" wrote:
> 
> On Fri, 20 Jul 2001, Christopher Cain wrote:
> 
> > [snip] Are we talking a specialized wrapper
> > targetting specifically the stuff required for JSP, or are we talking
> > about a general all-purpose Java wrapper that we could possibly release
> > as a separate tool?
> >
> 
> As an absolute minimum, Jasper doesn't need much -- just a way to invoke
> the compiler in a multi-threaded server environment without multiple
> instances clashing with each other.  Even external processes work, albeit
> much more slowly than one would like.
> 
> I'm interested in accumulating a list of nicer features that we'd like to
> see in a compiler API.  Here's some of my initial thoughts:
> 
> - Small, fast, lightweight, but generates good (optimized)
>   bytecodes.  (Who says goals can't conflict with each other?  :-).
> 

Hmm.  I wonder how much optimization is needed in the generated byte
code for something that will get profiled and optimized to native
opcodes by HotSpot server.  Of course things other than Jasper, like Ant,
might want to use it with a great deal of optimization.  
Inclusion/use of the optimization should be optional.  I would rather
have a small footprint fast JSP java source compile and let HotSpot server do the
profiling and optimization.

> - Full support for all the features currently in, and about to be
>   added to, the Java Language Specification (i.e. assertions and
>   generics as soon as possible).
> 
> - Written in Java (and so embeddable in the Tomcat JVM) or accessible
>   easily and reliably via JNI on lots of platforms.
> 
> - Published, stable, and supported invocation API.
> 
> - Packaged in such a way that multiple compiles can be initiated
>   simultaneously (on different threads) with no conflicts.
> 
> - Accepts source input from configurable-per-class input stream,
>   not just files.
> 
> - Writes the bytecodes of its output to a configurable-per-class
>   output stream, not just files.
> 
> - Accepts its notion of a "class path" for looking up dependencies by
>   handing it a class loader, instead of a CLASSPATH-type environment.
> 
> - Generates debugging information usable to map lines of Java code back
>   to a non-Java language that the Java code was generated from (i.e.
>   the outcome of JSR-045).
> 
> What did I miss?
> 
> Craig McClanahan

That is a very good list of requirements, can't think of any additons.

Glenn
 
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

Re: sun.tools.javac.Main will be removed from JDK1.4

[Pier P. Fumagalli]

Christopher Cain at [EMAIL PROTECTED] wrote:
> 
>> Generic interface, of course :)
> 
> Nice ...

What's the point of doing otherwise?

>> But I didn't say I'm going to do it... :)
> 
> D'oh! Maybe I'll have to send my men into your home again, and maybe
> this time they steal your primary mod_webapp development box ... you
> know, free up a little of your development time. =)

Yeah, then Craig will send a couple of nuclear missiles over Colorado (and
London :)

> [...] Anyway, sorry to hear about your situation. That blows.

Just my Win32/RedHat 7.1 box...

> Seriously, though, based on your knowledge of the codebase, how much
> effort would you estimate it to be? And how hard would you estimate the
> C portion to be (assuming we didn't use JNI or some other Java/C
> abstraction layer)? Would anyone else have the inclination and time to
> have a go at it, too? Where would be the best place for development to
> happen?

I'd say _at_least_ two weeks to come up with a very-very-very rough
implementation (based on what was there last year, and what I can remember).

I just re-downloaded it, and they made even better, check out jikesapi.h and
check out the C++ class JikesAPI... Very well designed, indeed, everything
you need is in there...

FileReader and FileWriter would have to be represented in Java, as well as
something to handle JikesError, but then, it would be fairly done.

The biggest changes would be in jikes.cpp (where everything is created,
basically).

BUT, the problem is then to strengthen it. C is a bitch, takes the same
amount of time to write, and 10 times more to debug it (also, no throw
Exception means a LOT of gdb involved)

To get with something fairly working, I'd give it 1/2 months...

> [...] Finally, a way be a real live MTV "Jackass" without setting myself on
> fire.

Or wrestling a bear :)

Pier

Compiler API Features [Was: sun.tools.javac.Main will be removedfrom JDK1.4}

[Craig R. McClanahan]

On Fri, 20 Jul 2001, Christopher Cain wrote:

> [snip] Are we talking a specialized wrapper
> targetting specifically the stuff required for JSP, or are we talking
> about a general all-purpose Java wrapper that we could possibly release
> as a separate tool?
> 

As an absolute minimum, Jasper doesn't need much -- just a way to invoke
the compiler in a multi-threaded server environment without multiple
instances clashing with each other.  Even external processes work, albeit
much more slowly than one would like.

I'm interested in accumulating a list of nicer features that we'd like to
see in a compiler API.  Here's some of my initial thoughts:

- Small, fast, lightweight, but generates good (optimized)
  bytecodes.  (Who says goals can't conflict with each other?  :-).

- Full support for all the features currently in, and about to be
  added to, the Java Language Specification (i.e. assertions and
  generics as soon as possible).

- Written in Java (and so embeddable in the Tomcat JVM) or accessible
  easily and reliably via JNI on lots of platforms.

- Published, stable, and supported invocation API.

- Packaged in such a way that multiple compiles can be initiated
  simultaneously (on different threads) with no conflicts.

- Accepts source input from configurable-per-class input stream,
  not just files.

- Writes the bytecodes of its output to a configurable-per-class
  output stream, not just files.

- Accepts its notion of a "class path" for looking up dependencies by
  handing it a class loader, instead of a CLASSPATH-type environment.

- Generates debugging information usable to map lines of Java code back
  to a non-Java language that the Java code was generated from (i.e.
  the outcome of JSR-045).

What did I miss?

Craig McClanahan

Re: Problem with mod_jk 1.2.0 (latest CVS snapshot)

[Bojan Smojver]

GOMEZ Henri wrote:
> 
> >Just did a DSO version and couldn't replicate the problem (BTW, I've
> >recompiled/statically linked Apache and mod_jk again since then and the
> >problem was still there). So, maybe it has to do with statically linking
> >Apache after all...
> 
> Strange problem. What's the difference between static and dynamic.
> We may have missed something at mod_jk init time ?

This only happens during a graceful restart. Normal restart is OK. What
does mod_jk do when it receives SIGUSR1? Does it actually do anything?
Maybe that's the problem. Or it could have to do with Apache's behaviour
on SIGUSR1. Something like, if DSO then modules are reloaded and
therefore reinitialised, if static then the configuration file is
re-read and that's it (pure speculative BS, I have no idea what Apache
actually does). I kind of remember that people from mod_ssl were saying
something about Apache init process being a bit strange (something like
two passes) but that I think has to do with startup. Not sure.

> >I still have to distribute this DSO version of Apache and mod_jk to some
> >slower machines to see if that makes any difference at all. The machine
> >that didn't produce any errors is a 1 GHz Athlon, so timing issues could
> >have been resolved by brute force, who knows...
> 
> Thanks to tell us what happened...

Well, once I actually do that I surely will. I don't know if you've been
in the position to run your own business, but I can only 'hack' when
nothing else requires my immediate attention :-(

> >Is there a recommendation as to the order of loading mod_jk for both
> >statically linked version and the DSO version? Maybe that's important.
> 
> I load mod_jk after alias and before rewrite and never get any problems.
> Not I also use php4

Thanks for the tips about module order. I'll see how that affects the
whole thing.

Bojan

Re: sun.tools.javac.Main will be removed from JDK1.4

[Christopher Cain]

"Pier P. Fumagalli" wrote:
> 
> Christopher Cain at [EMAIL PROTECTED] wrote:
> > "Pier P. Fumagalli" wrote:
> >> Craig R. McClanahan at [EMAIL PROTECTED] wrote:
> >>>
> >>> I haven't looked at Jikes, so can't comment on the suitability of any APIs
> >>> it exposes.  Would someone like to look at this and report back?
> >>
> >> Last time I looked at the sources (when I was at IBM, 1+1/2 years ago),
> >> Jikes was not relying on threads, and had a decent code base (it wasn't
> >> printing error messages to stderr, but was mirroring its FILE * in an
> >> internal variable, if I remember it right)...
> >>
> >> If that's the case, it _would_ be possible (probably, but not guaranteed) to
> >> compile it as a library with some hacks and wrap it somehow with a nice
> >> class, with all callbacks we need...
> >>
> >> Should check the code at this point, though...
> >
> > That would be SWEET. I would be willing to help with the Java wrapper
> > part, but since I know just enough C to be dangerous, I wouldn't really
> > be of much help with that aspect. Are we talking a specialized wrapper
> > targetting specifically the stuff required for JSP, or are we talking
> > about a general all-purpose Java wrapper that we could possibly release
> > as a separate tool?
> 
> Generic interface, of course :)

Nice ...

> But I didn't say I'm going to do it... :)

D'oh! Maybe I'll have to send my men into your home again, and maybe
this time they steal your primary mod_webapp development box ... you
know, free up a little of your development time. =)

Just kidding. That really does suck to get your hardware lifted. Some
clowns broke into my townhome a few years ago and made off with a
Windoze box. As luck would have it, my revved-up Linux development box
just happened to be locked in a separate room at the time. I almost
didn't bother calling the police on that one, because I figured that
having Windoze 95 running on Compaq hardware would be punishment enough
for the thieves ... but then I remembered that they were just going to
just sell it for some smack, not actually use it. Anyway, sorry to hear
about your situation. That blows.

Seriously, though, based on your knowledge of the codebase, how much
effort would you estimate it to be? And how hard would you estimate the
C portion to be (assuming we didn't use JNI or some other Java/C
abstraction layer)? Would anyone else have the inclination and time to
have a go at it, too? Where would be the best place for development to
happen?

> >> Pier (ROTFL for the new MTV-ringtones ad)
> >
> > WTF? I must have missed that one. A pop-up web ad, you mean?
> 
> Nope... New ring tones for your cellphone from MTV (only GSM in Europe, and
> the ad is _way_too_funny_)

I've often wondered why I couldn't have played-out bubble-gum rap on my
cell phone. Now I can finally hear "Who Let the Dogs Out" in all its
digital glory!!!

Finally, a way be a real live MTV "Jackass" without setting myself on
fire.

- Christopher

cvs commit: jakarta-tomcat/src/doc JDBCRealm-howto.html

[nacho]

nacho   01/07/20 17:44:25

  Modified:src/doc  JDBCRealm-howto.html
  Log:
  Bug#: 1608
  Inaccuracies in JDBCRealm-howto.html
  
  Reported by pbwest at powerup.com.au (Peter B. West)
  Patch  by pbwest at powerup.com.au (Peter B. West)
  
  Revision  ChangesPath
  1.3   +36 -8 jakarta-tomcat/src/doc/JDBCRealm-howto.html
  
  Index: JDBCRealm-howto.html
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/doc/JDBCRealm-howto.html,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- JDBCRealm-howto.html  2000/09/05 17:57:42 1.2
  +++ JDBCRealm-howto.html  2001/07/21 00:44:25 1.3
  @@ -131,8 +131,7 @@
   
   
   
  -(Optional)
   
   
    
   Done!!
   
   Using digested passwords
  -To use digested password you need to store them digested.
  -To achieve this, you will  need to use the same digest strategies that JDBCrealm 
uses to store the passwords, inside JDBCRealm there is a static method with signature 
final public static String Digest(String password,String algorithm) this 
method is provided as a tool to be used outside JDBCRealm by an application that want 
to store passwords readable by JDBCRealm.
  +
  +
  +  To use digested password you need to store them digested.  To
  +  achieve this, you will need to use the same digest strategies that
  +  JDBCrealm uses to store the passwords. Iinside JDBCRealm there is a
  +  static method with signature final public static String
  +  digest(String password,String algorithm). This method is
  +  provided as a tool to be used outside JDBCRealm by an application
  +  that wants to generate digested passwords readable by JDBCRealm.
  +
  +
  +
  +  The class JDBCRealm contains a main method, so it can be used as an
  +  application to generate digests and print them to stdout.  Usage
  +  is:
  +
  +  java org.apache.tomcat.modules.aaa.JDBCRealm -a
  +   
  +  [ ...]
  +
  +  where  is a supported message digest
  +  algorithm, e.g. MD5, and  is a plaintext
  +  password to be digested.
  +
  +
   Hints
   
  
  - Make sure that the JDBC driver is in the lib directory.
   
   - If you have problem connecting you can specify connectionName and 
connectionPassword
  -$Header: 
/home/cvs/jakarta-tomcat/src/doc/JDBCRealm-howto.html,v 1.2 2000/09/05 17:57:42 nacho 
Exp $
  +$Header: 
/home/cvs/jakarta-tomcat/src/doc/JDBCRealm-howto.html,v 1.3 2001/07/21 00:44:25 nacho 
Exp $
   
   
  -
  \ No newline at end of file
  +
  
  
  

Re: [FAQ] jGuru FAQ Update

[Pier P. Fumagalli]

[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)

[FAQ] jGuru FAQ Update

[Alex Chaffee]

jGuru maintains FAQs and Forums on Servlets, JSP, and Tomcat (as well as
many other Java topics).  Here is an automated update on recent postings to
Tomcat-related FAQs.  Please direct flames and feedback to [EMAIL PROTECTED] .

 - Alex


SPONSORED BY developerWorks

need it? get it. tools, code and tutorials for open-standards based development.

Stay informed with dW's weekly email newsletter
http://www.jguru.com/misc/register_devworks.jsp?src=notify
-

Hi.  You asked to be notified weekly when certain jGuru.com items get new entries.

You can shut email notification off at the FAQ home
page(s) or:

  http://www.jguru.com/guru/notifyprefs.jsp


++ JavaServer Pages (JSP) FAQ: http://www.jguru.com/faq/JSP

How can I use a JSP as an Apache ErrorDocument -- so Apache will display its 
errors using my JSP?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=458488

How do I implement a hit counter in Servlets or JSP?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=456418

Why do I get "java.lang.NoClassDefFoundError: sun/tools/javac/Main" ?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=455768

While forwarding from one page to another by using RequestDispatcher, how do I avoid 
the error " OutputStream is already being used for this request" ?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=455248

What is Ant? Do I need it to run Tomcat?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=455192

++ Servlets FAQ: http://www.jguru.com/faq/Servlets

How can I automatically invoke a servlet at regular time intervals using Resin?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=458416

How do I trap a 404 error inside my servlet if my servlet does a 
RequestDispatcher to a non-existent page ?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=457102

How do I implement a hit counter in Servlets or JSP?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=456418

Why do I get "java.lang.NoClassDefFoundError: sun/tools/javac/Main" ?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=455768

Is there a way in Tomcat to set up zones for servlets like in jserv?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=455766

What is the difference between ServletContext.getInitParameter() and 
HttpServlet.getInitParameter() ?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=455711

How do I prevent users from viewing the contents of my WEB-INF directory?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=455249

While forwarding from one page to another by using RequestDispatcher, how do I avoid 
the error " OutputStream is already being used for this request" ?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=455248

How to allow the client to download and execute a .bat file?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=455219

Can I spawn a background thread from my servlet?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=455215

How can I generate an output in CSV format from a database query?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=455207

What is a session and why is it required?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=455205

How to allow the client to download and execute a .bat or .exe file?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=455202

Why do I sometimes get the error "ODBC Driver Manager ...function Sequence Error"?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=455201

How do I process FDF files created by the Acrobat Forms plug-in?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=455199

++ Tomcat FAQ: http://www.jguru.com/faq/Tomcat

How can I use a JSP as an Apache ErrorDocument -- so Apache will display its 
errors using my JSP?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=458488

Why do I get "java.lang.NoClassDefFoundError: sun/tools/javac/Main" ?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=455768

Is there a way in Tomcat to set up zones for servlets like in jserv?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=455766

How do I upgrade from Tomcat 3 to Tomcat 4?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=455735

Do I need to create my own web.xml file?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=455725

What is the right way to set the JAVA_HOME environment variable on Windows NT?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=455718

How do you pass options such as -Xrs to the JVM when your Tomcat container is running 
in-process within a W

Re: sun.tools.javac.Main will be removed from JDK1.4

[Pier P. Fumagalli]

Christopher Cain at [EMAIL PROTECTED] wrote:
> "Pier P. Fumagalli" wrote:
>> Craig R. McClanahan at [EMAIL PROTECTED] wrote:
>>> 
>>> I haven't looked at Jikes, so can't comment on the suitability of any APIs
>>> it exposes.  Would someone like to look at this and report back?
>> 
>> Last time I looked at the sources (when I was at IBM, 1+1/2 years ago),
>> Jikes was not relying on threads, and had a decent code base (it wasn't
>> printing error messages to stderr, but was mirroring its FILE * in an
>> internal variable, if I remember it right)...
>> 
>> If that's the case, it _would_ be possible (probably, but not guaranteed) to
>> compile it as a library with some hacks and wrap it somehow with a nice
>> class, with all callbacks we need...
>> 
>> Should check the code at this point, though...
> 
> That would be SWEET. I would be willing to help with the Java wrapper
> part, but since I know just enough C to be dangerous, I wouldn't really
> be of much help with that aspect. Are we talking a specialized wrapper
> targetting specifically the stuff required for JSP, or are we talking
> about a general all-purpose Java wrapper that we could possibly release
> as a separate tool?

Generic interface, of course :) But I didn't say I'm going to do it... :)

>> Pier (ROTFL for the new MTV-ringtones ad)
> 
> WTF? I must have missed that one. A pop-up web ad, you mean?

Nope... New ring tones for your cellphone from MTV (only GSM in Europe, and
the ad is _way_too_funny_)

Pier

Re: sun.tools.javac.Main will be removed from JDK1.4

[Christopher Cain]

"Pier P. Fumagalli" wrote:
> 
> Craig R. McClanahan at [EMAIL PROTECTED] wrote:
> >
> > I haven't looked at Jikes, so can't comment on the suitability of any APIs
> > it exposes.  Would someone like to look at this and report back?
> 
> Last time I looked at the sources (when I was at IBM, 1+1/2 years ago),
> Jikes was not relying on threads, and had a decent code base (it wasn't
> printing error messages to stderr, but was mirroring its FILE * in an
> internal variable, if I remember it right)...
> 
> If that's the case, it _would_ be possible (probably, but not guaranteed) to
> compile it as a library with some hacks and wrap it somehow with a nice
> class, with all callbacks we need...
> 
> Should check the code at this point, though...

That would be SWEET. I would be willing to help with the Java wrapper
part, but since I know just enough C to be dangerous, I wouldn't really
be of much help with that aspect. Are we talking a specialized wrapper
targetting specifically the stuff required for JSP, or are we talking
about a general all-purpose Java wrapper that we could possibly release
as a separate tool?

> Pier (ROTFL for the new MTV-ringtones ad)

WTF? I must have missed that one. A pop-up web ad, you mean?

Re: sun.tools.javac.Main will be removed from JDK1.4

[Pier P. Fumagalli]

Craig R. McClanahan at [EMAIL PROTECTED] wrote:
> 
> I haven't looked at Jikes, so can't comment on the suitability of any APIs
> it exposes.  Would someone like to look at this and report back?

Last time I looked at the sources (when I was at IBM, 1+1/2 years ago),
Jikes was not relying on threads, and had a decent code base (it wasn't
printing error messages to stderr, but was mirroring its FILE * in an
internal variable, if I remember it right)...

If that's the case, it _would_ be possible (probably, but not guaranteed) to
compile it as a library with some hacks and wrap it somehow with a nice
class, with all callbacks we need...

Should check the code at this point, though...

Pier (ROTFL for the new MTV-ringtones ad)

Re: sun.tools.javac.Main will be removed from JDK1.4

[Pier P. Fumagalli]

Jon Stevens at [EMAIL PROTECTED] wrote:
> 
> The real solution is to get Sun to get off their high horse and OSS the
> javac compiler and/or not do stupid things like remove something that tons
> of people depend on and not give an alternative way to do things.

I have to disagree, this time.. The invitation was open (if not from Sun -my
employer, btw-, from Neal Gafter, the "javac" guy at Sun, when he opened the
Yahoo E-Group for discussing what the requirements were, and draft an
interface to the compiler) we simply didn't jump on...

But anyway, that is related to JSPs, and I didn't remember you were such
worried about their support :)

Pier

Re: tar bundle of latest mod-Web source?

[Pier P. Fumagalli]

Craig R. McClanahan at [EMAIL PROTECTED] wrote:
> On Fri, 20 Jul 2001, Thom Park wrote:
> 
>> Hi all,
>> 
>> is there a tarbundle somewhere of the latest (circa-Tomcat 4-b6) web-app
>> connector stuff anywhere?
> 
> Will, it would have been there already if the person slated to do the work
> (Pier) hadn't been broken into last night, with several PCs and a bunch of
> other stuff stolen :-(.

No, it would have been already there if I didn't forget to copy them to the
WWW server after I rolled them today at the cops station :)

They're up now, at



Sources only... Whoever tries to build them is more than welcome (meaning
I'm going to shoot you if you don't) to tell so, report problems and so on.

For B6, I didn't update the Makefiles for Win32, so, those still need to be
fixed, but they should work on any platform where APR has been ported to.

The APR version included is quite old, pre SMS (those who don't know what it
is, SMS is a huge piece of code that was committed some weeks ago dealing
with memory and so on, even though I trust David Reid and he told me it was
OK, I'd rather bundle an older and more secure version, found to compile
almost everywhere) and I'm planning to update to the more recent one after I
hear what comes up with Apache 2.0b21 (shouldn't change anything, just some
testing).

It's not "yet" a "beta" as it doesn't include documentation (especially for
the WARP protocol, and Jean Frederic will kill me if I don't write it - he's
in France, much closer to me than you guys in California, and so way more
scary :), and because there are still some WatchDog tests not working.

Apart from all this bullshit, it's _way_ more stable than the previous one,
the new protocol (WARP/0.9, getting close to 1.0 if this one proves
satisfactory) holds much better than the previous one (in several tests I
made, approximately 5 hits, I never dropped the socket - whohooo!).

So, have fun, try it out, and get me some feedback :)

Cheers...

Pier

Re: cvs commit: jakarta-tomcat-4.0 build.xml

[Jon Stevens]

on 7/20/01 4:38 PM, "Glenn Nielsen" <[EMAIL PROTECTED]> wrote:

> You are easily amused.
> 
> I'm surprised at how neutral your echo is for Jasper,
> I would have thought you would use something like
> 
> Target: Jasper - Tracking, Firing, Hit...
> 
> ;-)
> 
> Glenn

This is the new nicer Jon.

JSP still sucks though.

-jon

Re: cvs commit: jakarta-tomcat-4.0 build.xml

[Glenn Nielsen]

You are easily amused.

I'm surprised at how neutral your echo is for Jasper,
I would have thought you would use something like

Target: Jasper - Tracking, Firing, Hit...

 ;-)

Glenn

[EMAIL PROTECTED] wrote:
> 
> jon 01/07/20 14:46:32
> 
>   Modified:.build.xml
>   Log:
>   added some echo statements for my own amusement.
> 
>   Revision  ChangesPath
>   1.30  +3 -0  jakarta-tomcat-4.0/build.xml
> 
>   Index: build.xml
>   ===
>   RCS file: /home/cvs/jakarta-tomcat-4.0/build.xml,v
>   retrieving revision 1.29
>   retrieving revision 1.30
>   diff -u -r1.29 -r1.30
>   --- build.xml 2001/07/18 18:32:49 1.29
>   +++ build.xml 2001/07/20 21:46:32 1.30
>   @@ -33,8 +33,11 @@
> 
>  
>  
>   +Target: Catalina - Deploy...
>
>   +Target: Jasper - Deploy...
>
>   +Target: Webapps - Deploy...
>
>  
> 
> 
> 
> 

-- 
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

Updates to build processes and docs on jakarta-servletapi-4 andjakarta-watchdog-4

[Craig R. McClanahan]

Hey folks,

As I mentioned earlier, I've gone through the "jakarta-servletapi-4" and
"jakarta-watchdog-4.0" build processes, and brought them up to date with
our current practices.  In addition, I've brought the following
docuemntation files up to date for both repositories:

README.txtQuick intro, documentation of the contents of the
  release, and pointers to other info

BUILDING.txt  Building a binary distribution from source

RUNNING.txt   (Watchdog only) Running the Watchdog tests against
  your servlet container

In particular, folks working on Tomcat 4 will want to note the revised
(simpler) test execution procedures for Watchdog tests.

The revisions are in CVS now, and will show up in tonight's nightly
builds.  Please take a look, and provide feedback on the correctness and
ease of use of the updated documentation.

Craig McClanahan

PS:  The jakarta-tomcat-4.0 repository is next on my target list :-)

Re: sun.tools.javac.Main will be removed from JDK1.4

[Craig R. McClanahan]

On Fri, 20 Jul 2001, Christopher Cain wrote:

> 
> "JULIEN,TIMOTHY (HP-NewJersey,ex2)" wrote:
> > 
> > Over in HP middleware, we're not to happy with this development either
> > our JSP implementation will suffer for the same reasons Jasper will
> > 
> > We can work with an external compiler, but for speed, we much prefer
> > sun.tool.javac.Main.
> 
> Just a question to satisfy my own curiosity (and possibly point out my
> compiler ignorance WRT using sun.tool.javac.Main and/or JSP compilation
> [since I don't do JSP]). You mention speed being the primary factor in
> using the Main compiler. Since Jikes is infinitely faster than javac
> (which I assume is derived from or otherwise related to Main), I have
> two questions.
> 
> 1) Is it possible to even use Jikes in a JSP-compilation module, or are
> there technical issues which make it difficult to incorporate in a JSP
> environment?
> 

It is certainly technically feasible.  And I *thought* that, at least
somewhere in the Jasper lineage, it had actually been implemented.  Ant
has interfaces for Jikes already, also.

> 2) If it is not a JSP-specific issue, then I assume that the problem is
> due to Jikes not exposing some kind of API that can be imported and/or
> called from Java classes, and that it would therefore require the
> invokation of a separate external process (which is of course out of the
> question). Is that the case?
> 

I haven't looked at Jikes, so can't comment on the suitability of any APIs
it exposes.  Would someone like to look at this and report back?

> Again, I have very little knowledge of programatic compilation in Java,
> so I am just asking out of wild curiousity. It's an interesting problem.
> 
> Regards,
> 
> Christopher
> 

Craig

Re: tar bundle of latest mod-Web source?

[Craig R. McClanahan]

On Fri, 20 Jul 2001, Thom Park wrote:

> 
> Hi all,
> 
> is there a tarbundle somewhere of the latest (circa-Tomcat 4-b6) web-app
> connector stuff anywhere?
> 
> I was a little bemused to see that the release announcment of TC4-b6
> mentioned the all new
> webapp connector and then proceded to omit said source from the source
> bundle.
> 
> Pulling the sources out of CVS piece-meal is a bit onerous.
> 
> So anyone know of where a tarball of the source might be (or has anyone got
> a script that
> can be run to generate such?
> 

Will, it would have been there already if the person slated to do the work
(Pier) hadn't been broken into last night, with several PCs and a bunch of
other stuff stolen :-(.

> thanks,
> 
> Thom
> 

Craig

Re: sun.tools.javac.Main will be removed from JDK1.4

[Craig R. McClanahan]

On Fri, 20 Jul 2001, Paul Speed wrote:

> 
> 
> "Craig R. McClanahan" wrote:
> > 
> > There are some pretty intense discussions going on about this, and the
> > story hasn't yet been finished ...
> > 
> > On the other hand, the "new" compiler entry point has an absolutely
> > horrible feature (from the point of view of Jasper) -- you have to modify
> > System.out and System.err to redirect the compiler output.  Unless system
> > variables are unique per classloader (they weren't last time I checked),
> > that means we can only do one compile at a time :-(.
> 
> This concerns me for a lot of reasons.  Mostly because it's a sign
> of a poorly architected program.  A compiler that does not abstract its
> error reporting is very poorly designed.  What happens when Java has
> a logging API and they want to use that instead?
> 
> I'm one of the biggest Sun supporters you'll find.  I think a lot of
> bright engineers have come up with some very cool stuff.  However,
> this "feature" is one of the most boneheaded things I've ever heard. ;)
> 

I think it's more an issue of not even thinking about needs beyond a
command line compiler (which is all it was for in the first place --
remember we're using an *unsupported* internal entry point).  It's as much
our (Tomcat and Ant communities, as well as others who do internal
compilations) fault for not being more actively involved in making sure
the J2SE folks understand our needs as anything else.

> -Paul Speed
> 

Craig

Re: sun.tools.javac.Main will be removed from JDK1.4

[Christopher Cain]

Jon Stevens wrote:
> 
> Jikes works fine.
>
> The issue is that Jikes is a C++ binary and isn't ported to every platform.

Oh yeah ... =)

> It also makes installation/distribution issues a bit more tricky than simply
> calling a Java class file...

Yep. I figured the issue was that it would require an external process.
Damn!

> The real solution is to get Sun to get off their high horse and OSS the
> javac compiler and/or not do stupid things like remove something that tons
> of people depend on and not give an alternative way to do things.

Granted, I'm a Jikes butt-boy, but what I would really love to see is a
Java port of it rather than a new OSS project based on the javac code.
I'm actually not sure what the license on Jikes looks like, but if it's
a GPL-type license then of course it might be a bit of a bundling
problem.

*Quickly ducks the the flames of the GPL-pro camp*

One other thing, just to (slightly) defend Sun here. They have always
been quite unequivocal about not relying on any sun.* classes, as it is
the equivalent of coding to an undocumented API feature in the DLL world
(which, as we all know, are liable to change on a whim). I actually give
Sun a little credit here for providing advanced notice of the situation,
especially at this apparently early stage in the debate.

Of course, that's to say nothing of why there isn't a published compiler
extension (or classes), or why the javac is not OSS in the first place,
or why there is really no alternative to relying on the Main compiler in
many cases. I'm not saying it's right, I'm just saying that everyone
knew it was a possibility from the get-go.

- Christopher

Re: [TC4] jakarta-regexp.jar

[Craig R. McClanahan]

On Fri, 20 Jul 2001, Jon Stevens wrote:

> on 7/19/01 10:58 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
> 
> > I'm positive Jon will be +1 for this :-), but I'm very -1 for reasons that
> > have been discussed at length on this and other lists in the past.
> > Storing JAR files is evil, because it creates dependencies on those
> > particular versions of the JAR files and you cannot reliably recreate a
> > release purely from sources.
> 
> In the case of Catalina, I'm against it since you have setup a system of
> defining things in the build.properties file and requiring people to already
> download a ton of other stuff anyway.
> 
> The next logical step is to use Geir's JJAR (look in the
> jakarta-commons-sandbox) to automatically download the right .jar files for
> you.
> 
Yep.

> > Actually, Jon's suggestion is the right answer.
> >
> > Craig McClanahan
> 
> I'm going to print that quote (taken entirely out of context) out and frame
> it next to my JSP Sucks article. :-)
> 
> 
> 

That's why I even autographed it for you :-)

> -jon
> 

Craig

Re: [TC4] jakarta-regexp.jar

[Craig R. McClanahan]

On Fri, 20 Jul 2001, Jon Stevens wrote:

> The next logical step is to use Geir's JJAR (look in the
> jakarta-commons-sandbox) to automatically download the right .jar files for
> you.
> 
> > Actually, Jon's suggestion is the right answer.
> >
> > Craig McClanahan
> 
> I'm going to print that quote (taken entirely out of context) out and frame
> it next to my JSP Sucks article. :-)
> 
> 
> 
> -jon
> 
> -- 
> If you come from a Perl or PHP background, JSP is a way to take
> your pain to new levels. --Anonymous
> 
> 
> 

Re: sun.tools.javac.Main will be removed from JDK1.4

[Christopher Cain]

Jon Stevens wrote:
> 
> Time to drop Javac and just use Jikes...

LOL! I hadn't even read this one when I (just now) asked my "why not
just go with Jikes" question. I've started noticing that Jon and I think
alot alike, from HTML-formatted e-mail to documention approaches to JSP
to compiler technologies ... and I'm not entirely sure how I feel about
that. It's an odd combination of intellectual validation ... and a vague
sense of horror ;-)

(j/k)

Oh well, it's funner to fight with someone who's brilliant anyway. You
can be the Moriarty to my Holmes =)

- Christopher

Re: sun.tools.javac.Main will be removed from JDK1.4

[Jon Stevens]

on 7/20/01 3:45 PM, "Christopher Cain" <[EMAIL PROTECTED]> wrote:

> Just a question to satisfy my own curiosity (and possibly point out my
> compiler ignorance WRT using sun.tool.javac.Main and/or JSP compilation
> [since I don't do JSP]). You mention speed being the primary factor in
> using the Main compiler. Since Jikes is infinitely faster than javac
> (which I assume is derived from or otherwise related to Main), I have
> two questions.
> 
> 1) Is it possible to even use Jikes in a JSP-compilation module, or are
> there technical issues which make it difficult to incorporate in a JSP
> environment?
> 
> 2) If it is not a JSP-specific issue, then I assume that the problem is
> due to Jikes not exposing some kind of API that can be imported and/or
> called from Java classes, and that it would therefore require the
> invokation of a separate external process (which is of course out of the
> question). Is that the case?

Jikes works fine.

The issue is that Jikes is a C++ binary and isn't ported to every platform.

It also makes installation/distribution issues a bit more tricky than simply
calling a Java class file...

The real solution is to get Sun to get off their high horse and OSS the
javac compiler and/or not do stupid things like remove something that tons
of people depend on and not give an alternative way to do things.

-jon

Re: sun.tools.javac.Main will be removed from JDK1.4

[Christopher Cain]

"JULIEN,TIMOTHY (HP-NewJersey,ex2)" wrote:
> 
> Over in HP middleware, we're not to happy with this development either
> our JSP implementation will suffer for the same reasons Jasper will
> 
> We can work with an external compiler, but for speed, we much prefer
> sun.tool.javac.Main.

Just a question to satisfy my own curiosity (and possibly point out my
compiler ignorance WRT using sun.tool.javac.Main and/or JSP compilation
[since I don't do JSP]). You mention speed being the primary factor in
using the Main compiler. Since Jikes is infinitely faster than javac
(which I assume is derived from or otherwise related to Main), I have
two questions.

1) Is it possible to even use Jikes in a JSP-compilation module, or are
there technical issues which make it difficult to incorporate in a JSP
environment?

2) If it is not a JSP-specific issue, then I assume that the problem is
due to Jikes not exposing some kind of API that can be imported and/or
called from Java classes, and that it would therefore require the
invokation of a separate external process (which is of course out of the
question). Is that the case?

Again, I have very little knowledge of programatic compilation in Java,
so I am just asking out of wild curiousity. It's an interesting problem.

Regards,

Christopher

Re: t4 - jasper go boo boo

[Jon Stevens]

on 7/20/01 3:13 PM, "Kevin Seguin" <[EMAIL PROTECTED]> wrote:

> you need a new servlet.jar.  update and build jakarta-servletapi-4.

Ok...cool...

Fyi...i'm getting these javadoc errors when building it...

  [javadoc] javadoc: warning - Tag @see: Class or Package not found:
java.io.Buf
feredWriter
  [javadoc] javadoc: warning - Tag @see: Class or Package not found:
java.lang.I
nteger#toString(int)
  [javadoc] javadoc: warning - Tag @see: Class or Package not found:
java.lang.L
ong#toString(long)
  [javadoc] javadoc: warning - Tag @see: Class or Package not found:
java.lang.F
loat#toString(float)
  [javadoc] javadoc: warning - Tag @see: Class or Package not found:
java.lang.D
ouble#toString(double)

-jon

RE: t4 - jasper go boo boo

[Kevin Seguin]

you need a new servlet.jar.  update and build jakarta-servletapi-4.

> -Original Message-
> From: Jon Stevens [mailto:[EMAIL PROTECTED]]
> Sent: Friday, July 20, 2001 4:50 PM
> To: tomcat-dev
> Subject: t4 - jasper go boo boo
> 
> 
> I just did a fresh cvs update, ant clean, ant and I get this...
> 
> -jon
> 
> [176][ ~/checkout/jakarta-tomcat-4.0 ]% ant clean
> Buildfile: build.xml
> 
> clean:
> 
> build-clean:
> 
> dist-clean:
> 
> clean:
> 
> build-clean:
> 
> dist-clean:
> 
> clean:
> 
> build-clean:
> 
> dist-clean:
> 
> clean:
> 
> build-clean:
> 
> dist-clean:
> 
> clean:
> 
> BUILD SUCCESSFUL
> 
> Total time: 2 seconds
> [177][ ~/checkout/jakarta-tomcat-4.0 ]% ant
> Buildfile: build.xml
> 
> deploy-prepare:
> [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build
> 
> deploy-static:
> 
> deploy-main:
>  [echo] Target: Catalina - Deploy...
> 
> build-prepare:
> [mkdir] Created dir:
> /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build
> [mkdir] Created dir:
> /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/b
> in
> [mkdir] Created dir:
> /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/c
> lasses
> [mkdir] Created dir:
> /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/c
> onf
> [mkdir] Created dir:
> /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/l
> ib
> [mkdir] Created dir:
> /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/c
> ommon
> [mkdir] Created dir:
> /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/c
> ommon/lib
> [mkdir] Created dir:
> /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/s
> erver
> [mkdir] Created dir:
> /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/s
> erver/lib
> 
> copy-jaxp-jar:
>  [copy] Copying 1 file to
> /Users/jon/checkout/jakarta-tomcat-4.0/catalina/bu
> ild/server/lib
> 
> build-static:
>  [copy] Copying 9 files to
> /Users/jon/checkout/jakarta-tomcat-4.0/catalina/b
> uild/bin
>  [copy] Copying 5 files to
> /Users/jon/checkout/jakarta-tomcat-4.0/catalina/b
> uild/conf
>  [copy] Copying 1 file to
> /Users/jon/checkout/jakarta-tomcat-4.0/catalina/bu
> ild/common/lib
>  [copy] Copying 1 file to
> /Users/jon/checkout/jakarta-tomcat-4.0/catalina/bu
> ild/common/lib
>  [copy] Copying 1 file to
> /Users/jon/checkout/jakarta-tomcat-4.0/catalina/bu
> ild/server/lib
>  [copy] Copying 1 file to
> /Users/jon/checkout/jakarta-tomcat-4.0/catalina/bu
> ild/server/lib
> 
> build-main:
> [javac] Compiling 278 source files to
> /Users/jon/checkout/jakarta-tomcat-4.0
> /catalina/build/classes
>  [copy] Copying 26 files to
> /Users/jon/checkout/jakarta-tomcat-4.0/catalina/
> build/classes
>   [jar] Building jar:
> /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/
> bin/bootstrap.jar
>   [jar] Building jar:
> /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/
> common/lib/naming.jar
>   [jar] Building jar:
> /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/
> common/lib/resources.jar
>   [jar] Building jar:
> /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/
> lib/namingfactory.jar
> 
> deploy-prepare:
> [mkdir] Created dir: 
> /Users/jon/checkout/jakarta-tomcat-4.0/build/bin
> [mkdir] Created dir: 
> /Users/jon/checkout/jakarta-tomcat-4.0/build/conf
> [mkdir] Created dir: 
> /Users/jon/checkout/jakarta-tomcat-4.0/build/lib
> [mkdir] Created dir: 
> /Users/jon/checkout/jakarta-tomcat-4.0/build/logs
> [mkdir] Created dir: 
> /Users/jon/checkout/jakarta-tomcat-4.0/build/common
> [mkdir] Created dir:
> /Users/jon/checkout/jakarta-tomcat-4.0/build/common/lib
> [mkdir] Created dir: 
> /Users/jon/checkout/jakarta-tomcat-4.0/build/server
> [mkdir] Created dir:
> /Users/jon/checkout/jakarta-tomcat-4.0/build/server/lib
> [mkdir] Created dir: 
> /Users/jon/checkout/jakarta-tomcat-4.0/build/work
> 
> deploy-static:
>  [copy] Copying 10 files to
> /Users/jon/checkout/jakarta-tomcat-4.0/build/bin
>  [copy] Copying 5 files to
> /Users/jon/checkout/jakarta-tomcat-4.0/build/conf
>  [copy] Copying 1 file to
> /Users/jon/checkout/jakarta-tomcat-4.0/build/lib
>  [copy] Copying 4 files to
> /Users/jon/checkout/jakarta-tomcat-4.0/build/comm
> on/lib
>  [copy] Copying 3 files to
> /Users/jon/checkout/jakarta-tomcat-4.0/build/serv
> er/lib
> 
> deploy-main:
>   [jar] Building jar:
> /Users/jon/checkout/jakarta-tomcat-4.0/build/server/li
> b/catalina.jar
>   [jar] Building jar:
> /Users/jon/checkout/jakarta-tomcat-4.0/build/server/li
> b/warp.jar
> 
> deploy:
>  [echo] Target: Jasper - Deploy...
> 
> build-prepare:
> [mkdir] Created dir: 
> /Users/jon/checkout/jakarta-tomcat-4.0/jasper/build
> [mkdir] Created dir:
> /Users/jon/checkout/jakarta-tomcat-4.0/jasper/build/bin
> [mkdir] Created dir:
> /Users/jon/checkout/jakarta-tomcat-4.0/jasper/build/cla
> sses
> [mkdir] Created dir:
> /Users/jon/checkout/jakarta-tomcat-4.0/jasper/build/lib
> 
> cop

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server Ajp13.java

[mmanders]

mmanders01/07/20 15:08:16

  Modified:src/share/org/apache/tomcat/modules/server Ajp13.java
  Log:
  When calling setUserPrincipal, use the RemoteUser we just read instead of reading 
the next string in the message.  Otherwise, we through the message/protocol off.
  
  Revision  ChangesPath
  1.21  +1 -1  
jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13.java
  
  Index: Ajp13.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13.java,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- Ajp13.java2001/07/17 04:06:29 1.20
  +++ Ajp13.java2001/07/20 22:08:16 1.21
  @@ -330,7 +330,7 @@
req.setRemoteUser( msg.getString());
// XXX recycle ?
// Note that roles are not integrated with apache
  - req.setUserPrincipal( new SimplePrincipal( msg.getString()));
  + req.setUserPrincipal( new SimplePrincipal( req.getRemoteUser() ));
   break;

case SC_A_AUTH_TYPE:
  
  
  

t4 - jasper go boo boo

[Jon Stevens]

I just did a fresh cvs update, ant clean, ant and I get this...

-jon

[176][ ~/checkout/jakarta-tomcat-4.0 ]% ant clean
Buildfile: build.xml

clean:

build-clean:

dist-clean:

clean:

build-clean:

dist-clean:

clean:

build-clean:

dist-clean:

clean:

build-clean:

dist-clean:

clean:

BUILD SUCCESSFUL

Total time: 2 seconds
[177][ ~/checkout/jakarta-tomcat-4.0 ]% ant
Buildfile: build.xml

deploy-prepare:
[mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build

deploy-static:

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

build-prepare:
[mkdir] Created dir:
/Users/jon/checkout/jakarta-tomcat-4.0/catalina/build
[mkdir] Created dir:
/Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/b
in
[mkdir] Created dir:
/Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/c
lasses
[mkdir] Created dir:
/Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/c
onf
[mkdir] Created dir:
/Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/l
ib
[mkdir] Created dir:
/Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/c
ommon
[mkdir] Created dir:
/Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/c
ommon/lib
[mkdir] Created dir:
/Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/s
erver
[mkdir] Created dir:
/Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/s
erver/lib

copy-jaxp-jar:
 [copy] Copying 1 file to
/Users/jon/checkout/jakarta-tomcat-4.0/catalina/bu
ild/server/lib

build-static:
 [copy] Copying 9 files to
/Users/jon/checkout/jakarta-tomcat-4.0/catalina/b
uild/bin
 [copy] Copying 5 files to
/Users/jon/checkout/jakarta-tomcat-4.0/catalina/b
uild/conf
 [copy] Copying 1 file to
/Users/jon/checkout/jakarta-tomcat-4.0/catalina/bu
ild/common/lib
 [copy] Copying 1 file to
/Users/jon/checkout/jakarta-tomcat-4.0/catalina/bu
ild/common/lib
 [copy] Copying 1 file to
/Users/jon/checkout/jakarta-tomcat-4.0/catalina/bu
ild/server/lib
 [copy] Copying 1 file to
/Users/jon/checkout/jakarta-tomcat-4.0/catalina/bu
ild/server/lib

build-main:
[javac] Compiling 278 source files to
/Users/jon/checkout/jakarta-tomcat-4.0
/catalina/build/classes
 [copy] Copying 26 files to
/Users/jon/checkout/jakarta-tomcat-4.0/catalina/
build/classes
  [jar] Building jar:
/Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/
bin/bootstrap.jar
  [jar] Building jar:
/Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/
common/lib/naming.jar
  [jar] Building jar:
/Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/
common/lib/resources.jar
  [jar] Building jar:
/Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/
lib/namingfactory.jar

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

deploy-static:
 [copy] Copying 10 files to
/Users/jon/checkout/jakarta-tomcat-4.0/build/bin
 [copy] Copying 5 files to
/Users/jon/checkout/jakarta-tomcat-4.0/build/conf
 [copy] Copying 1 file to
/Users/jon/checkout/jakarta-tomcat-4.0/build/lib
 [copy] Copying 4 files to
/Users/jon/checkout/jakarta-tomcat-4.0/build/comm
on/lib
 [copy] Copying 3 files to
/Users/jon/checkout/jakarta-tomcat-4.0/build/serv
er/lib

deploy-main:
  [jar] Building jar:
/Users/jon/checkout/jakarta-tomcat-4.0/build/server/li
b/catalina.jar
  [jar] Building jar:
/Users/jon/checkout/jakarta-tomcat-4.0/build/server/li
b/warp.jar

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

build-prepare:
[mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/jasper/build
[mkdir] Created dir:
/Users/jon/checkout/jakarta-tomcat-4.0/jasper/build/bin
[mkdir] Created dir:
/Users/jon/checkout/jakarta-tomcat-4.0/jasper/build/cla
sses
[mkdir] Created dir:
/Users/jon/checkout/jakarta-tomcat-4.0/jasper/build/lib

copy-jaxp-jar:
 [copy] Copying 1 file to
/Users/jon/checkout/jakarta-tomcat-4.0/jasper/buil
d/lib

build-static:
 [copy] Copying 5 files to
/Users/jon/checkout/jakarta-tomcat-4.0/jasper/bui
ld/bin
 [copy] Copying 1 file to
/Users/jon/checkout/jakarta-tomcat-4.0/jasper/buil
d/lib

build-main:
[javac] Compiling 91 source files to
/Users/jon/checkout/jakarta-tomcat-4.0/
jasper/build/classes
[javac]
[javac] Found 2 semantic errors compiling
"/Users/jon/checkout/jakarta-tomca
t-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java
":
[javac]
[javac]  

cvs commit: jakarta-tomcat-4.0 build.xml

[jon]

jon 01/07/20 14:46:32

  Modified:.build.xml
  Log:
  added some echo statements for my own amusement.
  
  Revision  ChangesPath
  1.30  +3 -0  jakarta-tomcat-4.0/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/build.xml,v
  retrieving revision 1.29
  retrieving revision 1.30
  diff -u -r1.29 -r1.30
  --- build.xml 2001/07/18 18:32:49 1.29
  +++ build.xml 2001/07/20 21:46:32 1.30
  @@ -33,8 +33,11 @@
   
 
 
  +Target: Catalina - Deploy...
   
  +Target: Jasper - Deploy...
   
  +Target: Webapps - Deploy...
   
 
   
  
  
  

tar bundle of latest mod-Web source?

[Thom Park]

Hi all,

is there a tarbundle somewhere of the latest (circa-Tomcat 4-b6) web-app
connector stuff anywhere?

I was a little bemused to see that the release announcment of TC4-b6
mentioned the all new
webapp connector and then proceded to omit said source from the source
bundle.

Pulling the sources out of CVS piece-meal is a bit onerous.

So anyone know of where a tarball of the source might be (or has anyone got
a script that
can be run to generate such?

thanks,

Thom

-Original Message-
From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 20, 2001 1:48 PM
To: [EMAIL PROTECTED]
Subject: Re: sun.tools.javac.Main will be removed from JDK1.4


JULIEN,TIMOTHY (HP-NewJersey,ex2) at [EMAIL PROTECTED] wrote:

> Over in HP middleware, we're not to happy with this development either
> our JSP implementation will suffer for the same reasons Jasper will
>
> We can work with an external compiler, but for speed, we much prefer
> sun.tool.javac.Main.

That's why probably TWO MONTHS ago I encouraged this mailing list to put
someone on the javax-compiler group at Yahoo. But apparently no one cared :)

Pier

RE: [ANNOUNCEMENT] Tomcat 4.0-beta-6 Released

[Ken Torimaru]

NEVER MIND
I just need to recompile my applications.

-Original Message-
From: Ken Torimaru [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 20, 2001 1:49 PM
To: [EMAIL PROTECTED]
Subject: RE: [ANNOUNCEMENT] Tomcat 4.0-beta-6 Released


Have I done something wrong or do the directory
listing still read "Apache Tomcat/4.0-b5"?

-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 20, 2001 12:21 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: [ANNOUNCEMENT] Tomcat 4.0-beta-6 Released


The Tomcat team is proud to announce the availability of the latest beta
release of Tomcat 4.0.  This next-generation servlet and JSP container
boasts the following new and improved features:
* Fix for the security vulnerability reported on July 16, 2001.
* Support for the "Proposed Final Draft 3" versions of the Servlet 2.3
  and JSP 1.2 Specifications.
* Many bug fixes and performance improvements.
* Support for executing external CGI scripts and programs.
* An updated version of the Apache web connector (binaries for various
  platforms will be available soon)
* A new experimental installer for the Windows platform that lets you
  download and install Tomcat 4.0 in a manner typical of other Windows
  based programs (including installation of Tomcat as an NT service).

Binary distributions of Tomcat 4.0-beta-6 are available at:

  http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-b6/

and source distributions are available at:

  http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-b6/src/

Please see the included RELEASE-NOTES-4.0-B6.txt file for details about
the changes included in this release.

Craig McClanahan

Re: sun.tools.javac.Main will be removed from JDK1.4

[Jon Stevens]

on 7/20/01 12:11 PM, "JULIEN,TIMOTHY (HP-NewJersey,ex2)"
<[EMAIL PROTECTED]> wrote:

> Over in HP middleware, we're not to happy with this development either
> our JSP implementation will suffer for the same reasons Jasper will
> 
> We can work with an external compiler, but for speed, we much prefer
> sun.tool.javac.Main.
> 
> Tim Julien
> HP Middleware

Yet another reason why having Sun at the top of the "standards" heap is a
bad idea.

Wake up people.

-jon

RE: [ANNOUNCEMENT] Tomcat 4.0-beta-6 Released

[Ken Torimaru]

Have I done something wrong or do the directory
listing still read "Apache Tomcat/4.0-b5"?

-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 20, 2001 12:21 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: [ANNOUNCEMENT] Tomcat 4.0-beta-6 Released


The Tomcat team is proud to announce the availability of the latest beta
release of Tomcat 4.0.  This next-generation servlet and JSP container
boasts the following new and improved features:
* Fix for the security vulnerability reported on July 16, 2001.
* Support for the "Proposed Final Draft 3" versions of the Servlet 2.3
  and JSP 1.2 Specifications.
* Many bug fixes and performance improvements.
* Support for executing external CGI scripts and programs.
* An updated version of the Apache web connector (binaries for various
  platforms will be available soon)
* A new experimental installer for the Windows platform that lets you
  download and install Tomcat 4.0 in a manner typical of other Windows
  based programs (including installation of Tomcat as an NT service).

Binary distributions of Tomcat 4.0-beta-6 are available at:

  http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-b6/

and source distributions are available at:

  http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-b6/src/

Please see the included RELEASE-NOTES-4.0-B6.txt file for details about
the changes included in this release.

Craig McClanahan

Re: sun.tools.javac.Main will be removed from JDK1.4

[Paul Speed]

"Craig R. McClanahan" wrote:
> 
> There are some pretty intense discussions going on about this, and the
> story hasn't yet been finished ...
> 
> On the other hand, the "new" compiler entry point has an absolutely
> horrible feature (from the point of view of Jasper) -- you have to modify
> System.out and System.err to redirect the compiler output.  Unless system
> variables are unique per classloader (they weren't last time I checked),
> that means we can only do one compile at a time :-(.

This concerns me for a lot of reasons.  Mostly because it's a sign
of a poorly architected program.  A compiler that does not abstract its
error reporting is very poorly designed.  What happens when Java has
a logging API and they want to use that instead?

I'm one of the biggest Sun supporters you'll find.  I think a lot of
bright engineers have come up with some very cool stuff.  However,
this "feature" is one of the most boneheaded things I've ever heard. ;)

-Paul Speed

> 
> An additional note of interest to Ant developers - there is evidence that
> running the compiler (either old or new) leaves a fair amount of cruft
> lying around in static variables, after the compile has completed. The
> recommended solution is to load the compiler itself in its own class
> loader, so that you can throw it all away afterwards.  That's the approach
> we'll take when modifying Jasper.
> 
> Craig
> 
> On Fri, 20 Jul 2001, Sam Ruby wrote:
> 
> > FYI.  Bye bye "classic" compiler.
> >
> > Ant looks safe (it uses reflection), but Jasper looks like it will be
> > affected.
> >
> > - Sam Ruby
> >
> > -- Forwarded by Sam Ruby/Raleigh/IBM on 07/20/2001
> > 07:30 AM ---
> >
> > Davanum Srinivas <[EMAIL PROTECTED]> on 07/20/2001 06:16:57 AM
> >
> > Please respond to [EMAIL PROTECTED]
> >
> > To:   [EMAIL PROTECTED]
> > cc:
> > Subject:  sun.tools.javac.Main will be removed from JDK1.4
> >
> >
> >
> > FYI,
> >
> > -Original Message-
> > From: Leclair, Donald
> > Sent: Thursday, July 19, 2001 7:15 PM
> > To: J2EE Communications
> > Subject: Message 14: Class change impact
> >
> >
> > Sent: Thursday, July 19, 2001 7:08 PM
> > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Subject: Class change impact
> >
> >
> > Dear Licensee,
> >
> > The Java(TM) 2 Platform, Standard Edition team will be making
> > a change that might impact you.
> >
> > The change is that the class "sun.tools.javac.Main"
> > (used for compiling java classes) will be removed in J2SE 1.4.
> > This is not a public API change. If you depend on this class
> > you may be impacted.
> >
> > If you have questions, please follow-up with your designated
> > Licensee Engineer.
> >
> > Regards,
> > Jill Smith
> > Java Partner Engineering
> >
> > =
> > Davanum Srinivas, JNI-FAQ Manager
> > http://www.jGuru.com/faq/JNI
> >
> > __
> > Do You Yahoo!?
> > Get personalized email addresses from Yahoo! Mail
> > http://personal.mail.yahoo.com/
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> >
> >
> >
> >

Re: sun.tools.javac.Main will be removed from JDK1.4

[Pier P. Fumagalli]

JULIEN,TIMOTHY (HP-NewJersey,ex2) at [EMAIL PROTECTED] wrote:

> Over in HP middleware, we're not to happy with this development either
> our JSP implementation will suffer for the same reasons Jasper will
> 
> We can work with an external compiler, but for speed, we much prefer
> sun.tool.javac.Main.

That's why probably TWO MONTHS ago I encouraged this mailing list to put
someone on the javax-compiler group at Yahoo. But apparently no one cared :)

Pier

Re: cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.0-B6.txt

[Jon Stevens]

on 7/20/01 1:36 AM, "Pier P. Fumagalli" <[EMAIL PROTECTED]> wrote:

> Windows coming in few days, as someone broke into my apt tonight and stole a
> couple of PCs and god knows what else... Other OSes, after I get back from
> the cops (thank god I keep my Macs in by bedroom).
> 
>   Pier (nothing _ever_ goes right)

Oh my god! That sucks! I'm sorry Pier!!!

-jon

Re: [TC4] jakarta-regexp.jar

[Jon Stevens]

on 7/20/01 1:29 AM, "GOMEZ Henri" <[EMAIL PROTECTED]> wrote:

> Why could still use symlink as I do in my RPM :)
> 
> ln -s jakarta-regexp-1.2.jar jakarta-regexp.jar

Doesn't work on winblows.

-jon

Re: [TC4] jakarta-regexp.jar

[Jon Stevens]

on 7/19/01 10:58 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:

> I'm positive Jon will be +1 for this :-), but I'm very -1 for reasons that
> have been discussed at length on this and other lists in the past.
> Storing JAR files is evil, because it creates dependencies on those
> particular versions of the JAR files and you cannot reliably recreate a
> release purely from sources.

In the case of Catalina, I'm against it since you have setup a system of
defining things in the build.properties file and requiring people to already
download a ton of other stuff anyway.

The next logical step is to use Geir's JJAR (look in the
jakarta-commons-sandbox) to automatically download the right .jar files for
you.

> Actually, Jon's suggestion is the right answer.
>
> Craig McClanahan

I'm going to print that quote (taken entirely out of context) out and frame
it next to my JSP Sucks article. :-)



-jon

-- 
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous

RE: sun.tools.javac.Main will be removed from JDK1.4

[JULIEN,TIMOTHY (HP-NewJersey,ex2)]

Over in HP middleware, we're not to happy with this development either
our JSP implementation will suffer for the same reasons Jasper will

We can work with an external compiler, but for speed, we much prefer
sun.tool.javac.Main.

Tim Julien
HP Middleware

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Friday, July 20, 2001 1:54 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: sun.tools.javac.Main will be removed from JDK1.4
> 
> 
> There are some pretty intense discussions going on about this, and the
> story hasn't yet been finished ...
> 
> On the other hand, the "new" compiler entry point has an absolutely
> horrible feature (from the point of view of Jasper) -- you 
> have to modify
> System.out and System.err to redirect the compiler output.  
> Unless system
> variables are unique per classloader (they weren't last time 
> I checked),
> that means we can only do one compile at a time :-(.
> 
> An additional note of interest to Ant developers - there is 
> evidence that
> running the compiler (either old or new) leaves a fair amount of cruft
> lying around in static variables, after the compile has completed. The
> recommended solution is to load the compiler itself in its own class
> loader, so that you can throw it all away afterwards.  That's 
> the approach
> we'll take when modifying Jasper.
> 
> Craig
> 
> 
> On Fri, 20 Jul 2001, Sam Ruby wrote:
> 
> > FYI.  Bye bye "classic" compiler.
> > 
> > Ant looks safe (it uses reflection), but Jasper looks like 
> it will be
> > affected.
> > 
> > - Sam Ruby
> > 
> > -- Forwarded by Sam Ruby/Raleigh/IBM on 
> 07/20/2001
> > 07:30 AM ---
> > 
> > Davanum Srinivas <[EMAIL PROTECTED]> on 07/20/2001 06:16:57 AM
> > 
> > Please respond to [EMAIL PROTECTED]
> > 
> > To:   [EMAIL PROTECTED]
> > cc:
> > Subject:  sun.tools.javac.Main will be removed from JDK1.4
> > 
> > 
> > 
> > FYI,
> > 
> > -Original Message-
> > From: Leclair, Donald
> > Sent: Thursday, July 19, 2001 7:15 PM
> > To: J2EE Communications
> > Subject: Message 14: Class change impact
> > 
> > 
> > Sent: Thursday, July 19, 2001 7:08 PM
> > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Subject: Class change impact
> > 
> > 
> > Dear Licensee,
> > 
> > The Java(TM) 2 Platform, Standard Edition team will be making
> > a change that might impact you.
> > 
> > The change is that the class "sun.tools.javac.Main"
> > (used for compiling java classes) will be removed in J2SE 1.4.
> > This is not a public API change. If you depend on this class
> > you may be impacted.
> > 
> > If you have questions, please follow-up with your designated
> > Licensee Engineer.
> > 
> > Regards,
> > Jill Smith
> > Java Partner Engineering
> > 
> > =
> > Davanum Srinivas, JNI-FAQ Manager
> > http://www.jGuru.com/faq/JNI
> > 
> > __
> > Do You Yahoo!?
> > Get personalized email addresses from Yahoo! Mail
> > http://personal.mail.yahoo.com/
> > 
> > 
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> > 
> > 
> > 
> > 
> 

Re: [TC4] jakarta-regexp.jar

[Glenn Nielsen]

[EMAIL PROTECTED] wrote:
> 
> > >The problem you are having can be easily resolved by simply editing your
> > >local jakarta-turbine-4.0/build.properties or your
> > >${user.home}/build.properties
> >
> > Why could still use symlink as I do in my RPM :)
> >
> > ln -s jakarta-regexp-1.2.jar jakarta-regexp.jar
> 
> Yes, these are all possible solutions, but I'd prefer it if there
> weren't a problem in the first place.  "Easily" editing a file or
> making a symlink is one more step that a local user can mess up.
> (user = developer, I know, but it's an open source project; it should
> be as simple as possible for people to fix bugs etc.)
> 
> Anyway, nevermind.  I see I'm not going to make headway here.  :-)
> 

-1 For putting jar files in cvs ;-)

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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

[costin]

costin  01/07/20 11:46:04

  Modified:src/share/org/apache/tomcat/modules/config ApacheConfig.java
  Log:
  Remove the SetHandler option.
  
  This is new code, and will probably be available with all the new
  features and ajp14 as part of j-t-c.
  
  There is no need to put it into the official 3.3 beta/release - people
  who need this feature will be better served by a standalone module, as
  this is likely to evolve in the future ( as oposed to the 3.3 "main" codebase,
  which is supposed to remain freezed - so we can focus on features and modules
  knowing the base is stable and it's not going to change )
  
  The current autoconfiguration mechanism in 3.3 ( using JkMount ) should work
  as well ( or better ) than before, with either the old mod_jk or the new
  one.
  
  Revision  ChangesPath
  1.19  +10 -36
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ApacheConfig.java
  
  Index: ApacheConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ApacheConfig.java,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- ApacheConfig.java 2001/07/20 12:45:20 1.18
  +++ ApacheConfig.java 2001/07/20 18:46:04 1.19
  @@ -1,4 +1,4 @@
  -/* $Id: ApacheConfig.java,v 1.18 2001/07/20 12:45:20 larryi Exp $
  +/* $Id: ApacheConfig.java,v 1.19 2001/07/20 18:46:04 costin Exp $
* 
*
* The Apache Software License, Version 1.1
  @@ -127,9 +127,6 @@
the web.xml may not be duplicated in Apache.
Review the mod_jk.conf file to see what
configuration is actually being set in Apache.
  - useJkMount - If true, use JkMount mount directives.  If false,
  -  and SetHandler directives are used.
  - the default is true.
jkDebug - JK Loglevel setting.  May be debug, info, error, or emerg.
 If not set, defaults to no log.
noRoot - If true, the root context is not mapped to
  @@ -140,7 +137,7 @@
   
   @author Costin Manolache
   @author Mel Martinez
  - @version $Revision: 1.18 $ $Date: 2001/07/20 12:45:20 $
  + @version $Revision: 1.19 $ $Date: 2001/07/20 18:46:04 $
*/
   public class ApacheConfig  extends BaseInterceptor { 
   
  @@ -237,13 +234,6 @@
forwardAll=b;
   }
   
  -/** Use JkMount directives ( default ) or 
  - and SetHandler ( if false )
  -*/
  -public void setUseJkMount( boolean b ) {
  - useJkMount=b;
  -}
  -
   /** Special option - do not generate mappings for the ROOT
   context. The default is true, and will not generate the mappings,
   not redirecting all pages to tomcat (since /* matches everything).
  @@ -579,17 +569,11 @@
log("Ignoring root context in mount-all mode  ");
return true;
} 
  - if( useJkMount ) {
  - mod_jk.println(indent + "JkMount " +  nPath + " " + jkProto );
  -if( "".equals(ctxPath) )
  -mod_jk.println(indent + "JkMount " +  nPath + "* " + jkProto );
  -else
  -mod_jk.println(indent + "JkMount " +  nPath + "/* " + jkProto );
  - } else {
  - mod_jk.println(indent + "");
  - mod_jk.println(indent + "SetHandler jakarta-servlet");
  - mod_jk.println(indent + "");
  - }
  + mod_jk.println(indent + "JkMount " +  nPath + " " + jkProto );
  + if( "".equals(ctxPath) )
  + mod_jk.println(indent + "JkMount " +  nPath + "* " + jkProto );
  + else
  + mod_jk.println(indent + "JkMount " +  nPath + "/* " + jkProto );
if( vhost != null ) {
mod_jk.println("");
indent="";
  @@ -685,25 +669,15 @@
   private boolean addExtensionMapping( String ctxPath, String ext,
 PrintWriter mod_jk )
   {
  - mod_jk.println(indent + "" );
  - mod_jk.println(indent + "SetHandler jakarta-servlet ");
  - mod_jk.println(indent + "");
  + mod_jk.println(indent + "JkMount " + ctxPath + "/*." + ext
  ++ " " + jkProto);
return true;
   }
   
   
   private boolean addMapping( String fullPath, PrintWriter mod_jk ) {
log( "Adding map for " + fullPath );
  - if( useJkMount ) {
  - mod_jk.println(indent + "JkMount " + fullPath + "  " + jkProto );
  - } else {
  - mod_jk.println(indent + "");
  - mod_jk.println(indent + "SetHandler jakarta-servlet ");
  - // XXX Other nice things like setting servlet and other attributes
  - mod_jk.println(indent + "");
  - mod_jk.println();
  - }
  + mod_jk.println(indent + "JkMount " +

cvs commit: jakarta-tomcat/src/doc readme

[larryi]

larryi  01/07/20 11:42:33

  Modified:src/doc  readme
  Log:
  Update some information on the connector interceptors.
  
  Revision  ChangesPath
  1.17  +7 -4  jakarta-tomcat/src/doc/readme
  
  Index: readme
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/doc/readme,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- readme2001/07/19 20:20:10 1.16
  +++ readme2001/07/20 18:42:33 1.17
  @@ -1,4 +1,4 @@
  -$Id: readme,v 1.16 2001/07/19 20:20:10 larryi Exp $
  +$Id: readme,v 1.17 2001/07/20 18:42:33 larryi Exp $
   
  Release Notes for:
  
  @@ -99,9 +99,12 @@
Conf file:conf/jk/obj.conf-auto
 Workers file:conf/jk/workers.properties
   
  -  Note: The old organization used in Tomcat 3.2 where all the configuration is
  -  placed in server.xml is still supported by Tomcat 3.3b1 for Apache.  However,
  -  you will need to set the appropriate parameters on the interceptor.
  +  Note: The ApacheConfig, JservConfig, and IISConfig by default write a
  +  config file that tries to send all requests for a context to Tomcat.  That
  +  is the best way to insure that behavior specified in the web application's
  +  web.xml functions properly.  If you desire, you can copy the auto generated
  +  file and modify it to have the web server serve some of the web application's
  +  resources.
   
   - Tomcat Testing:
   
  
  
  

Re: jakarta-watchdog-4.0

[Craig R. McClanahan]

I'm going to take a pass through all the build stuff for
jakarta-tomcat-4.0, jakarta-servletapi-4, and jakarta-watchdog-4.0 in the
next couple of days.  I'll incorporate appropriate stuff from your READMEs
as well.

Craig


On Fri, 20 Jul 2001, jean-frederic clere wrote:

> Hi,
> 
> The build complains for: "[copydir] DEPRECATED - The copydir task is
> deprecated.  Use copy instead.", I should fix it?
> 
> Cheers
> 
> Jean-frederic
> 

Re: [TC4] jakarta-regexp.jar

[Craig R. McClanahan]

On Fri, 20 Jul 2001 [EMAIL PROTECTED] wrote:

> > >The problem you are having can be easily resolved by simply editing your
> > >local jakarta-turbine-4.0/build.properties or your
> > >${user.home}/build.properties
> > 
> > Why could still use symlink as I do in my RPM :)
> > 
> > ln -s jakarta-regexp-1.2.jar jakarta-regexp.jar 
> 
> Yes, these are all possible solutions, but I'd prefer it if there
> weren't a problem in the first place.  "Easily" editing a file or
> making a symlink is one more step that a local user can mess up.
> (user = developer, I know, but it's an open source project; it should
> be as simple as possible for people to fix bugs etc.)
> 
> Anyway, nevermind.  I see I'm not going to make headway here.  :-)
> 

By the way, Alex, I *do* agree with you that version numbers in JAR files
are a pain :-).

>  - A
> 
> -- 
> Alex Chaffee   mailto:[EMAIL PROTECTED]

Craig

Re: [DOC] Re: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/class es

[Craig R. McClanahan]

On Fri, 20 Jul 2001, Rob S. wrote:

> A, maybe I should add this to the INSTALL.txt file - unset your
> CLASSPATH before starting TC?  I've logged into my fair share of *nix boxes
> where the admins have conveniently set a system-wide CLASSPATH containing an
> XML parser, etc.
> 

The standard Tomcat 4 startup scripts already ignore your CLASSPATH
variable, and reconstruct one tuned to its needs.  If you want to make
application classes available to all web apps, put them (unpacked) into
$CATALINA_HOME/classes or in JAR files under $CATALINA_HOME/lib.

Craig

Re: [DOC] Re: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/class es

[David Haraburda]

I don't think unsetting your CLASSPATH is necessary, especially since other
applications may rely on it.  I would guess that most problems occur when:

1) You add things you have in your WEB-INF/classes to your CLASSPATH (thus causing them
to be loaded by the system class loader, not the Tomcat web app class loader, which
causes problems)

or, as the case would appear to be with the POET sdk referred to before,

2) Your web application requires a certain JAR that you have placed in your WEB-INF/lib
directory, but unbeknownst to you, there is actually another JAR (perhaps an older
version of the software) sitting in your classpath, which gets loaded first.

Remember, a classloader always asks it's parent classloader to load a resource first,
and then only loads it itself if the parent cannot find it.

Just make sure things your web application requires are in your WEB-INF/libs directory,
and not in your classpath.

Craig McClanahan has two good posts about this:

http://mikal.org/interests/java/tomcat/archive/view?mesg=22444
http://mikal.org/interests/java/tomcat/archive/view?mesg=8512

As far as logging goes, you may want to check out the  elements is your
server.xml file. They provide a good way to keep your terminal un-cluttered. :-)

David

David Rees wrote:

> On Fri, Jul 20, 2001 at 06:22:21AM -0700, Rob S. wrote:
> > A, maybe I should add this to the INSTALL.txt file - unset your
> > CLASSPATH before starting TC?  I've logged into my fair share of *nix boxes
> > where the admins have conveniently set a system-wide CLASSPATH containing an
> > XML parser, etc.
>
> I think it's the safe thing to do.  I think Tomcat 3.3 and Tomcat 4 both do this by
> default.  For Tomcat 3.2.X, I do this in custom startup scripts which make
> startup/shutdown a lot easier if you're maintaining multiple copies of Tomcat per
> host.  I also modify bin/tomcat.sh to redirect stdout/err to log files instead of
> cluttering the terminal.  If anyone is interested, I can send copies of the scripts
> and the patch to tomcat.sh...
>
> I would at least like to see the stdout/err patch integrated into Tomcat, I just
> don't know if there's much interest in including it into Tomcat 3.2.
>
> -Dave

Post B6 modifications...

[Pier P. Fumagalli]

This is the first set of modifications I made to the Catalina code to allow
port < 1024 binding under Unix. Basically, I added an "initialize()" method
to Server, Service and Connector, and that gets called appropriately before
"start()". Now, the only thing left to do is to move the ServerSocket
creation within connectors in "initialize()", and launch Catalina with a
wrapper around the Service code I committed last week.

Basically, during "load()" in service, we build the whole components tree
and call "initialize()" on the Server. Then during "start()" and "stop()" we
call the same methods in Server, and (in theory) the trick should be done.

I'd need to modify Remy's BootstrapService and CatalinaService to perform a
two-stage initialization process (and I don't know what JavaService, the one
he's using under Windows does), but, more or less, that should be it...

This patch actually starts fixing things, but doesn't break the build
neither compromises functionality (checked it already), but I would like
someone (Craig/Remy/Amy/Glenn...) to review it and, if ok, apply it...

Cheers...

Pier (back from the cops)




Index: Connector.java
===
RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Connector.java,v
retrieving revision 1.5
diff -c -3 -r1.5 Connector.java
*** Connector.java  2001/05/09 23:42:07 1.5
--- Connector.java  2001/07/20 17:38:25
***
*** 240,244 
--- 240,252 
   */
  public Response createResponse();
  
+ /**
+  * Invoke a pre-startup initialization. This is used to allow connectors
+  * to bind to restricted ports under Unix operating environments.
+  *
+  * @exception LifecycleException If this server was already initialized.
+  */
+ public void initialize()
+ throws LifecycleException;
  
  }
Index: Server.java
===
RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Server.java,v
retrieving revision 1.2
diff -c -3 -r1.2 Server.java
*** Server.java 2000/09/30 19:15:43 1.2
--- Server.java 2001/07/20 17:38:25
***
*** 163,167 
   */
  public void removeService(Service service);
  
! 
  }
--- 163,174 
   */
  public void removeService(Service service);
  
! /**
!  * Invoke a pre-startup initialization. This is used to allow connectors
!  * to bind to restricted ports under Unix operating environments.
!  *
!  * @exception LifecycleException If this server was already initialized.
!  */
! public void initialize()
! throws LifecycleException;
  }
Index: Service.java
===
RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Service.java,v
retrieving revision 1.2
diff -c -3 -r1.2 Service.java
*** Service.java2000/12/14 02:56:13 1.2
--- Service.java2001/07/20 17:38:25
***
*** 150,154 
--- 150,162 
   */
  public void removeConnector(Connector connector);
  
+ /**
+  * Invoke a pre-startup initialization. This is used to allow connectors
+  * to bind to restricted ports under Unix operating environments.
+  *
+  * @exception LifecycleException If this server was already initialized.
+  */
+ public void initialize()
+ throws LifecycleException;
  
  }
Index: connector/http/HttpConnector.java
===
RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java,v
retrieving revision 1.18
diff -c -3 -r1.18 HttpConnector.java
*** connector/http/HttpConnector.java   2001/07/10 07:36:42 1.18
--- connector/http/HttpConnector.java   2001/07/20 17:38:26
***
*** 258,263 
--- 258,269 
  
  
  /**
+  * Has this component been initialized yet?
+  */
+ private boolean initialized = false;
+ 
+ 
+ /**
   * Has this component been started yet?
   */
  private boolean started = false;
***
*** 1055,1060 
--- 1061,1079 
  
lifecycle.removeLifecycleListener(listener);
  
+ }
+ 
+ 
+ /**
+  * Initialize this connector (create ServerSocket here!)
+  */
+ public void initialize()
+ throws LifecycleException {
+   if (initialized)
+   throw new LifecycleException (
+   sm.getString("httpConnector.alreadyInitialized"));
+   this.initialized=true;
+   System.err.println("HTTP Connector initialized");
  }
  
  
Index: connector/http/LocalStrings.properties
===
RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/LocalStrings.properties,v
retrieving revision 1.3
diff -c -3 -r1.3 

cvs commit: jakarta-tomcat/src/tests/webpages/WEB-INF test-tomcat.xml

[larryi]

larryi  01/07/20 10:43:25

  Modified:src/tests/webpages/WEB-INF test-tomcat.xml
  Log:
  Add test to insure normal ";jsessionid" works as expected.
  
  Revision  ChangesPath
  1.39  +7 -1  jakarta-tomcat/src/tests/webpages/WEB-INF/test-tomcat.xml
  
  Index: test-tomcat.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/tests/webpages/WEB-INF/test-tomcat.xml,v
  retrieving revision 1.38
  retrieving revision 1.39
  diff -u -r1.38 -r1.39
  --- test-tomcat.xml   2001/07/20 04:28:16 1.38
  +++ test-tomcat.xml   2001/07/20 17:43:25 1.39
  @@ -16,7 +16,7 @@
   early tests.
   -->
   
  -   
  +   



  @@ -1211,6 +1211,12 @@
  method="GET" />
 
 
  +  
  +  
  +  
  +  
  +  
 
  
   
  
  
  

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SessionId.java

[larryi]

larryi  01/07/20 10:42:47

  Modified:src/share/org/apache/tomcat/modules/session SessionId.java
  Log:
  req.unparsedURI may be unset. Fix NPE.
  
  Revision  ChangesPath
  1.12  +7 -5  
jakarta-tomcat/src/share/org/apache/tomcat/modules/session/SessionId.java
  
  Index: SessionId.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/session/SessionId.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- SessionId.java2001/07/18 21:06:38 1.11
  +++ SessionId.java2001/07/20 17:42:47 1.12
  @@ -139,11 +139,13 @@
// rewrite URL, do I need to do anything more?
request.requestURI().setString(uri.substring(0, foundAt));
   
  -// remove from unparsedURI too, if not already
  -foundAt = request.unparsedURI().indexOf(sig);
  -if (foundAt!=-1) {
  -uri=request.unparsedURI().toString();
  -request.unparsedURI().setString(uri.substring(0, foundAt));
  +// remove from unparsedURI too, if necessary
  +if( !request.unparsedURI().isNull() ) {
  +foundAt = request.unparsedURI().indexOf(sig);
  +if (foundAt!=-1) {
  +uri=request.unparsedURI().toString();
  +request.unparsedURI().setString(uri.substring(0, foundAt));
  +}
   }
   
// No validate now - we just note that this is what the user
  
  
  

Re: problem with mod_webapp on rh7.1

[Eric L. Anderson]

Make sure ServerName is configured prior to the mod_webapp config statements
in httpd.conf.

On Fri, Jul 20, 2001 at 12:30:49PM +0200, Michael Steindl wrote:
> hi craig,
> 
> the newest CVS files compilation seems to work properly, without having
> defined any WebAppDeploy's - thx so far!
> 
> but
> having definded the following in the httpd.conf of apache1.3:
>   # 4 tomcat
>   LoadModule webapp_module /etc/httpd/modules/mod_webapp.so
>   AddModule mod_webapp.c
>   WebAppConnection warpConnection warp localhost:8008
>   WebAppDeploy jetspeed warpConnection /jetspeed/
> 
> this error occured:
>   Starting httpd: Syntax error on line 7 of /etc/httpd/conf/httpd.conf:
>   Invalid virtual host name
>[FAILED]
> 
> any idea?
> 
> cu,
> michael.
> 
> >-Original Message-
> >From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> >Sent: Donnerstag, 19. Juli 2001 17:41
> >To: Michael Steindl
> >Subject: Re: problem with mod_webapp on rh7.1
> >
> >
> >Recent versions from the "jakarta-tomcat-connectors" CVS repository have
> >worked for me.  Can you give them a try?
> >
> >Craig
> >
> >
> >On Thu, 19 Jul 2001, Michael Steindl wrote:
> >
> >> hi craig,
> >>
> >> having the same problem than you've posted with
> >> mod_webapp/tomcat4.0b5/apache1.3/rh7.1
> >>
> >> do you have any solution until now?
> >>
> >> would be great to get a working mod_webapp module.
> >>
> >> cheers and thx,
> >> michael.
> >>
> >>
> >
> >
> 

-- 
Eric L. Anderson
[EMAIL PROTECTED]

Re: [DOC] Re: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/class es

[David Rees]

On Fri, Jul 20, 2001 at 06:22:21AM -0700, Rob S. wrote:
> A, maybe I should add this to the INSTALL.txt file - unset your
> CLASSPATH before starting TC?  I've logged into my fair share of *nix boxes
> where the admins have conveniently set a system-wide CLASSPATH containing an
> XML parser, etc.

I think it's the safe thing to do.  I think Tomcat 3.3 and Tomcat 4 both do this by
default.  For Tomcat 3.2.X, I do this in custom startup scripts which make
startup/shutdown a lot easier if you're maintaining multiple copies of Tomcat per
host.  I also modify bin/tomcat.sh to redirect stdout/err to log files instead of
cluttering the terminal.  If anyone is interested, I can send copies of the scripts 
and the patch to tomcat.sh...

I would at least like to see the stdout/err patch integrated into Tomcat, I just 
don't know if there's much interest in including it into Tomcat 3.2.

-Dave

RE: problem with mod_webapp on rh7.1

[Michael Steindl]

hi craig,

the newest CVS files compilation seems to work properly, without having
defined any WebAppDeploy's - thx so far!

but
having definded the following in the httpd.conf of apache1.3:
  # 4 tomcat
  LoadModule webapp_module /etc/httpd/modules/mod_webapp.so
  AddModule mod_webapp.c
  WebAppConnection warpConnection warp localhost:8008
  WebAppDeploy jetspeed warpConnection /jetspeed/

this error occured:
  Starting httpd: Syntax error on line 7 of /etc/httpd/conf/httpd.conf:
  Invalid virtual host name
   [FAILED]

any idea?

cu,
michael.

>-Original Message-
>From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
>Sent: Donnerstag, 19. Juli 2001 17:41
>To: Michael Steindl
>Subject: Re: problem with mod_webapp on rh7.1
>
>
>Recent versions from the "jakarta-tomcat-connectors" CVS repository have
>worked for me.  Can you give them a try?
>
>Craig
>
>
>On Thu, 19 Jul 2001, Michael Steindl wrote:
>
>> hi craig,
>>
>> having the same problem than you've posted with
>> mod_webapp/tomcat4.0b5/apache1.3/rh7.1
>>
>> do you have any solution until now?
>>
>> would be great to get a working mod_webapp module.
>>
>> cheers and thx,
>> michael.
>>
>>
>
>

Re: ajp13 slowish

[kkal]

Speak of the devil, I just ran across this page today, from a hosting
service:
http://www.aoindustries.com/servlet/com.aoindustries.website.WhatsNew

which says:
"Please note that AJP13 is still much slower than AJP12. Using AJP12,
ourstandard "Hello" servlet processes 544 requests per second. Using the
newer AJP13 protocol, that rate drops to a lowly 38 requests per
second."

Martin Lichtin wrote:
> 
> GOMEZ Henri wrote:
> w> Could you tell us more on Platform used in tests ?
> > Also could you send us code which was used to do the
> > benchmarks.
> 
> This is on a RedHat 7.1 system, with Tomcat 3.2.2, Java 1.3.1 from Sun.
> 
> Sorry, I have no actual test code. Our web application typically creates
> a frameset. Sometimes, four frames are reloaded as a result of an
> operation. Anyway, when accessing the application via port 8080, it
> responds fast, ie. all frames are drawn instantly. Accessing the
> application via port 80 (apache-ajp13), it shows delays when those
> same pages are accessed.
> It's obvious, just by clicking around, that there's something
> in Apache or ajp13 slowing it down.
> 
> Let me know if you have some benchmarking code I could run.

-- 

Regards,

Ken Kalish
http://javakk.com

jakarta-watchdog-4.0

[jean-frederic clere]

Hi,

The build complains for: "[copydir] DEPRECATED - The copydir task is
deprecated.  Use copy instead.", I should fix it?

Cheers

Jean-frederic

jakarta-watchdog-4.0 [Insufficient Karma!]

[jean-frederic clere]

Hi,

I have tried to commit the following changes in jakarta-watchdog-4.0/Readme but
I have got the following error message:
 Access denied: Insufficient Karma (jfclere|jakarta-watchdog-4.0)   
cvs server: Pre-commit check failed 

Could someone with more Karma commit the patch attached?

Cheers

Jean-frederic

Index: Readme
===
RCS file: /home/cvs/jakarta-watchdog-4.0/Readme,v
retrieving revision 1.2
diff -u -r1.2 Readme
--- Readme  2001/01/24 22:46:15 1.2
+++ Readme  2001/07/20 15:32:29
@@ -39,12 +39,12 @@
   subdirectory, which will be used when building Watchdog.
 
 * Download and install the Servletapi distribution (subproject
-  "jakarta-servletapi") into a subdirectory named
-  "$JAKARTA_HOME/jakarta-servletapi".  If you have downloaded the source
+  "jakarta-servletapi-4") into a subdirectory named
+  "$JAKARTA_HOME/jakarta-servletapi-4".  If you have downloaded the source
   distribution, you will need to build the executable version by
   executing the following commands:
 
-   cd $JAKARTA_HOME/jakarta-servletapi
+   cd $JAKARTA_HOME/jakarta-servletapi-4
./build.sh dist <-- Unix
build dist  <-- Windows
 
@@ -68,7 +68,7 @@
   If you have downloaded the source distribution, you will need to build the
   executable version by executing the following commands:
 
-   cd $JAKARTA_HOME/jakarta-tomcat
+   cd $JAKARTA_HOME/jakarta-tomcat-4.0
./build.sh dist <-- Unix
build dist  <-- Windows
 
@@ -77,16 +77,16 @@
   to practice executing the Watchdog tests, as described below.
 
 * Download and install the Watchdog source distribution (subproject
-  "jakarta-watchdog") into a subdirectory named
-  "$JAKARTA_HOME/jakarta-watchdog".  To build the executable version
+  "jakarta-watchdog-4.0") into a subdirectory named
+  "$JAKARTA_HOME/jakarta-watchdog-4.0".  To build the executable version
   of Watchdog, execute the following commands:
 
-   cd $JAKARTA_HOME/jakarta-watchdog
+   cd $JAKARTA_HOME/jakarta-watchdog-4.0
./build.sh dist <-- Unix
build dist  <-- Windows
 
   This will result in a binary distribution version of Watchdog being
-  built in directory "$JAKARTA_HOME/dist/watchdog", which can be used
+  built in directory "$JAKARTA_HOME/watchdog-4.0/dist", which can be used
   to execute the tests against your servlet container as described below.
 
 
@@ -102,13 +102,13 @@
 * Deploy the two web applications into your servlet container.  If you have
   downloaded and built the Tomcat source distribution, you would do this:
 
-   cd $JAKARTA_HOME/dist/watchdog/webapps
-   cp *.war ../../tomcat/webapps
+   cd $JAKARTA_HOME/jakarta-watchdog-4.0/dist/webapps
+   cp *.war $JAKARTA_HOME/jakarta-tomcat-4.0/dist/webapps
 
 * Start your servlet container.  If you have downloaded and built the Tomcat
   source distribution, you would do this:
 
-   cd $JAKARTA_HOME/dist/tomcat
+   cd $JAKARTA_HOME/jakarta-tomcat-4.0/dist
bin/startup.sh  <-- Unix
bin\startup <-- Windows
 
@@ -116,7 +116,7 @@
   against a servlet container at http://localhost:8080 with the test suite
   deployed, but the server name and port can be added as arguments.
 
-   cd $JAKARTA_HOME/dist/watchdog/bin
+   cd $JAKARTA_HOME/jakarta-watchdog-4.0/dist/bin
./watchdog.sh servlet [hostname] [port] <-- Unix
watchdog servlet [hostname] [port]  <-- Windows
 
@@ -124,7 +124,7 @@
   against a servlet container at http://localhost:8080 with the test suite
   deployed, but the server name and port can be added as arguments.
 
-   cd $JAKARTA_HOME/dist/watchdog/bin
+   cd $JAKARTA_HOME/jakarta-watchdog-4.0/dist/bin
./watchdog.sh jsp [hostname] [port] <-- Unix
watchdog jsp [hostname] [port]  <-- Windows
 
@@ -134,7 +134,7 @@
   delete the "expanded" versions of the two web applications in order for
   the new war files to be deployed, as follows:
 
-   cd $JAKARTA_HOME/dist/tomcat/webapps
+   cd $JAKARTA_HOME/jakarta-tomcat-4.0/dist/webapps
rm -rf jsp-tests
rm -rf servlet-tests
 

Re: [TC4] jakarta-regexp.jar

[guru]

> >The problem you are having can be easily resolved by simply editing your
> >local jakarta-turbine-4.0/build.properties or your
> >${user.home}/build.properties
> 
> Why could still use symlink as I do in my RPM :)
> 
> ln -s jakarta-regexp-1.2.jar jakarta-regexp.jar 

Yes, these are all possible solutions, but I'd prefer it if there
weren't a problem in the first place.  "Easily" editing a file or
making a symlink is one more step that a local user can mess up.
(user = developer, I know, but it's an open source project; it should
be as simple as possible for people to fix bugs etc.)

Anyway, nevermind.  I see I'm not going to make headway here.  :-)

 - A

-- 
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/

cvs commit: jakarta-tomcat-connectors/jk/native/apache-1.3 mod_jk.dsp

[mmanders]

mmanders01/07/20 08:10:26

  Modified:jk/native/apache-1.3 mod_jk.dsp
  Log:
  Fixed project so that MSDev can use it.
  
  Revision  ChangesPath
  1.5   +10 -10jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.dsp
  
  Index: mod_jk.dsp
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.dsp,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- mod_jk.dsp2001/06/07 13:48:45 1.4
  +++ mod_jk.dsp2001/07/20 15:10:26 1.5
  @@ -146,23 +146,23 @@
   
   SOURCE=.\mod_jk.c
   # End Source File
  -# End Group
  +# Begin Source File
   
   SOURCE=..\common\jk_ajp14.c
   # End Source File
  -# End Group
  +# Begin Source File
   
   SOURCE=..\common\jk_ajp14_worker.c
   # End Source File
  -# End Group
  +# Begin Source File
   
   SOURCE=..\common\jk_md5.c
   # End Source File
  -# End Group
  +# Begin Source File
   
   SOURCE=..\common\jk_context.c
   # End Source File
  -# End Group
  +# Begin Source File
   
   SOURCE=..\common\jk_ajp_common.c
   # End Source File
  @@ -243,23 +243,23 @@
   
   SOURCE=..\common\jk_worker_list.h
   # End Source File
  -# End Group
  +# Begin Source File
   
   SOURCE=..\common\jk_ajp14.h
   # End Source File
  -# End Group
  +# Begin Source File
   
   SOURCE=..\common\jk_ajp14_worker.h
   # End Source File
  -# End Group
  +# Begin Source File
   
   SOURCE=..\common\jk_md5.h
   # End Source File
  -# End Group
  +# Begin Source File
   
   SOURCE=..\common\jk_context.h
   # End Source File
  -# End Group
  +# Begin Source File
   
   SOURCE=..\common\jk_ajp_common.h
   # End Source File
  
  
  

cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp14_worker.h

[mmanders]

mmanders01/07/20 08:09:48

  Modified:jk/native/common jk_ajp14_worker.h
  Log:
  Added a define for snprintf under Windows.
  
  Revision  ChangesPath
  1.4   +6 -1  jakarta-tomcat-connectors/jk/native/common/jk_ajp14_worker.h
  
  Index: jk_ajp14_worker.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp14_worker.h,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- jk_ajp14_worker.h 2001/06/18 14:15:28 1.3
  +++ jk_ajp14_worker.h 2001/07/20 15:09:48 1.4
  @@ -58,7 +58,7 @@
   /***
* Description: ajpv14 worker header file  *
* Author:  Henri Gomez <[EMAIL PROTECTED]>   *
  - * Version: $Revision: 1.3 $   *
  + * Version: $Revision: 1.4 $   *
***/
   
   #ifndef JK_AJP14_WORKER_H
  @@ -79,6 +79,11 @@
   #endif /* __cplusplus */
   
   #define JK_AJP14_WORKER_NAME ("ajp14")
  +
  +#ifdef WIN32
  +/* define snprint to match windows version */
  +#define snprintf _snprintf
  +#endif
   
   int JK_METHOD ajp14_worker_factory(jk_worker_t **w,
  const char *name,
  
  
  

Re: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/classes

[David Haraburda]

Oops,

That's right, you can read any file you want from WEB-INF/classes using
getResource() (which is probably what you are doing) -- that is implemented
correctly in AdaptiveClassLoader.  If you want to find all resources of a
specified name (for example, you have a properties file of the same name at
the web-application level and the system level, and you want to concatenate
values from both places together), the ClassLoader class provides a
getResources() method.  (This method in turn calls findResources which is
supposed to be implemented in all subclasses of ClassLoader, but isn't for
AdaptiveClassLoader)

I'm glad to know that fixed it.

David

Will England wrote:

> On Fri, 20 Jul 2001, David Haraburda wrote:
>
> > Have you tried using the Jdk12Interceptor?  That fixed class loading
> > problems for me.  In your server.xml do:
> >
> >  > className="org.apache.tomcat.request.Jdk12Interceptor"/>
>
> Got that, and it fixed the finding of my .conf files that I store in
> WEB-INF/classes.  I can now read any text file I want from WEB-INF/classes
> from a servlet.
>
> > Note this will only fix the loading of CLASSES... if you have resources
> > in your WEB-INF/classes directory, such as .properties files, that the
> > ClassLoader is supposed to pick up, this will not happen.  I submitted a
> > patch for this to the mailing list last night, but haven't heard
> > anything from a developer/committer yet.
>
> Odd.  Worked well for me.  As soon as the admin gets the box back up, I'll
> drop you a copy of my server.xml and the code I use to read a text file.
>
> > A good way to see what ClassLoader is being used is by sticking in a
> > System.out.println( "CL: " +
> > Thread.currentThread().getContextClassLoader().toString() );
> >
> > If it says com.sun.misc.something (I forget the package name), you are
> > using the System classloader... if it says AdaptiveClassLoader, you are
> > using the Tomcat one which knows about stuff in the WEB-INF directory.
>
> Nice tip - I'll try that!
>
> Will

Re: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/classes

[Will England]

On Fri, 20 Jul 2001, David Haraburda wrote:

> Have you tried using the Jdk12Interceptor?  That fixed class loading
> problems for me.  In your server.xml do:
> 
>  className="org.apache.tomcat.request.Jdk12Interceptor"/>

Got that, and it fixed the finding of my .conf files that I store in
WEB-INF/classes.  I can now read any text file I want from WEB-INF/classes
from a servlet.

> Note this will only fix the loading of CLASSES... if you have resources
> in your WEB-INF/classes directory, such as .properties files, that the
> ClassLoader is supposed to pick up, this will not happen.  I submitted a
> patch for this to the mailing list last night, but haven't heard
> anything from a developer/committer yet.

Odd.  Worked well for me.  As soon as the admin gets the box back up, I'll
drop you a copy of my server.xml and the code I use to read a text file.

> A good way to see what ClassLoader is being used is by sticking in a
> System.out.println( "CL: " +
> Thread.currentThread().getContextClassLoader().toString() );
> 
> If it says com.sun.misc.something (I forget the package name), you are
> using the System classloader... if it says AdaptiveClassLoader, you are
> using the Tomcat one which knows about stuff in the WEB-INF directory.


Nice tip - I'll try that!

Will

RE: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/classes

[Will England]

On Fri, 20 Jul 2001, Andrew McGhee wrote:

> Guys,
> I've copied in an email returned to a support desk regarding a problem
> similar to this. There is a link to mikal.org that explains it in better
> detail, but essentially it refers to where your classes are found, as to
> what classloader they inherit. And the solution we found (similar to the
> post) is to ensure your classpath is unset before starting Tomcat.
> 

The solution posted (unset your classpath, cause there might be a class
with the same name somewhere else) is fine for first year university
students.  Most likely, that *is* what causes their problems.  

But, I have set, unset, hard coded, soft coded and so on the classpath.

In tomcat.sh, I have a hard-coded classpath pointing to the .jar files in
TOMCAT_HOME/lib, and tools.jar.  Nothing else.  I try to hit a JSP for the
first time, the compile fails.  Jasper reports that it cannot find classes
that are located in the web applications WEB-INF/classes
directory.  Theoretically, the adaptive classloader should know about
WEB-INF/classes, and I thought Jaspter used the adaptive classloader.

If I change the hard-coded classpath in tomcat.sh to point to the web
applications WEB-INF/classes directory, so that the WEB-INF/classes folder
is in the system classpath, Jasper can now find the classes and
compilation continues normally.

Can one of the developers detail out where Jasper looks for classes for
compiling JSPs?

Thanks for any tips or suggestions!

Will

Re: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/classes

[David Haraburda]

Hi,

I too missed the original message, but have been dealing with these
problems myself.

Have you tried using the Jdk12Interceptor?  That fixed class loading
problems for me.  In your server.xml do:



There are some weird classloader issues w/ Java 2 that this fixes.

Note this will only fix the loading of CLASSES... if you have resources
in your WEB-INF/classes directory, such as .properties files, that the
ClassLoader is supposed to pick up, this will not happen.  I submitted a
patch for this to the mailing list last night, but haven't heard
anything from a developer/committer yet.

A good way to see what ClassLoader is being used is by sticking in a
System.out.println( "CL: " +
Thread.currentThread().getContextClassLoader().toString() );

If it says com.sun.misc.something (I forget the package name), you are
using the System classloader... if it says AdaptiveClassLoader, you are
using the Tomcat one which knows about stuff in the WEB-INF directory.

David

Will England wrote:
> 
> On Thu, 19 Jul 2001, David Rees wrote:
> 
> > (Sorry about the double-qoute, I missed the original message)
> >
> >
> > I have noticed the same problem while doing some development using
> > Tomcat 3.2.[23].  I worked around it by making sure that I unset the
> > classpath before calling startup.sh, then things seemed to work properly
> > and classes were found as expected.
> 
> Tried that.  Tried hard-coding the classpath.  If the web applications
> WEB-INF/classes directory was in the system classpath, it compiles.  If it
> is not in the system classpath, the JSP's do not compile.
> 
> So, why does Jasper not know about the web-application classpath?
> 
> Will

-- 
David Haraburda - [EMAIL PROTECTED]
Everest - Helping You Manage Outsourcing
972-980-0013 x736

Re: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/classes

[Will England]

On Thu, 19 Jul 2001, David Rees wrote:

> (Sorry about the double-qoute, I missed the original message)
> 
> 
> I have noticed the same problem while doing some development using
> Tomcat 3.2.[23].  I worked around it by making sure that I unset the
> classpath before calling startup.sh, then things seemed to work properly
> and classes were found as expected.

Tried that.  Tried hard-coding the classpath.  If the web applications
WEB-INF/classes directory was in the system classpath, it compiles.  If it
is not in the system classpath, the JSP's do not compile.  

So, why does Jasper not know about the web-application classpath?  

Will

RE: Problem with mod_jk 1.2.0 (latest CVS snapshot)

[GOMEZ Henri]

>Just did a DSO version and couldn't replicate the problem (BTW, I've
>recompiled/statically linked Apache and mod_jk again since then and the
>problem was still there). So, maybe it has to do with statically linking
>Apache after all...

Strange problem. What's the difference between static and dynamic.
We may have missed something at mod_jk init time ?

>I still have to distribute this DSO version of Apache and mod_jk to some
>slower machines to see if that makes any difference at all. The machine
>that didn't produce any errors is a 1 GHz Athlon, so timing issues could
>have been resolved by brute force, who knows...

Thanks to tell us what happened...

>Is there a recommendation as to the order of loading mod_jk for both
>statically linked version and the DSO version? Maybe that's important.

I load mod_jk after alias and before rewrite and never get any problems.
Not I also use php4


LoadModule mmap_static_module lib/apache/mod_mmap_static.so
LoadModule vhost_alias_module lib/apache/mod_vhost_alias.so
LoadModule env_module lib/apache/mod_env.so
LoadModule define_module  lib/apache/mod_define.so
LoadModule config_log_module  lib/apache/mod_log_config.so
LoadModule agent_log_module   lib/apache/mod_log_agent.so
LoadModule referer_log_module lib/apache/mod_log_referer.so
LoadModule mime_magic_module  lib/apache/mod_mime_magic.so
LoadModule mime_modulelib/apache/mod_mime.so
LoadModule negotiation_module lib/apache/mod_negotiation.so
LoadModule status_module  lib/apache/mod_status.so
LoadModule info_modulelib/apache/mod_info.so
LoadModule includes_modulelib/apache/mod_include.so
LoadModule autoindex_module   lib/apache/mod_autoindex.so
LoadModule dir_module lib/apache/mod_dir.so
LoadModule cgi_module lib/apache/mod_cgi.so
LoadModule asis_modulelib/apache/mod_asis.so
LoadModule imap_modulelib/apache/mod_imap.so
LoadModule action_module  lib/apache/mod_actions.so
LoadModule speling_module lib/apache/mod_speling.so
LoadModule userdir_module lib/apache/mod_userdir.so
LoadModule alias_module   lib/apache/mod_alias.so
LoadModule jk_module  lib/apache/mod_jk.so
LoadModule auth_ldap_module   lib/apache/auth_ldap.so
LoadModule rewrite_module lib/apache/mod_rewrite.so
LoadModule access_module  lib/apache/mod_access.so
LoadModule auth_modulelib/apache/mod_auth.so
LoadModule anon_auth_module   lib/apache/mod_auth_anon.so
LoadModule dbm_auth_modulelib/apache/mod_auth_dbm.so
LoadModule db_auth_module lib/apache/mod_auth_db.so
LoadModule digest_module  lib/apache/mod_digest.so
LoadModule proxy_module   lib/apache/libproxy.so
LoadModule cern_meta_module   lib/apache/mod_cern_meta.so
LoadModule expires_module lib/apache/mod_expires.so
LoadModule headers_module lib/apache/mod_headers.so
LoadModule usertrack_module   lib/apache/mod_usertrack.so
LoadModule example_module lib/apache/mod_example.so
LoadModule unique_id_module   lib/apache/mod_unique_id.so
LoadModule setenvif_modulelib/apache/mod_setenvif.so
LoadModule php4_modulelib/apache/libphp4.so
LoadModule perl_modulelib/apache/libperl.so
LoadModule dav_module lib/apache/libdav.so
LoadModule gzip_module  lib/apache/mod_gzip.so


LoadModule ssl_module lib/apache/libssl.so


...

ClearModuleList
AddModule mod_mmap_static.c
AddModule mod_vhost_alias.c
AddModule mod_env.c
AddModule mod_define.c
AddModule mod_log_config.c
AddModule mod_log_agent.c
AddModule mod_log_referer.c
AddModule mod_mime_magic.c
AddModule mod_mime.c
AddModule mod_negotiation.c
AddModule mod_status.c
AddModule mod_info.c
AddModule mod_include.c
AddModule mod_autoindex.c
AddModule mod_dir.c
AddModule mod_cgi.c
AddModule mod_asis.c
AddModule mod_imap.c
AddModule mod_actions.c
AddModule mod_speling.c
AddModule mod_userdir.c
AddModule mod_alias.c
AddModule mod_jk.c
AddModule auth_ldap.c
AddModule mod_rewrite.c
AddModule mod_access.c
AddModule mod_auth.c
AddModule mod_auth_anon.c
AddModule mod_auth_dbm.c
AddModule mod_auth_db.c
AddModule mod_digest.c
AddModule mod_proxy.c
AddModule mod_cern_meta.c
AddModule mod_expires.c
AddModule mod_headers.c
AddModule mod_usertrack.c
AddModule mod_example.c
AddModule mod_unique_id.c
AddModule mod_so.c
AddModule mod_setenvif.c
AddModule mod_php4.c
AddModule mod_perl.c
AddModule mod_dav.c
AddModule mod_gzip.c


AddModule mod_ssl.c

[DOC] Re: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/class es

[Rob S.]

A, maybe I should add this to the INSTALL.txt file - unset your
CLASSPATH before starting TC?  I've logged into my fair share of *nix boxes
where the admins have conveniently set a system-wide CLASSPATH containing an
XML parser, etc.

- r

On Fri, 20 Jul 2001 12:59:01 +0100 [EMAIL PROTECTED] wrote:
> Guys,
> I've copied in an email returned to a support desk regarding a problem
> similar to this. There is a link to mikal.org that explains it in better
> detail, but essentially it refers to where your classes are found, as to
> what classloader they inherit. And the solution we found (similar to the
> post) is to ensure your classpath is unset before starting Tomcat.
> 
> Regards,
> Andrew Mc.Ghee
> 
> > Thanks again for your help on this,
> > Looks like we have tracked down the problem, and it was due to a
> reference to the Poet SDK on the CLASSPATH. References to > Poet code was
> finding the class instance on the jar file specified within the CLASSPATH
> itself, and so was not having
> > access to the classloader from tomcat, making anything within
> webapps/WEB-INF/lib unavailable. We have simply removed the
> > reference to the poet jar files from the classpath, and placed the jar
> file within the webapps/WEB-INF/lib directory, and
> > voila! (No need to set the database classloader now either)
> 
> > Thanks again for your assistance in this, pointing out the classpath
> loading help to isolate the problem.
> 
> > A useful link regarding this problem was;
> http://mikal.org/interests/java/tomcat/archive/view?mesg=22444 (And
> probably > explains the situation far better than I can)
> 
> -Original Message-
> 
> -Original Message-
> From: David Rees [mailto:[EMAIL PROTECTED]]
> Sent: 19 July 2001 22:27
> To: [EMAIL PROTECTED]
> Subject: Re: [3.2] JSP Compiling Classpath issues -- finding
> WEB-INF/classes
> 
> 
> (Sorry about the double-qoute, I missed the original message)
> 
> > > -Original Message-
> > > From: Will England [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, July 19, 2001 10:49 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: [3.2] JSP Compiling Classpath issues -- finding
> WEB-INF/classes > >
> > >
> > > Greetings!
> > >
> > > Over on tomcat-users, theres been a discussion on JSP's finding the
> > > WEB-INF/classes directory when compiling.  They can't.  From searches,
I
> > > understand this issue has come up before in regards to the Coocon
> project.
> > >
> > > The root problem is that Jasper cannot find classes located in
> > > WEB-INF/classes of the web application that the JSP's belong to.  This

> > > occurs when a JSP is either first deployed or the TOMCAT_HOME/work
> > > directory is cleared, requiring a recompile of the JSP's.
> > >
> > > The system is Tomcat 3.2 under Apache with mod_jk, running on SunOS
2.7
> > > with JDK 1.2.
> 
> I have noticed the same problem while doing some development using
> Tomcat 3.2.[23].  I worked around it by making sure that I unset the
> classpath before calling startup.sh, then things seemed to work properly
> and classes were found as expected.
> 
> It seems that certain combinations of classes in different ares
> (CLASSPATH, WEB-INF/lib, or other) will break things, but I haven't
> pinned it down, so it could simply be user stupidity.
> 
> -Dave

cvs commit: jakarta-tomcat/src/facade22/org/apache/tomcat/facade JspInterceptor.java

[larryi]

larryi  01/07/20 06:05:39

  Modified:src/facade22/org/apache/tomcat/facade JspInterceptor.java
  Log:
  Turning "tryJikes" off.  This introduces a configuration unknown with a
  default installation of Tomcat.
  
  Revision  ChangesPath
  1.27  +1 -1  
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/JspInterceptor.java
  
  Index: JspInterceptor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/JspInterceptor.java,v
  retrieving revision 1.26
  retrieving revision 1.27
  diff -u -r1.26 -r1.27
  --- JspInterceptor.java   2001/07/16 20:32:03 1.26
  +++ JspInterceptor.java   2001/07/20 13:05:39 1.27
  @@ -709,7 +709,7 @@
if( debug>5) log.log( "ClassPath " + cp);
   }
   
  -static boolean tryJikes=true;
  +static boolean tryJikes=false;
   static Class jspCompilerPlugin = null;
   
   /** Compile a java to class. This should be moved to util, togheter
  
  
  

RE: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/classes

[Andrew McGhee]

Guys,
I've copied in an email returned to a support desk regarding a problem
similar to this. There is a link to mikal.org that explains it in better
detail, but essentially it refers to where your classes are found, as to
what classloader they inherit. And the solution we found (similar to the
post) is to ensure your classpath is unset before starting Tomcat.

Regards,
Andrew Mc.Ghee

> Thanks again for your help on this,
> Looks like we have tracked down the problem, and it was due to a reference
to the Poet SDK on the CLASSPATH. References to > Poet code was finding the
class instance on the jar file specified within the CLASSPATH itself, and so
was not having
> access to the classloader from tomcat, making anything within
webapps/WEB-INF/lib unavailable. We have simply removed the
> reference to the poet jar files from the classpath, and placed the jar
file within the webapps/WEB-INF/lib directory, and
> voila! (No need to set the database classloader now either)

> Thanks again for your assistance in this, pointing out the classpath
loading help to isolate the problem.

> A useful link regarding this problem was;
http://mikal.org/interests/java/tomcat/archive/view?mesg=22444 (And probably
> explains the situation far better than I can)

-Original Message-

-Original Message-
From: David Rees [mailto:[EMAIL PROTECTED]]
Sent: 19 July 2001 22:27
To: [EMAIL PROTECTED]
Subject: Re: [3.2] JSP Compiling Classpath issues -- finding
WEB-INF/classes


(Sorry about the double-qoute, I missed the original message)

> > -Original Message-
> > From: Will England [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, July 19, 2001 10:49 AM
> > To: [EMAIL PROTECTED]
> > Subject: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/classes
> >
> >
> > Greetings!
> >
> > Over on tomcat-users, theres been a discussion on JSP's finding the
> > WEB-INF/classes directory when compiling.  They can't.  From searches, I
> > understand this issue has come up before in regards to the Coocon
project.
> >
> > The root problem is that Jasper cannot find classes located in
> > WEB-INF/classes of the web application that the JSP's belong to.  This
> > occurs when a JSP is either first deployed or the TOMCAT_HOME/work
> > directory is cleared, requiring a recompile of the JSP's.
> >
> > The system is Tomcat 3.2 under Apache with mod_jk, running on SunOS 2.7
> > with JDK 1.2.

I have noticed the same problem while doing some development using
Tomcat 3.2.[23].  I worked around it by making sure that I unset the
classpath before calling startup.sh, then things seemed to work properly
and classes were found as expected.

It seems that certain combinations of classes in different ares
(CLASSPATH, WEB-INF/lib, or other) will break things, but I haven't
pinned it down, so it could simply be user stupidity.

-Dave

cvs commit: jakarta-tomcat-site/docs index.html

[marcsaeg]

marcsaeg01/07/20 05:50:51

  Modified:docs index.html
  Log:
  Getting Alex's previous fixes built into the HTML files.
  
  Revision  ChangesPath
  1.4   +3 -3  jakarta-tomcat-site/docs/index.html
  
  Index: index.html
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/docs/index.html,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- index.html2001/07/17 18:25:14 1.3
  +++ index.html2001/07/20 12:50:51 1.4
  @@ -131,7 +131,7 @@
 
   
   There are several versions of Tomcat 
currently available for download.  Version 3.1.1
  -is a legacy release.  Version 3.2.1 is the current production quality release.  
Tomcat 3.3
  +is a legacy release.  Version 3.2.3 is the current production quality release.  
Tomcat 3.3
   is the latest continuation of the Tomcat 3.x architecture.  All Tomcat 3.x releases
   trace their heritage back to the original Servlet and JSP implementations that Sun
   donated to the Apache Software Foundation.  The 3.x versions all implement the
  @@ -149,8 +149,8 @@
   latest maintenance release, 3.1.1, contained fixes for security problems.  
   There is no active development ongoing for Tomcat 3.1.x.  Users of Tomcat 
   3.1 should update to 3.1.1 to close the security holes and they are 
  -strongly encouraged to migrate to the current production release, Tocmat 
  -3.2.1.
  +strongly encouraged to migrate to the current production release, Tomcat 
  +3.2.3.
   Tomcat 3.2.x.  
Tomcat 3.2.3 is the current production 
   quality release.  Version 3.2 added few new features; the major effort was 
   a refactoring of the internals to improve performance and stability.  The 
  
  
  

cvs commit: jakarta-tomcat README

[larryi]

larryi  01/07/20 05:50:29

  Modified:.README
  Log:
  More beta-1 updates
  
  Revision  ChangesPath
  1.17  +3 -11 jakarta-tomcat/README
  
  Index: README
  ===
  RCS file: /home/cvs/jakarta-tomcat/README,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- README2001/06/21 04:51:32 1.16
  +++ README2001/07/20 12:50:29 1.17
  @@ -29,31 +29,23 @@
 you should set ANT_HOME using the DOS 8.3 name.  Also, add "$ANT_HOME/bin"
 (%ANT_HOME%/bin for Windows) to your PATH.
   
  -* Download JAXP version 1.0.1 from  and install it
  -  in the $JAKARTA_HOME directory.
  -
   * If you want to include SSL support, download the Java Secure Sockets
 Extension (JSSE) implementation (current version number is 1.0.2) from
  and install it into $JAKARTA_HOME.
   
  -* Obtain the following source distributions either from anonymous CVS (see
  +* Obtain the following source distribution(s) either from anonymous CVS (see
  for details) or by
 downloading the appropriate source archives from the Jakarta site
 (see ):
   
 jakarta-tomcat
  -  jakarta-tomcat-connectors
  -  jakarta-tomcat-jasper
   
  -  If you download source archives, you will need to expand them and rename
  +  If you download source archive(s), you will need to expand them and rename
 the resulting directories to match the following build directory structure.
  -  JAXP and JSSE are shown below as well.
  +  JSSE is shown below as well.
   
 <$JAKARTA_HOME>
 jakarta-tomcat
  -  jakarta-tomcat-connectors
  -  jakarta-tomcat-jasper
  -  jaxp1.0.1
 jsse1.0.2  optional
 
   
  
  
  

Re: [DOC] TC4 B6

[Rob S.]

  Apologies for whatever funked up attachments got sent.  I'm using
my university's "webmail".

- r

On Fri, 20 Jul 2001 5:27:58 PDT [EMAIL PROTECTED] wrote:
> INSTALL is under $CATALINA_HOME/src?  Is that the right place for it?
> =0D
> Also, here's my take on a reworked ROOT/index.html.  I'd like to come up
> with a common look and feel for the default web-apps...=0D
> =0D
> - r=0D

cvs commit: jakarta-tomcat/src/admin tomcat.gif index.html

[larryi]

larryi  01/07/20 05:49:46

  Modified:src/admin index.html
  Added:   src/admin tomcat.gif
  Log:
  Make the admin web app self contained.  Including its own copy of
  tomcat.gif.
  
  Revision  ChangesPath
  1.5   +1 -1  jakarta-tomcat/src/admin/index.html
  
  Index: index.html
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/admin/index.html,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- index.html2001/03/15 20:28:26 1.4
  +++ index.html2001/07/20 12:49:46 1.5
  @@ -13,7 +13,7 @@
   
 
   
  -
  +
   Tomcat Administration Tools
 
 
  
  
  
  1.1  jakarta-tomcat/src/admin/tomcat.gif
  
<>
  
  

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

[larryi]

larryi  01/07/20 05:47:44

  Modified:src/share/org/apache/tomcat/modules/config IISConfig.java
  Log:
  Modified to have all requests for a context sent to Tomcat.  This is consistent
  with the Apache connector and insures behavior specified in the web.xml
  functions correctly for the web application.
  
  Need to update this interceptor to support similar options as ApacheConfig
  
  Revision  ChangesPath
  1.4   +6 -3  
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/IISConfig.java
  
  Index: IISConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/IISConfig.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- IISConfig.java2001/03/02 04:49:12 1.3
  +++ IISConfig.java2001/07/20 12:47:44 1.4
  @@ -154,10 +154,13 @@
   uri_worker.println();
   
   uri_worker.println("#"); 
  -uri_worker.println("# If you want tomcat to serve all the 
resources (including static) that");
  -uri_worker.println("# are part of the " + path + " context, 
uncomment the following line");
  +uri_worker.println("# The following line specifies that tomcat 
should serve all the resources");
  +uri_worker.println("# (including static) that are port of the " 
+ path + " context.  This insures");
  +uri_worker.println("# that behavior specified in the web.xml 
functions correctly.  If you want");
  +uri_worker.println("# IIS to serve static resources, comment 
out this line and replace with");
  +uri_worker.println("# appropriate mappings.  Then update the 
IIS configuration as needed.");
   uri_worker.println("#");
  - uri_worker.println("# " + path +"/*=$(default.worker)");
  +uri_worker.println(path +"/*=$(default.worker)");
   
   
uri_worker.println("###"); 
  
   uri_worker.println("# Auto configuration for the " + path + " 
context ends.");
  
  
  

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

[larryi]

larryi  01/07/20 05:45:20

  Modified:src/share/org/apache/tomcat/modules/config ApacheConfig.java
  Log:
  Modified handling when forwardAll is true and using JkMount to also include
  the context pattern, i.e. "/ctx/*".  Just "/ctx" defines an exact match only.
  
  Made noRoot default to true.  JkMount doesn't seem to be able to steal
  "/index.html" from Apache, so noRoot=false doesn't completely work with
  JkMount which is the default.
  
   with "setHandler" can get all the requests, but setHandler doesn't
  currently work because mod_jk's  jk_handler() gets called without a worker
  name being set.  This means that useJkMount=false and forwardAll=false
  shouldn't be used until this is fixed.
  
  Updated the javadoc.
  
  Revision  ChangesPath
  1.18  +37 -16
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ApacheConfig.java
  
  Index: ApacheConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ApacheConfig.java,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- ApacheConfig.java 2001/07/16 00:00:41 1.17
  +++ ApacheConfig.java 2001/07/20 12:45:20 1.18
  @@ -1,4 +1,4 @@
  -/* $Id: ApacheConfig.java,v 1.17 2001/07/16 00:00:41 costin Exp $
  +/* $Id: ApacheConfig.java,v 1.18 2001/07/20 12:45:20 larryi Exp $
* 
*
* The Apache Software License, Version 1.1
  @@ -95,7 +95,7 @@
   initialized during startup.
   
   This config interceptor is enabled by inserting an ApacheConfig
  -element in the \ tag body inside
  +element in the  tag body inside
   the server.xml file like so:
   
   * < ContextManager ... >
  @@ -106,26 +106,41 @@
   
   where options can include any of the following attributes:
   
  - confighome - default parent directory for the following paths.
  + configHome - default parent directory for the following paths.
   If not set, this defaults to TOMCAT_HOME. Ignored
   whenever any of the following paths is absolute.

  - jkconfig - path to write apacke mod_jk conf file to. If
  + jkConfig - path to write apacke mod_jk conf file to. If
   not set, defaults to
   "conf/jk/mod_jk.conf".
  - workersconfig - path to workers.properties file used by 
  + workersConfig - path to workers.properties file used by 
   mod_jk. If not set, defaults to
   "conf/jk/workers.properties".
  - modjk - path to Apache mod_jk plugin file.  If not set,
  + modJk - path to Apache mod_jk plugin file.  If not set,
   defaults to "modules/mod_jk.dll" on windows,
   "modules/mod_jk.nlm" on netware, and
   "libexec/mod_jk.so" everywhere else.
  - jklog - path to log file to be used by mod_jk. 
  
  + jkLog - path to log file to be used by mod_jk.
  + forwardAll - If true, forward all requests to Tomcat.  IF
  + false, let Apache serve static resources.
  + Warning: When false, some configuration in
  + the web.xml may not be duplicated in Apache.
  + Review the mod_jk.conf file to see what
  + configuration is actually being set in Apache.
  + useJkMount - If true, use JkMount mount directives.  If false,
  +  and SetHandler directives are used.
  + the default is true.
  + jkDebug - JK Loglevel setting.  May be debug, info, error, or emerg.
  +  If not set, defaults to no log.
  + noRoot - If true, the root context is not mapped to
  + Tomcat.  If false, Tomcat services all requests
  + to the root context.  The default is true.
  + This setting only applies if forwardAll is true.
   
   
   @author Costin Manolache
   @author Mel Martinez
  - @version $Revision: 1.17 $ $Date: 2001/07/16 00:00:41 $
  + @version $Revision: 1.18 $ $Date: 2001/07/20 12:45:20 $
*/
   public class ApacheConfig  extends BaseInterceptor { 
   
  @@ -168,7 +183,7 @@
   
   private String jkDebug=null;
   
  -private boolean noRoot=false;
  +private boolean noRoot=true;
   
   // ssl settings 
   private boolean sslExtract=true;
  @@ -230,11 +245,13 @@
   }
   
   /** Special option - do not generate mappings for the ROOT
  - context. The default is false, and will generate the mappings,
  - redirecting all page

[DOC] TC4 B6

[Rob S.]

INSTALL is under $CATALINA_HOME/src?  Is that the right place for it?

Also, here's my take on a reworked ROOT/index.html.  I'd like to come up
with a common look and feel for the default web-apps...

- r

RE: cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.0-B6.txt

[Rob S.]

> Windows coming in few days, as someone broke into my apt tonight
> and stole a
> couple of PCs and god knows what else... Other OSes, after I get back from
> the cops (thank god I keep my Macs in by bedroom).

Ugh, Pier...  hope everything turns out ok =/

- r

Re: cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.0-B6.txt

[Pier P. Fumagalli]

[EMAIL PROTECTED] at [EMAIL PROTECTED] wrote:

> +Tomcat 4.0-beta-6 now includes an updated version of the Java side of the
> +MOD_WEBAPP connector, used to run Tomcat behind Apache.  Binary versions of
> +the MOD_WEBAPP connector for various platforms will be published (in the same
> +directory where you downloaded Tomcat-4.0-beta-6 shortly).

Windows coming in few days, as someone broke into my apt tonight and stole a
couple of PCs and god knows what else... Other OSes, after I get back from
the cops (thank god I keep my Macs in by bedroom).

Pier (nothing _ever_ goes right)

RE: [TC4] jakarta-regexp.jar

[GOMEZ Henri]

>on 7/19/01 7:08 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

> P.S.  I'd like to propose that jakarta-regexp project name all their
> jars jakarta-regexp.jar no matter what version they are.  This doesn't
> affect the decision here.

>-1

>Until we have a CJAN, I like version numbers on jar files.

>The problem you are having can be easily resolved by simply editing your
>local jakarta-turbine-4.0/build.properties or your
>${user.home}/build.properties

Why could still use symlink as I do in my RPM :)

ln -s jakarta-regexp-1.2.jar jakarta-regexp.jar 

Re: Problem with mod_jk 1.2.0 (latest CVS snapshot)

[Bojan Smojver]

Bojan Smojver wrote:

> As for DSO, I'll have to work on that, so probably some time tomorrow
> (Sydney time).

Just did a DSO version and couldn't replicate the problem (BTW, I've
recompiled/statically linked Apache and mod_jk again since then and the
problem was still there). So, maybe it has to do with statically linking
Apache after all...

I still have to distribute this DSO version of Apache and mod_jk to some
slower machines to see if that makes any difference at all. The machine
that didn't produce any errors is a 1 GHz Athlon, so timing issues could
have been resolved by brute force, who knows...

Is there a recommendation as to the order of loading mod_jk for both
statically linked version and the DSO version? Maybe that's important.

And just one other observation, I'm also using php4. When statically
linked Apache doesn't contain php4 the problem is more difficult to
replicate (ie. it only occurs occasionally) which sort of pointed me
towards timing issues. But then again, I really don't understand the
internals of Apache to say what could be causing this.

All suggestions, fixes, resolutions etc. welcome ;-)

Bojan