RE: Problems building Tomcat 4.0.1
I seem to remember getXMLReader is a SAX2 method. What SAX/XML parser are you linking with in the build? -Original Message- From: JLupo Sent: 20 December 2001 20:39 To: tomcat-dev Cc: JLupo Subject: Problems building Tomcat 4.0.1 When I try to build Tomcat 4.0.1 on my system, I get the following error and it fails: build-main: [javac] Compiling 93 source files to /opt/jakarta-tomcat-4.0.1-src/jasper/build/classes [javac] /opt/jakarta-tomcat-4.0.1-src/jasper/src/share/org/apache/jasper/compile r/Pa rserXJspSax.java:147: Method getXMLReader() not found in class javax.xml.parsers.SAXParser. [javac] XMLReader parser = saxParser.getXMLReader(); [javac] ^ [javac] 1 error I've verified that I've followed the BUILDING.txt directions to no avail. Searching the Internet revealed the following link to the archives of this list, http://w6.metronet.com/~wjm/tomcat/2000/Oct/msg00402.html but the response doesn't help me because I've never had any other versions of JAXP installed other than v1.1. By the by, I'm running Solaris 8 x86 with JDK 1.2.2 installed. thanks. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5554] New: - request.getRequestDispatcher(uri).include() puts included contents at wrong place
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5554. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5554 request.getRequestDispatcher(uri).include() puts included contents at wrong place Summary: request.getRequestDispatcher(uri).include() puts included contents at wrong place Product: Tomcat 4 Version: 4.0.1 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Hi, I am trying to include a.jsp into b.jsp by doing the following: ---a.jsp--- This is included @ %= new java.util.Date() % ---b.jsp--- brStart includebr % request.getRequestDispatcher(a.jsp).include(request, response); % br end includebr When requesting b.jsp from browser, here is the output: ---output of Tomcat This is included @ Thu Dec 20 16:56:56 CST 2001 Start include end include --- The problem is that the included content was inserted at the wrong place! I tried this on both Tomcat 3.2.3 and 4.0.1 and got the same behavior. I tried this on WebLogic 6.1, it works as I expected: output of weblogic Start include This is included @ Thu Dec 20 16:56:56 CST 2001 end include -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5554] - request.getRequestDispatcher(uri).include() puts included contents at wrong place
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5554. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5554 request.getRequestDispatcher(uri).include() puts included contents at wrong place [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-12-21 10:23 --- Fixed in the HEAD branch (nightly builds) and in the 4.0.2 release (4.0.2-beta-2 was just posted last night). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina build.xml
craigmcc01/12/21 10:42:23 Modified:catalina build.xml Log: Do not compile org.apache.naming.NamingService unless JMX is present. Revision ChangesPath 1.90 +2 -0 jakarta-tomcat-4.0/catalina/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/build.xml,v retrieving revision 1.89 retrieving revision 1.90 diff -u -r1.89 -r1.90 --- build.xml 2001/11/13 23:56:07 1.89 +++ build.xml 2001/12/21 18:42:23 1.90 @@ -639,6 +639,8 @@ unless=jdk.1.3.present/ exclude name=org/apache/catalina/servlets/CGIServlet.java unless=jdk.1.3.present/ + exclude name=org/apache/naming/NamingService.java + unless=compile.jmx/ exclude name=org/apache/naming/factory/DbcpDataSourceFactory.java unless=compile.dbcp/ exclude name=org/apache/naming/factory/TyrexDataSourceFactory.java -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina build.xml
craigmcc01/12/21 10:42:23 Modified:catalina build.xml Log: Do not compile org.apache.naming.NamingService unless JMX is present. It looks like I had missed that one. Thanks for fixing it :) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5560] New: - Removal of unnecesary white space in output
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5560.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5560
Removal of unnecesary white space in output
Summary: Removal of unnecesary white space in output
Product: Tomcat 3
Version: 3.3 Final
Platform: Other
OS/Version: Windows NT/2K
Status: NEW
Severity: Enhancement
Priority: Other
Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Hi. I don't know if this kind of stuff should be done in here, but here it is.
We use tomcat to serve our portal, and lots of unnecesary white space are
served to the browser (line feeds, tabs, spaces), which increases size of pages
and thus makes site slow on modems.
I modified org.apache.jasper.compiler.CharDataMapper.generateChunk (and
MappedCharDataMapper.generateChunk) to remove them at Jasper compilation time.
The new method looks like:
private void generateChunk(ServletWriter writer, int from, int to)
{
// Generate the char data:
int limit;
int lastChar;
StringBuffer sb;
sb = new StringBuffer();
limit = chars.length;
lastChar = 0;
for (int i = 0; i limit; i++)
{
int ch = chars[i];
switch (ch)
{
case '' :
sb.append(\\\);
break;
case '\\' :
sb.append();
break;
case '\r' :
ch = '\n';
case '\n' :
if ( '\n' != lastChar )
{
sb.append(\\r\\n);
}
break;
case ' ' :
if ( ! isBlank(lastChar) )
{
sb.append( );
}
break;
case '\t' :
if ( ! isBlank(lastChar) )
{
sb.append(\\t);
}
break;
default :
sb.append((char) ch);
}
lastChar = ch;
}
if ( 0 sb.length() )
{
writer.indent();
writer.print(out.write(\);
writer.print(sb.toString());
writer.print(\);\n);
}
}
protected static boolean isBlank(int ch)
{
return (' ' == ch) || ('\t' == ch) || ('\n' == ch);
}
This reduces our page sizes by 3-4K
Just to let you know
Thks
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5561] New: - Mangling of reserved words not working some times
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5561.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5561
Mangling of reserved words not working some times
Summary: Mangling of reserved words not working some times
Product: Tomcat 3
Version: 3.3 Final
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Major
Priority: Other
Component: Servlet
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I detected an error on package name mangling. Reserved works were not mangled
if they were not the last part of the JSP path.
The problem was in this snippet of code in
org.apache.tomcat.util.JavaGeneratorTool.manglePackage(String):
...
if ((s.length() endIdx + 1) s.charAt(endIdx + 1) != '/')
{
index = s.indexOf(keywords[i], index + 3);
continue;
}
...
There is an error in there since endIdx is already at the character immediately
after the reserved work. The +1 moves the index one character further, which
is the first letter in the JSP's next directory.
Removing the +1 corrected the problem:
...
if ((s.length() endIdx) s.charAt(endIdx) != '/')
{
index = s.indexOf(keywords[i], index + 3);
continue;
}
...
Thks
PD I put this in servlet. Sorry if it dooes not belong there.
PD I don't know if the severity is OK. For us it is a MAJOR since our site
uses public in one directory, and there are lots of dirs under it, making
TC3.3 unusable with this bug.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5561] - Mangling of reserved words not working some times
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5561. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5561 Mangling of reserved words not working some times [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2001-12-21 11:03 --- The patch you suggest has already been applied and appears in the current Tomcat 3.3.1 nightly. *** This bug has been marked as a duplicate of 5365 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5365] - JSPs cannot be compiled if their working path includes reserved word
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5365. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5365 JSPs cannot be compiled if their working path includes reserved word [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2001-12-21 11:03 --- *** Bug 5561 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat RELEASE-NOTES-3.3.1.txt
keith 01/12/21 11:14:25 Modified:.RELEASE-NOTES-3.3.1.txt Log: Document ErrorHandler change. Revision ChangesPath 1.17 +5 -2 jakarta-tomcat/RELEASE-NOTES-3.3.1.txt Index: RELEASE-NOTES-3.3.1.txt === RCS file: /home/cvs/jakarta-tomcat/RELEASE-NOTES-3.3.1.txt,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- RELEASE-NOTES-3.3.1.txt 2001/12/20 03:49:14 1.16 +++ RELEASE-NOTES-3.3.1.txt 2001/12/21 19:14:25 1.17 @@ -3,7 +3,7 @@ Release Notes = -$Id: RELEASE-NOTES-3.3.1.txt,v 1.16 2001/12/20 03:49:14 billbarker Exp $ +$Id: RELEASE-NOTES-3.3.1.txt,v 1.17 2001/12/21 19:14:25 keith Exp $ This document describes the changes that have been made since the @@ -111,6 +111,9 @@ 5497 Ignore the If-Modified-Since header when including a static page. + Do not return a body with 304 responses (forbidden by HTTP/1.x and + confusing to NS 6.x). + Configuration: Bug No. Description @@ -146,4 +149,4 @@ key is used only on Win98. JDBCRealm-howto.html updated to name the correct class and its jar - location for digested passwords. \ No newline at end of file + location for digested passwords. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/tester/web Include03c.jsp
craigmcc01/12/21 11:15:38
Modified:tester/src/bin tester.xml
Added: tester/web Include03c.jsp
Log:
Add JSP-Servlet and JSP-JSP cases for ensuring that a request attribute
set by the included resource is visible to the including resource. Previously we
were only checking Servlet-Servlet and Servlet-JSP.
Revision ChangesPath
1.81 +8 -0 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.80
retrieving revision 1.81
diff -u -r1.80 -r1.81
--- tester.xml2001/12/20 12:37:02 1.80
+++ tester.xml2001/12/21 19:15:38 1.81
@@ -939,6 +939,14 @@
request=${context.path}/WrappedInclude03?path=/Include03b.jsp
outContent=Include03 PASSED debug=${debug}/
+tester host=${host} port=${port} protocol=${protocol}
+ request=${context.path}/Include03c.jsp?path=/Include03a
+ outContent=Include03c.jsp PASSED debug=${debug}/
+
+tester host=${host} port=${port} protocol=${protocol}
+ request=${context.path}/Include03c.jsp?path=/Include03b.jsp
+ outContent=Include03c.jsp PASSED debug=${debug}/
+
echo message=- Include Then Forward -/
tester host=${host} port=${port} protocol=${protocol}
1.1 jakarta-tomcat-4.0/tester/web/Include03c.jsp
Index: Include03c.jsp
===
%@ page contentType=text/plain %%
// Duplicate logic from Include03.java
StringBuffer sb = new StringBuffer();
String path = request.getParameter(path);
if (path == null)
path = /Include03a;
RequestDispatcher rd =
getServletContext().getRequestDispatcher(path);
if (rd == null) {
sb.append( No RequestDispatcher returned/);
} else {
rd.include(request, response);
}
response.resetBuffer();
String value = null;
try {
value = (String) request.getAttribute(path.substring(1));
} catch (ClassCastException e) {
sb.append( Returned attribute not of type String/);
}
if ((sb.length() 1) (value == null)) {
sb.append( No includee-created attribute was returned/);
}
if (sb.length() 1)
out.println(Include03c.jsp PASSED);
else {
out.print(Include03c.jsp FAILED -);
out.println(sb.toString());
}
%
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Connector compatibility between TC 4.0 and 4.1
On Fri, 21 Dec 2001, Kevin Seguin wrote: My thinking ( for 4.1/3.3 ) was to have j-t-c built as a 'standalone module', a trusted/priviledged webapp that can be deployed and is self-contained. can you provide some more detail? i'm quite interested in learning more. It's quite simple - the idea is to 'package' tomcat modules ( i.e. anything providing additional functionality ) as 'plain' WAR files. Why ? Many good reasons: - reuse - all the infrastructure for webapps will apply to modules as well. With a bit of work we can get dynamic module loading/reloading, deployment ( including 'hot' ) etc. Even setting module properties will benefit from the UI for web.xml admin ( i.e. most config can be done using Context attributes in web.xml ). - self-contained and well defined environment for modules. We'll know that the directory structure on deployment will be clear, we can call getRealPath(/) and know where all our files are located. That's container independent, etc. ( I assume modules will be 'expanded' - that's a requirement, as we'll use the directory structure to generate configs, etc) - a lot of the module can be implemented as plain servlet/jsp. Like 'seeing' jk status, logs, etc. Again, everything is self-contained and have a defined structure ( like in a webapp ) - the original reason for doing that ( in 3.3 ) was simplifying the code. We wanted 3.3 to be as simple as possible, with a minimal core providing the 'referenece implementation' part and nothing else, and have all the 'features' implemented as optional modules. That's what the 'modules/' directory is for. 3.3 does have all the features from 3.2.x, but we tried to not add anything else - any feature should be provided as a module. - of course, the build environment and everything else becomes more 'faimiliar' for people. It's a webapp that happens to implement and use one extra API ( or few APIs ) to interface with the container. It's no different from a webapp that is using diferent parsers or databases. The only 'special' thing is that our webapp can affect the container behavior ( exacly like /admin or /manager ). The only problem is making the 'webapp' usable on multiple containers ( that support the concept ). This is quite painfull for 4.x ( including 4.1 ), because in order to access the internals you need to implement an interface on a servlet ( and that will not load in 3.3 ). But I think there are some ( maybe ugly ) ways to get around this. Again, in a webapp that does database access or xml you want to be able to support multiple 'drivers' - a module doing authentication will also have 'drivers' for different servlet containers, same for jk. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Connector compatibility between TC 4.0 and 4.1
As appealing an idea as this sounds (packaging plug-in modules as webapps), it doesn't solve the underlying issue -- different containers have radically different internal architectures, and packaging the plug-in as webapp doesn't avoid having to deal with that. You still have to bridge the architectural differences for installing the plug-in functionality in the container, using container-specific APIs. To be successful at bridging this gap, you've really only got a couple of choices: * Create an external common API for things that are not architecture dependent (like web connectors) that a container can choose to support or not support, and don't bother trying to standardize things that are radically different between architectures (for example, RequestInterceptor vs. Valve, or the very different concepts of how the core components of the container are organized). * Create a meta-architecture (via a set of common APIs) that all containers must support -- never mind that it might mandate doing things in a totally different way than any existing container. IMHO, the latter option is not practical. Packaging plug-in functionality as a web app does nothing to help resolve the basic issue that containers are different on the inside. And, if you went to the effort to do this, you'd spend your time more efficiently by just creating a container conforming to those APIs and be done with it. Oh wait ... we've already done that ... twice :-). That seems entirely sufficient to me. Craig On Fri, 21 Dec 2001 [EMAIL PROTECTED] wrote: Date: Fri, 21 Dec 2001 11:34:57 -0800 (PST) From: [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: RE: Connector compatibility between TC 4.0 and 4.1 On Fri, 21 Dec 2001, Kevin Seguin wrote: My thinking ( for 4.1/3.3 ) was to have j-t-c built as a 'standalone module', a trusted/priviledged webapp that can be deployed and is self-contained. can you provide some more detail? i'm quite interested in learning more. It's quite simple - the idea is to 'package' tomcat modules ( i.e. anything providing additional functionality ) as 'plain' WAR files. Why ? Many good reasons: - reuse - all the infrastructure for webapps will apply to modules as well. With a bit of work we can get dynamic module loading/reloading, deployment ( including 'hot' ) etc. Even setting module properties will benefit from the UI for web.xml admin ( i.e. most config can be done using Context attributes in web.xml ). - self-contained and well defined environment for modules. We'll know that the directory structure on deployment will be clear, we can call getRealPath(/) and know where all our files are located. That's container independent, etc. ( I assume modules will be 'expanded' - that's a requirement, as we'll use the directory structure to generate configs, etc) - a lot of the module can be implemented as plain servlet/jsp. Like 'seeing' jk status, logs, etc. Again, everything is self-contained and have a defined structure ( like in a webapp ) - the original reason for doing that ( in 3.3 ) was simplifying the code. We wanted 3.3 to be as simple as possible, with a minimal core providing the 'referenece implementation' part and nothing else, and have all the 'features' implemented as optional modules. That's what the 'modules/' directory is for. 3.3 does have all the features from 3.2.x, but we tried to not add anything else - any feature should be provided as a module. - of course, the build environment and everything else becomes more 'faimiliar' for people. It's a webapp that happens to implement and use one extra API ( or few APIs ) to interface with the container. It's no different from a webapp that is using diferent parsers or databases. The only 'special' thing is that our webapp can affect the container behavior ( exacly like /admin or /manager ). The only problem is making the 'webapp' usable on multiple containers ( that support the concept ). This is quite painfull for 4.x ( including 4.1 ), because in order to access the internals you need to implement an interface on a servlet ( and that will not load in 3.3 ). But I think there are some ( maybe ugly ) ways to get around this. Again, in a webapp that does database access or xml you want to be able to support multiple 'drivers' - a module doing authentication will also have 'drivers' for different servlet containers, same for jk. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/ROOT index.jsp index.html
craigmcc01/12/21 13:15:45
Modified:catalina/src/share/org/apache/catalina Globals.java
catalina/src/share/org/apache/catalina/cluster
ClusterMemberInfo.java
catalina/src/share/org/apache/catalina/connector/http
Constants.java HttpProcessor.java
catalina/src/share/org/apache/catalina/connector/http10
Constants.java HttpProcessor.java
catalina/src/share/org/apache/catalina/core
ApplicationContext.java StandardEngine.java
catalina/src/share/org/apache/catalina/servlets
DefaultServlet.java HTMLManagerServlet.java
catalina/src/share/org/apache/catalina/valves
ErrorReportValve.java
Added: catalina/src/share/org/apache/catalina/util ServerInfo.java
ServerInfo.properties
webapps/ROOT index.jsp
Removed: webapps/ROOT index.html
Log:
Make it easy to customize the Tomcat version number when updating it (or when
embedding it in another environment). Now, the only file that has to be
modified is:
catalina/src/share/org/apache/catalina/util/ServerInfo.properties
Revision ChangesPath
1.43 +4 -10
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Globals.java
Index: Globals.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Globals.java,v
retrieving revision 1.42
retrieving revision 1.43
diff -u -r1.42 -r1.43
--- Globals.java 2001/10/27 18:56:22 1.42
+++ Globals.java 2001/12/21 21:15:44 1.43
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Globals.java,v
1.42 2001/10/27 18:56:22 craigmcc Exp $
- * $Revision: 1.42 $
- * $Date: 2001/10/27 18:56:22 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Globals.java,v
1.43 2001/12/21 21:15:44 craigmcc Exp $
+ * $Revision: 1.43 $
+ * $Date: 2001/12/21 21:15:44 $
*
*
*
@@ -69,7 +69,7 @@
* Global constants that are applicable to multiple packages within Catalina.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.42 $ $Date: 2001/10/27 18:56:22 $
+ * @version $Revision: 1.43 $ $Date: 2001/12/21 21:15:44 $
*/
public final class Globals {
@@ -230,12 +230,6 @@
*/
public static final String REQUEST_URI_ATTR =
javax.servlet.include.request_uri;
-
-
-/**
- * The descriptive information about this server and version.
- */
-public static final String SERVER_INFO = Apache Tomcat/4.1-dev;
/**
1.4 +6 -6
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/cluster/ClusterMemberInfo.java
Index: ClusterMemberInfo.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/cluster/ClusterMemberInfo.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ClusterMemberInfo.java2001/07/22 20:25:06 1.3
+++ ClusterMemberInfo.java2001/12/21 21:15:44 1.4
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/cluster/ClusterMemberInfo.java,v
1.3 2001/07/22 20:25:06 pier Exp $
- * $Revision: 1.3 $
- * $Date: 2001/07/22 20:25:06 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/cluster/ClusterMemberInfo.java,v
1.4 2001/12/21 21:15:44 craigmcc Exp $
+ * $Revision: 1.4 $
+ * $Date: 2001/12/21 21:15:44 $
*
*
*
@@ -64,14 +64,14 @@
package org.apache.catalina.cluster;
import java.io.Serializable;
-import org.apache.catalina.Globals;
+import org.apache.catalina.util.ServerInfo;
/**
* Class that represents a member in a Cluster, keeps information
* that can be used when implementing Classes thats utilizing a Cluster.
*
* @author Bip Thelin
- * @version $Revision: 1.3 $
+ * @version $Revision: 1.4 $
*/
public final class ClusterMemberInfo implements Serializable {
@@ -103,7 +103,7 @@
}
public String getServerVersion() {
-return(Globals.SERVER_INFO);
+return(ServerInfo.getServerInfo());
}
public void setClusterInfo(String clusterInfo) {
1.6 +3 -8
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/Constants.java
Index: Constants.java
===
RCS file:
DO NOT REPLY [Bug 5564] New: - JDBCRealm and Interbase 6
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5564.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5564
JDBCRealm and Interbase 6
Summary: JDBCRealm and Interbase 6
Product: Tomcat 4
Version: 4.0.1 Final
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Blocker
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Using Interbase for JDBCRealm I get a java.lang.NullPointerException and a HTTP
500 - Internal server error on the client.
Looking in the JDBCRealm.java code I discovered the error in the authenticate
method:
public Principal authenticate(String username, String credentials) {
try {
} catch (SQLException e) {
}
}
Interbase raises a NullPointerException when username and credential are null
(as this method is called the first time), but this exception isn't catched.
Thanks
Diego
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[FAQ] jGuru FAQ Update
jGuru maintains FAQs and Forums on Servlets, JSP, and Tomcat (as well as many other Java topics). Here is an automated update on recent postings to Tomcat-related FAQs. Please direct flames and feedback to [EMAIL PROTECTED] . - Alex ++ JavaServer Pages (JSP) FAQ: http://www.jguru.com/faq/JSP Can I make a jsp custom tag to return a value in to a jsp variable.p I want a jsp custom tag to evaluate some condition based on the parameters I pass and return a boolean to the jsp page in a java variable (type boolean).p Can anybody give some sample of the code using similar functionality. brCan we some how use the get methods in the tagHandler in our jsp to retrieve the values? http://www.jguru.com/misc/faqtrampoline.jsp?src=notifyEID=593533 Is it possible to invoke customtags onEvents like onClick? http://www.jguru.com/misc/faqtrampoline.jsp?src=notifyEID=592466 Here is what I have: P 1. My application is under /opt/tomcat/webapps/myApp br 2. My jsp file is : /opt/tomcat/webapps/myApp/web/test.jsp br It contains; br . . . br lt;% br String configFile=getInitParameter(configFile); br System.out.println(configFIle=+configFile); br %gt; P 3. My web.xml is: /opt/tomcat/webapps/myApp/WEB-INF/web.xml br It contains: lt;web-appgt; br lt;servletgt; br lt;servlet-namegt;testlt;/servlet-namegt; br lt;jsp-filegt;/web/test.jsplt;/jsp-filegt; br lt;init-parametergt; br lt;param-namegt;configFilelt;/param-namegt; br lt;param-valuegt;TOTOlt;/param-valuegt; br lt;/init-parametergt; br lt;/servletgt; br lt;servlet-mappinggt; br lt;servlet-namegt;testlt;/servlet-namegt; br lt;url-patterngt;/web/test.jsplt;/url-patterngt; br lt;/servlet-mappinggt; br lt;/web-appgt; P What am I doing wrong? http://www.jguru.com/misc/faqtrampoline.jsp?src=notifyEID=592461 I'm working on the JSP - Tomcat model, I'm using JSPC to pre-compile my JSPs, Is there a way to prevent any new (non pre-compiled) JSPs from being executed (compiled) in tomcat? ie. I do not want any new JSPs , which have not being pre-compiled to be executed via tomcat on the browser, Is there any property/configuration file which I need to change in Tomcat?? http://www.jguru.com/misc/faqtrampoline.jsp?src=notifyEID=592460 Why use JSP? All that we can do with scriptlets we can do with JavaScript as well, I think. Can somebody explain? http://www.jguru.com/misc/faqtrampoline.jsp?src=notifyEID=590882 We are building a series of JSP pages, each of which is responsible for producing a different area of the screen. Any given screen that the end user sees, therefore, is made up of a number of blocks, each of which has been generated by a single JSP. The top level JSP calls in the blocks using a jsp:include. We are trying to use the JSP errorPage directive on every JSP to display an error to the user if something goes wrong with any of the blocks, but are finding that we end up with the error page only taking up part of the screen (for the block which had an error), whereas we would like the whole screen to be filled up by the errorPage. In other words - if something goes wrong with any of the blocks that comprise a screen - we would like to display nothing but the error page. What is the best way to do this ? http://www.jguru.com/misc/faqtrampoline.jsp?src=notifyEID=590880 ++ Servlets FAQ: http://www.jguru.com/faq/Servlets HttpUtils.parseQueryString is deprecated. What should we use instead ? http://www.jguru.com/misc/faqtrampoline.jsp?src=notifyEID=587251 In some web.xml I find DOCTYPE reference of web-app_2_2.dtd,(in Weblogic 5.1 example) in others, of web-app_2.2.dtd (in java pet store). What is the difference between the two DTDs? http://www.jguru.com/misc/faqtrampoline.jsp?src=notifyEID=586710 What are the steps that I need to follow to deploy my servlet in WebLogic 6.1? http://www.jguru.com/misc/faqtrampoline.jsp?src=notifyEID=586701 How can I suppress the parameters from displaying in the URL? For instance, if I pass in a password, I don't want it to show up in the address bar. http://www.jguru.com/misc/faqtrampoline.jsp?src=notifyEID=586493 ++ Tomcat FAQ: http://www.jguru.com/faq/Tomcat Why is Tomcat 4.0 so slow when connecting via a URLConnection? http://www.jguru.com/misc/faqtrampoline.jsp?src=notifyEID=588390 You can
