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

[larryi]

larryi  01/07/10 22:24:15

  Modified:src/share/org/apache/tomcat/core Tag: tomcat_32
ContextManager.java
  Log:
  Prior patch to fix recursive status handling went too far and broke
  authorization which makes a recursive call to the status handling.
  Modify to report a recursive loop only if recursion occurs with the same
  status code.
  
  Suggested by: Ignacio J. Ortega
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.100.2.25 +5 -3  
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.100.2.24
  retrieving revision 1.100.2.25
  diff -u -r1.100.2.24 -r1.100.2.25
  --- ContextManager.java   2001/07/06 18:40:05 1.100.2.24
  +++ ContextManager.java   2001/07/11 05:24:14 1.100.2.25
  @@ -1047,7 +1047,7 @@
if( debug>0 )
ctx.log( "Handler " + errorServlet + " " + errorPath);
   
  -if ( statusLoop( ctx, req ) ){
  +if ( statusLoop( ctx, req, code ) ){
   log( "Error loop for " + req + " error code " + code);
   return;
   }
  @@ -1206,8 +1206,10 @@
   
   /** Handle the case of status handler generating an error
*/
  -private boolean statusLoop( Context ctx, Request req ) {
  -if ( req.getAttribute("javax.servlet.error.status_code") != null ) {
  +private boolean statusLoop( Context ctx, Request req, int newCode ) {
  +Integer lastCode = 
(Integer)req.getAttribute("javax.servlet.error.status_code");
  +// If status code repeated, assume recursive loop
  +if ( lastCode != null && lastCode.intValue() == newCode) {
   if( ctx.getDebug() > 0 )
   ctx.log( "Error: nested error inside status servlet " +
   req.getAttribute("javax.servlet.error.status_code"));
  
  
  

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/generators ErrorHandler.java

[larryi]

larryi  01/07/10 22:19:50

  Modified:src/share/org/apache/tomcat/modules/generators
ErrorHandler.java
  Log:
  Prior patch to fix recursive status handling went too far and broke
  authorization which makes a recursive call to the status handling.
  Modify to report a recursive loop only if recursion occurs with the same
  status code.
  
  Suggested by: Ignacio J. Ortega
  
  Revision  ChangesPath
  1.15  +6 -5  
jakarta-tomcat/src/share/org/apache/tomcat/modules/generators/ErrorHandler.java
  
  Index: ErrorHandler.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/generators/ErrorHandler.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- ErrorHandler.java 2001/07/06 18:41:00 1.14
  +++ ErrorHandler.java 2001/07/11 05:19:50 1.15
  @@ -191,7 +191,7 @@
}
   
boolean isDefaultHandler = false;
  -if ( statusLoop( ctx, req ) ){
  +if ( statusLoop( ctx, req, code ) ){
   log( "Error loop for " + req + " error code " + code);
   return;
   }
  @@ -399,11 +399,12 @@
   
   /** Handle the case of status handler generating an error
*/
  -private boolean statusLoop( Context ctx, Request req ) {
  -if ( req.getAttribute("javax.servlet.error.status_code") != null ) {
  +private boolean statusLoop( Context ctx, Request req, int newCode ) {
  +Integer lastCode = 
(Integer)req.getAttribute("javax.servlet.error.status_code");
  +// If status code repeated, assume recursive loop
  +if ( lastCode != null && lastCode.intValue() == newCode) {
   if( ctx.getDebug() > 0 )
  -ctx.log( "Error: nested error inside status servlet " +
  -req.getAttribute("javax.servlet.error.status_code"));
  +ctx.log( "Error: nested error inside status servlet " + newCode);
   return true;
   }
   return false;
  
  
  

Re: t4 - status check

[Pier P. Fumagalli]

Craig R. McClanahan at [EMAIL PROTECTED] wrote:
> 
> I would like to see Apache+Tomcat pass all the tester and Watchdog tests,
> the same way that Tomcat standalone does.  Pier et. al., where do we stand
> on that?

I still have one bug that tackles me (CGI not working when mod_webapp is
used on Solaris 8/Sparc), after that, tests are compliant.

Pier (going to bed now since it's 5 AM and I'm tired)

Jasper and parsed tree

[John Yu]

I'm new to Tomcat/Jasper. I have a question regarding Jasper:

Does Jasper parse a JSP into a DOM-like objects. In other words, does Jasper
create in-memory parsed tree of the the JSP file?

I notice from Tomcat 4.0's documentation that there's some plan to upgrade Jasper.
I'm wondering how that's going and whether the upgrade does anything related
to the above area I mentioned.

Thanks in advance.
--
John Yu  Scioworks Technologies
e: [EMAIL PROTECTED]w: +(65)  873 5989
w: http://www.scioworks.com  m: +(65) 9782 9610

Re: t4 - status check

[Jon Stevens]

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

> PS:  I know you didn't ask for a timeline, but I'd like to float a concept
> and see how the other developers feel about it:  The Servlet 2.3 and JSP
> 1.2 specs will go final (along with the rest of the J2EE specs) sometime
> in the pretty near future, and I'd like to release Tomcat 4.0 final on the
> day that the specs go final.  Does that sound like a worthwhile goal?

It is a good goal, however, it must not be the deciding factor.

In other words, I'm just stating that releasing before the specs go final
*is* possible.

-jon

RE: '_' <-> 0x5f and Jasper

[Keith Wannamaker]

Our build process precompiles jsps using jasper then javac from
make.  make expects foo_bar.jsp to be compiled to foo_bar.java
in order to invoke javac on the correct file.
When jasper cooks up foo_0005fbar.java, make is confused.

I built a hacked jasper after I changed the mangler to not mangle '_'.

Keith

| -Original Message-
| From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
| Sent: Tuesday, July 10, 2001 10:19 PM
| To: [EMAIL PROTECTED]
| Subject: Re: '_' <-> 0x5f and Jasper
|
|
| On Sat, 7 Jul 2001, Keith Wannamaker wrote:
|
| > Is there a known problem with jsp filenames containing '_'?
| > The Jasper in jakarta-tomcat head compiles 'foo_bar.jsp' to
| > 'foo_0005fbar.jsp' for me.  Clearly there is some escaping
| > gone awry, but surely I'm not the first to encounter this?
| > I'm digging into it now...
| > Keith
| >
| >
| What problem does it cause you that the escaping is done?  The application
| should not care what the generated Java source code filenames are.
|
| Craig
|
|

signoff tomcat-dev

[Vaskar Mistri]

signoff tomcat-dev


begin:vcard 
n:Mistri;Vaskar
tel;cell:91-98301-45597
tel;fax:+91.33.337.6290
tel;work:+91.33.334.0467
x-mozilla-html:TRUE
org:Vaskar Technology Corporation;Software Development
version:2.1
email;internet:[EMAIL PROTECTED]
title:CEO
adr;quoted-printable:;;BC  37  Suite No. 1=0D=0ASalt Lake City;Calcutta;;700064;India
fn:Vaskar Mistri
end:vcard

Re: [TC322 diff] appending to logfiles

[Craig R. McClanahan]

On Tue, 10 Jul 2001, Marcus Crafter wrote:

> Hi All,
> 
>   Hope all is well.
> 
>   I know TC322 is now in maintainence mode, but FWIW, here's a patch
>   that allows you to specify append="boolean" in the Logger definitions
>   of the server.xml. This allows you to configure appending to log
>   files in the server.xml.
> 
>   Is such functionality already in TC33 or T4 ?

In Tomcat 4, log files are automatically opened in append mode.  They also
roll over automatically on the first logged message after midnight.

> 
>   Cheers,
> 
>   Marcus
> 

Craig


> -- 
> .
>  ,,$,  Marcus Crafter
> ;$'  ':Computer Systems Engineer
> $: :   Open Software Associates GmbH
>  $   o_)$$$:   82-84 Mainzer Landstrasse
>  ;$,_/\ &&:'   60327 Frankfurt Germany
>' /( &&&
>\_' Email : [EMAIL PROTECTED]
>   .Business Hours : +49 69 9757 200
> &&&:
> 

Re: [t4] StandardSession.readObject()

[Craig R. McClanahan]

On Mon, 9 Jul 2001, Jon Stevens wrote:

> Shouldn't it call setAttribute(name, value) instead of:
> 
> synchronized (attributes) {
> attributes.put(name, value);
> }
> 
> ?
> 

If it did, the session event listeners and HttpSessionBindingListeners
will get called more than once for the same attribute -- once when you
originally added it, and once for each time you reload the application.  
That doesn't seem like the right thing to do, since (as far as the app is
concerned), persisting and reloading should be transparent.

> -jon
> 
> 

Craig

Re: t4 - status check

[Craig R. McClanahan]

On Mon, 9 Jul 2001, Jon Stevens wrote:

> What is the status of T4? I haven't seen a huge amount of commits from Craig
> and Remy recently and it seems like the whole adaptor stuff will never get
> finished cause it seems like a big political, testing and configuration
> mess.
> 

As usual, I'm focused on the container.  There seems to be progress made
on the connectors as well but (just getting back from vacation) I'm not up
to date on the details.

I would like to see Apache+Tomcat pass all the tester and Watchdog tests,
the same way that Tomcat standalone does.  Pier et. al., where do we stand
on that?

> I'm not asking for a timeline, just a status report.
> 

I'd like to see a concerted effort to clean up the outstanding Bugzilla
reports and then cut a "beta 6" release within the next couple of
weeks.  This will allow us to catch up on all the recent bug fixes and
enhancements, and have a release that closely corresponds to what will be
included in J2EE 1.3.

At the moment, there are 25 outstanding "Tomcat 4" bug reports.  I think a
bunch of them have already been fixed, so I would like the folks focusing
on those areas of the code to please update Bugzilla to reflect that -- so
we'll be able to clearly identify outstanding issues, and get to work on
them.

If anyone has issues that are not reflected in Bugzilla (perhaps you've
reported them in email), *please* submit a bug report.  That way, we can
track it for posterity, and not have to wade back through the mail
archives to find them.

> -jon
> 
> 

Craig

PS:  I know you didn't ask for a timeline, but I'd like to float a concept
and see how the other developers feel about it:  The Servlet 2.3 and JSP
1.2 specs will go final (along with the rest of the J2EE specs) sometime
in the pretty near future, and I'd like to release Tomcat 4.0 final on the
day that the specs go final.  Does that sound like a worthwhile goal?

Re: [DOC]: Vote on oustanding doc issues?

[Craig R. McClanahan]

On Tue, 10 Jul 2001, Alex Chaffee wrote:

> Rob S. wrote:
> 
> 
> > The tough thing about separating the docs is that the server.xml config
> > stuff is spread out among multiple files.  I wonder how difficult it would
> > be to maintain an index, or even if it's necessary.
> 
> 
> I don't think it's a big deal. I forgot to list the appendices, but one of 
> them will be a technical doc describing server.xml tag by tag. Whoever 
> writes this should put links in to the relevant parts of the TOC (which will 
> in turn contain links to the relevant documents).
> 

For Tomcat 4 at least, you'll find that the tag-by-tag docs on server.xml
is about 90% done -- the remaining work is to document the few remaining
undocumented elements, then convert the stuff from HTML to XML.  Having a
file per major element seemed to be a convenient way to organize it, but
I'm certainly open to any reasonable layout.

See directory "catalina/docs/config/" in the source repository -- or just
follow the online links if you're running Tomcat.

These docs were designed to be reference material, so they fit the concept
of an Appendix (as described above) quite well.  What's also important, of
course, is the *why* I would use a particular element, and the *how* to
solve some standard problems like "I want to use a single JDBCRealm for
all the webapps on this virtual host" or "how do I set up user home
directory based web apps?".


Craig

RE: My small, simple problem continued... (null container for my valve)

[Craig R. McClanahan]

On Tue, 10 Jul 2001, Kedar Hirve wrote:

> All right, I think I figured it out, and it seems a little strange. I was
> checking to see what the container for my valve was, in the
> _constructor_...the constructor is getting called before any of the
> heirarchy tree is built, it seems. Does Catalina load up components and run
> constructors in-order, rather than pre-order?
> 

For the record, Catalina assumes that all components can be instantiated
dynamically with newInstance(); then initialized by having the appropriate
setXxxx methods called; and finally (if it implements Lifecycle) then
start() will be called.  Therefore, testing for stuff in the constructor
is not going to work.

> One odd question, though...when IS the invoke method of a valve called?
> 

It is called once per request.  If you nest it inside a , as your
example indicates, then every request for that webapp will flow through
your Valve, but no request for any other webapp.


> -KSH
> 

Craig


> -Original Message-
> From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 09, 2001 5:57 PM
> To: [EMAIL PROTECTED]
> Subject: Re: My small, simple problem continued... (null container for
> my valve)
> 
> 
> > Oh, WOW. It did work, and I didn't even have to modify Catalina's startup
> > classpath. I had tried putting the class under common\lib and server\lib,
> > but I didn't know that common\classes would work. But now I've got another
> > problem...
> 
> In the lib folders, you can only put jars. Un-jarred classes should be in
> the classes folders. That's mentioned in the CL docs.
> 
> The best place to put your valve here is in server/classes/
> 
> > Again, I have this barebones valve class I wrote, and I've gotten it to
> load
> > up without exception in Catalina. Now, oddly enough, I find that my valve
> > has a null container, even though its nested in a context in my
> server.xml:
> >
> >  > debug="0"
> >  docBase="/" reloadable="true">
> >
> > > directory="/logs/kedlog" prefix="valvetest" timestamp="true" />
> >
> >
> > 
> >
> > Is there some initialization I need to do, or am I forgetting some tags in
> > my server.xml?
> 
> Does your valve extend ValveBase or implement Contained ?
> 
> Remy
> 

Re: Probably a simple problem with an equally simple solution...

[Craig R. McClanahan]

On Mon, 9 Jul 2001, Kedar Hirve wrote:

>   I was trying to develop my own valve to plug into Catalina, but
> running into some problems. I wrote up a little class that implements Valve
> and has empty code for getInfo() and invoke(). I put it in its own package
> called valvetest, compiled it just fine, put that folder
> with the class in it in Catalina's startup classpath, and added a valve
> element to my server.xml.
>   Catalina could find the class when it started, but would give me an
> IllegalArgumentException - argument type mismatch for the valve. Finally I
> decided to stick the classes into catalina.jar, and it worked. The odd thing
> here is that before I jarred it, Catalina found the class just fine, and
> even _ran its constructor_.
>   Though I have one solution for this now (jarring it into
> catalina.jar), I'm not terribly satisfied with that. I wanted to know if
> there's a more convenient way of adding my custom components without
> modifying catalina.jar.
> 
> Thanks, in advance.
> -KSH
> 

You should put Valve classes in one of the following two places:
- Unpacked under $CATALINA_HOME/server/classes
- In a JAR file under $CATALINA_HOME/server/lib

The startup processing automatically adds these repositories to the
correct class loader, so no mucking around with CLASSPATH is required (or
allowed).

Craig

Re: Table of Contents

[Punky Tse]

> >2) How about moving Developing Interceptors, Valves and Connectors, and
> >Using Tomcat Utility Classes to a seperate Developer Guide?
> >They are only
> >useful for real hackers.
>
> Don't forget what make Apache HTTP server so successfull.
> The number of modules built for Apache 1.2/1.3 APIs.
> If we don't comments and explain how to use and extend
> Tomcat, we'll loose many contributions and indirects
> users.
>

Henri,

Agree.  And we need to make the developer guide more richer in content.  But
before that, we should make a good user guide first in order to make tomcat
more popular.  Once we have a large user base, we will have a stronger
support for extending tomcat.

Punky

P.S. What hacker I mean is:  The one who read the source code and make
change to it so that the whole system get benefit from it.  So you are
hacker. (but me not yet).  The guy who break the system is cracker, or black
hacker to be specific.

Re: Copyright issues (was Re: DOC: Table of Contents)

[Craig R. McClanahan]

For Apache projects, documentation is licensed under the same license as
the code (i.e. "documentation" is "software").  If you check it in to an
Apache repository, it needs to have the Apache license (including the
Apache copyright on it).

Of course, that also gives you the right to use the docs under the same
terms as you can use the software.

Note that discussion of GPL licensing for docs isn't really relevant to
Tomcat documentation.

Craig


On Mon, 9 Jul 2001, Alex Fernández wrote:

> Hi Alex!
> 
> Alex Chaffee wrote:
> > A note on copyright: I'm claiming copyright for this document, since I
> > may use parts of it to write articles or books, and I haven't done the
> > research on what it means to post text (as opposed to code) into an
> > Apache project. I'd contribute it explicitly as open source if I were
> > sure I'd keep my rights to use it too. If anyone can enlighten me on
> > this topic, please respond with a separate subject line (like
> > "Copyrights") so we can keep discussions of copyright separate from
> > discussions of the table of contents itself. The copyright will not
> > prevent other Apache contributors from using or editing it or adding it
> > to the code base -- that is, I want to preserve *my* right to use it in
> > a non-Apache context, but also to grant Apache the right to use it too.
> > If that's even possible. I'm confused.
> 
> On www.gnu.org you can read the following:
> 
> ---
> Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001 Free Software
> Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
> 02111, USA 
> 
> Verbatim copying and distribution of this entire article is permitted in
> any medium, provided this notice is preserved. 
> 
> Updated: $Date: 2001/06/29 17:42:09 $ $Author: rms $ 
> ---
> 
> For all I know, (c) in software is not essentially different from (c)
> issues in text. Of course, the concept has been borrowed from there,
> otherwise we would use patents. In fact, you can "copyleft" a book, or
> BSD-like-license an essay.
> 
> But I don't know much anyway. Perhaps the following link would be
> useful:
> 
> http://www.gnu.org/philosophy/nonsoftware-copyleft.html
> 
> Un saludo,
> 
> Alex.
> 

Re: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS:[TomcatDocumentation Redactors To Hire]

[Craig R. McClanahan]

On Mon, 9 Jul 2001, Jon Stevens wrote:

> on 7/7/01 9:33 AM, "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
> 
> > FWIW, I'm fine with Anakia, XSLT, Cocoon, Stylebook, Docbook, or whatever
> > ... but IF AND ONLY IF the tags for use by the document authors are well
> > documented, and the page generation procedure is amenable to Ant scripting
> > (not a difficult problem in most cases).
> 
> Jakarta-Site tags are now documented.
> 
> http://jakarta.apache.org/site/jakarta-site-tags.html
> 

Cool.  That's exactly what I was looking for.

> Also, please quit grouping Anakia into "Anakia tags need to be documented".
> It is the Jakarta-Site2 project's tags which need to be documented (and have
> been). Anakia itself doesn't give a shit what tags you use. :-)
> 

That's correct.  It's also correct of XSLT :-).

> -jon
> 
> 

Craig

Re: '_' <-> 0x5f and Jasper

[Craig R. McClanahan]

On Sat, 7 Jul 2001, Keith Wannamaker wrote:

> Is there a known problem with jsp filenames containing '_'?
> The Jasper in jakarta-tomcat head compiles 'foo_bar.jsp' to
> 'foo_0005fbar.jsp' for me.  Clearly there is some escaping 
> gone awry, but surely I'm not the first to encounter this?
> I'm digging into it now...
> Keith
> 
> 
What problem does it cause you that the escaping is done?  The application
should not care what the generated Java source code filenames are.

Craig

Re: [DOC] Vote on oustanding doc issues?

[Craig R. McClanahan]

On Mon, 9 Jul 2001, Alex Chaffee wrote:

> > 
> > Bundle the 3.2.x docs with 3.2.x and only have the 3.3 docs online ("latest
> > Tomcat release").  If you want the 3.2.x docs, get them with the binary or
> > whatever.  I certainly don't think we should keep old versions of
> > documentation updated.  I mean, why would updated 3.0 or 3.1 docs be useful?
> > 

Unless and until there's a 3.3 or 4.0 final release, *3.2* is the "latest
Tomcat release", and deserves to be documented on the web site.

Fortunately, there's a real easy way to handle this -- it's called
subdirectories :-).

There's no reason to banish the current Tomcat released version, or any
other version that is being actively developed.  And it's quite easy to
arrange the user interface so that it's obvious which version you are
looking at (for example, including "Tomcat X.Y" in the header or footer of
the pages about that version).

Craig

Re: Poor Tomcat 3.2.2 performance on Win32 with class reloadingenabled

[Craig R. McClanahan]

On Mon, 9 Jul 2001, Stuart Roebuck wrote:

> Remy & Craig,
> 
> Thanks for your responses...
> 
> On Saturday, July 7, 2001, at 07:28  am, Remy Maucherat wrote:
> 
> >> The cases you've described above all happen only once (at startup
> >> time).  Assuming that we could safely optimize these cases, would it
> >> really make a significant difference?
> >
> > It wouldn't.
> >
> > While you were away, I did some profiling of the startup (since people
> > complained), and it turns out that the time is mostly spent in :
> > - Crimson, because it's used in validating mode
> > - introspecting and doing various things in the XML mapper (no surprise)
> 
> The examples I gave were just some examples of getCanonicalPath that I 
> located in the source - I acknowledge that I had been unable to identify 
> which ones were taking up significant resources, though all the ones I 
> listed were at least in loops.
> 
> I have had problems profiling Tomcat and Cocoon, but in those threads I 
> have been able to profile under Mac OS X, getCanonicalPath (i.e. native 
> UnixFileSystem.canonicalize) calls whilst running Tomcat 4 and Cocoon II 
> constitute a *very* significant proportion of runtime.  I know that others 
> have noted that this is also true under Windows, so this does not appear 
> to be specific to Mac OS X, though the 'cost' of getCanonicalPath under 
> Mac OS X may be proportionally higher than on other operating systems due 
> to certain underlying filesystem issues.
> 

One commonality, IIRC - both Windows and MacOS are case insensitive.

The servlet spec (at least in 2.3) mandates case sensitive comparisons for
web app resources.  The only way we've discovered to do that is to rely on
getCanonicalPath().

> >> To influence the performance of Cocoon, we'd want to look at the 
> >> Resources
> >> implementation.  It's been worked on, but I would certainly not say we've
> >> really optimized it yet.  And reducing the number of calls to
> >> getCanonicalPath() sounds like a good strategy -- as long as it can be
> >> done safely.
> >
> > getCanonicalPath is called only under Windows (for case sensitivity
> > checking).
> > More profiling showed that the resources were fast enough.
> >
> > Remy
> 
> Remy - could you explain what you mean here.  getCanonicalPath calls 
> within Tomcat are not, as far as I can see, conditional upon runtime 
> Operating System.  Both Windows filing systems and HFS / HFS+ (Under Mac 
> OS / Mac OS X) are case insensitive, the latter being BSD Unix derivative.
>I would have thought that calls to getCanonicalPath would be required, 
> not just for case sensitivity reasons, but also to deal with the 
> assortment of equivalent path descriptors, e.g. the use of "..", ".", 
> "~user" and the effects of filesystem softlinks, hardlinks, aliases, 
> shortcuts, or whathaveyou.  If getCanonicalPath is being used as a case 
> insensitive string comparitor, then I am sure there are less costly 
> alternatives.
> 
> When you say that profiling indicated that resources were fast enough, do 
> you mean that getCanonicalPath is not a significant bottleneck on any 
> platform?  I'm not doubting this with respect to Tomcat 4, as the main 
> issues I have run across may be largely Cocoon II specific, unfortunately 
> currently profiling  problems mean that I'm going round the houses a 
> little to pin this one down.  However, as I indicated in my earlier email,
>   I have tested substituting th java.io.File.getCanonicalPath() method with 
> a caching version and found a very visible speedup which confirms that 
> getCanonicalPath is an issue somewhere in this Tomcat 4 / Cocoon II 
> combination.
> 
> Stuart.
> 
> 
> -
> Stuart Roebuck  [EMAIL PROTECTED]
> Lead Developer   Java, XML, MacOS X, XP, etc.
> ADOLOS   
> 
Craig

Re: [DOC] Table of Contents

[Punky Tse]

> > 3) How about putting all the installation and configuration of Tomcat
> > standalone first, and then followed by some chapters (advanced topics)
about
> > Running Tomcat behind web servers?
>
>
> It's already organized that way. See the first paragraph of the
> "editorial notes:"
>  >>I think there should be a
>  >>chapter or series of chapters on installing Tomcat standalone, that
>  >>covers *everything* or almost everything start-to-finish. Then we also
>  >>need separate chapters for installing behind each Web server. Then
>  >>come chapters on administration and advanced configuration issues.
>
> I have a feeling you may have missed the attachment. See the post I just
> made for the latest one (in much detail).

Alex,

What I mean is to swap Part II with Part III like below:

I. Standalone Installation Guide
II. Deploying and Configuring, or Tomcat Administrator's Guide
III. Installation Behind a Web Server Guide
IV. Performance Tuning Guide
V. Tomcat Developer's Guide (writing code for Tomcat itself)

I treat "Installation Behind a Web Server Guide" as advanced topics.  For
general tomcat users, they should be more interested in configuring Tomcat
than in making it running behind web server.

Punky

RE: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS: [TomcatDocumentation Redactors To Hire]

[Craig R. McClanahan]

On Tue, 10 Jul 2001, GOMEZ Henri wrote:

> >Craog
> >> I have a feeling that whatever is the same will be a lot of 
> >piecemeal here
> >> and there, excluding of course, web-app documentation.  So 
> >far yourself,
> >> Pier, and Henri are the only three TC developers to post 
> >their position on
> >> that (re: inter-version relevancy).  
> 
> Pier and I also working together on a separate sub-project, J-T-C.
> A starting user will first install the servlet-engine and then will
> try to figure how to link it with its web-server.
> Should we ask him to switch from one documentation to another ?
> 

The user doesn't care what repository the docs came from -- they only care
that the hyperlinks work correctly :-).

In other words, the packaging of the docs in the binary distribution need
not have anything to do with the source file organization.

> >I thought of another reason for my preference in the shower 
> >this morning
> >:-).  Consider that I might make a code change that also 
> >requires a change
> >to the corresponding docs.  If the docs are in the same 
> >repository, that
> >can easily be done on the same commit (and it becomes obvious 
> >to everyone
> >when a developer makes a change that breaks the documentation, 
> >but fails
> >to update it :-).  Having a separate docs repository means I need to do
> >two independent check-ins -- it's easy to forget one, and there is no
> >obvious link between them to remind you (for example) to back 
> >out the docs
> >change if you back out the code change.
> 
> If you commit a code change in TC 4.0, you'll only have one doc commit
> in J-T-D. What's the duplicate effort here ?
> 

Assume a change to class Abc.java and a corresponding change to
Abc-doc.html.

If they are in the same CVS repository, a single commit does
both.  Otherwise, you need to remember to do two individual commits (one
on each repository).

Likewise, when you decide later to back out this change (because it was
incorrect or something), you have to remember that there was also a commit
on the docs repository.  In the same repository, the commit message
contains both sets of changes, so you know that you have to back them both
out.

Craig McClanahan

Re: please read -- need to specify current working directory

[Craig R. McClanahan]

On Sun, 8 Jul 2001, Donald Ball wrote:

> On Sun, 8 Jul 2001, Victor Wynnytsky wrote:
> 
> > [ WHY I NEED THIS ]
> > It is very common for an XSL page to include another XSL page.
> > An XSL page called "orderDetail.xsl" might begin like this...
> >
> >   http://www.w3.org/1999/XSL/Transform";
> > version="1.0">
> >   
> >   
> >   
> >   ...
> >
> > The focus of my problem is on the  tag.  I'm using a *web*
> > path there, and I'm sure everyone using Xalan is using an *file* path.
> > The above sample XSL shows orderDetail.xsl trying to refer to nav.xsl
> > in the same folder (ie: web path).
> 
> you should check out the javax.xml.transform.URIResolver interface. you
> can have trax transformers call one of your methods to resolve uris.
> 

You should really do as Donald suggests.  One of the flaws to your current
approach is that "user.dir" is global to all webapps, so as soon as you
have your apps processing multiple requests at the same time, you're going
to run into race conditions.

> - donald
> 
> 

Craig McClanahan

Re: [DOC] TOC - thoughts

[Punky Tse]

> First off, I think we should have an ultra-quick install guide.  If you're
> like a lot of geeks, you know your stuff.  You need to know a quick few
> steps, a quick 2-3 gotchas, and BAM that's it.  I want to make sure the
> quick-and-dirty "impatient" install is available to the people who can
take
> advantage of it; admins experienced with other containers, trying Tomcat
for
> the first time perhaps.

README file of the binary distribution of tomcat already contains the
ultra-quick install guide.  If not, just make sure the README file have it,
right?

Punky

StandardContext.getNamingContextName returns non unique name

[Vishy Kasar]

StandardContext.getNamingContextName() returns name of the form

/host/context

no matter which engine the context is part of. This will create a
problem for running multiple services serving the same webapp. It should
be returning the name of the form

/engine/host/context

Let me know if this is a bug or am I missing something?

--
Cheers!

RE: cvs commit:jakarta-tomcat/src/facade22/org/apache/tomcat/facadeHttpSessionFacade.java

[Ignacio J. Ortega]

> 
> I would say that following coding conventions for a project 
> is extremely
> important. It increases the ability to read the code and 
> given that this is
> an OSS project, that is very important.
> 

Well, was my intention to slowly change tabs to spaces, to not excite
too much sensibilities along the way.., but you are completely right ,
or all the repository is changed or is a nonsense to have part of the
source files in a way and part in other..

It's opinable if maintaining the tabs makes code more readable.. :)

> So, here is my -1.
> 

Done

> Personally, I hate tabs, but your friend Costin loves em. Go figure.
> 

Me too, but i like K&R indenting Style too, we still can argument to
many things :)))

> -jon
> 
> 


Saludos ,
Ignacio J. Ortega

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

[nacho]

