Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs

What about using external entities? ie: http://java.sun.com/dtd/web-app_2_3.dtd"; [ ] > then, between the servlet and servlet mapping sections &jspservlet; -SMD - Original Message - From: "Remy Maucherat" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTE

Re: [VOTE] Proposed jspc refactoring

On Friday 08 November 2002 03:28 pm, Hans Bergsten wrote: > Glenn Nielsen wrote: > > Remy Maucherat wrote: > > [...] > > I agree that JSPC needs to be simplified and that the webapp mode should > > be retained. But the webapp mode should allow for a war file to be > > generated > > which is self c

Re: [VOTE] Proposed jspc refactoring

It's better to look at it as a compiler. It's output happens to be java, but it acts a whole lot more like a compiler than a precompiler. Precompilers are usually more like macro preprocessors. On Friday 08 November 2002 07:05 am, John Trollinger wrote: > I have to disagree with this, jspc is a

Re: [VOTE] Proposed jspc refactoring

I dislike this option immensely. It's entirely contrary to what JSPC is for. It's a tool for generating servlets from JSP that do not require the entire JSP machinery. It produces a web.xml file that maps each jsp page to the generated servlet. The generated servlets are portable between servlet

Re: mavenize tomcat

On Thursday 24 October 2002 08:15 pm, Warner Onstine wrote: > - Original Message - > From: "Costin Manolache" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, October 24, 2002 4:50 PM > Subject: Re: mavenize tomcat > > > > FYI, tomcat5 does have a 'download' target that gets

Re: [5.0] building ?

On Monday 14 October 2002 01:19 pm, Costin Manolache wrote: > Remy Maucherat wrote: > > No, but: > > - my computer is relatively fast (P4m 1.6 these days) > > - I'll get a new one a lot faster really soon :) > > Well, I prefer laptops - and I prefer light over fast. > And those things are quite ex

Re: JSP 2.0's J2SE 1.4 Requirement

The spec defines a conforming JSP 2.0 implementation as one that runs on JDK 1.4. A JSP author may therefore assume the new API's are available when creating their webapp. It's a serious issue for, say, Oracle, or IBM, who has a custom Java VM. But, I hadn't noticed that Apache is bundling JD

Re: Is Compile Failure? was Re: Need some clarifications

seException: The string "--" is not permitted within comments. So I went to line 306, added a /n and tried again. I was just trying to locate the problem. And it vanished. On Friday 04 October 2002 03:55 am, Henri Gomez wrote: > Steve Downey wrote: > > On Thursday 03 October 20

Re: Is Compile Failure? was Re: Need some clarifications

On Thursday 03 October 2002 12:14 pm, Henri Gomez wrote: > Steve Downey wrote: > > Actually, with the recent release of commons-logging, we should be able > > to get rid of the explicit LogKit and Log4J. They're there so as to get a > > complete build of commons-loggin

Re: Is Compile Failure? was Re: Need some clarifications

On Thursday 03 October 2002 12:14 pm, Henri Gomez wrote: > Steve Downey wrote: > > Actually, with the recent release of commons-logging, we should be able > > to get rid of the explicit LogKit and Log4J. They're there so as to get a > > complete build of commons-loggin

Re: cvs commit: jakarta-tomcat-5 build.properties.default

This causes all 181 Watchdog JSP tests to fail. I don't know why yet, and it's probably something simple, but it's not a good sign. On Thursday 03 October 2002 08:56 am, [EMAIL PROTECTED] wrote: > remm2002/10/03 05:56:39 > > Modified:.build.properties.default > Log: >

Re: Is Compile Failure? was Re: Need some clarifications

Actually, with the recent release of commons-logging, we should be able to get rid of the explicit LogKit and Log4J. They're there so as to get a complete build of commons-logging. Tomcat 5 itself doesn't use either directly. Xerces is a different issue. There was a bug that was preventing Tomc

Re: Is Compile Failure? was Re: Need some clarifications

You need to be using the HEAD version of digester. It should have been built in the directory specified by base.path. Double check that it was built correctly. I just recreated it in my depends directory, and the system built fine. A number of the dependencies are unreleased at this point. 'an

Re: Need some clarifications

On Wednesday 02 October 2002 09:38 am, Christian Gross wrote: > Hi > > So I worked myself through the various CVS sources and have a couple of > "official" position questions to ask. > > The CVS projects jakarta-tomcat-catalina and jakarta-tomcat-jasper, will be > forming the Tomcat 5 work? jaka

Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability

On Tuesday 24 September 2002 05:26 pm, Jon Scott Stevens wrote: > on 2002/9/24 4:59 AM, "Remy Maucherat" <[EMAIL PROTECTED]> wrote: > > A security vulnerability has been confirmed to exist in all Apache > > Tomcat 4.x releases (including Tomcat 4.0.4 and Tomcat 4.1.10), which > > allows to use a s

[5][PATCH]catalina-tester assumes that ServletExceptions are NOT unwrapped

Per Servlet 2.3, if a servlet throws a wrapped exception, the error handler that receives it gets the underlying root cause as the exception. That is, if ServletException(new TesterException()) is thrown, the exception in the request under attribute "javax.servlet.error.exception" will be Test

[5][PATCH]catalina/tester fix golden files for new request listener noise

JSP includes now trigger request listeners with the attributes for dispatcher types and dispatcher request paths. This patch adds the output from the request listener to the golden files. Index: JspInclude01a.txt === RCS file: /h

[PATCH][5] Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator SSLAuthenticator.java

JDK 1.4's javac doesn't like this. It's complaining about casting Object to X509Certificate[]. On Saturday 21 September 2002 02:50 am, [EMAIL PROTECTED] wrote: > billbarker2002/09/20 23:50:30 > > Modified:catalina/src/share/org/apache/catalina/authenticator > SS

Re: Jasper 2 Question

On Friday 20 September 2002 07:27 am, peter lin wrote: > I would also like to see the comments in jasper1 ported over to > jasper2. Now if only I didn't need sleep, I'd do it myself and submit a > patch. the code changed quite a bit between jasper1 and jasper2. the > class responsible is in jaspe

Re: Jasper 2 Question

On Friday 20 September 2002 06:18 am, Pier Fumagalli wrote: > Hm The original question was about line numbers on JSPs, when they > are compiled, and when they are executed and throw exceptions, right? > Yes, it was... > > I said "use some tea" because Tea, developed by Disney, goes exactly in

Re: Jasper 2 Question

Jasper2 is targeting JSR45, Debugging Support for Other Languages. On Thursday 19 September 2002 06:28 pm, Lenny Karpel wrote: > ok .. now I am really confused .. here is the tomcat development group .. > the 'Official Reference Implementation' for JSP .. and I am being told by > people within t

[PATCH] catalina DateTool thread safety issue

This patch mirrors that in connectors. DateTool in catalina util is largely obsolete, in any case. The patch cuts out unused code. ? share/org/apache/catalina/startup/CatalinaService.java.smd Index: share/org/apache/catalina/util/CookieTools.java ===

Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf DateTool.java

On Wednesday 18 September 2002 08:34 am, Henri Gomez wrote: > > The upshot is that DateFormats need to be either thread local, or created > > new each time. > > Created each time is exactly what we want to avoid ;) Sacrificing correctness for speed isn't a great trade-off. After all, if it doesn'

Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf DateTool.java

OK, ignore my last message. But, it's not just less paranoid. It's more correct. If rfc1123Format were used elsewhere, the lock on Class.DateTool would not be sufficient. Actually, refreshing my memory on this bug, synchronization is insufficient. http://developer.java.sun.com/developer/bugPa

Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf DateTool.java

I think that should probably be public static String format1123( Date d ) { synchronized(rfc1123Format) { return format1123(d, rfc1123Format); } } Synching on 'this' is overkill. On Tuesday 17 September 2002 11:50 pm, [EMAIL PROTECTED] wrote: > billbarker200

Re: (tester failure) cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves ErrorDispatcherValve.java

The new attributes in the request are causing tester to fail on a number of include and forward tests. For example [tester] EXPECTED: == [tester] This is before the include [tester] Include00a PASSEDSessionListener01: sessionCreated() [tester] Sessi

Re: Contributing patches/enhancements?

From my experience, it depends if it's a bug or an enhancement. If it's a bug, Bugzilla is your friend. Someone will eventually have to deal with it before a release. Just posting to the mailing list means that it's likely to get lost. And patches for bugs tend to be fairly stable over time. On

Re: Catalina tester failure on JSP Document Parsing

