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

Pierre Delisle wrote: > Hans Bergsten wrote: > > [...] > > In general, I prefer imports for the reason you mention; it makes it easier > > to see all dependencies. In generated JSP compilation classes, the important > > thing is not to have other complete package imports than the ones in the > > s

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

Hans Bergsten wrote: > > Pierre Delisle wrote: > > > > Hans Bergsten wrote: > > > > > > [EMAIL PROTECTED] wrote: > > > > > > > > pierred 00/12/09 21:56:44 > > > > > > > > Modified:jasper/src/share/org/apache/jasper Constants.java > > > >jasper/src/share/org/apache/jasp

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

Pierre Delisle wrote: > > Hans Bergsten wrote: > > > > [EMAIL PROTECTED] wrote: > > > > > > pierred 00/12/09 21:56:44 > > > > > > Modified:jasper/src/share/org/apache/jasper Constants.java > > >jasper/src/share/org/apache/jasper/compiler > > > Bea

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

Hans Bergsten wrote: > > [EMAIL PROTECTED] wrote: > > > > pierred 00/12/09 21:56:44 > > > > Modified:jasper/src/share/org/apache/jasper Constants.java > >jasper/src/share/org/apache/jasper/compiler > > BeanGenerator.java JspParseEventListener.ja

username and password for admin tomcat 3.2

hi, i tried to use admin function in tomcat but donot know the initial username and password. could you please help ? tia

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

[EMAIL PROTECTED] wrote: > > pierred 00/12/09 21:56:44 > > Modified:jasper/src/share/org/apache/jasper Constants.java >jasper/src/share/org/apache/jasper/compiler > BeanGenerator.java JspParseEventListener.java > ParserXJs

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

pierred 00/12/09 21:56:44 Modified:jasper/src/share/org/apache/jasper Constants.java jasper/src/share/org/apache/jasper/compiler BeanGenerator.java JspParseEventListener.java ParserXJspSaxHandler.java Log: Take 2 on the

Re: cvs commit:jakarta-tomcat/src/examples/WEB-INF/classes/examples ShowSource.java

Jon Stevens wrote: > on 12/9/2000 7:07 PM, "[EMAIL PROTECTED]" > <[EMAIL PROTECTED]> wrote: > > > +(jspFile.toUpperCase().indexOf("/WEB-INF/") != 0) || > > +(jspFile.toUpperCase().indexOf("/META-INF/") != 0)) > > Seems like it would be better to define this as a constant s

Re: [PROPOSAL] JSSI for Tomcat

Jon Stevens wrote: > on 12/9/2000 6:21 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]> > wrote: > > > If it is Tomcat-specific, is there any reason it really needs to be a separate > > Jakarta project at all? Why not just absorb it into Tomcat? > > Problem with that in my eyes is that Tomcat is su

cvs commit: jakarta-tomcat/src/examples/WEB-INF/classes/examples ShowSource.java

craigmcc00/12/09 19:07:51 Modified:src/examples/WEB-INF/classes/examples Tag: tomcat_32 ShowSource.java Log: Fix a security vulnerability -- the "ShowSource" custom tag in conjunction with the "/examples/jsp/source.jsp page could be used to expose the conte

Re: cvs commit:jakarta-tomcat/src/examples/WEB-INF/classes/examples ShowSource.java

on 12/9/2000 7:07 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > +(jspFile.toUpperCase().indexOf("/WEB-INF/") != 0) || > +(jspFile.toUpperCase().indexOf("/META-INF/") != 0)) Seems like it would be better to define this as a constant somewhere... public static final

Re: [PROPOSAL] JSSI for Tomcat

on 12/9/2000 6:21 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote: > If it is Tomcat-specific, is there any reason it really needs to be a separate > Jakarta project at all? Why not just absorb it into Tomcat? Problem with that in my eyes is that Tomcat is supposed to be the reference imple

cvs commit: jakarta-tomcat-4.0/webapps/examples/WEB-INF/classes/examples ShowSource.java

craigmcc00/12/09 19:12:19 Modified:webapps/examples/WEB-INF/classes/examples ShowSource.java Log: Fix a security vulnerability. The "ShowSource" custom tag, in conjunction with the "/examples/jsp/source.jsp" page, could be used to expose sensitive data in the WEB-INF and META-I

Re: [PROPOSAL] JSSI for Tomcat