nacho   01/07/10 16:56:36

  Modified:src/facade22/org/apache/tomcat/facade HttpSessionFacade.java
  Log:
  Readded tabs, to maintain actual coding style..
  
  Revision  ChangesPath
  1.10  +45 -45
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpSessionFacade.java
  
  Index: HttpSessionFacade.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpSessionFacade.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- HttpSessionFacade.java2001/07/10 23:08:32 1.9
  +++ HttpSessionFacade.java2001/07/10 23:56:33 1.10
  @@ -100,21 +100,21 @@
   /** Package-level method - accessible only by core
*/
   void setRealSession(ServerSession s) {
  -realSession=s;
  -realSession.setFacade( this );
  + realSession=s;
  + realSession.setFacade( this );
}
   
   /** Package-level method - accessible only by core
*/
   void recycle() {
  -//  realSession=null;
  + //  realSession=null;
   }
   
   //  public facade 
   
   public String getId() {
  -checkValid();
  -return realSession.getId().toString();
  + checkValid();
  + return realSession.getId().toString();
   }
   
   /**
  @@ -125,8 +125,8 @@
*  invalidated session
*/
   public long getCreationTime() {
  -checkValid();
  -return realSession.getTimeStamp().getCreationTime();
  + checkValid();
  + return realSession.getTimeStamp().getCreationTime();
   }
   
   /**
  @@ -136,12 +136,12 @@
* @deprecated
*/
   public HttpSessionContext getSessionContext() {
  -return new SessionContextImpl();
  + return new SessionContextImpl();
   }
   
   public long getLastAccessedTime() {
  -checkValid();
  -return realSession.getTimeStamp().getLastAccessedTime();
  + checkValid();
  + return realSession.getTimeStamp().getLastAccessedTime();
   }
   
   /**
  @@ -151,8 +151,8 @@
*  an invalidated session
*/
   public void invalidate() {
  -checkValid();
  -realSession.getTimeStamp().setValid( false );
  + checkValid();
  + realSession.getTimeStamp().setValid( false );
   }
   
   /**
  @@ -166,15 +166,15 @@
*  invalidated session
*/
   public boolean isNew() {
  -checkValid();
  -return realSession.getTimeStamp().isNew();
  + checkValid();
  + return realSession.getTimeStamp().isNew();
   }
   
   /**
* @deprecated
*/
   public void putValue(String name, Object value) {
  -setAttribute(name, value);
  + setAttribute(name, value);
   }
   
   public void setAttribute(String name, Object value) {
  @@ -203,25 +203,25 @@
* @deprecated
*/
   public Object getValue(String name) {
  -return getAttribute(name);
  + return getAttribute(name);
   }
   
   public Object getAttribute(String name) {
  -checkValid();
  -return realSession.getAttribute(name);
  + checkValid();
  + return realSession.getAttribute(name);
   }
  -
  +
   /**
* @deprecated
*/
   public String[] getValueNames() {
  -checkValid();
  -
  -Enumeration attrs = getAttributeNames();
  -String names[] = new String[realSession.getAttributeCount()];
  -for (int i = 0; i < names.length; i++)
  -names[i] = (String)attrs.nextElement();
  -return names;
  + checkValid();
  + 
  + Enumeration attrs = getAttributeNames();
  + String names[] = new String[realSession.getAttributeCount()];
  + for (int i = 0; i < names.length; i++)
  + names[i] = (String)attrs.nextElement();
  + return names;
   }
   
   /**
  @@ -232,15 +232,15 @@
*  invalidated session
*/
   public Enumeration getAttributeNames() {
  -checkValid();
  -return realSession.getAttributeNames();
  + checkValid();
  + return realSession.getAttributeNames();
   }
   
   /**
* @deprecated
*/
   public void removeValue(String name) {
  -removeAttribute(name);
  + removeAttribute(name);
   }
   
   /**
  @@ -258,33 +258,33 @@
*  invalidated session
*/
   public void removeAttribute(String name) {
  -checkValid();
  -Object object=realSession.getAttribute( name );
  -realSession.removeAttribute(name);
  -if (object instanceof HttpSessionBindingListener) {
  -((HttpSessionBindingListener) object).valueUnbound
  -(new HttpSessionBindingEvent( this, name));
  -}
  + checkValid();
  + Object obj

Re: [DOC] TOC - thoughts

[Christopher Cain]

"Rob S." wrote:

[snip]
> First off, I think we should have an ultra-quick install guide.  If you're
> like a lot of geeks, you know your stuff.  You need to know a quick few
> steps, a quick 2-3 gotchas, and BAM that's it.  I want to make sure the
> quick-and-dirty "impatient" install is available to the people who can take
> advantage of it; admins experienced with other containers, trying Tomcat for
> the first time perhaps.

+1

> PI.2.1:  I love pictures!  Some nice diagrams in here would go a lllong way.
> Not sure about the "choose OS" or "install Java" sections.  I mean, there's
> catering to the LCD and there's catering to the LCD...

I haven't yet had a chance to look over the TOC (planning on doing it
tonight), but one of the docs I have lying around is a step-by-step on
installing java on Linux *specifically* in preparation for a Tomcat
build/install. Granted, the README file hits the important stuff, like
what needs to be in the CLASSPATH, etc. I was actually thinking of
morphing it into a more general (and quick) guide to preping your OS for
a Tomcat build/install (I have some Windoze notes lying around as well).
I could very quickly touch on Java installation, including a few
Linux-specific tips above and beyond the rather obvious actual install,
cover the environment varibles that need to be defined for a build,
reiterate the "jakarta" directory structure that needs to be in place,
etc. Basically, everything up to the point of the actual build.

Again, I haven't yet looked over the TOC, and maybe this doesn't fit
that scheme, or is not at all what is being discussed in PI.2.1. So
don't flame me too badly for not RTFM, just a quick thought I had when
reading Rob's reply.

> I think a lot of PI.2 is overkill, and some unnecessary, dependant upon the
> implied length of the sections from  the TOC I suppose...  I mean one or two
> sentences to "downloading JDK", sure, but more than that?  Definitely more
> suited to a book than "good enough" docs ;)

Well, my thoughts on the aforementioned doc I was planning are to
provide a list of the available JDKs for each platform, what else one
needs to download for certain optional functionality (SSL, etc.), where
to get each of them, and any relevant comments on software selection.
Mainly just the huge stuff, like the infamous "Sun 1.3.1 JDK for Linux
completely broken under the new gcc threading libraries." (That one
really pissed me off.) This might fall under the category of "too much
information" as Rob is stating, but my feeling is that it is easy enough
to skip over entire sections (assuming they're laid out logically) in a
"Preping your OS for Tomcat" doc, and those users who are planning on
building out a new box (or reformatting an existing box) specifically
for a web server will appreciate such heads-up info. Getting Tomcat up
and running on a barebones OS install is pretty rare for us developers,
but it happens quite frequently in the corporate world. The bigger the
master Tomcat documentation library, from the essentials to the
sublimely tangential steps along the way, the more comfortable
corporations will feel about choosing Tomcat over a proprietary
solution. As long as someone is willing to write such things, which in
this case I am, why not just throw it in the mix for the few people who
might benefit from it? Of course, I completely agree that there also
needs to be some short-and-sweet versions of how to do install-type
things, so maybe an abbreviated version of my Preping doc would also be
in order.

Just a thought ...

- Christopher

cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler TagLibraryInfoImpl.java JspParseEventListener.java

[horwat]

horwat  01/07/10 16:50:30

  Modified:jasper/src/share/org/apache/jasper/compiler
TagLibraryInfoImpl.java JspParseEventListener.java
  Log:
  TagLibraryValidator update. Reflect changes in the JSP 1.2 PFD specification. 
Validation now returns an error list.
  
  Submitted by: Eduardo Pelegri-Llopart
  
  Revision  ChangesPath
  1.23  +5 -4  
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java
  
  Index: TagLibraryInfoImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java,v
  retrieving revision 1.22
  retrieving revision 1.23
  diff -u -r1.22 -r1.23
  --- TagLibraryInfoImpl.java   2001/03/22 01:26:44 1.22
  +++ TagLibraryInfoImpl.java   2001/07/10 23:50:24 1.23
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java,v
 1.22 2001/03/22 01:26:44 horwat Exp $
  - * $Revision: 1.22 $
  - * $Date: 2001/03/22 01:26:44 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java,v
 1.23 2001/07/10 23:50:24 horwat Exp $
  + * $Revision: 1.23 $
  + * $Date: 2001/07/10 23:50:24 $
*
* The Apache Software License, Version 1.1
*
  @@ -89,6 +89,7 @@
   import javax.servlet.jsp.tagext.PageData;
   import javax.servlet.jsp.tagext.VariableInfo;
   import javax.servlet.jsp.tagext.TagVariableInfo;
  +import javax.servlet.jsp.tagext.ValidationMessage;
   
   import org.apache.jasper.JspCompilationContext;
   import org.apache.jasper.JasperException;
  @@ -605,7 +606,7 @@
* @param thePage The JSP page object
* @return A string indicating whether the page is valid or not.
*/
  -public String validate(PageData thePage) {
  +public ValidationMessage[] validate(PageData thePage) {
TagLibraryValidator tlv = getTagLibraryValidator();
if (tlv == null) return null;
return tlv.validate(getPrefixString(), getURI(), thePage);
  
  
  
  1.31  +10 -5 
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java
  
  Index: JspParseEventListener.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
  retrieving revision 1.30
  retrieving revision 1.31
  diff -u -r1.30 -r1.31
  --- JspParseEventListener.java2001/05/22 21:43:29 1.30
  +++ JspParseEventListener.java2001/07/10 23:50:26 1.31
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
 1.30 2001/05/22 21:43:29 horwat Exp $
  - * $Revision: 1.30 $
  - * $Date: 2001/05/22 21:43:29 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
 1.31 2001/07/10 23:50:26 horwat Exp $
  + * $Revision: 1.31 $
  + * $Date: 2001/07/10 23:50:26 $
*
* 
*
  @@ -76,6 +76,7 @@
   
   import javax.servlet.jsp.tagext.TagInfo;
   import javax.servlet.jsp.tagext.TagLibraryInfo;
  +import javax.servlet.jsp.tagext.ValidationMessage;
   
   import org.apache.jasper.JasperException;
   import org.apache.jasper.Constants;
  @@ -1117,8 +1118,12 @@
   while (enum.hasMoreElements()) {
   TagLibraryInfo tli = (TagLibraryInfo)enum.nextElement();
//@@@ remove cast when TagLibraryInfo is fixed in spec
  -String msg = ((TagLibraryInfoImpl)tli).validate(xo.getPageData());
  -if (msg != null) {
  +
  + ValidationMessage[] errors =
  +   ((TagLibraryInfoImpl)tli).validate(xo.getPageData());
  +if ((errors != null) && (errors.length != 0)) {
  + // for now just report the first error!
  + String msg = errors[0].getMessage();
   throw new JasperException(
Constants.getString(
   "jsp.error.taglibraryvalidator.invalidpage",
  
  
  

Re: cvs commit:jakarta-tomcat/src/facade22/org/apache/tomcat/facadeHttpSessionFacade.java

[Jon Stevens]

on 7/10/01 4:29 PM, "Ignacio J. Ortega" <[EMAIL PROTECTED]> wrote:

> Hola Jon:
> 
> Who will cry for the lost of tabs? me not.. perhaps you? :)
> 
> Lazy Consensus 3 days for a -1.. if anybody complaints ( more ) i will
> rollback and reapply my patch..
> 
> Saludos ,
> Ignacio J. Ortega

I would say that following coding conventions for a project is extremely
important. It increases the ability to read the code and given that this is
an OSS project, that is very important.

So, here is my -1.

Personally, I hate tabs, but your friend Costin loves em. Go figure.

-jon

RE: Possible bug in isapi_redirector.dll

[sam]

Hi Henry

I agree, i think the bug is in IIS.

We havent been able to find anything about this bug on the microsoft site.

Also we havent reported it.

But we think therese buckleys chance of gettting microsoft to fix it.
They'll probably say its fixed in IIS 5.0.

We have modified the isapi_redirector.dll code for our own purposes.

I guess its up to you guys about how you want to approach the situatation.


Cheers

Sam


-Original Message-
From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 10, 2001 5:55 PM
To: [EMAIL PROTECTED]
Subject: RE: Possible bug in isapi_redirector.dll


Hi Sam,

>-Original Message-
>From: sam [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, July 10, 2001 9:31 AM
>To: [EMAIL PROTECTED]
>Subject: Possible bug in isapi_redirector.dll
>
>
>Hello there everybody, We think we may have found a bug,
>possibly in IIS,
>which affects isapi_redirect.dll. We were wondering if anyone
>else has seen
>this. Perhaps this is a bug for MS, but it seems to affect
>tomcat so maybe
>someone here can shed some light.
>
>Our software versions are:
>IIS 4.0
>jk_isapi_plugin.c revision 1.5.2.2
>tomcat 3.2.2
>Windows NT 4.0 sp6
>
>
>
>The relevant code in is the file jk_isapi_plugin.c, line 960 in the
>function:
>
>static int get_server_value(LPEXTENSION_CONTROL_BLOCK lpEcb,
>char *name,
>char  *buf,
>DWORD bufsz,
>char  *def_val)
>
>
>When the function lpEcb->GetServerVariable(...) on line 965 is
>called to
>retrieve CERT_SERIALNUMBER, the value returned in bufsz is wrong. Our
>certificate serial number is 48 chars long, but the value
>contained in bufsz
>is 47, where it should be 49 (the length of the serial number
>+ 1 for string
>terminator).
>After the call to GetServerVariable() a '\0' is inserted into buf at
>bufsz-1. This causes our certificate serial number to be truncated by 2
>bytes.
>
>The microsoft doco says that the value returned should be the
>value length +
>1 for the string terminator. This is from:
>http://msdn.microsoft.com/library/en-us/iisref/html/psdk/asp/is
re8376.asp?fr
ame=true

The problem is clearly in IIS. It return 47 instead of 49
Could you see if the bug is reported in IIS 

cvs commit: jakarta-tomcat-4.0/tester/web/WEB-INF web.xml

[craigmcc]

craigmcc01/07/10 16:30:16

  Modified:tester/src/bin tester.xml
   tester/web/WEB-INF web.xml
  Added:   tester/src/tester/org/apache/tester Lifecycle01.java
Lifecycle02.java
  Log:
  Add unit tests to prove that servlet lifecycle is handled correctly - i.e.
  init() is called exactly once before the service() method is invoked, and
  the first call can be either a GET or a POST.
  
  These tests indicate that the error reported by Bugzilla #206 does *not*
  occur with current Tomcat 4.0 code.
  
  Revision  ChangesPath
  1.53  +24 -1 jakarta-tomcat-4.0/tester/src/bin/tester.xml
  
  Index: tester.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/tester/src/bin/tester.xml,v
  retrieving revision 1.52
  retrieving revision 1.53
  diff -u -r1.52 -r1.53
  --- tester.xml2001/06/25 15:40:47 1.52
  +++ tester.xml2001/07/10 23:30:10 1.53
  @@ -15,7 +15,7 @@
 
   
   
  -  
  +  
   
   
 
  @@ -493,6 +493,29 @@
   
  +
  +  
  +
  +
  +  
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
   
 
   
  
  
  
  1.1  
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/Lifecycle01.java
  
  Index: Lifecycle01.java
  ===
  /* = *
   *   *
   * The Apache Software License,  Version 1.1 *
   *   *
   * Copyright (c) 1999, 2000, 2001  The Apache Software Foundation.   *
   *   All rights reserved.*
   *   *
   * = *
   *   *
   * Redistribution and use in source and binary forms,  with or without modi- *
   * fication, are permitted provided that the following conditions are met:   *
   *   *
   * 1. Redistributions of source code  must retain the above copyright notice *
   *notice, this list of conditions and the following disclaimer.  *
   *   *
   * 2. Redistributions  in binary  form  must  reproduce the  above copyright *
   *notice,  this list of conditions  and the following  disclaimer in the *
   *documentation and/or other materials provided with the distribution.   *
   *   *
   * 3. The end-user documentation  included with the redistribution,  if any, *
   *must include the following acknowlegement: *
   *   *
   *   "This product includes  software developed  by the Apache  Software *
   *Foundation ."  *
   *   *
   *Alternately, this acknowlegement may appear in the software itself, if *
   *and wherever such third-party acknowlegements normally appear. *
   *   *
   * 4. The names  "The  Jakarta  Project",  "Tomcat",  and  "Apache  Software *
   *Foundation"  must not be used  to endorse or promote  products derived *
   *from this  software without  prior  written  permission.  For  written *
   *permission, please contact <[EMAIL PROTECTED]>.*
   *   *
   * 5. Products derived from this software may not be called "Apache" nor may *
   *"Apache" appear in their names without prior written permission of the *
   *Apache Software Foundation.*
   *   *
   * THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESSED OR IMPLIED WARRANTIES *
   * INCLUDING, BUT NOT LIMITED TO,  THE IMPLIED WARRANTIES OF MERCHANTABILITY *
   * AND FITNESS FOR  A PARTICULAR PURPOSE  ARE DISCLAIMED.  IN NO EVENT SHALL *
   * THE APACHE  SOFTWARE  FOUNDATION OR  ITS CONTRIBUTORS  BE LIABLE  FOR ANY *
   * DIRECT,  INDIRECT,   INCIDENTAL,  SPECIAL,  EXEMPLARY,  OR  CONSEQUENTIAL *
   * DAMAGES (INCLUDING,  BUT NOT LIMITED TO,  PROCUREMENT OF SUBSTITUTE GOODS *
   * OR SERVICES;  LOSS OF USE,  DATA,  OR PROFITS;  OR BUSINESS INTERRUPTION) *
   * HOWEVER CAUSED AND  ON ANY  THEORY  OF  LIAB

RE: cvs commit:jakarta-tomcat/src/facade22/org/apache/tomcat/facadeHttpSessionFacade.java

[Ignacio J. Ortega]

Hola Jon:

Who will cry for the lost of tabs? me not.. perhaps you? :)

Lazy Consensus 3 days for a -1.. if anybody complaints ( more ) i will
rollback and reapply my patch..

Saludos ,
Ignacio J. Ortega


> -Mensaje original-
> De: Jon Stevens [mailto:[EMAIL PROTECTED]]
> Enviado el: miércoles 11 de julio de 2001 1:16
> Para: tomcat-dev
> Asunto: Re: cvs
> commit:jakarta-tomcat/src/facade22/org/apache/tomcat/facadeHtt
> pSessionFa
> cade.java
> 
> 
> on 7/10/01 4:08 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> 
> >  public long getLastAccessedTime() {
> > -checkValid();
> > -return realSession.getTimeStamp().getLastAccessedTime();
> > +checkValid();
> > +return realSession.getTimeStamp().getLastAccessedTime();
> >  }
> 
> I thought that Costin wants tabs in the files for Tomcat 3.x.
> 
> -jon
> 
> 

Re: cvs commit:jakarta-tomcat/src/facade22/org/apache/tomcat/facadeHttpSessionFacade.java

[Jon Stevens]

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

>  public long getLastAccessedTime() {
> -checkValid();
> -return realSession.getTimeStamp().getLastAccessedTime();
> +checkValid();
> +return realSession.getTimeStamp().getLastAccessedTime();
>  }

I thought that Costin wants tabs in the files for Tomcat 3.x.

-jon

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/resources LocalStrings_es.properties

[nacho]

nacho   01/07/10 16:14:29

  Modified:src/share/org/apache/tomcat/resources
LocalStrings_es.properties
  Log:
  Missed string
  
  Revision  ChangesPath
  1.17  +2 -1  
jakarta-tomcat/src/share/org/apache/tomcat/resources/LocalStrings_es.properties
  
  Index: LocalStrings_es.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/resources/LocalStrings_es.properties,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- LocalStrings_es.properties2001/06/09 00:24:21 1.16
  +++ LocalStrings_es.properties2001/07/10 23:14:25 1.17
  @@ -1,4 +1,4 @@
  -# $Id: LocalStrings_es.properties,v 1.16 2001/06/09 00:24:21 costin Exp $
  +# $Id: LocalStrings_es.properties,v 1.17 2001/07/10 23:14:25 nacho Exp $
   #
   
   # Localized strings for package org.apache.tomcat.core
  @@ -111,6 +111,7 @@
   standardSession.getCreationTime.ise=getCreationTime: Sesión ya invalidada
   standardSession.getMaxInactiveInterval.ise=getMaxInactiveInterval: Sesión ya 
invalidada
   standardSession.getValueNames.ise=getAttributeNames: Sesión ya invalidada
  +endpoint.err.nonfatal=El Endpoint {0} a ignorado la excepcion: {1}
   standardSession.removeAttribute.ise=removeAttribute: Sesión ya invalidada
   standardSession.setAttribute.ise=setAttribute: Atributo no serializable
   standardSession.setAttribute.ise=setAttribute: Sesión ya invalidada
  
  
  

cvs commit: jakarta-tomcat KEYS

[nacho]

nacho   01/07/10 16:13:23

  Modified:.KEYS
  Log:
  Adding my key
  
  Revision  ChangesPath
  1.4   +27 -0 jakarta-tomcat/KEYS
  
  Index: KEYS
  ===
  RCS file: /home/cvs/jakarta-tomcat/KEYS,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- KEYS  2001/06/22 06:50:26 1.3
  +++ KEYS  2001/07/10 23:13:20 1.4
  @@ -75,3 +75,30 @@
   =6l+I
   -END PGP PUBLIC KEY BLOCK-
   
  +Type bits  keyID  Date   User ID
  +DSS  1024/1024 0xFEA4C043 2001/6/24  Ignacio J. Ortega <[EMAIL PROTECTED]>
  +
  +-BEGIN PGP PUBLIC KEY BLOCK-
  +Version: PGPfreeware 7.0.3 for non-commercial use 
  +
  +mQGiBDs1PSgRBAD8g1RLIdDEk1+XW0DeaOrtzDPRUblHwty9S7a2UfiOEJA8GMZv
  +GAT7HcEynxt6P4a58k3DceWvRw4kcu5PRF++qufzroWkSHK3V/gaDxva9XavfbS0
  +vgQC5In4ZG+iKw1CbGeXzMnA28YIVbQztpKWFhyrD5q86DjrcBTefM2e0wCg/+iA
  +J0DSHbKfiu9mqe8HzVcuXlsEALSSTdUJPRa80bmr6prsuc2heJLa22ddGHkJ5OXD
  +pvY9mmY+fDe9wL5bnsbnDvmhwoDAsog/+jjWjJhleF+TR+wzEkmO5fYLv8qZPXet
  +r6loSaY84XwrcN1ZMvGKfhfZMeAGg/McUeivT2q+3NH2dD5IK5tM960lPvq2kk6f
  +41miA/4kxh/en3CG/qyfb0E33L6XY5xY+IMTnGX7tKFZuGcXtni04mqnmJAdGcoM
  +Y8IwLQ1jyy3rJnXYKcJ59ZaIiku5fsOYOMu2MKRr7H6sBhC9wbmk1XfAHNJAaWTK
  +GItHjCIIjneFZwZttC44PRspMI5bzb2sskSlH1gO7bt7nbDKMLQkSWduYWNpbyBK
  +LiBPcnRlZ2EgPG5hY2hvQGFwYWNoZS5vcmc+iQBYBBARAgAYBQI7NT0oCAsDCQgH
  +AgEKAhkBBRsDAAoJEAO7fiv+pMBDCqQAn08IyL3DNeIF6mo4DlE4BVk7rEN4
  +AJ43Di7ytG4nj9y5qioBRhfBjkMZRLkBDQQ7NT0tEAQA2MJMI4ekdHE7YH0CEt1N
  +GwPm6ymI0Qkg4L4bFXtazgZAKH0iJS6+kpQ0W2wqt9/QKEOxb+OQvECChu+wgJXf
  +wg2P4ZoqdwXvfR8vZiMaJ08+aK1p280qxuhkb82WoTspnGOI0lvwXpi1rMTDT+j7
  +AHvugFdwv9XFoTnomDpm/tkAAgIEAL1gLivRvNlYlFbuXEoucD5/48gKQdUsOSL9
  +WFTroUCwuvrLUJe9EHcb0aiDNRDX/CMtwmznLtFMUteUQBWjiDij39WnPDISvWvj
  +tVxg1wthlNsFqd/M2SpvE1b4yI5I0jPAQ/t4LYD3DOQ94xqUvA/5oWb/g54KNUQD
  +YbEf2RYSiQBMBBgRAgAMBQI7NT0tBRsMAAoJEAO7fiv+pMBDGhEAnRz4KyzY
  +exuadIvVuO6wHxaKqnBjAJ0Zmsli7ai95+k7BwOpWx3Hv8YWVw==
  +=GIGG
  +-END PGP PUBLIC KEY BLOCK-
  
  
  

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

[nacho]

nacho   01/07/10 16:08:35

  Modified:src/facade22/org/apache/tomcat/facade HttpSessionFacade.java
  Log:
  *  setAttribute() was calling valueBound() after storing the
 object in the session.  The spec calls for the reverse.
  *   setAttribute() didn't call valueUnbound() for the
 object it replaces, if present.
  
  Revision  ChangesPath
  1.9   +63 -60
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpSessionFacade.java
  
  Index: HttpSessionFacade.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpSessionFacade.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- HttpSessionFacade.java2001/03/09 23:33:59 1.8
  +++ HttpSessionFacade.java2001/07/10 23:08:32 1.9
  @@ -100,21 +100,21 @@
   /** Package-level method - accessible only by core
*/
   void setRealSession(ServerSession s) {
  - realSession=s;
  - realSession.setFacade( this );
  +realSession=s;
  +realSession.setFacade( this );
}
   
   /** Package-level method - accessible only by core
*/
   void recycle() {
  - //  realSession=null;
  +//  realSession=null;
   }
   
   //  public facade 
   
   public String getId() {
  - checkValid();
  - return realSession.getId().toString();
  +checkValid();
  +return realSession.getId().toString();
   }
   
   /**
  @@ -125,8 +125,8 @@
*  invalidated session
*/
   public long getCreationTime() {
  - checkValid();
  - return realSession.getTimeStamp().getCreationTime();
  +checkValid();
  +return realSession.getTimeStamp().getCreationTime();
   }
   
   /**
  @@ -136,12 +136,12 @@
* @deprecated
*/
   public HttpSessionContext getSessionContext() {
  - return new SessionContextImpl();
  +return new SessionContextImpl();
   }
   
   public long getLastAccessedTime() {
  - checkValid();
  - return realSession.getTimeStamp().getLastAccessedTime();
  +checkValid();
  +return realSession.getTimeStamp().getLastAccessedTime();
   }
   
   /**
  @@ -151,8 +151,8 @@
*  an invalidated session
*/
   public void invalidate() {
  - checkValid();
  - realSession.getTimeStamp().setValid( false );
  +checkValid();
  +realSession.getTimeStamp().setValid( false );
   }
   
   /**
  @@ -166,59 +166,62 @@
*  invalidated session
*/
   public boolean isNew() {
  - checkValid();
  - return realSession.getTimeStamp().isNew();
  +checkValid();
  +return realSession.getTimeStamp().isNew();
   }
   
   /**
* @deprecated
*/
   public void putValue(String name, Object value) {
  - setAttribute(name, value);
  +setAttribute(name, value);
   }
   
   public void setAttribute(String name, Object value) {
  - checkValid();
  +checkValid();
  +Object oldValue;
  +//  ServerSessionManager ssm=(ServerSessionManager)
  +//  realSession.getManager();
  +// Original code - it's up to session manager to decide
  +// what it can handle.
  +//  if (ssm.isDistributable() &&
  +//!(value instanceof Serializable))
  +//  throw new IllegalArgumentException
  +//  (sm.getString("standardSession.setAttribute.iae"));
  +oldValue=realSession.getAttribute( name) ;
  +if (oldValue!=null) {
  +removeAttribute(name);
  +}
  +if (value instanceof HttpSessionBindingListener)
  +   ((HttpSessionBindingListener) value).valueBound
  +(new HttpSessionBindingEvent( this, name));
  +realSession.setAttribute( name, value );
   
  - //  ServerSessionManager ssm=(ServerSessionManager)
  - //  realSession.getManager();
  - // Original code - it's up to session manager to decide
  - // what it can handle. 
  - //  if (ssm.isDistributable() &&
  - //!(value instanceof Serializable))
  - //  throw new IllegalArgumentException
  - //  (sm.getString("standardSession.setAttribute.iae"));
  - 
  - realSession.setAttribute( name, value );
  - if (value instanceof HttpSessionBindingListener)
  - ((HttpSessionBindingListener) value).valueBound
  - (new HttpSessionBindingEvent( this, name));
  -
   }
   
   /**
* @deprecated
*/
   public Object getValue(String name) {
  - return getAttribute(name);
  +return getAttribute(name);
   }
   
   public Object getAttribute(String name) {
  - 

Re: cvscommit:jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compilerParserController.java

[Jon Stevens]

on 7/10/01 3:25 PM, "Rob S." <[EMAIL PROTECTED]> wrote:

> Ha!  I've been working with JSP since 1999 and I never caught that!

Even more proof!

:-)

JSP is overly complex and takes *years* to master.

:-)

-jon

Re: Suggestions (was Re: hello everyone (regarding documentation))

[Christopher Cain]

Alex Fernández wrote:
> 
> Hi Hiten!
> 
> hiten pandya wrote:
> > i am planning to start my own documentation project for Tomcat 3.3 and 4.0.
> > The different thing about this project is that, i am going to port all of
> > the tomcat documentation to XML Docbook format.
> 
> Not speaking officially, I'm not a committer: if you want to document
> Tomcat, then go ahead and good luck!
> 
> Your focused work can do lots for the docs: you will probably end before
> the "committee" decides the right format for Tomcat docs :)

LLAMF! True that.

> Just a suggestion:
> > Though i am not very good at docbook but i think i can cope. Once the
> > documentation is complete, I will submit it to the main tomcat development
> > team.
> 
> Don't wait till everything is ready; send your updates regularly to the
> dev list, so folks can criticize your work and point possible mistakes.
[snip]

Am I the only one that initially read that as "send your updates
regularly so that folks can criticize you and your pointless mistakes"?
Alex deals some very sage advice here, but when I first hit "Reply" he
was about to get some even higher praise for the funniest pointed
sarcasm I had heard in quite some time.

...

Uhhh ... I guess you had to be there. In any event, Alex's advice is
quite sound, FWIW.

[DOC] TOC - thoughts

[Rob S.]

There is a WHACK of info in that TOC.  Your copyright is well-deserved =)

First off, I think we should have an ultra-quick install guide.  If you're
like a lot of geeks, you know your stuff.  You need to know a quick few
steps, a quick 2-3 gotchas, and BAM that's it.  I want to make sure the
quick-and-dirty "impatient" install is available to the people who can take
advantage of it; admins experienced with other containers, trying Tomcat for
the first time perhaps.

PI.1.1:  I agree with the "big picture" view of things, but from what's
there, it almost looks like you're explaining the parts that I as an admin,
would expect to see in the installation documentation.  Was there something
more to this section than a description of Tomcat's internal layout?

PI.1.2:  Agree with comments, remove to appendix.  There are a million other
places on the Internet that introduce these things, and I'm sure they'll
have done a better job than most of us care to attempt.

PI.2.1:  I love pictures!  Some nice diagrams in here would go a lllong way.
Not sure about the "choose OS" or "install Java" sections.  I mean, there's
catering to the LCD and there's catering to the LCD...

I think a lot of PI.2 is overkill, and some unnecessary, dependant upon the
implied length of the sections from  the TOC I suppose...  I mean one or two
sentences to "downloading JDK", sure, but more than that?  Definitely more
suited to a book than "good enough" docs ;)

Overall, thanks for organizing this in such detail.  It's a really good
read!  I need to cook dinner and catch Law and Order.  I'll reply to the
rest later =)

- r

RE: cvs commit:jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compilerParserController.java

[Rob S.]

> >   <%@ include file="XX" %> says "file" and is thus relative to 
> the "JSP file".
> >says "page" and is thus relative 
> to the "JSP
> > page".
> 
> Try teaching that to a web designer.
> 
> Bah. JSP sucks.

Ha!  I've been working with JSP since 1999 and I never caught that!

(That page vs. file thing, not that Jon thinks JSP sucks) ;)

- r

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

[remm]

remm01/07/10 15:08:30

  Modified:catalina/src/share/org/apache/catalina/session
LocalStrings.properties StandardSession.java
  Log:
  - Specifying a null name will result in a illegal arg exception being thrown.
Bug reported by Kumar Mettu 
  
  Revision  ChangesPath
  1.8   +1 -0  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/LocalStrings.properties
  
  Index: LocalStrings.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/LocalStrings.properties,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- LocalStrings.properties   2001/04/26 01:40:55 1.7
  +++ LocalStrings.properties   2001/07/10 22:08:25 1.8
  @@ -42,6 +42,7 @@
   standardSession.sessionEvent=Session event listener threw exception
   standardSession.setAttribute.ise=setAttribute: Non-serializable attribute
   standardSession.setAttribute.ise=setAttribute: Session already invalidated
  +standardSession.setAttribute.namenull=setAttribute: name parameter cannot be null
   standardSession.sessionCreated=Created Session id = {0}
   persistentManager.loading=Loading {0} persisted sessions
   persistentManager.unloading=Saving {0} persisted sessions
  
  
  
  1.22  +9 -4  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardSession.java
  
  Index: StandardSession.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardSession.java,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- StandardSession.java  2001/07/10 03:18:57 1.21
  +++ StandardSession.java  2001/07/10 22:08:27 1.22
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardSession.java,v
 1.21 2001/07/10 03:18:57 jon Exp $
  - * $Revision: 1.21 $
  - * $Date: 2001/07/10 03:18:57 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardSession.java,v
 1.22 2001/07/10 22:08:27 remm Exp $
  + * $Revision: 1.22 $
  + * $Date: 2001/07/10 22:08:27 $
*
* 
*
  @@ -111,7 +111,7 @@
* @author Craig R. McClanahan
* @author Sean Legassick
* @author mailto:[EMAIL PROTECTED]";>Jon S. Stevens
  - * @version $Revision: 1.21 $ $Date: 2001/07/10 03:18:57 $
  + * @version $Revision: 1.22 $ $Date: 2001/07/10 22:08:27 $
*/
   
   class StandardSession
  @@ -1021,6 +1021,11 @@
*  invalidated session
*/
   public void setAttribute(String name, Object value) {
  +
  +// Name cannot be null
  +if (name == null)
  +throw new IllegalArgumentException
  +(sm.getString("standardSession.setAttribute.namenull"));
   
   // Null value is the same as removeAttribute()
   if (value == null) {
  
  
  

Re: cvs commit:jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compilerParserController.java

[Jon Stevens]

on 7/10/01 1:12 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

>   <%@ include file="XX" %> says "file" and is thus relative to the "JSP file".
>says "page" and is thus relative to the "JSP
> page".

Try teaching that to a web designer.

Bah. JSP sucks.

-jon

cvs commit: jakarta-tomcat/src/tests/webpages/aaa/protected index.jsp

[larryi]

larryi  01/07/10 14:13:24

  Modified:src/tests/webpages/WEB-INF test-tomcat.xml web.xml
  Added:   src/tests/webpages/aaa login.jsp loginerr.jsp
   src/tests/webpages/aaa/protected index.jsp
  Log:
  Add a test that catches my recent breakage of authorization in the patch
  for avoiding recursive status errors.  Patch for fixing authorization to follow.
  
  Also some minor cleanup.
  
  Revision  ChangesPath
  1.32  +15 -5 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.31
  retrieving revision 1.32
  diff -u -r1.31 -r1.32
  --- test-tomcat.xml   2001/05/23 03:28:13 1.31
  +++ test-tomcat.xml   2001/07/10 21:13:02 1.32
  @@ -16,7 +16,7 @@
   early tests.
   -->
   
  -   
  +   



  @@ -1113,7 +1113,7 @@
   
  
   
  -   
  +   
 
  
   
  -   
  +   
 
 Writer test, closing writer at end
 
  @@ -1219,7 +1219,7 @@
 
 
 
  -  Writer test,trying to catch reciclying issues
  +  Writer test,trying to catch recycling issues
 
 
 
  @@ -1227,8 +1227,18 @@
 
  
   
  +   
  +  
  +  Test for required authorization redirection response
  +  
  +  
  +  http://${host}:${port}/test/aaa/login.jsp"; />
  +  
  +  
  +   
  +
  
  -   
  +   
  
   
  
  
  
  
  1.11  +16 -0 jakarta-tomcat/src/tests/webpages/WEB-INF/web.xml
  
  Index: web.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/tests/webpages/WEB-INF/web.xml,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- web.xml   2001/03/11 22:25:46 1.10
  +++ web.xml   2001/07/10 21:13:07 1.11
  @@ -203,4 +203,20 @@
CONFIDENTIAL


  + 
  + 
  + Access-Authentication-Authorization Test 
Area
  + /aaa/protected/*
  + 
  + 
  + role1
  + 
  + 
  + 
  + FORM
  + 
  + /aaa/login.jsp
  + /aaa/loginerr.jsp
  + 
  + 
   
  
  
  
  1.1  jakarta-tomcat/src/tests/webpages/aaa/login.jsp
  
  Index: login.jsp
  ===
  
  
   Username: 
   Password: 
   
  
  
  
  
  
  1.1  jakarta-tomcat/src/tests/webpages/aaa/loginerr.jsp
  
  Index: loginerr.jsp
  ===
  
  Login failed
  
  
  
  
  1.1  jakarta-tomcat/src/tests/webpages/aaa/protected/index.jsp
  
  Index: index.jsp
  ===
  
  This page is protected
  
  
  

cvs commit: jakarta-tomcat/src/tests/webpages/aaa/protected - New directory

[larryi]

larryi  01/07/10 14:03:26

  jakarta-tomcat/src/tests/webpages/aaa/protected - New directory

cvs commit: jakarta-tomcat/src/tests/webpages/aaa - New directory

[larryi]

larryi  01/07/10 14:01:06

  jakarta-tomcat/src/tests/webpages/aaa - New directory

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

[larryi]

larryi  01/07/10 13:51:10

  Modified:src/share/org/apache/tomcat/core BaseInterceptor.java
  Log:
  Update authorize() method to default to returning DECLINED so it doesn't
  authorize by default.
  
  Revision  ChangesPath
  1.48  +2 -2  
jakarta-tomcat/src/share/org/apache/tomcat/core/BaseInterceptor.java
  
  Index: BaseInterceptor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/BaseInterceptor.java,v
  retrieving revision 1.47
  retrieving revision 1.48
  diff -u -r1.47 -r1.48
  --- BaseInterceptor.java  2001/06/28 07:43:00 1.47
  +++ BaseInterceptor.java  2001/07/10 20:51:08 1.48
  @@ -163,7 +163,7 @@
*  The authorize is called by isUserInRole() and by ContextManager
*  if the request have security constraints.
*
  - *  @returns 0 if the module can't take a decision
  + *  @returns DECLINED if the module can't make a decision
*   401 If the user is not authorized ( doesn't have
*   any of the required roles )
*   200 If the user have the right roles. No further module
  @@ -171,7 +171,7 @@
*/
   public int authorize(Request request, Response response,
 String reqRoles[]) {
  - return 0;
  + return DECLINED;
   }
   
   /** Called before service method is invoked. 
  
  
  

cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler CharDataGenerator.java MappedCharDataGenerator.java

[larryi]

larryi  01/07/10 13:43:38

  Modified:src/share/org/apache/jasper/compiler Tag: tomcat_32
CharDataGenerator.java MappedCharDataGenerator.java
  Log:
  Fix problem with JSP files which use just CR as line terminator. During
  translation CR's would be stripped instead of kept as is or replaced with
  CRLF.  With this patch, line termination is preserved.
  
  Submitted by: Si Ly
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.2.4.1   +6 -5  
jakarta-tomcat/src/share/org/apache/jasper/compiler/CharDataGenerator.java
  
  Index: CharDataGenerator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/CharDataGenerator.java,v
  retrieving revision 1.2
  retrieving revision 1.2.4.1
  diff -u -r1.2 -r1.2.4.1
  --- CharDataGenerator.java2000/04/05 02:55:12 1.2
  +++ CharDataGenerator.java2001/07/10 20:43:33 1.2.4.1
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/CharDataGenerator.java,v 
1.2 2000/04/05 02:55:12 craigmcc Exp $
  - * $Revision: 1.2 $
  - * $Date: 2000/04/05 02:55:12 $
  + * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/CharDataGenerator.java,v 
1.2.4.1 2001/07/10 20:43:33 larryi Exp $
  + * $Revision: 1.2.4.1 $
  + * $Date: 2001/07/10 20:43:33 $
*
* 
* 
  @@ -107,7 +107,8 @@
sb.append("");
break;
case '\r':
  - continue;
  + sb.append("\\r");
  + break;
/*
  case '\'':
  sb.append('\\');
  @@ -115,7 +116,7 @@
  break;
*/
case '\n':
  - sb.append("\\r\\n");
  + sb.append("\\n");
break;
case '\t':
sb.append("\\t");
  
  
  
  1.2.4.1   +6 -5  
jakarta-tomcat/src/share/org/apache/jasper/compiler/MappedCharDataGenerator.java
  
  Index: MappedCharDataGenerator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/MappedCharDataGenerator.java,v
  retrieving revision 1.2
  retrieving revision 1.2.4.1
  diff -u -r1.2 -r1.2.4.1
  --- MappedCharDataGenerator.java  2000/03/06 00:33:51 1.2
  +++ MappedCharDataGenerator.java  2001/07/10 20:43:34 1.2.4.1
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/MappedCharDataGenerator.java,v
 1.2 2000/03/06 00:33:51 mandar Exp $
  - * $Revision: 1.2 $
  - * $Date: 2000/03/06 00:33:51 $
  + * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/MappedCharDataGenerator.java,v
 1.2.4.1 2001/07/10 20:43:34 larryi Exp $
  + * $Revision: 1.2.4.1 $
  + * $Date: 2001/07/10 20:43:34 $
*
* 
* 
  @@ -93,7 +93,8 @@
sb.append("");
break;
case '\r':
  - continue;
  + sb.append("\\r");
  + break;
/*
  case '\'':
  sb.append('\\');
  @@ -101,7 +102,7 @@
  break;
*/
case '\n':
  - sb.append("\\r\\n");
  + sb.append("\\n");
writer.print(sb.toString());
writer.print("\");\n");
sb = new StringBuffer();
  
  
  

cvs commit: jakarta-tomcat-jasper/jasper34/generator/org/apache/jasper34/generator CharDataGenerator.java MappedCharDataGenerator.java

[larryi]

larryi  01/07/10 13:41:53

  Modified:jasper34/generator/org/apache/jasper34/generator
CharDataGenerator.java MappedCharDataGenerator.java
  Log:
  Fix problem with JSP files which use just CR as line terminator. During
  translation CR's would be stripped instead of kept as is or replaced with
  CRLF.  With this patch, line termination is preserved.
  
  Submitted by: Si Ly
  
  Revision  ChangesPath
  1.5   +6 -5  
jakarta-tomcat-jasper/jasper34/generator/org/apache/jasper34/generator/CharDataGenerator.java
  
  Index: CharDataGenerator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper34/generator/org/apache/jasper34/generator/CharDataGenerator.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- CharDataGenerator.java2001/06/13 01:11:35 1.4
  +++ CharDataGenerator.java2001/07/10 20:41:49 1.5
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-jasper/jasper34/generator/org/apache/jasper34/generator/CharDataGenerator.java,v
 1.4 2001/06/13 01:11:35 costin Exp $
  - * $Revision: 1.4 $
  - * $Date: 2001/06/13 01:11:35 $
  + * $Header: 
/home/cvs/jakarta-tomcat-jasper/jasper34/generator/org/apache/jasper34/generator/CharDataGenerator.java,v
 1.5 2001/07/10 20:41:49 larryi Exp $
  + * $Revision: 1.5 $
  + * $Date: 2001/07/10 20:41:49 $
*
* 
* 
  @@ -109,7 +109,8 @@
sb.append("");
break;
case '\r':
  - continue;
  + sb.append("\\r");
  + break;
/*
  case '\'':
  sb.append('\\');
  @@ -117,7 +118,7 @@
  break;
*/
case '\n':
  - sb.append("\\r\\n");
  + sb.append("\\n");
break;
case '\t':
sb.append("\\t");
  
  
  
  1.3   +6 -5  
jakarta-tomcat-jasper/jasper34/generator/org/apache/jasper34/generator/MappedCharDataGenerator.java
  
  Index: MappedCharDataGenerator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper34/generator/org/apache/jasper34/generator/MappedCharDataGenerator.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- MappedCharDataGenerator.java  2001/06/06 06:17:47 1.2
  +++ MappedCharDataGenerator.java  2001/07/10 20:41:50 1.3
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-jasper/jasper34/generator/org/apache/jasper34/generator/MappedCharDataGenerator.java,v
 1.2 2001/06/06 06:17:47 costin Exp $
  - * $Revision: 1.2 $
  - * $Date: 2001/06/06 06:17:47 $
  + * $Header: 
/home/cvs/jakarta-tomcat-jasper/jasper34/generator/org/apache/jasper34/generator/MappedCharDataGenerator.java,v
 1.3 2001/07/10 20:41:50 larryi Exp $
  + * $Revision: 1.3 $
  + * $Date: 2001/07/10 20:41:50 $
*
* 
* 
  @@ -95,7 +95,8 @@
sb.append("");
break;
case '\r':
  - continue;
  + sb.append("\\r");
  + break;
/*
  case '\'':
  sb.append('\\');
  @@ -103,7 +104,7 @@
  break;
*/
case '\n':
  - sb.append("\\r\\n");
  + sb.append("\\n");
writer.print(sb.toString());
writer.print("\");\n");
sb = new StringBuffer();
  
  
  

cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler TagEndGenerator.java

[horwat]

horwat  01/07/10 13:32:04

  Modified:jasper/src/share/org/apache/jasper/compiler
TagEndGenerator.java
  Log:
  Changed to a more meaningful variable name.
  
  Bugzilla #2364
  
  Revision  ChangesPath
  1.7   +2 -2  
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/TagEndGenerator.java
  
  Index: TagEndGenerator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/TagEndGenerator.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- TagEndGenerator.java  2001/04/26 23:17:40 1.6
  +++ TagEndGenerator.java  2001/07/10 20:32:01 1.7
  @@ -179,9 +179,9 @@
   
// TryCatchFinally
if (implementsTryCatchFinally) {
  - writer.println("} catch (Throwable t) {");
  + writer.println("} catch (Throwable exception) {");
writer.pushIndent();
  - writer.println(thVarName+".doCatch(t);");
  + writer.println(thVarName+".doCatch(exception);");
writer.popIndent();
}
   
  
  
  

cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtime PageContextImpl.java

[horwat]

horwat  01/07/10 13:20:05

  Modified:jasper/src/share/org/apache/jasper/runtime
PageContextImpl.java
  Log:
  Added missing break statement to REQUEST_SCOPE case.
  
  Bugzilla #2423
  
  Revision  ChangesPath
  1.11  +4 -3  
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtime/PageContextImpl.java
  
  Index: PageContextImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtime/PageContextImpl.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- PageContextImpl.java  2001/05/10 20:42:33 1.10
  +++ PageContextImpl.java  2001/07/10 20:20:02 1.11
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtime/PageContextImpl.java,v
 1.10 2001/05/10 20:42:33 craigmcc Exp $
  - * $Revision: 1.10 $
  - * $Date: 2001/05/10 20:42:33 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtime/PageContextImpl.java,v
 1.11 2001/07/10 20:20:02 horwat Exp $
  + * $Revision: 1.11 $
  + * $Date: 2001/07/10 20:20:02 $
*
* 
*
  @@ -262,6 +262,7 @@
   
case REQUEST_SCOPE:
request.removeAttribute(name);
  +break;
   
case SESSION_SCOPE:
if (session == null)
  
  
  

cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler ParserController.java

[horwat]

horwat  01/07/10 13:12:13

  Modified:jasper/src/share/org/apache/jasper/compiler
ParserController.java
  Log:
  Fixes include bug. Nested include directive files were not found. In an include 
directive, the file should be found relative to the jsp file doing the including.
  
  Helpful hint:
  
<%@ include file="XX" %> says "file" and is thus relative to the "JSP file".
 says "page" and is thus relative to the "JSP page".
  
  Bugzilla #2543
  
  Revision  ChangesPath
  1.16  +1 -2  
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/ParserController.java
  
  Index: ParserController.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/ParserController.java,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- ParserController.java 2001/06/02 18:44:45 1.15
  +++ ParserController.java 2001/07/10 20:12:07 1.16
  @@ -186,7 +186,6 @@
   
   String absFileName = resolveFileName(inFileName);
//p("filePath: " + filePath);
  -
String encoding = topFileEncoding;
   InputStreamReader reader = null;
   try {
  @@ -419,7 +418,7 @@
isAbsolute ?
inFileName : (String) baseDirStack.peek() + inFileName;
String baseDir = 
  - inFileName.substring(0, inFileName.lastIndexOf("/") + 1);
  + fileName.substring(0, fileName.lastIndexOf("/") + 1);
baseDirStack.push(baseDir);
return fileName;
   }
  
  
  

Re: Suggestions (was Re: hello everyone (regarding documentation))

[guru]

On Tue, Jul 10, 2001 at 10:39:12AM +0200, Alex Fernández wrote:
> Hi Hiten!
> 
> hiten pandya wrote:
> > i am planning to start my own documentation project for Tomcat 3.3 and 4.0.
> > The different thing about this project is that, i am going to port all of
> > the tomcat documentation to XML Docbook format.
> 
> Not speaking officially, I'm not a committer: if you want to document
> Tomcat, then go ahead and good luck!
> 
> Your focused work can do lots for the docs: you will probably end before
> the "committee" decides the right format for Tomcat docs :)

OK, I appreciate the :-) but... that's not *quite* fair.  We're
closing in on a decision, and if you want to write new stuff now you
should just go ahead and do it.  Use text or HTML or even Word.  I
think using DocBook is premature.

I don't think a wholesale conversion of existing docs to DocBook will
be a good use of anyone's time right now.  Maybe in a week or two
we'll be converting them to Anakia or DocBook but not just yet.

> Just a suggestion:
> > Though i am not very good at docbook but i think i can cope. Once the
> > documentation is complete, I will submit it to the main tomcat development
> > team.
> 
> Don't wait till everything is ready; send your updates regularly to the
> dev list, so folks can criticize your work and point possible mistakes.
> That way, you can change course in a timely manner; otherwise you might
> find at the end that a chapter is unnecessary and another one is missing
> :)

Before you write a chapter (or article or HOWTO or whatever you want
to call it), please take a look at (a) the existing docs, and more
importantly (b) the Table of Contents and see if it fits in anywhere.
Then let the list know what you're working on.  We're trying to
organize the docs so there's no redundant information.

(For instance, there's lots of information on configuring Apache
scattered among half a dozen howtos and FAQs right now.  Most of it is
now out of date, and it'll be impossible to bring it all current.  I'd
like there to be one chapter on "integrating with Apache," with
subsections for "mod_jk," "mod_webapp", "mod_jserv," and so on -- and
since the subsections can rely on the introduction of the Apache
chapter, they won't have to duplicate information that's already been
covered above, and won't confuse anybody.  On the Tomcat Forum I
regularly get questions where people have read a mod_jserv howto
instead of a mod_jk howto and they don't even realize there's a
difference, since they're both called "Configuring Apache" without
mentioning the name of the connector.)


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

Tomcat 3.2 "freezing" on .....initializing service: ResourcesService.

[Joe . Bogushefsky]

Title: Tomcat 3.2 "freezing" on .initializing service: ResourcesService.





I  am currently doing a "proof-of-concept" project using Jetspeed for Enterprise-wide Corporate Portal development.


We are using...SuSe 7.1 Linux, Apache Web Server 1.3.14, Tomcat 3.2.2, Jetspeed 1.3a1, Ant, JDK1.3.1, JRE 1.3.1


I have been frustrated with the "build" and "configuration" process.  (I can tell many others have also.)




Can anyone help me with the following problem?


-When starting Tomcat,  Tomcat gets 'hung' at.initializing service: ResourcesService.
-Tomcat started just fine before adding Jetspeed 1.3a1 to TOMCAT_HOME/webapps
-I know that is not telling you much, but pointing me in some direction would be great!


Thanks!!!
Joe 



---
-Here are the messages when starting Tomcat:


jetspeed:/opt/jakarta/bin # ./startup.sh
Guessing TOMCAT_HOME from tomcat.sh to ./..
Setting TOMCAT_HOME to ./..
Using classpath: .:./../lib/META-INF:./../lib/ant-1.2.jar:./../lib/com:./../lib/jasper.jar:./../lib/javax:./../lib/org:./../lib/servlet.jar:./../lib/test:./../lib/webserver.jar:./../lib/xml.jar:/usr/lib/jdk1.3.1/lib/tools.jar:/opt/jakarta/jakarta-ant/lib:/opt/jakarta/jars:/opt/jakarta/lib:/opt/jakarta/jaxp-1.1:/opt/jakarta/jsse1.0.2/lib:/opt/jakarta/Jetspeed-1.3a1/lib:/opt/jakarta/Jetspeed-1.3a1/bin/classes:/opt/jakarta/Jetspeed-1.3a1/bin/:/opt/jakarta/Jetspeed-1.3a1/bin/Jetspeed.jar

jetspeed:/opt/jakarta/bin # Context log: path="/examples" Adding context path="/examples"  docBase="webapps/examples"
Context log: path="" Adding context path=""  docBase="webapps/ROOT"
Context log: path="/test" Adding context path="/test"  docBase="webapps/test"
Context log: path="/jetspeed" Adding context path="/jetspeed"  docBase="webapps/jetspeed"
Starting tomcat. Check logs/tomcat.log for error messages
Starting tomcat install="./.." home="/opt/jakarta" classPath=".:./../lib/META-INF:./../lib/ant-1.2.jar:./../lib/com:./../lib/jasper.jar:./../lib/javax:./../lib/org:./../lib/servlet.jar:./../lib/test:./../lib/webserver.jar:./../lib/xml.jar:/usr/lib/jdk1.3.1/lib/tools.jar:/opt/jakarta/jakarta-ant/lib:/opt/jakarta/jars:/opt/jakarta/lib:/opt/jakarta/jaxp-1.1:/opt/jakarta/jsse1.0.2/lib:/opt/jakarta/Jetspeed-1.3a1/lib:/opt/jakarta/Jetspeed-1.3a1/bin/classes:/opt/jakarta/Jetspeed-1.3a1/bin/:/opt/jakarta/Jetspeed-1.3a1/bin/Jetspeed.jar"

Context log: path="/admin" Automatic context load docBase="/opt/jakarta/webapps/admin" Context log: path="/admin" Adding context path="/admin"  docBase="/opt/jakarta/webapps/admin"

Context log: path="/META-INF" Automatic context load docBase="/opt/jakarta/webapps/META-INF"
Context log: path="/META-INF" Adding context path="/META-INF"  docBase="/opt/jakarta/webapps/META-INF"
Context log: path="/servlets" Automatic context load docBase="/opt/jakarta/webapps/servlets"
Context log: path="/servlets" Adding context path="/servlets"  docBase="/opt/jakarta/webapps/servlets"
Context log: path="/jsp" Automatic context load docBase="/opt/jakarta/webapps/jsp"
Context log: path="/jsp" Adding context path="/jsp"  docBase="/opt/jakarta/webapps/jsp"Context log: path="/WEB-INF" Automatic context load docBase="/opt/jakarta/webapps/WEB-INF"

Context log: path="/WEB-INF" Adding context path="/WEB-INF"  docBase="/opt/jakarta/webapps/WEB-INF"
Context log: path="/images" Automatic context load docBase="/opt/jakarta/webapps/images"
Context log: path="/images" Adding context path="/images"  docBase="/opt/jakarta/webapps/images"
Context log: path="/apidocs" Automatic context load docBase="/opt/jakarta/webapps/apidocs"
Context log: path="/apidocs" Adding context path="/apidocs"  docBase="/opt/jakarta/webapps/apidocs"
Context log: path="/search" Automatic context load docBase="/opt/jakarta/webapps/search"
Context log: path="/search" Adding context path="/search"  docBase="/opt/jakarta/webapps/search"
Context log: path="/about" Automatic context load docBase="/opt/jakarta/webapps/about" Context log: path="/about" Adding context path="/about"  docBase="/opt/jakarta/webapps/about"

Context log: path="/dynamic" Automatic context load docBase="/opt/jakarta/webapps/dynamic"
Context log: path="/dynamic" Adding context path="/dynamic"  docBase="/opt/jakarta/webapps/dynamic"
Context log: path="/ocs" Automatic context load docBase="/opt/jakarta/webapps/ocs"
Context log: path="/ocs" Adding context path="/ocs"  docBase="/opt/jakarta/webapps/ocs"Context log: path="/jcm" Automatic context load docBase="/opt/jakarta/webapps/jcm"

Context log: path="/jcm" Adding context path="/jcm"  docBase="/opt/jakarta/webapps/jcm"Context log: path="/css" Automatic context load docBase="/opt/jakarta/webapps/css"

Context log: path="/css" Adding context path="/css"  docBase="/opt/jakarta/webapps/css"Context log: path="/rss" Automatic context load docBase="/opt/jakarta/webapps/rss"

Context log: path="/rss" Adding context path="/rss"  docBase="/opt/jakarta/webapps/rss"Conte

InstanceListener event handling?

[Thom Park]

Hi Folks,


more on the whole InstanceListener thing.

First the good news - Inserting a DefaultContext at the Engine or Host level
allows each
Context that doesn't define the override attribute to successfully pick up
the InstanceListener defined
in the DefaultContext.

I'm assuming that the only syntax for multiple InstanceListeners is as
follows:


  my.instance.listener1


Please tell me if this is a wrong assumption.

And now for something that's confusing me!
I've written a simple instance listener that simply outputs which event it's
either before or after
and I get the following output:

beforeFilter received for app '/examples'
beforeFilter received for app '/examples'
beforeService received for app '/examples'
beforeInit received for app '/examples'
afterInit received for app '/examples'
afterService received for app '/examples'
afterFilter received for app '/examples'
afterFilter received for app '/examples'
beforeService received for app '/examples'
afterService received for app '/examples'
beforeService received for app '/examples'
afterService received for app '/examples'
beforeService received for app '/examples'
afterService received for app '/examples'
beforeService received for app '/examples'
afterService received for app '/examples'

Why does the 'beforeService' get called before the 'beforeInit'?
Shouldn't an init precede the service event in all cases of a servlet call?
In the above output, \
the init call seems to be nested withing the service call e.g.

...
beforeService
beforeInit
afterInit
afterService
...

The before and after events for my servlet also seem to be being called far
more often
that I would expect ie.

for one request why don't I see the following:

beforeFilter
afterFilter (for every filter defined for my app)
beforeInit
afterInit
beforeService
afterService

and, ultimately,

beforeDestroy
afterDestroy

why do I see so many beforeService/afterService calls? - after all,
I'm only invoking my servlet once.

and, if it's some system servlet (like invokerServlet), why don't I see
just as many beforeInit/afterInit calls.

Of course this is all likely due to my lack of understanding of the Servlet
spec (it usually is!)


-Thom

Re: [DOC] Table of Contents

[Alex Chaffee]

Martin van den Bemt wrote:

> I'm missing a very important one : servlet debugging. All the development
> environments support jps debugging, but servlet debugging is still a pain..
> So that could need some explenation..
> 


See

http://www.jguru.com/faq/view.jsp?EID=158


I've added it to the TOC.

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

RE: InstanceListener syntax?

[Thom Park]

I've had a better look at DefaultContext, it appears to do what I want -
i.e.
give me the ability to define InstanceListener once that will be applied
for all contexts within a given host.

Now I need to find out how to define a DefaultContext ;-)

-Thom


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Glenn Nielsen
Sent: Tuesday, July 10, 2001 6:16 AM
To: [EMAIL PROTECTED]
Subject: Re: InstanceListener syntax?


Remy Maucherat wrote:
>
> > Hi folks,
> >
> > can someone give me the definitive syntax for the InstanceListener?
> > Also, is it possible to setup an Engine (or Host) level InstanceListener
> > that would get applied to all context's within said Engine or Host?
> >
> > Having to add a InstanceListener to every context just to get the old
> > tomcat 3.2 pre/post Lifecycle event (Init,service,destroy) support is a
> > bit onerous.
>
> Glenn, would the default context help here ?
>
> Remy

Its in the code for DefaultContext, but I don't know if it has been tested.

Glenn

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

RE: InstanceListener syntax?

[Thom Park]

Hi Guys,

I'm a wee bit confused - I was looking for the XML Syntax for the
InstanceListener, not how it's
being used within the default context.

I've tried the following in server.xml (within a Context definition):


my.instance.listener


And this works fine, however it doesn't match the other more familiar
constructs
within server.xml, something similar to:




I was just curious as to what, if any, xml exposed options were available
for InstanceListener.

And again, I'm still wondering if it's possible to have an Engine or Host
level instance listener be applied
to all Contexts (where the context doesn't have an Instance entry of it's
own).

How is DefaultContext used? Is it used in the case where there is not a
Context entry for a war file being served
by tomcat?

Either way, it looks to me that, if I want to handle before/after events for
any given servlet, I need to specifically add
an InstanceListener to each and every Context.

Does anyone know of an alternative way of catching the before and after
stages of servlet init, service and destroy?

In tomcat 3.2 I just used a specialized Interceptor (which nicely applied to
all contexts) this new way is a bit awkward...

Hmm... maybe I can add a InstanceListener list to the parent container(s)
and, in the code that handles the current
InstanceListener processing, in the absence of there being a ContextLevel
InstanceListener, I could go up the hierarchy looking for
Instance listeners to invoke.

Any thoughts if that makes sense - or am I likely to get in trouble with
class loading (Context level vs. host & Engine level)...


-Thom

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Glenn Nielsen
Sent: Tuesday, July 10, 2001 6:16 AM
To: [EMAIL PROTECTED]
Subject: Re: InstanceListener syntax?


Remy Maucherat wrote:
>
> > Hi folks,
> >
> > can someone give me the definitive syntax for the InstanceListener?
> > Also, is it possible to setup an Engine (or Host) level InstanceListener
> > that would get applied to all context's within said Engine or Host?
> >
> > Having to add a InstanceListener to every context just to get the old
> > tomcat 3.2 pre/post Lifecycle event (Init,service,destroy) support is a
> > bit onerous.
>
> Glenn, would the default context help here ?
>
> Remy

Its in the code for DefaultContext, but I don't know if it has been tested.

Glenn

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

Suggestions (was Re: hello everyone (regarding documentation))

[Alex Fernández]

Hi Hiten!

hiten pandya wrote:
> i am planning to start my own documentation project for Tomcat 3.3 and 4.0.
> The different thing about this project is that, i am going to port all of
> the tomcat documentation to XML Docbook format.

Not speaking officially, I'm not a committer: if you want to document
Tomcat, then go ahead and good luck!

Your focused work can do lots for the docs: you will probably end before
the "committee" decides the right format for Tomcat docs :)

Just a suggestion:
> Though i am not very good at docbook but i think i can cope. Once the
> documentation is complete, I will submit it to the main tomcat development
> team.

Don't wait till everything is ready; send your updates regularly to the
dev list, so folks can criticize your work and point possible mistakes.
That way, you can change course in a timely manner; otherwise you might
find at the end that a chapter is unnecessary and another one is missing
:)

Un saludo,

Alex.

RE: [DOC] Table of Contents

[Martin van den Bemt]

I'm missing a very important one : servlet debugging. All the development
environments support jps debugging, but servlet debugging is still a pain..
So that could need some explenation..

Mvgr,
Martin

> -Original Message-
> From: Alex Chaffee [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, July 10, 2001 4:37 AM
> To: [EMAIL PROTECTED]
> Subject: [DOC] Table of Contents
>
>
> OK, at Craig's request, here's the current Table of Contents for Tomcat
> docs.  (I wrote a program to convert *** to 1.2.3. format so it's easier
> to read.)
>
> It just occured to me that maybe the TOC will be applicable to both
> versions (3 vs 4), even though the content of each chapter will be
> completely different. I think there's actually value in synchronizing
> the TOCs of two different books, though maybe I'm just being weird :-)
>
> --
> 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/
>

Re: [DOC]: Vote on oustanding doc issues?

[Jon Stevens]

on 7/10/01 4:06 AM, "Rob S." <[EMAIL PROTECTED]> wrote:

> PDF conversion would be pretty cool...  Anyone feel like coming up with a
> sheet to generate XSL:FO? =)

We have started that here:



Not perfect yet because Anakia will need some tweaking to generate all of
the pages as a single FO object, but it is a start.

The real hard part is figuring out how to write FO's. :-)

-jon

Re: [DOC] Vote on oustanding doc issues?

[Alex Chaffee]

Rob S. wrote:


>>I like this compromise.  I will propose that we get rid of the 3.2 docs
>>on the site -- once I'm convinced they're similar enough.  There's still
>>that old "3.3 is a rogue release" sentiment floating around, and people
>>might not appreciate giving 3.3 implied legitimacy by making it the
>>"official" documentation...
>>
> 
> Woah, I thought the committers worked that out a long time ago. 


I was off the list for a while. I tried to read through the archives but all 
the vitriol gave me a headache. Did they just agree to disagree?  Do you 
think there'll be a problem with proposing to remove the 3.2 docs from the site?




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

Re: [DOC]: Vote on oustanding doc issues?

[Alex Chaffee]

Rob S. wrote:


> The tough thing about separating the docs is that the server.xml config
> stuff is spread out among multiple files.  I wonder how difficult it would
> be to maintain an index, or even if it's necessary.


I don't think it's a big deal. I forgot to list the appendices, but one of 
them will be a technical doc describing server.xml tag by tag. Whoever 
writes this should put links in to the relevant parts of the TOC (which will 
in turn contain links to the relevant documents).

> As well, is the intro not part of this breakdown or just not necessary or
> what?  Is the list even getting my emails? =)  I still think we should have
> an intro for people that may/not use Tomcat... err I'll just write it tonite
> and send it to the list and you guys can let me know if you like the
> direction it's headed in! =p


I'm not too worried about the intro, since the Web site already has a 
paragraph describing it, but a "why should I use Tomcat" chapter would go in 
the "Overview" section (see TOC).  Also, that's more a FAQ than a chapter. 
But hey, write it! We'll check it in, and you can also post it to the jGuru 
FAQ if you like.




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

Re: hello everyone (regarding documentation)

[Alex Chaffee]

GOMEZ Henri wrote:

>>Pier:
>>A nice way to duplicate the job, indeed... Why not joining 
>>Alex et. al and 
>>
> 
> Each contribution is good to have. If he feel more confortable
> using docbook, why not let him start some docs with it.
> 
> 
>>write the documentation with them? Just because you want to do it with 
>>the DocBook DTD? A ridiculous excuse, as with a very simple XSLT 
>>stylesheet you can convert the Anakia DTD in DocBook with no fuzz...
>>
> 
> If an XSLT exist for converting Anakia to DocBook, it should be possible 
> to do the reverse. Could you provide us, Pier, the XLST file to convert 
> from Anakia to DocBook ?
> 


Docbook is a *huge* file format. I've heard it described as "SGML in XML." 
There are probably features in DocBook that would be very difficult to 
automatically port back to XHTML.

> BTW, I didn't recall there was a vote on the list to decide if we should 
> use DocBook or Anakia to produce documentation ?
> 

Not yet. Another reason why nobody should jump the gun with a complicated 
format that might end up having to be ported to XHTML.

My advice for potential authors is to use text or very simple HTML (, 
, , , and ) so it'll be easy to shift to a common format 
once we do decide. Also it'll mean you don't waste time making it pretty, 
and focus on the text itself.

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

Year in copyright

[Alex Chaffee]

The current LICENSE file in jakarta-tomcat root says "Copyright 1999". 
Shouldn't this be "1999-2001"?

Or does it apply to the text of the license, and not to the content of the 
project?

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

Re: t4 - status check

[Pier P. Fumagalli]

GOMEZ Henri at [EMAIL PROTECTED] wrote:

>> Knowing Jon, I don't really think he was referring to the
>> module... He would
>> have called it "module" :)
> 
> Could someone teach us why the word 'module' is so impopular in Tomcat
> whereas it was the success reason of Apache HTTP Server.
> 
> Small is beautifull  :)

It's not unpopular at all... Who makes you believe it is?

Pier

RE: t4 - status check

[Tom Comeau]

> > Did you hear about Sun's shutdown last week ? ;-)
> > 
> 
> no ... :)  what is this all about ??

Sun "asked" everybody to use up some vacation, so they could stop carrying
it as a future liability.  They weren't alone.  See, e.g.:
http://public.wsj.com/sn/y/SB993836687859524630.html

tc>

InvocationTargetException tomcat + visualage

[Jayne Hehir]

Hi,

I also have had similar problems with an InvocationTargetException being
thrown by StartTomcat.

I am using VisualAge 3.0 Enterprise and Tomcat 3.2.2, following instructions
found in http://www7.software.ibm.com/vad.nsf/Data/Document2390?OpenDocument

I also have made the suggested code change to the main in StartTomcat,
overcome the issue of passing arguments and setting the home to "." in the
main of StartTomcat.

Have you any other suggestions, as to what the cause is?

Cheers
Jayne

RE: My small, simple problem continued... (null container for my valve)

[Kedar Hirve]

Forget the last question. I'm finding that I'm rising to new levels of
stupidity. :)

RE: My small, simple problem continued... (null container for my valve)

[Kedar Hirve]

All right, I think I figured it out, and it seems a little strange. I was
checking to see what the container for my valve was, in the
_constructor_...the constructor is getting called before any of the
heirarchy tree is built, it seems. Does Catalina load up components and run
constructors in-order, rather than pre-order?

One odd question, though...when IS the invoke method of a valve called?

-KSH

-Original Message-
From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 09, 2001 5:57 PM
To: [EMAIL PROTECTED]
Subject: Re: My small, simple problem continued... (null container for
my valve)


> Oh, WOW. It did work, and I didn't even have to modify Catalina's startup
> classpath. I had tried putting the class under common\lib and server\lib,
> but I didn't know that common\classes would work. But now I've got another
> problem...

In the lib folders, you can only put jars. Un-jarred classes should be in
the classes folders. That's mentioned in the CL docs.

The best place to put your valve here is in server/classes/

> Again, I have this barebones valve class I wrote, and I've gotten it to
load
> up without exception in Catalina. Now, oddly enough, I find that my valve
> has a null container, even though its nested in a context in my
server.xml:
>
>  debug="0"
>  docBase="/" reloadable="true">
>
> directory="/logs/kedlog" prefix="valvetest" timestamp="true" />
>
>
> 
>
> Is there some initialization I need to do, or am I forgetting some tags in
> my server.xml?

Does your valve extend ValveBase or implement Contained ?

Remy

RE: t4 - status check

[GOMEZ Henri]

>Knowing Jon, I don't really think he was referring to the 
>module... He would
>have called it "module" :)

Could someone teach us why the word 'module' is so impopular in Tomcat 
whereas it was the success reason of Apache HTTP Server.

Small is beautifull  :)

[TC322 diff] appending to logfiles

[Marcus Crafter]

Hi All,

Hope all is well.

I know TC322 is now in maintainence mode, but FWIW, here's a patch
that allows you to specify append="boolean" in the Logger definitions
of the server.xml. This allows you to configure appending to log
files in the server.xml.

Is such functionality already in TC33 or T4 ?

Cheers,

Marcus

-- 
.
 ,,$,  Marcus Crafter
;$'  ':Computer Systems Engineer
$: :   Open Software Associates GmbH
 $   o_)$$$:   82-84 Mainzer Landstrasse
 ;$,_/\ &&:'   60327 Frankfurt Germany
   ' /( &&&
   \_' Email : [EMAIL PROTECTED]
  .Business Hours : +49 69 9757 200
&&&:


Index: src/share/org/apache/tomcat/logging/Logger.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/logging/Attic/Logger.java,v
retrieving revision 1.7.4.1
diff -u -r1.7.4.1 Logger.java
--- src/share/org/apache/tomcat/logging/Logger.java 2000/07/06 22:20:17 
1.7.4.1
+++ src/share/org/apache/tomcat/logging/Logger.java 2001/07/10 10:20:47
@@ -236,7 +236,7 @@
if (!file.exists())
new File(file.getParent()).mkdirs();

-   this.sink = new FileWriter(path);
+   this.sink = new FileWriter(path, append);
} catch (IOException ex) {
System.err.print("Unable to open log file: "+path+"! ");
System.err.println(" Using stderr as the default.");
@@ -253,6 +253,19 @@
 public static final int INFORMATION = 3;
 public static final int DEBUG = 4;
 
+/**
+ * Set whether this logger should append to log files or not. Default is
+ * not to.
+ *
+ * @param  flagboolean string indicated whether or not logs
+ * should be appended to.
+ */
+public void setAppend(String flag) {
+if ("true".equalsIgnoreCase(flag))
+   this.append = true;
+   else
+   this.append = false;
+}
 
 /**
  * Set the verbosity level for this logger. This controls how the
@@ -398,6 +411,7 @@
 protected static Hashtable loggers = new Hashtable(5);
 
 private int level = WARNING;
+private boolean append = false;
 
 /**
  * Should we timestamp this log at all?

Re: t4 - status check

[Pier P. Fumagalli]

GOMEZ Henri at [EMAIL PROTECTED] wrote:

>> What is the status of T4? I haven't seen a huge amount of
>> commits from Craig
>> and Remy recently and it seems like the whole adaptor stuff
>> will never get
>> finished cause it seems like a big political, testing and configuration
>> mess.
> 
> Did you notice the commit from JF Clere and Pier on J-T-C ???

Knowing Jon, I don't really think he was referring to the module... He would
have called it "module" :)

Pier

Re: InstanceListener syntax?

[Glenn Nielsen]

Remy Maucherat wrote:
> 
> > Hi folks,
> >
> > can someone give me the definitive syntax for the InstanceListener?
> > Also, is it possible to setup an Engine (or Host) level InstanceListener
> > that would get applied to all context's within said Engine or Host?
> >
> > Having to add a InstanceListener to every context just to get the old
> > tomcat 3.2 pre/post Lifecycle event (Init,service,destroy) support is a
> > bit onerous.
> 
> Glenn, would the default context help here ?
> 
> Remy

Its in the code for DefaultContext, but I don't know if it has been tested.

Glenn

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

cvs commit: jakarta-tomcat build.xml

[larryi]

larryi  01/07/10 06:03:40

  Modified:.build.xml
  Log:
  Update javadoc tasks to avoid most of the error messages
  
  Revision  ChangesPath
  1.140 +35 -8 jakarta-tomcat/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat/build.xml,v
  retrieving revision 1.139
  retrieving revision 1.140
  diff -u -r1.139 -r1.140
  --- build.xml 2001/07/02 19:40:54 1.139
  +++ build.xml 2001/07/10 13:03:34 1.140
  @@ -636,11 +636,31 @@
   
 
   
  +  
  +
  +
  +  
  +  
  +  
  +  
  +
  +
  +  
  +
  +
  +  
  +
  +
  +  
  +
  +  
  +
 
   
   
   
 
   
 
   
 
   
 
   
 
   
 
   
 
   

RE: t4 - status check

[GOMEZ Henri]

>What is the status of T4? I haven't seen a huge amount of 
>commits from Craig
>and Remy recently and it seems like the whole adaptor stuff 
>will never get
>finished cause it seems like a big political, testing and configuration
>mess.

Did you notice the commit from JF Clere and Pier on J-T-C ???

Re: t4 - status check

[kevin seguin]

> 
> > What is the status of T4? I haven't seen a huge amount of commits from
> Craig
> > and Remy recently
> 
> Did you hear about Sun's shutdown last week ? ;-)
> 

no ... :)  what is this all about ??

AW: [DOC]: Vote on oustanding doc issues?

[Thomas Bezdicek]

> PDF conversion would be pretty cool...  Anyone feel like coming up with a
> sheet to generate XSL:FO? =)
No problem, I can help out on this issue

regards, tom

RE: Table of Contents

[GOMEZ Henri]

>2) How about moving Developing Interceptors, Valves and Connectors, and
>Using Tomcat Utility Classes to a seperate Developer Guide?  
>They are only
>useful for real hackers.

Don't forget what make Apache HTTP server so successfull. 
The number of modules built for Apache 1.2/1.3 APIs.
If we don't comments and explain how to use and extend 
Tomcat, we'll loose many contributions and indirects
users.
 

RE: [DOC]: Vote on oustanding doc issues?

[GOMEZ Henri]

>PDF conversion would be pretty cool...  Anyone feel like 
>coming up with a
>sheet to generate XSL:FO? =)

Good idea, we should find help on xml.apache.org.

>> If someone is scared of XML, they can submit it to us in 
>text format and
>> we can go add tags (as time permits), but we're all 
>developers here, so
>> I don't think that's an issue.
>
>With the (hopeful ;) abundance of docs we'll put in there ourselves,
>there'll be plenty of sample 'code' to work with.  As well, 
>the closer we
>stick to HTML, the easier it'll be...
>
>> I. Standalone Installation Guide
>> II. Installation Behind a Web Server Guide
>> III. Deploying and Configuring, or Tomcat Administrator's Guide
>> IV. Performance Tuning Guide
>> V. Tomcat Developer's Guide (writing code for Tomcat itself)
>>
>> I and II may merge, as may III and IV, but I think we're 
>looking at at
>> least three major parts. Seems natural that they'd be in separate
>> subdirectories.  But...

I feel that I and II shouldn't merge. It will confuse users 
with Apache .conf, and server.xml. Also many time, it will be
only the Admin/WebMaster of a site which will read the part II.
May be more fluent in Apache config that Tomcat server.xml...

>> My vote is -1 for a separate mailing list at this point, at 
>least until
>> we prove that we're not going to peter out like every other
>> documentation effort so far. :-)

I agree with you. Just prefix your mail with [J-T-D] and it 
will help developpers follow your works and questions :)

RE: [DOC] Vote on oustanding doc issues?

[Rob S.]

> Things To Do before we decide on format or CVS:
>
> * Look at the latest TOC and make comments
>
> * Pick a section or subsection and start writing :-)
>
> * Look at http://tomcatbook.sourceforge.net/ and
> http://groups.yahoo.com/group/tcbook and see if there's anyone there to
> recruit, or if effort is being duplicated

Sounds good to me.  That latest TOC is even more mind-blowing than the first
one.  I think you're *really* scaring people off =)

> I like this compromise.  I will propose that we get rid of the 3.2 docs
> on the site -- once I'm convinced they're similar enough.  There's still
> that old "3.3 is a rogue release" sentiment floating around, and people
> might not appreciate giving 3.3 implied legitimacy by making it the
> "official" documentation...

Woah, I thought the committers worked that out a long time ago.  Well, I
don't want to open any cans of worms so AFAIC, the TC3 doc people can do
what they want (of course), although I don't think maintaining 2 sets of
docs is expected, a good idea, or will even happen =)

> Good point.  I'm for Anakia plus a stylebook saying which HTML tags and
> tricks are approved (like, stay away from JavaScript :-)

OMG! +1 (re: JavaScript)

> No, I think we're making progress.

As far as the TOC is concerned, agreed.

- r

RE: [DOC]: Vote on oustanding doc issues?

[Rob S.]

> Yeah, I guess anarchy will be a little too... anarchic :-)  (Rob S. made
> the point more strongly in his latest message.)

PDF conversion would be pretty cool...  Anyone feel like coming up with a
sheet to generate XSL:FO? =)

> If someone is scared of XML, they can submit it to us in text format and
> we can go add tags (as time permits), but we're all developers here, so
> I don't think that's an issue.

With the (hopeful ;) abundance of docs we'll put in there ourselves,
there'll be plenty of sample 'code' to work with.  As well, the closer we
stick to HTML, the easier it'll be...

> I. Standalone Installation Guide
> II. Installation Behind a Web Server Guide
> III. Deploying and Configuring, or Tomcat Administrator's Guide
> IV. Performance Tuning Guide
> V. Tomcat Developer's Guide (writing code for Tomcat itself)
>
> I and II may merge, as may III and IV, but I think we're looking at at
> least three major parts. Seems natural that they'd be in separate
> subdirectories.  But...

I like the above breakdown as a high-level view of things.  I won't have a
chance to look at the new detailed TOC until tonite, but anything I can't
think of that would go in the docs easily fits under I - V.

The tough thing about separating the docs is that the server.xml config
stuff is spread out among multiple files.  I wonder how difficult it would
be to maintain an index, or even if it's necessary.

As well, is the intro not part of this breakdown or just not necessary or
what?  Is the list even getting my emails? =)  I still think we should have
an intro for people that may/not use Tomcat... err I'll just write it tonite
and send it to the list and you guys can let me know if you like the
direction it's headed in! =p

> My vote is -1 for a separate mailing list at this point, at least until
> we prove that we're not going to peter out like every other
> documentation effort so far. :-)

Agreed!

- r

RE: Possible bug in isapi_redirector.dll

[GOMEZ Henri]

Hi Sam,

>-Original Message-
>From: sam [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, July 10, 2001 9:31 AM
>To: [EMAIL PROTECTED]
>Subject: Possible bug in isapi_redirector.dll
>
>
>Hello there everybody, We think we may have found a bug, 
>possibly in IIS,
>which affects isapi_redirect.dll. We were wondering if anyone 
>else has seen
>this. Perhaps this is a bug for MS, but it seems to affect 
>tomcat so maybe
>someone here can shed some light.
>
>Our software versions are:
>IIS 4.0
>jk_isapi_plugin.c revision 1.5.2.2
>tomcat 3.2.2
>Windows NT 4.0 sp6
>
>
>
>The relevant code in is the file jk_isapi_plugin.c, line 960 in the
>function:
>
>static int get_server_value(LPEXTENSION_CONTROL_BLOCK lpEcb,
>char *name,
>char  *buf,
>DWORD bufsz,
>char  *def_val)
>
>
>When the function lpEcb->GetServerVariable(...) on line 965 is 
>called to
>retrieve CERT_SERIALNUMBER, the value returned in bufsz is wrong. Our
>certificate serial number is 48 chars long, but the value 
>contained in bufsz
>is 47, where it should be 49 (the length of the serial number 
>+ 1 for string
>terminator).
>After the call to GetServerVariable() a '\0' is inserted into buf at
>bufsz-1. This causes our certificate serial number to be truncated by 2
>bytes.
>
>The microsoft doco says that the value returned should be the 
>value length +
>1 for the string terminator. This is from:
>http://msdn.microsoft.com/library/en-us/iisref/html/psdk/asp/is
re8376.asp?fr
ame=true

The problem is clearly in IIS. It return 47 instead of 49
Could you see if the bug is reported in IIS 

RE: [PATCH] Ajp13 wrong Response

[GOMEZ Henri]

I'll study carefully this one to see if he didn't 
broke the recovery stuff added to handle case
where tomcat is restarted...

Thanks

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: William Barker [mailto:[EMAIL PROTECTED]]
>Sent: Monday, July 09, 2001 8:58 PM
>To: [EMAIL PROTECTED]
>Subject: [PATCH] Ajp13 wrong Response
>
>
>This fixes the problem reported by Angel Aray in thread 23795. 
> The diff is
>against TC3.3 M4.  What was happening is that the user hitting 
>the "stop"
>button in the browser was invoking the re-try broken 
>connection logic.  This
>totally freaks out the proxy server who now thinks that the 
>re-sent page is
>actually the page for a different request.
>

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http10 HttpConnector.java

[remm]

remm01/07/10 00:37:08

  Modified:catalina/src/share/org/apache/catalina/connector/http10
HttpConnector.java
  Log:
  - Negative value for maxProcessors means unlimited number of processors.
Bug reported by Kumar Mettu 
  
  Revision  ChangesPath
  1.7   +12 -7 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http10/HttpConnector.java
  
  Index: HttpConnector.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http10/HttpConnector.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- HttpConnector.java2001/05/09 23:42:14 1.6
  +++ HttpConnector.java2001/07/10 07:37:05 1.7
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http10/HttpConnector.java,v
 1.6 2001/05/09 23:42:14 craigmcc Exp $
  - * $Revision: 1.6 $
  - * $Date: 2001/05/09 23:42:14 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http10/HttpConnector.java,v
 1.7 2001/07/10 07:37:05 remm Exp $
  + * $Revision: 1.7 $
  + * $Date: 2001/07/10 07:37:05 $
*
* 
*
  @@ -94,7 +94,7 @@
* purposes.  Not intended to be the final solution.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.6 $ $Date: 2001/05/09 23:42:14 $
  + * @version $Revision: 1.7 $ $Date: 2001/07/10 07:37:05 $
*/
   
   
  @@ -742,10 +742,15 @@
synchronized (processors) {
if (processors.size() > 0)
return ((HttpProcessor) processors.pop());
  - if ((maxProcessors > 0) && (curProcessors < maxProcessors))
  + if ((maxProcessors > 0) && (curProcessors < maxProcessors)) {
return (newProcessor());
  - else
  - return (null);
  + } else {
  +if (maxProcessors < 0) {
  +return (newProcessor());
  +} else {
  +return (null);
  +}
  +}
}
   
   }
  
  
  

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http HttpConnector.java

[remm]

remm01/07/10 00:36:44

  Modified:catalina/src/share/org/apache/catalina/connector/http
HttpConnector.java
  Log:
  - Negative value for maxProcessors means unlimited number of processors.
Bug reported by Kumar Mettu 
  
  Revision  ChangesPath
  1.18  +17 -11
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java
  
  Index: HttpConnector.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- HttpConnector.java2001/06/18 21:35:54 1.17
  +++ HttpConnector.java2001/07/10 07:36:42 1.18
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java,v
 1.17 2001/06/18 21:35:54 remm Exp $
  - * $Revision: 1.17 $
  - * $Date: 2001/06/18 21:35:54 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java,v
 1.18 2001/07/10 07:36:42 remm Exp $
  + * $Revision: 1.18 $
  + * $Date: 2001/07/10 07:36:42 $
*
* 
*
  @@ -95,7 +95,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.17 $ $Date: 2001/06/18 21:35:54 $
  + * @version $Revision: 1.18 $ $Date: 2001/07/10 07:36:42 $
*/
   
   
  @@ -805,18 +805,24 @@
   
synchronized (processors) {
if (processors.size() > 0) {
  -//if (debug >= 2)
  -//log("createProcessor: Reusing existing 
processor");
  +// if (debug >= 2)
  +// log("createProcessor: Reusing existing processor");
return ((HttpProcessor) processors.pop());
   }
if ((maxProcessors > 0) && (curProcessors < maxProcessors)) {
  -//if (debug >= 2)
  -//log("createProcessor: Creating new 
processor");
  +// if (debug >= 2)
  +// log("createProcessor: Creating new processor");
return (newProcessor());
   } else {
  -//if (debug >= 2)
  -//log("createProcessor: Cannot create new 
processor");
  - return (null);
  +if (maxProcessors < 0) {
  +// if (debug >= 2)
  +// log("createProcessor: Creating new processor");
  +return (newProcessor());
  + } else {
  +// if (debug >= 2)
  +// log("createProcessor: Cannot create new processor");
  +return (null);
  +}
   }
}
   
  
  
  

cvs commit: jakarta-tomcat-4.0/catalina/src/bin catalina.bat

[remm]

remm01/07/10 00:35:46

  Modified:catalina/src/bin catalina.bat
  Log:
  - Syntax fix.
Patch submitted by Sergey A. Lipnevich 
  
  Revision  ChangesPath
  1.15  +2 -2  jakarta-tomcat-4.0/catalina/src/bin/catalina.bat
  
  Index: catalina.bat
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/bin/catalina.bat,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- catalina.bat  2001/01/03 19:55:45 1.14
  +++ catalina.bat  2001/07/10 07:35:43 1.15
  @@ -12,7 +12,7 @@
   rem
   rem   JAVA_HOME Must point at your Java Development Kit installation.
   rem
  -rem $Id: catalina.bat,v 1.14 2001/01/03 19:55:45 craigmcc Exp $
  +rem $Id: catalina.bat,v 1.15 2001/07/10 07:35:43 remm Exp $
   rem ---
   
   
  @@ -68,7 +68,7 @@
   if "%1" == "stop" goto doStop
   
   :doUsage
  -echo Usage:  catalina ( env | run | start | stop )
  +echo Usage:  catalina ( env ^| run ^| start ^| stop )
   echo Commands:
   echo   env -   Set up environment variables that Catalina would use
   echo   run -   Start Catalina in the current window
  
  
  

RE: hello everyone (regarding documentation)

[GOMEZ Henri]

>Pier:
>A nice way to duplicate the job, indeed... Why not joining 
>Alex et. al and 

Each contribution is good to have. If he feel more confortable
using docbook, why not let him start some docs with it.

>write the documentation with them? Just because you want to do it with 
>the DocBook DTD? A ridiculous excuse, as with a very simple XSLT 
>stylesheet you can convert the Anakia DTD in DocBook with no fuzz...

If an XSLT exist for converting Anakia to DocBook, it should be possible 
to do the reverse. Could you provide us, Pier, the XLST file to convert 
from Anakia to DocBook ?

BTW, I didn't recall there was a vote on the list to decide if we should 
use DocBook or Anakia to produce documentation ?

RE: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS: [TomcatDocumentation Redactors To Hire]

[GOMEZ Henri]

>Craog
>> I have a feeling that whatever is the same will be a lot of 
>piecemeal here
>> and there, excluding of course, web-app documentation.  So 
>far yourself,
>> Pier, and Henri are the only three TC developers to post 
>their position on
>> that (re: inter-version relevancy).  

Pier and I also working together on a separate sub-project, J-T-C.
A starting user will first install the servlet-engine and then will
try to figure how to link it with its web-server.
Should we ask him to switch from one documentation to another ?

>I thought of another reason for my preference in the shower 
>this morning
>:-).  Consider that I might make a code change that also 
>requires a change
>to the corresponding docs.  If the docs are in the same 
>repository, that
>can easily be done on the same commit (and it becomes obvious 
>to everyone
>when a developer makes a change that breaks the documentation, 
>but fails
>to update it :-).  Having a separate docs repository means I need to do
>two independent check-ins -- it's easy to forget one, and there is no
>obvious link between them to remind you (for example) to back 
>out the docs
>change if you back out the code change.

If you commit a code change in TC 4.0, you'll only have one doc commit
in J-T-D. What's the duplicate effort here ?

>On the other hand, a separate docs repository has one 
>potential advantage
>as well:  we can grant CVS commit privileges on the docs to 
>people who do
>not have those privileges on the code repositories.  To me, 
>this isn't a
>big deal -- if we can trust people to get the docs right, we should be
>able to trust them not to screw up the code -- but it's still there.

That's the goal. a redactor will have access only to J-T-D. A tomcat
commiter will have access to code & docs... 

>> > * The files that are checked in should only be the XML 
>sources, *not* the
>> >   generated files.  This varies from what Jon set up in 
>jakarta-site2,
>> >   based on long and drawn out earlier discussions (same 
>issues as those
>> >   surrounding checking JAR files into CVS :-).
>> 
>> Someone will have to setup something that exposes the latest 
>generated
>> documentation on the Jakarta www site.  It's being done 
>already for Struts,
>> so I guess that won't be a big problem.
>> 
>
>It's pretty straightforward.
>
>> > * At least two documentation webapps (developer-oriented and
>> >   user-oriented) would seem to be appropriate.  Having 
>more than two
>> 
>> "developer" as in "web" or "Tomcat"?  I'm not sure why 
>separating the doc
>> into two packages helps - perhaps I'm missing some obvious 
>benefit trying to
>> think at 7:15am =)
>> 
>
>"Developer" in the sense of this sentence is a Tomcat
>developer.  "User" is the people that just want to download, install,
>configure, and utilize Tomcat as a servlet container.

And a third category is the redactor, someone who write docs to explains 
users how to install and run TC stuff. He also describe to potentials 
new developpers Tomcats (3.2/3.3/4.0) architectures and how they could add
functionnalities to the main core. That's why Apache HTTPD server was
so successfull...