: > I'd suggest that we remove this test. > > Jasper 2 and jasper produces different but correct XML view of the JSP > document. If the golden file is fixed to pass in TC5, it would then > fail in TC4.0. > > > Date: Wed, 11 Sep 2002 18:10:59 -0400 > > From: Stev

Catalina tester failure on JSP Document Parsing

I'm seeing the following error on catalina's tester app, running it under Tomcat 5: [echo] - JSP Document Parsing - [tester] EXPECTED: == [tester] texttexttexttexttexttext [tester] [teste

[5][PATCH] Enable manager app in catalina/tester deployment

The tester app needs to unload and reload the tester webapp, but, of course, the manager app is not enabled by default. This adds a tomcat-users.xml so that it can be deployed and run automatically. Now there are only a few failures left that I'm seeing. The tomcat-users.xml should go into a

Re: [5][PATCH] catalina/tester fix some false positive and false negative tests

On Tuesday 10 September 2002 10:56 pm, Steve Downey wrote: > This patch builds tester against the servletapi-5 classes and repairs the > URLs in the JSP examples used by tester. These were causing some false > positve and false negative test results. Index:

[5][PATCH] catalina/tester fix some false positive and false negative tests

This patch builds tester against the servletapi-5 classes and repairs the URLs in the JSP examples used by tester. These were causing some false positve and false negative test results. -- To unsubscribe, e-mail: For additional commands, e-mail:

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

Broken build, please revert this. Log has no log method. (Second time today. Bound to happen once in while.) On Tuesday 10 September 2002 03:40 pm, [EMAIL PROTECTED] wrote: > jfarcand2002/09/10 12:40:25 > > Modified:catalina/src/share/org/apache/catalina/startup >

Re: cvs commit: jakarta-tomcat-catalina build.xml gump.xml

Perhaps you could also change > back to target="deploy", since you deleted the catalina.target property? On Tuesday 10 September 2002 01:26 pm, [EMAIL PROTECTED] wrote: > bobh2002/09/10 10:26:17 > > Modified:.build.xml gump.xml > Log: > - Larry Isaacs suggests t

[5][PATCH]JSP examples now at different URI

Rather than being under /examples/jsp/, they're now under /jsp-examples/. The plugin needs to be aware of the full URI, but everything else is context relative. ? .classpath ? .cvsignore ? .project Index: jsr152/examples/WEB-INF/web.xml

[5][PATCH]o.a.j.runtime.* import in gen'd JSP

Generated JSP classes import org.apache.jasper.runtime.*. According to the JSP spec the default imports should be java.lang.*, javax.servlet.*, javax.servlet.jsp.* and javax.servlet.http.*. The classes from o.a.j.runtime should be fully qualified, rather than imported. As far as I can tell, th

Re: [4.1.10] New test milestone released

There's a tester application in Catalina. Watchdog is the basis for the official test kit for the servlet and JSP specs. It's portable and generic. Tester, on the other hand, is Tomcat specific. So putting Tomcat regression tests in it is very appropriate. On Monday 02 September 2002 09:30 am

[5][PATCH] Build and run the catalina tester webapp against tomcat5

, so the 'touch' tasks had to be removed. Since the tomcat.base is rebuilt every run, the touches are redundant. Unfortunately, many of the tester tests are failing. I don't know, yet, if they are bugs in tester or bugs in tomcat. But at least there's a baseline for comparis

RE: Spec question: RE BUG 12052

I think you're missing the virtual server angle. There is NOT a 1-1 mapping from ip address to DNS name. It's N-M. Even from the standpoint of a single machine which received the request, there are many possible names for the IP address. So, given a request like: GET /pub/WWW/TheProject.ht

Re: HTTP Host Request header and TC Connectors

My understanding is that this is really a client issue, rather than server. By the time a connector gets it, it's too late to do much about it. A little bit of research indicates that the user agents I have about will put the IP address in the Host header if the URI is specified by IP. That see

RE: Jasper 2 class files

However, in the context of JspC, it's a problem to map them to the same package and class name. The custom URLClassLoader works within the JSP engine, but the general servlet class loader doesn't know about those rules. So when it sees those entries in web.xml, it will map all hello.jsp files, no

RE: Jasper 2 class files

he jsp pages there and without going through jasper? > > > org.apache.jsp.hello_jsp > org.apache.jsp.hello_jsp > > > > org.apache.jsp.hello_jsp > /subdir/hello.jsp > > > -Original Message- > From

Re: Jasper 2 class files

Is jspcache the place that Tomcat is looking for generated classes? If so, then the custom JSP classloader is doing its magic. The java and class files produced by the JspC command line compiler should be able to be jared up and placed into the WEB-INF directory, like any other servlet. And t

RE: jasper package

The compiler driver and classloader used by tomcat does a lot of magic to get it to work. All jsp files named, for example, index.jsp, will be compiled to a class named org.apache.jsp.index$jsp.java. It will be in a directory with the same name as the directory of the jsp file, but that's not repr

RE: jasper package

For the command line compiler, I've found it very useful. It specifies the base package for the compiled jsp pages. By matching that with the directory that the pages are output into, I can then point an ant javac task at them and validate that everything compiles correctly, as part of an automate

Re: Watchdog aggregation of headers may be incorrect

On Sunday 18 August 2002 11:02 am, [EMAIL PROTECTED] wrote: > My understanding - the HTTP spec doesn't ( and can't ) define a complete > list of headers supporting multiple values. That's impossible given that > additional headers are supported. > The spec does exactly that. It enumerates the pro

Re: Watchdog aggregation of headers may be incorrect

On Sunday 18 August 2002 08:39 am, Remy Maucherat wrote: > Steve Downey wrote: > > On Saturday 17 August 2002 01:40 pm, Remy Maucherat wrote: > >>Steve Downey wrote: > > > > > > > >>>The real problem, for the servlet spec implementation, is that n

Re: Watchdog aggregation of headers may be incorrect

On Saturday 17 August 2002 01:40 pm, Remy Maucherat wrote: > Steve Downey wrote: > > > > The real problem, for the servlet spec implementation, is that not just > > getHeaders() is affected. getHeader() must be also. getHeader, if there > > are multiple values, needs

Re: Watchdog aggregation of headers may be incorrect

On Saturday 17 August 2002 12:47 pm, Remy Maucherat wrote: > Steve Downey wrote: > > On Saturday 17 August 2002 09:00 am, Remy Maucherat wrote: > >>Patrick Luby wrote: > >>>Steve, > >>> > >>>Your assessment is correct: an aggregate header li

Re: Watchdog aggregation of headers may be incorrect

On Saturday 17 August 2002 12:13 pm, Patrick Luby wrote: > Remy, > > Remy Maucherat wrote: > > No, this is not correct. > > > > You are allowed to do that only if the application knows it makes sense > > to do so (ie, only when it call getHeaders). > > > > Some code to do that should be added in t

Re: Watchdog aggregation of headers may be incorrect

On Saturday 17 August 2002 09:00 am, Remy Maucherat wrote: > Patrick Luby wrote: > > Steve, > > > > Your assessment is correct: an aggregate header like: > > > > header1: val1, val2 > > > > should be converted to this for the HttpRequest: > > > > header1: val1 > > header1: val2 > > No, this

Re: Watchdog aggregation of headers may be incorrect

On Friday 16 August 2002 09:43 pm, Patrick Luby wrote: > Tomcat 4 used to do this conversion correctly but then it stopped doing > the conversion a few months ago. > I'll bet dollars to donuts that it was exactly when Coyote was brought in as the connector, replacing the older o.a.c.connector.ht

Re: Watchdog aggregation of headers may be incorrect

Servlet spec non-compliance. However, I > am not sure where the parsing of headers is now performed in Tomcat? > > Can anyone point Steve to where this header parsing of the > ServerSocket input stream is being done? > > Patrick > > Steve Downey wrote: > >> Watchdog

Watchdog aggregation of headers may be incorrect

Watchdog now merges headers, by design. ie (from the checking message) Modified logic to send duplicate headers as one aggregated header vs. two headers: header1: val1 header1: val2 -will now be- header1: val1, val2 Due to this, it looks like a couple of tests are failing. GetHeaders

Re: [5][PATCH] Fix the JUnit tests in Catalina

Steve Downey wrote: >This patch fixes the JUnit tests in Catalina to run against the ROOT webapp. >Now 'ant test' succeeds. > > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PR

[5][PATCH] Fix the JUnit tests in Catalina

This patch fixes the JUnit tests in Catalina to run against the ROOT webapp. Now 'ant test' succeeds. -- To unsubscribe, e-mail: For additional commands, e-mail:

Re: [5] Config

> > >> >> >> What do you think ? > > > I love it :) > > This really seems to pick the best APIs for the job. > It's a good idea to use JNDI for configuration storing indeed, as it > allows enterprise scale deployments, and seems generally better suited > than JMX. > > Remy > > To the extent th

Re: cvs commit: jakarta-tomcat-catalina/catalina build.xml

(jta.present == true) and (full.dist=true or tyrex.present) If I'm reading this correctly, this won't build the Tyrex dependant components if jta is not present, EVEN IF full.dist is requested. That means you can set full.dist on and NOT get a full dist. If full.dist is set true, then the buil

Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml

[EMAIL PROTECTED] wrote: > > > >Well, CatalinaService is not 'completed' - just started :-) > >What we do in 3.3 is have 2 setters, and at execute check if: >- if only one is set, the other takes this value >- if none is set, use discovery ( locate the base from the CLASSPATH ) >- if both are set

Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml

Jean-francois Arcand wrote: > > > Steve Downey wrote: > >> Thanks for pointing the tomcat5 task out. I'm trying to reimplement >> with that, and have run into a couple of snags. >> >> First is that o.a.c.startup.CatalinaService doesn't distingui

Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml

is what I was using for the tomcat5 task: [EMAIL PROTECTED] wrote: >On Wed, 14 Aug 2002, Steve Downey wrote: > >>This patch starts up a copy of tomcat with the

[5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml

This patch starts up a copy of tomcat with the watchdog war files, runs watchdog against it, and shuts down tomcat afterwards. It uses the Launcher to run tomcat in the background, and puts the webapps, work, logs and conf directories in a tmp dir so as not to muck up the build. The only part

[5] examples webapp and catalina unit tests

The catalina unit tests depend on the examples webapp, which isn't part of the jakarta-tomcat-catalina repository. I believe Remy had suggested making the examples part of the servlet-api repo, but that isn't done. Should the examples webapp be brought into the jakarta-tomcat-catalina repo, or

[5][PATCH] Patch to BUILDING.txt to identify dependencies for optional components

This patch to BUILDING.txt documents what the optional components enable in Tomcat, and where the build process expects to find things. ? .project Index: BUILDING.txt === RCS file: /home/cvspublic/jakarta-tomcat-5/BUILDING.txt,v re

Re: [5.0] [VOTE] Release numbering scheme and test releases

Milestones imply a series of goals to be met, not just when we feel like it, or every Tuesday. To be a milestone, there need to some objective criteria that everyone can agree have been met. Don't get me wrong, I like frequent builds, I just hate to see a useful release engineering term get

Re: [5.0] Build notes

The only snag is that 'ant download' doesn't download optional components. And some of them are optional the same way that brakes on a go-cart are optional. It'll work, just not quite the way you expect it to. More importantly, any developer building Tomcat needs to build a full version, other

Re: [5][PATCH] BUILDING.txt and build.properties.default refer to old JTA version

On Monday 12 August 2002 03:22 pm, you wrote: > After this patch, the build is slightly broken if Tyrex isn't available. It > appears that compilation of org/apache/naming/factory/TyrexFactory.java > and TyrexResourceFactory are conditioned only on JTA. Patch to follow. Patch is NOT to have ful

Re: [5][PATCH] BUILDING.txt and build.properties.default refer to old JTA version

With patch actually attached ... On Monday 12 August 2002 03:22 pm, you wrote: > BUILDING.txt and the default build properties refer to an older version of > the Java Transaction API. The current version is 1.0.1a, where the old > version was 1.0.1. The are semantically the same, just documentati

[5][PATCH] BUILDING.txt and build.properties.default refer to old JTA version

BUILDING.txt and the default build properties refer to an older version of the Java Transaction API. The current version is 1.0.1a, where the old version was 1.0.1. The are semantically the same, just documentation changes. The current version of the jta jar file is named jta.jar, rather than

Re: [5][PATCH]commons-logging built without log4j/LogKit

t 2002 01:46 am, Patrick Luby wrote: > Steve, > > Thanks for the patch. I just committed it. > > I assume that log4j and LogKit are required dependencies. Any chance > that you could add those items to BUILDING.txt? > > Thanks, > > Patrick > > Steve Downey wrot

RE: [5][PATCH]commons-logging built without log4j/LogKit

ist > Subject: Re: [5][PATCH]commons-logging built without log4j/LogKit > > > Now, like Costin, I'm starting to think that the 5.0 build is scary. > > > - Original Message - > From: "Steve Downey" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTE

RE: [PATCH] JspC package names

I think this has been fixed with the patch to correct bug 5471. That changes how package names are generated in CommandLineContext. I'm glad to see someone else is using jspc. It's been broken so often, I thought I was the only one. > -Original Message- > From: Mike Schrag [mailto:[EMA

RE: [4.0.2] Bug list

If 5644 is going to be fixed, then 5471 should be too. Right now, given /index.jsp and /subdir/index.jsp, jspc will overwrite the first index.java with the second. It also conflates them in web.xml. I've submitted a patch to the list before. I've also just attached it to the bug report. I also ju

RE: [PATCH] Bug 5471 - JspC broken when compiling webapps

( My > apologies. > > I'll get the patch in, later. Thanks. > > > > Date: Tue, 18 Dec 2001 16:44:42 -0500 > > From: Steve Downey <[EMAIL PROTECTED]> > > Subject: RE: [PATCH] Bug 5471 - JspC broken when compiling webapps > > To: 'Tomcat Devel

RE: [PATCH] Bug 5471 - JspC broken when compiling webapps

e the path into the file name, but > to put the .java (and .class) files in a directory structure > that mirrors > the .jsp structure. This is how it work currently, for the > non -webapps > case. > > > > Date: Tue, 18 Dec 2001 15:47:25 -0500 > > From: Steve

[PATCH] Bug 5471 - JspC broken when compiling webapps

This patch changes CommandLineContext.getServletPackageName() to return a package name based on the path to the JSP as well as the package name supplied on the command line. Without a change like this, a webapp that has files with the same name, such as index.jsp, in more than one place is compil

RE: DO NOT REPLY [Bug 4545] New: - Webapp connector seg faults u nder an SSL connection

> -Original Message- > From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] > Sent: Friday, November 02, 2001 9:29 AM > To: Tomcat Developers List > Cc: [EMAIL PROTECTED] > Subject: RE: DO NOT REPLY [Bug 4545] New: - Webapp connector > seg faults > u nder an SSL connection > > > >> Environment

RE: DO NOT REPLY [Bug 3839] - Problem bookmarking login page

"Train the user not to do that" is a cop out. If an application doesn't work the way users expect, it's a problem with the application, not the user. That's usability 101. If the user shouldn't bookmark the login page, they shouldn't ever be exposed to the URI for the login page. That makes it i

RE: SCRIPT_NAME and PATH_INFO with extension mapping

As far as I can tell, the HTTP and HTML specs are completely silent on this. The CGI spec talks about PATH_INFO et al, but doesn't seem to address extension mapping. As another datapoint, static content with Apache doesn't work if you append path info to an HTML page, i.e. http://www.foo.com/in

RE: Tomcat before Apache

> -Original Message- > From: Christopher Cain [mailto:[EMAIL PROTECTED]] > Sent: Friday, August 17, 2001 2:32 PM > To: [EMAIL PROTECTED] > Subject: Re: Tomcat before Apache > > > > > "Pier P. Fumagalli" wrote: > > > > Christopher Cain at [EMAIL PROTECTED] wrote: > > > > > >> I'm att

RE: FORM-based authentication idea

> -Original Message- > From: Michael Jennings [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 21, 2001 11:55 AM > To: [EMAIL PROTECTED] > Subject: Re: FORM-based authentication idea > > > > The best way to think about form-based login is like this: > > > > * The login page is (in ess

RE: [jtc] tabs policy??

> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Sunday, June 24, 2001 7:16 AM > To: [EMAIL PROTECTED] > Subject: Re: [jtc] tabs policy?? > > > On Sun, 24 Jun 2001, Justin Erenkrantz wrote: > > > That just leads to formatting problems because people do

RE: Ways of Debugging tomcat itself..

With netbeans, in particular, an important trick is to disable the inclusion of its embedded tomcat in the executor and debugger. With 3.2, I think that's the {library} keyword. It changed between 3.1 and 3.2, I believe. Otherwise you're debugging the IDE, not the instance of Tomcat you're buildi

RE: Jasper34: Manglers

> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 11, 2001 12:18 AM > To: [EMAIL PROTECTED] > Subject: Re: Jasper34: Manglers > > > On Sun, 10 Jun 2001, Glenn Nielsen wrote: > > > Another advantage of jasper40 using a URLClassLoader for >

RE: virus warnings and

Mine, unfortunately for this list, isn't configured to be silent. It sends a warning back to the sender. I'm trying to see if we can get it to not do that for 'Precedence: Bulk' mail. It doesn't help that we've got about several developers following this list and the users list. Mea culpa, and

RE: Jasper performance

Given any reasonably timeframe for delivery on a new Jasper to production, jdk 1.1 is likely to be three cycles behind. Supporting legacy systems can only go so far. > -Original Message- > From: Glenn Nielsen [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 15, 2001 5:30 PM > To: [EMAIL P

RE: JNDI/LDAP realm

the root cause. > -Original Message- > From: John Holman [mailto:[EMAIL PROTECTED]] > Sent: Monday, May 14, 2001 5:55 PM > To: [EMAIL PROTECTED] > Subject: Re: JNDI/LDAP realm > > > > ----- Original Message - > From: "Steve Downey" <[EMAIL

RE: Trying New Connectors Build Stuff

With cygwin, it should build using ./configure && make && make check && make install. It's just another flavour for autoconf. Although it didn't used to be true, recently I am more surprised when a package does _not_ build using cygtools. However, the unix emulation layer is nowhere near as effi

RE: Trying New Connectors Build Stuff

Cygwin can add significant overhead in it's emulation layer. If you can do it with gcc -mno-cygwin, that might be a reasonable compromise. > -Original Message- > From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]] > Sent: Sunday, May 13, 2001 2:01 PM > To: [EMAIL PROTECTED] > Subject: Re:

RE: JNDI/LDAP realm

The downside to binding with the supplied credentials is that it chews up a file descriptor. For light loads, it's not an issue. For heavy loads, it can be a big issue. If the app server binds administratively, you can get by with two connections, one for reading and one for writing. Or even one,

[PATCH] bugs 412 and 112 for TC3.3

112 is really simple. Just a check if the TOMCAT_HOME should be '..' after checking for '.' 412 is almost as straightforward. It's a bug in JspC, where CommandLineContext is handed a URI with '\' s in the jspFile. Defensively, I've added a replace in CommandLineContext's constructor. Alternative

RE: Jasper34: sandboxing/Priviledged

> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 27, 2001 8:37 PM > To: [EMAIL PROTECTED] > Subject: Jasper34: sandboxing/Priviledged > > > > The other concern is that in one use case for jasper34 it may create > problems. We would lik

RE: Jasper34: diffs between 1.1 and 1.2

The only downside I see is that the security manager triggers the use of URLClassloader on a per JSP page basis. As I understand it, this class is broken w.r.t. Java 1.1. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, April 27, 2001 7:12 PM To: [EMA

RE: [GUMP] Build Failure - Tomcat 3.x

Index: ErrorHandler.java === RCS file: /home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/modules/generator s/ErrorHandler.java,v retrieving revision 1.10 diff -u -r1.10 ErrorHandler.java --- ErrorHandler.java 2001/04/23 01:

RE: Bugs <500

360 and 412 look like they might cause me some headaches. Are you -1 on fixing them, or -0? That is, should I bother or not? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Sunday, April 22, 2001 2:25 PM To: [EMAIL PROTECTED] Subject: Bugs <500 Hi, I finish

RE: [jetty-discuss] Re: Jasper JSP maintainer required for Jetty project.

> -Original Message- > From: Mel Martinez [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 10, 2001 2:56 PM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [jetty-discuss] Re: Jasper JSP maintainer required for > Jetty project. > >

RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

mentation for a new combination or style isn't that excessive. > -Original Message- > From: Alex Fernández [mailto:[EMAIL PROTECTED]] > Sent: Friday, March 30, 2001 2:49 AM > To: [EMAIL PROTECTED] > Subject: Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Thursday, March 29, 2001 3:04 PM > To: [EMAIL PROTECTED] > Subject: RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet > > > On Thu, 29 Mar 2001, Mel Martinez wrote: > > > activities that should be

RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

> -Original Message- > From: Mel Martinez [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 28, 2001 6:41 PM > To: [EMAIL PROTECTED] > Subject: RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet > > > Wow! I go away for a day and there is some great > discussion on this thread

RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 28, 2001 3:46 PM > To: [EMAIL PROTECTED] > Subject: RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet > > > On Wed, 28 Mar 2001, Steve Downey wrote: >

  1   2   >