"Craig R. McClanahan" wrote: > [...] > If it is Tomcat-specific, is there any reason it really needs to be a separate > Jakarta project at all? Why not just absorb it into Tomcat? > > In terms of CVS repositories, if the amount of version-dependent code is large it > would be easier just to put

Re: [PROPOSAL] JSSI for Tomcat

Jon Stevens wrote: > on 12/9/2000 3:55 PM, "Hans Bergsten" <[EMAIL PROTECTED]> wrote: > > > I know the migration of Java Apache projects has been discussed, but > > I have not seen a formal decision being made by PMC. So I like to > > run it by the PMC anyway, but based on what you say it sounds

Re: [PROPOSAL] JSSI for Tomcat

on 12/9/2000 3:55 PM, "Hans Bergsten" <[EMAIL PROTECTED]> wrote: > I know the migration of Java Apache projects has been discussed, but > I have not seen a formal decision being made by PMC. So I like to > run it by the PMC anyway, but based on what you say it sounds like it > will not be any pro

mod_jk.so for Linux

I've succeded running Apacche+Tomcat 3.2 with mod_jk.dll on Windows2000 But I can't start it on my Linux. I've compiled mod_jk.so and copied it to libexec folder, and it serves static content, but when it comes to servlets it doesn't work. Do I need to recompile mod_jk and build as a module in A

RE: Handler/ServletWrapper/Error handling

> Easy to do, seems a good idea. What about adding handleInitException() > and > handleServiceException() - since a ClassNotFound will have different > effects ( 404 if in init, normal error if in service - the first means > the > servlet wasn't found, the second may happen if the servlet does a

Re: [PROPOSAL] JSSI for Tomcat

Jon Stevens wrote: > [...] > > 1) Make this a new Jakarta subproject, named jakarta-jssi. > > The reason for this is that it's an optional module and it can > > live its own life outside the container development. > > > > Note! This requires approval by the PMC, but I want to see what > > this gro

How to enable Jikes without changing Tomcat 3.2 source code

I succeeded in getting Tomcat 3.2 final to use Jikes rather than Sun's compiler, but only after I changed the code in com.apache.tomcat.context.WebXMLReader. Is there any way to enable it via config file? The settings in conf/web.xml don't appear to be being read. There is a comment that says th

Re: [PROPOSAL] JSSI for Tomcat

on 12/9/2000 1:48 PM, "Hans Bergsten" <[EMAIL PROTECTED]> wrote: > After seeing a number of users on the TC user list asking about support > for tags and NCSA SSI directives, I decided to port Apache > JSSI to Tomcat. Now it's basically done for TC 3.2, and the question is > what to do with it ;

[PROPOSAL] JSSI for Tomcat

After seeing a number of users on the TC user list asking about support for tags and NCSA SSI directives, I decided to port Apache JSSI to Tomcat. Now it's basically done for TC 3.2, and the question is what to do with it ;-) If anyone is interested in this, I propose the following: 1) Make

Re: how to maintain session between HTTP and HTTPS?

In a load balanced environment, this is tricky with people behind a IP randomizing proxy (like AOL). If you use all SSL, the load balancer can track the SSL session ID across different IPs. If you use all non-SSL, you can track with a cookie. You can use IP based sticky if the IP stays the same

RE: Handler/ServletWrapper/Error handling

Hi Larry, > Suggestion 1) In Handler and ServletWrapper some calls are made to > contextM.handleStatus() and contextM.handleError(). I think it would > be an improvement to add handlerStatus() and handleError() to > Handler, which would make the call to contextM.handleXXX. This would > allow, S

RE: Handler/ServletWrapper/Error handling

Hi Costin, This sounds fine. I'll look forward to seeing your patches. I have been wrestling with porting the error handling changes I made to Tomcat 3.2. From this I have some suggestions and a question. Suggestion 1) In Handler and ServletWrapper some calls are made to contextM.handleStatus

BugRat Report #561 has been filed.

Bug report #561 has just been filed. You can view the report at the following URL: REPORT #561 Details. Project: Catalina Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical

pre compile

Hi all Does anybody know how do i compile all jsps at once from command line or whatever. I do not want to go to each page to have them compiled. Thanks = Cengiz Kayay WebObjects/JAVA Consultant __ Do You Yahoo!? Yahoo! Shopping - Thousand

BugRat Report #560 has been filed.

Bug report #560 has just been filed. You can view the report at the following URL: REPORT #560 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious