[jakarta-servletapi-3.2] javax.servlet.http.HttpUtils.parseName(...) change request - non 8859-1 troubles
Hello!
Preposition:
I have to work with non 8859-1 locales under servlets. (Tomcat 3.2 / MS Windows
2000).
Problem:
When I post form using GET or POST I got the instead of cyrillic charasters
in posted values when I'm using
request.getParameter(name).
Investigation:
Tomcat uses servlet api implementation and javax.servlet.http.HttpUtils class for
parsing posted data.
The chars disappears in the method parseName(String, StringBuffer).
Proposal:
Change code of parseName() method implementation in the HttpUtils class to
static private String parseName(String s, StringBuffer sb) {
return java.net.URLDecoder().decode(s)
}
or (if we need StringBuffer functionality further).
static private String parseName(String s, StringBuffer sb) {
sb.setLength(0);
sb.append(java.net.URLDecoder().decode(s));
return sb.toString();
}
Because the java.net.URLDecoder makes the same logical thing and chars are don't
dissappear ( :) ).
The code of URLDecoder very similar to current implementation of parseName method, but
have next additional part after decoding %NN's.
==
// Undo conversion to external encoding
String result = sb.toString();
try {
byte[] inputBytes = result.getBytes(8859_1);
result = new String(inputBytes);
} catch (UnsupportedEncodingException e) {
// The system should always have 8859_1
}
==
wbr, iit.
old code state for the HttpUtils
=
static private String parseName(String s, StringBuffer sb) {
sb.setLength(0);
for (int i = 0; i s.length(); i++) {
char c = s.charAt(i);
switch (c) {
case '+':
sb.append(' ');
break;
case '%':
try {
sb.append((char) Integer.parseInt(s.substring(i+1, i+3),
16));
i += 2;
} catch (NumberFormatException e) {
// XXX
// need to be more specific about illegal arg
throw new IllegalArgumentException();
} catch (StringIndexOutOfBoundsException e) {
String rest = s.substring(i);
sb.append(rest);
if (rest.length()==2)
i++;
}
break;
default:
sb.append(c);
break;
}
}
return sb.toString();
}
==the URLDecoder.decode() source
public static String decode(String s) {
StringBuffer sb = new StringBuffer();
for(int i=0; is.length(); i++) {
char c = s.charAt(i);
switch (c) {
case '+':
sb.append(' ');
break;
case '%':
try {
sb.append((char)Integer.parseInt(
s.substring(i+1,i+3),16));
} catch (NumberFormatException e) {
throw new IllegalArgumentException();
}
i += 2;
break;
default:
sb.append(c);
break;
}
}
// Undo conversion to external encoding
String result = sb.toString();
try {
byte[] inputBytes = result.getBytes(8859_1);
result = new String(inputBytes);
} catch (UnsupportedEncodingException e) {
// The system should always have 8859_1
}
return result;
}
Re: [PATCH] Catalina JNDIRealm - binding as the user
John Holman wrote: As said before I'd like to add the ability to search the directory for the user's dn to cover cases when a fixed pattern will not work, but will wait to see the fate of this patch before going ahead. Regarding the search, then bind authentication; what would be the suggested behaviour when there are more than one returned dn from the search? Should one try to authenticate as each of these, or automatically assume not authenticated? -- - Torgeir
Jasper Exception with security and login.jsp
Hi,
Runnong tomcat 3.2.2b4 using a slightly modified form of Hello world
example servlet I get an exception.
I am trying to access a protected resource and it is redirecting to the
login.jsp. Rather than display the login page it results in an
exception. The tomcat log shows an AccessControlException
2001-05-16 02:56:47 - ContextManager: AccessInterceptor: checking
/jsp/security/login/login.jsp
java.lang.ExceptionInInitializerError:
java.security.AccessControlException: access denied
(java.util.PropertyPermission line.separator read)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:272)
at
java.security.AccessController.checkPermission(AccessController.java:399)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
at
java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1278)
at java.lang.System.getProperty(System.java:560)
at
org.apache.jasper.runtime.JspWriterImpl.clinit(JspWriterImpl.java:385)
at
org.apache.jasper.runtime.PageContextImpl._createOut(PageContextImpl.java:467)
at
org.apache.jasper.runtime.PageContextImpl._initialize(PageContextImpl.java:181)
at
org.apache.jasper.runtime.PageContextImpl.initialize(PageContextImpl.java:149)
at
org.apache.jasper.runtime.JspFactoryImpl.getPageContext(JspFactoryImpl.java:99)
at
jsp.security.login._0002fjsp_0002fsecurity_0002flogin_0002flogin_0002ejsplogin_jsp_0._jspService(_0002fjsp_0002fsecurity_0002flogin_0002flogin_0002ej
splogin_jsp_0.java:49)
---
I can give myself access permissions, however, this then causes a
NullPointerException to be displayed in the browser. The 'Root cause'
shows a NullPointerException from
---
java.lang.NullPointerException
at
org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:111)
at
jsp.security.login._0002fjsp_0002fsecurity_0002flogin_0002flogin_0002ejsplogin_jsp_0._jspService(_0002fjsp_0002fsecurity_0002flogin_0002flogin_0002ejsplogin_jsp_0.java:67)
---
The login.jsp compiled code error line is
} finally {
if (out != null) out.flush();
if (_jspxFactory != null)
_jspxFactory.releasePageContext(pageContext);
}
Is this a known problem with an access control failure during an
authentication request.
Full exception details shown below.
Rgds
Antony
--
Antony Bowesman
Teamware Group
[EMAIL PROTECTED]
tel: +358 9 5128 2562
fax: +358 9 5128 2705
Error: 500
Location: /helloweb/jsp/security/login/login.jsp
Internal Servlet Error:
org.apache.jasper.JasperException
at
org.apache.jasper.servlet.JspServlet$JspCountedServlet.service(JspServlet.java:132)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:282)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:429)
at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:500)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:405)
at org.apache.tomcat.core.Handler.service(Handler.java:287)
at
org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
at
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797)
at
org.apache.tomcat.core.ContextManager.service(ContextManager.java:743)
at
org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:213)
at
org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416)
at
org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501)
at java.lang.Thread.run(Thread.java:484)
Root cause:
java.lang.NullPointerException
at
org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:111)
at
jsp.security.login._0002fjsp_0002fsecurity_0002flogin_0002flogin_0002ejsplogin_jsp_0._jspService(_0002fjsp_0002fsecurity_0002flogin_0002flogin_0002ejsplogin_jsp_0.java:67)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.jasper.servlet.JspServlet$JspCountedServlet.service(JspServlet.java:130)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:282)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:429)
at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:500)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
RE: Jasper performance
Have you said a Meg of html !!! Those are the test cases I need. Chau, Gaston - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 15, 2001 12:41 PM Subject: Re: Jasper performance We use Jasper (from a 3.1 build!) in another container. How big is the change if we wanted to move to the 3.3 version to get the tag pooling. I'm about to start performance testing our app, and currently the pages are taking ages to render (we build up to 1Meg of html.. :o), so we'll be looking at this area soon. In terms of a quick hit, anybody got opinions / experience of changing the generation to use an unsynchronized version of StringBuffer, I think this may show up as a possible easy enhancement. Ken. [EMAIL PROTECTED] on 15/05/2001 15:22:17 Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(bcc: Ken X Horn) Subject: Re: Jasper performance Jasper performance has already been identified as an area needing improvement. Discussions and work on this has already started in the main tomcat branch in CVS jakarta-tomcat/proposals/jasper34, but this may be moving to the CVS repository jakarta-tomcat-jasper. This work just started recently, I don't know when it will be ready. It will take few months - it's not that easy. We already added tag pooling in tomcat3.3, and that have a significant effect on performance if you are using tags - but that's just the beginning. The first step is to reorganize the code. Then we'll try to make the code generator more customizable ( probably by using XSLT for some of the operations ). The real performance enhancement will come when we start tunning the generated code - there are many ideas around, but we need the refactoring first. BTW, jasper will share most of the code for the 1.1 and 1.2 APIs, so all enhancements will be available in both 3.x and 4.x ( and other containers as well ). If you have ideas, code or opinions - please get involved, we need you :-) Costin Rickard Öberg wrote: Hi! We are using Tomcat/JBoss and are pleased with the actual functionality. What is killing us right now is the performance of the code generated by Jasper, especially when using taglibs in complex ways. The generated code is way too unoptimized. So, if this has not been asked before (in which case a RTFA is ok, although I've looked already), my question is: When will Jasper be rewritten? Are there any such projects underway now? Have there been any discussions about this yet? Am I the only one seeing this problem, or are more people concernced about it? Thanks, Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED]
RE: Jasper performance
I have some ideas to improbe performance. But it sounds like a should enter them at the CVS. Is that true? How can I do it? The JspCompacter is almost finished. (I also have to document it in english). When finished, that should I do. Should I send it to the list for evaluation? Chau, Gaston ps: I am adding also usage options. - Original Message - From: Glenn Nielsen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 15, 2001 6:49 AM Subject: Re: Jasper performance Jasper performance has already been identified as an area needing improvement. Discussions and work on this has already started in the main tomcat branch in CVS jakarta-tomcat/proposals/jasper34, but this may be moving to the CVS repository jakarta-tomcat-jasper. This work just started recently, I don't know when it will be ready. Regards, Glenn Rickard Öberg wrote: Hi! We are using Tomcat/JBoss and are pleased with the actual functionality. What is killing us right now is the performance of the code generated by Jasper, especially when using taglibs in complex ways. The generated code is way too unoptimized. So, if this has not been asked before (in which case a RTFA is ok, although I've looked already), my question is: When will Jasper be rewritten? Are there any such projects underway now? Have there been any discussions about this yet? Am I the only one seeing this problem, or are more people concernced about it? Thanks, Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
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 efficient as win32 native at such important tasks as disk and socket I/O. It's a wonderful user level tool. I use it everyday for many things. But deploying production systems isn't one of the things I'd do. However, since I just recently sold management on linux/apache/tomcat as our next gen platform, and I can put that on my desktop as well, it's not much skin off my nose if the connectors are suboptimal on NT. g -Original Message- From: kevin seguin [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 15, 2001 10:00 AM To: [EMAIL PROTECTED] Subject: Re: Trying New Connectors Build Stuff So we have 2 cygwin (amy+jon) and 1 msvc (kevin)... I hoped to have more feedback... I'll start with cygwin (since I can get it for free) does it really matter much? it should build with both cygwin and msvc, right? you might just have different makefiles for the two. -kevin. This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
RE: JNDI/LDAP realm
As I understand it, you can rebind with different credentials, but you can't have more than one set of credentials on the same connection. That means either synchronizing on the ldap connection, and serializing login, or having multiple connections and parallelizing login. Now, this isn't a terrible issue if the code cleans up promptly when done authenticating, but it is a resource contention issue. If the code doesn't clean up promptly, and relies on finalization, then it will only fail under load. Usually in some horrible manner that will be difficult to trace back to 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 PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 14, 2001 5:39 PM Subject: 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, if you're not replicating LDAP. According to the JNDI tutorial at least, Suns's provider for LDAP v3 is supposed to allow rebinding with a different principal.and credentials while keeping the same directory context and underlying network connection. (Although in practice it doesn't always seem to work quite like that). So it might be possible not to need additional file descriptors. Also, note that the LDAP connection is only needed for a brief period at the beginning of a session when the user first authenticates. Not that the present code attempts to be efficient about reusing directory contexts etc. But perhaps I misunderstand what you are saying. All in all, making it configurable is probably a good idea. Agreed. -Original Message- From: Ellen Lockhart [mailto:[EMAIL PROTECTED]] Sent: Sunday, May 13, 2001 12:58 PM To: [EMAIL PROTECTED] Subject: Re: JNDI/LDAP realm I preferred binding to the directory with supplied credentials because it allows the realm implementation to use an anonymous password for the rest of what it needs. To allow for DN's in the directory that may not be composed of the same attributes as other DN's, one thing I was thinking about doing to the one I submitted was to configure what the login attribute is (cn, uid, etc.) and search for it (with anonymous login) to get the dn, then bind to the directory with the resultant DN and the user-entered password to authenticate. This might be a little less efficient than just searching and getting the password as well, but is more secure than having the root password to the ldap server where it might be accessible by someone. - Original Message - From: John Holman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, May 13, 2001 5:02 AM Subject: JNDI/LDAP realm The current JNDI realm implementation in Tomcat 4 is based on code I submitted, which was subsequently modified and committed by Craig. Two significant changes he made are: - the original code found the DN of the user by searching the directory. The current implementation, like Ellen Lockhart's recent submission, determines the DN by substituting the username into a string. - the original code supported a mode in which the user is authenticated by binding to the directory with the supplied credentials (as does Ellen's). The code for this was removed, with a comment in the commit log that this mode should be supported probably in a separate implementation class. I did comment on this in an earlier message, but got no response - so I'm trying again now there is another little wave of interest :) Determining the DN. The pattern substitution method in the current implementation is obviously more efficient when applicable but the search method is more general. For example, unlike the current implementation, search can handle the following common use cases: - users are stored within multiple nodes in the directory (e.g. they may be held under different organisational units) - the attribute used in distinguished names is not the same as that the user enters into the basic authentication dialog box (e.g. the user might enter mail address as the username rather than uid; the directory might use commonName as a component of distinguished names rather than uid). So there are really two orthogonal issues for user authentication each with two options: - how the dn for the user is
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 PROTECTED] Subject: Re: Jasper performance I would like to propose that the new Jasper require jdk 1.2. The current version of jasper can be used by those who have jdk 1.1.x. Then we don't have to worry about jumping through hoops trying to get the new jasper to run both in 1.1 and 1.2, plus we can optimize for 1.2. In addition JSP 1.2 will require jdk 1.2 or greater. Regards, Glenn [EMAIL PROTECTED] wrote: Jasper performance has already been identified as an area needing improvement. Discussions and work on this has already started in the main tomcat branch in CVS jakarta-tomcat/proposals/jasper34, but this may be moving to the CVS repository jakarta-tomcat-jasper. This work just started recently, I don't know when it will be ready. It will take few months - it's not that easy. We already added tag pooling in tomcat3.3, and that have a significant effect on performance if you are using tags - but that's just the beginning. The first step is to reorganize the code. Then we'll try to make the code generator more customizable ( probably by using XSLT for some of the operations ). The real performance enhancement will come when we start tunning the generated code - there are many ideas around, but we need the refactoring first. BTW, jasper will share most of the code for the 1.1 and 1.2 APIs, so all enhancements will be available in both 3.x and 4.x ( and other containers as well ). If you have ideas, code or opinions - please get involved, we need you :-) Costin Rickard Öberg wrote: Hi! We are using Tomcat/JBoss and are pleased with the actual functionality. What is killing us right now is the performance of the code generated by Jasper, especially when using taglibs in complex ways. The generated code is way too unoptimized. So, if this has not been asked before (in which case a RTFA is ok, although I've looked already), my question is: When will Jasper be rewritten? Are there any such projects underway now? Have there been any discussions about this yet? Am I the only one seeing this problem, or are more people concernced about it? Thanks, Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
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 I'm trying to get it fixed. -Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 15, 2001 10:35 AM To: [EMAIL PROTECTED] Subject: Re: virus warnings and Pier P. Fumagalli wrote: Jay Doggett at [EMAIL PROTECTED] wrote: Ok, good call. I had multiple mail rules for this list. I still think that virus posters should get expunged. I didn't get any virus... Pier I also didn't get any virus, but our company mail servers may filter silently these things, but that also means we (the ones that tell no virus) cannot send these virus! Jean-frederic This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
RE: Jasper performance
Now, people are suggesting using something like XSLT to transform the .jsp XML/XHTML file into a .java file. Because you are introducing the XSLT layer into things, that will have a negative impact on the transformation performance (I'm not certain how much, but I am pretty much certain it will be more than the current system.). Given that this only happens when you are in development mode, I think that people developing JSP pages might not like the performance hit. I used XSLT in the past as a template mechanism and I think that Jon is right. XSLT is quite demanding on CPU and memory. (Yes, I am the TemplateMan: I already used XSLT, Freemarker, WebMacro and Velocity) MOREOVER, XSLT always adds a lot of baggage to the equation since the engines are usually quite big and demand for something more than a basic XML parser. And do not forget that, bad practice or not, a lot of people like to have compile-on-change JSPs even in production. So, what ever weight you add, it will be there all the time for a lot of people. And then, XSLT syntax is a pain in the ass, which pays even less when you are not trying to generate well formed XML. It is just too much trouble. I have been changing stuff from using XSLT to using Velocity and it is always a big relief. I do not believe that the code generation for JSPs will demand a very feature full template mechanism. OTOH, sometimes I often come across java products that have their own minimal template mechanism... which means it probably is not hard. So, I believe that Jasper needs a minimal template mechanism, and not a maximal one like XSLT. IF I was messing with Jasper, I would try to find out exactly what is the absolute minimum of templating features that Jasper would need to make the code generation easier. I would try to paths: 1) A very simple XML based template mechanism (with IFs, LOOPSs, VALUEs and so around/controlling-the-flow of the java templated text. No namespaces and no other complex XSLT sh*t; 2) A cut down version of the Webmacro/Velocity syntax. Since an XML parser is already used, 1) would not need much extra weight. If I would not be happy after playing with the 1) concept, I would go for a (very) cut down version of Velocity. My wild guess is that such cut down version could have less than 150 kB, which is much less that what you would have with a XSLT parser and it would be less memory and CPU intensive too. (Yes, Velocity as a load of baggage that can be thrown away for such simple mechanism, like resource management, app tools, part of the syntax features and so on.) For prototyping purposes... for 1) It might be possible to find some XML based mechanism in some OpenSource project somewhere. I bet that something like that exists; for 2) You have Velocity, of course. Well, it is just a suggestion. At the moment that is not my itch. Have fun, Paulo Gaspar -Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 16, 2001 7:19 AM on 5/15/01 8:32 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: +1 for the generator. Considerations on the generator: This will slow development down even further doing the transformation step. What ? Using JDK1.2 instead of JDK1.1 ? I doubt it, but thanks for worrying about this :-) Costin Sorry, let me quote the emails a bit better so that you can understand what I am trying to suggest. See above. Currently Jasper output's Java code from within Java code. This is about as fast as you are going to get because there is no intermediate transformation step going on, just conditional output of String data entirely within Java. While this is very fast, it also means that modifications to Jasper are damn near impossible without reading the source code in a fair amount of detail and doing quite a lot of testing. Now, people are suggesting using something like XSLT to transform the .jsp XML/XHTML file into a .java file. Because you are introducing the XSLT layer into things, that will have a negative impact on the transformation performance (I'm not certain how much, but I am pretty much certain it will be more than the current system.). Given that this only happens when you are in development mode, I think that people developing JSP pages might not like the performance hit. Just a word of consideration. -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ymtd/ymtd.html
Re: configure for jakarta-tomcat-connectors
[EMAIL PROTECTED] wrote: On Tue, 15 May 2001, jean-frederic clere wrote: By the way I have a question: Why jk_jni_worker.c is in common not in jni? What it is used for? (I have to add JAVA_HOME to the configure for it and I am curious). Error - it shouldn't be in common... But it should be in jni. jk_jni_worker uses JNI to start tomcat in the same process with Apache(2.0) or IIS/NES and uses in-process calls instead of TCP/IP. That means it should be configured for apache with configure --enable-jni --with-apxs=path_to_apxs --with-java-home=path_to_java_home correct? Does someone knows how to guess OS_TYPE? That is for -I$(JAVA_INCLUDE) -I$(JAVA_INCLUDE)/$(OS_TYPE) It should be the fastest - but it's the hardest to debug, and it hasn't been tunned too much. ( it is similar with the NES servlet container, which runs in-process too, or with mod_perl/mod_php ). Costin +++ CUT +++
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java
--- [EMAIL PROTECTED] wrote:
craigmcc01/05/15 18:43:56
Modified:
catalina/src/share/org/apache/catalina/authenticator
AuthenticatorBase.java
Log:
Revert the previous change, back to what was 1.13.
Revision ChangesPath
1.15 +97 -31
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java
Index: AuthenticatorBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- AuthenticatorBase.java 2001/05/16 01:40:00
1.14
+++ AuthenticatorBase.java 2001/05/16 01:43:54
1.15
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java,v
1.14 2001/05/16 01:40:00 craigmcc Exp $
- * $Revision: 1.14 $
- * $Date: 2001/05/16 01:40:00 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java,v
1.15 2001/05/16 01:43:54 craigmcc Exp $
+ * $Revision: 1.15 $
+ * $Date: 2001/05/16 01:43:54 $
*
*
*
@@ -66,6 +66,8 @@
import java.io.IOException;
+import java.net.MalformedURLException;
+import java.net.URL;
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.security.Principal;
@@ -119,7 +121,7 @@
* requests. Requests of any other type will
simply be passed through.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.14 $ $Date: 2001/05/16
01:40:00 $
+ * @version $Revision: 1.15 $ $Date: 2001/05/16
01:43:54 $
*/
@@ -474,32 +476,41 @@
log( Subject to constraint + constraint);
// Enforce any user data constraint for this
security constraint
+if (debug = 1)
+log( Calling checkUserData());
if (!checkUserData(hrequest, hresponse,
constraint)) {
if (debug = 1)
log( Failed checkUserData() test);
-((HttpServletResponse)
hresponse.getResponse()).sendError
-
(HttpServletResponse.SC_FORBIDDEN,
- ((HttpServletRequest)
hrequest.getRequest()).getRequestURI());
- return;
- }
-
- // Authenticate based upon the specified login
configuration
- if (!authenticate(hrequest, hresponse, config))
{
- if (debug = 1)
- log( Failed authenticate() test);
// ASSERT: Authenticator already set
the appropriate
// HTTP status code, so we do not
have to do anything special
return;
}
+ // Authenticate based upon the specified login
configuration
+if (constraint.getAuthConstraint()) {
+if (debug = 1)
+log( Calling authenticate());
+if (!authenticate(hrequest,
hresponse, config)) {
+if (debug = 1)
+log( Failed authenticate()
test);
+// ASSERT: Authenticator already
set the appropriate
+// HTTP status code, so we do not
have to do anything special
+return;
+}
+}
+
// Perform access control based on the specified
role(s)
- if (!accessControl(hrequest, hresponse,
constraint)) {
- if (debug = 1)
- log( Failed accessControl() test);
-// ASSERT: Access control method has
already set the appropriate
-// HTTP status code, so we do not
have to do anything special
- return;
- }
+if (constraint.getAuthConstraint()) {
+if (debug = 1)
+log( Calling accessControl());
+if (!accessControl(hrequest,
hresponse, constraint)) {
+if (debug = 1)
+log( Failed accessControl()
test);
+// ASSERT: AccessControl method
has already set the appropriate
+// HTTP status code, so we do not
have to do anything special
+return;
+}
+}
// Any and all specified constraints have been
satisfied
if (debug = 1)
@@ -634,22 +645,77 @@
throws IOException {
// Is there a relevant user data constraint?
- if (constraint == null)
+ if (constraint == null) {
+if (debug = 2)
+ log( No applicable security constraint
defined);
return (true);
+}
String userConstraint =
constraint.getUserConstraint();
- if (userConstraint == null)
+ if (userConstraint == null) {
+
RE: Collaborative Development (not Cat and Dog)
Well, I do NOT care about the fact that he is not documenting Tomcat instead since: - He already does a lot; - He is not alone at Tomcat, and others (even me or you) could work on the documentation too. We just have other priorities; - He as all the right to decide what he does on his free time and to have other priorities too; - Apache is not paying him and it is not up to us to discuss what Sun does or does not care about; Just to make clear that what I DO care about is that Craig is blaming all that mess on Tomcat 3.3 instead of pointing the real issue - the lack of documentation. More people do listen to Craig than to me, so: - It is much more productive when he points out the real issues (which in this case are quite obvious); - And it is much more nocive when he points on the wrong direction. I still stick with my statement that I DO admire Craig's work. But: - No one is perfect; - People tend to have a less clear vision of facts about something they are too involved with. Anyway, errors can be made, but they usually also can be fixed. Have fun, Paulo -Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 15, 2001 6:26 PM on 5/15/01 3:46 AM, Paulo Gaspar [EMAIL PROTECTED] wrote: My evaluation of facts is: - There is almost no documentation on Tomcat, either on web pages or under a more formal format. Tomcat is much more complex than Velocity (a Jakarta project I know well) but its documentation looks pathetic when compared to Velocity's. IMO, this is the _obvious_ cause for that Tomcat users confusion that shows at the USER mailing list; Now that isn't fair. Craig is just overly busy trying to document Struts so that JSP can take over the world! Unfortunately, no one will be able to run Struts because they can't figure out how to use Tomcat. Funny Catch-22 if you ask me. :-) ... -jon
RE: JNDI/LDAP realm
At 13:49 16/05/01, Steve Downey wrote: As I understand it, you can rebind with different credentials, but you can't have more than one set of credentials on the same connection. That means either synchronizing on the ldap connection, and serializing login, or having multiple connections and parallelizing login. That's my understanding too - and in fact the directory should abort any pending requests on a connection when a rebind occurs. But I think either synchronisation or multiple connections/contexts are needed anyway, even if a system account is used to bind to the directory and that the same credentials are used throughout. Now, this isn't a terrible issue if the code cleans up promptly when done authenticating, but it is a resource contention issue. If the code doesn't clean up promptly, and relies on finalization, then it will only fail under load. Usually in some horrible manner that will be difficult to trace back to the root cause. Yes. The initial code makes no attempt at performance - it serialises all requests through a single directory context. John -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 PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 14, 2001 5:39 PM Subject: 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, if you're not replicating LDAP. According to the JNDI tutorial at least, Suns's provider for LDAP v3 is supposed to allow rebinding with a different principal.and credentials while keeping the same directory context and underlying network connection. (Although in practice it doesn't always seem to work quite like that). So it might be possible not to need additional file descriptors. Also, note that the LDAP connection is only needed for a brief period at the beginning of a session when the user first authenticates. Not that the present code attempts to be efficient about reusing directory contexts etc. But perhaps I misunderstand what you are saying. All in all, making it configurable is probably a good idea. Agreed. -Original Message- From: Ellen Lockhart [mailto:[EMAIL PROTECTED]] Sent: Sunday, May 13, 2001 12:58 PM To: [EMAIL PROTECTED] Subject: Re: JNDI/LDAP realm I preferred binding to the directory with supplied credentials because it allows the realm implementation to use an anonymous password for the rest of what it needs. To allow for DN's in the directory that may not be composed of the same attributes as other DN's, one thing I was thinking about doing to the one I submitted was to configure what the login attribute is (cn, uid, etc.) and search for it (with anonymous login) to get the dn, then bind to the directory with the resultant DN and the user-entered password to authenticate. This might be a little less efficient than just searching and getting the password as well, but is more secure than having the root password to the ldap server where it might be accessible by someone. - Original Message - From: John Holman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, May 13, 2001 5:02 AM Subject: JNDI/LDAP realm The current JNDI realm implementation in Tomcat 4 is based on code I submitted, which was subsequently modified and committed by Craig. Two significant changes he made are: - the original code found the DN of the user by searching the directory. The current implementation, like Ellen Lockhart's recent submission, determines the DN by substituting the username into a string. - the original code supported a mode in which the user is authenticated by binding to the directory with the supplied credentials (as does Ellen's). The code for this was removed, with a comment in the commit log that this mode should be supported probably in a separate implementation class. I did comment on this in an earlier message, but got no response - so I'm trying again now there is another little wave of interest :) Determining the DN. The pattern substitution method in the current implementation is obviously more efficient when applicable but the search method is more general. For example, unlike the current implementation, search can handle the following common use cases: - users are
Re: Trying New Connectors Build Stuff
However, since I just recently sold management on linux/apache/tomcat as our next gen platform, and I can put that on my desktop as well, it's not much skin off my nose if the connectors are suboptimal on NT. g unfortunately, not all management is as enlightened as yours appears to be ;) performance on windows platforms is probably going to be important for a lot of people. or maybe just for me :)
Re: Trying New Connectors Build Stuff
kevin seguin at [EMAIL PROTECTED] wrote: However, since I just recently sold management on linux/apache/tomcat as our next gen platform, and I can put that on my desktop as well, it's not much skin off my nose if the connectors are suboptimal on NT. g unfortunately, not all management is as enlightened as yours appears to be ;) performance on windows platforms is probably going to be important for a lot of people. or maybe just for me :) I think you didn't understand what I meant for CygWin... CygWin is a bunch of stuff, is basically Unix into Windows, and it comes with a different set of tools: the GCC compiler, a set of shell tools, the unix compatibility library and so on... The point of using CygWin is only to use the compiler itself, and then rely on what M$ does at OS level with the API, ignoring the unix compatibility layer. :) We have APR for doing all that crap, and skimming thru the code, APR is using all the Win 32 specific API, not the compatible ones provided by the CygWin environment... But I might be AWFULLY wrong... :) As always... And don't hesitate to correct me if I am :) Pier
Re: web_app in jakarta-tomcat-connectors ?
[EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: [+1] Let's move mod_webapp and all its related stuff in jakarta-connectors. +1 The stuff is not ready ( neither the new mod_jk for 4.0 nor mod_webapp ), and when it is - tomcat-dev should decide which one will be used in 4.0. Isn't it how it works ? Yeah, however that doesn't force anyone to give up his work, or should we start debating on 3.x being a dead end??? :) :) :) This way it'll be fair - and you'll get your code used because and if it'll be better than mod_jk, not because it is the default for 4.0. Ok, I'm going to shut up now otherwise we'll end up in the same old flamewar. What-EVER. Pier
Re: Jasper performance
On Tue, 15 May 2001, Jon Stevens wrote: Currently Jasper output's Java code from within Java code. This is about as fast as you are going to get because there is no intermediate transformation step going on, just conditional output of String data entirely within Java. While this is very fast, it also means that modifications to Jasper are damn near impossible without reading the source code in a fair amount of detail and doing quite a lot of testing. We do need to read source code and do testing in order to make modification in a code generator ??? :-)... XLST will not change that. Now, people are suggesting using something like XSLT to transform the .jsp XML/XHTML file into a .java file. Because you are introducing the XSLT layer into things, that will have a negative impact on the transformation performance (I'm not certain how much, but I am pretty much certain it will be more than the current system.). Given that this only happens when you are in development mode, I think that people developing JSP pages might not like the performance hit. The code generation stage is not significant - compared with the javac compilation. Some people are even using XSLT at runtime ( not that this is a good idea ) - so I doubt it'll have such a significant impact on development mode ( if it's ok for a runtime page, it should be ok for a developer ). In addition, for pure jsp ( if no java fragment is used ) it would be possible to use the same technique as XSLTC ( now part of xalan ) - and generate the bytecode directly ( since most of the generated code is glue ) - and avoid the javac. Of course, the big goal is to allow some taglib optimzations ( create alternate implementations for common-used tags, with same behavior but generating code directly ) - and that's why XSLT is need. The good news about JSP is that it is a specification. People can use a different implementation if they are not happy with one, or use one for development and one for deployment. ( I have a feeling Cocoon2 and Resin are both using XSLT in developing the pages - so I guess we will be safe, both are doing OK ) Costin
if mod_jk can be compiled statically in Apache
Hello, First of all, thanks to developers group for Tomcat JServ products. I'm a bit new to Tomcat so please pardon me if this issue has been addressed before but I have followed as much as I could from the documentation and could not find solution for my needs. Basically, our company has been used JServ for number of months and now we are trying to implement Tomcat (simple replacement Jserv on Tomcat). With Jserv we had build Apache statically. The idea behind TOMCAT is same, - keep Apache statically. - build TOMCAT as out-of-process servlet engine. Prior to send this email to developers mailing list, I checked TOMCAT documentation + mailing archive of Users list but could not find an answer if I can compile mod_jk statically in Apache --with-apache flag. I been able to find some discussion about it under developers mailing list but still not be able to find exact syntax for ./configure to build mod_jk statically on SUN Solaris platform ( all documentation refer to Apache with DSO and apxs command). If anyone from developers group will be able to answer my question, it would be real appreciated. Sorry again, if I am sending this configuration question to developers list but I could not find anything in Tomcat users list. Awaiting kind reply. Regards, Albert Khokhlov Tech Lead Consultant of Global Logistics Technologies Inc (PA , USA) Environment: - Apache 1.3.14 (will try to upgrade to 1.3.19 as soon as Tomcat installed) - JDK 1.2.1-04 - Solaris 7 - Tomcat 3.2.1 (trying to implement).
[PATCH] configure.in for jakarta-tomcat-connectors
Hi, I have added the detection of the JAVA_HOME and OS that will be need for the jni connector. It is a copy of acinclude.m4 of JServ and some improvements. ;=) Please check it and commit it. Cheers Jean-frederic
Recycle Logic in 3.2.1 broken
Hi,
I have detected what seems to be a bug in the recycle logic
of TomCat 3.2.1. What seems to be happening is, that a
response object of some kind is using a Writer and processes
the request. In some other request the BufferedServletOutputStream's
usingWriter flag is still set, in other words, the recycling
doesn't seem to work properly.
I can demonstrate the problem and create a workaround by
adding the following code on top of my servlet. It uses
a method isUsingWriter(), which I have added to the
BufferedServletOutputStream class:
ServletOutputStream os = pRes.getOutputStream();
if (os instanceof org.apache.tomcat.core.BufferedServletOutputStream) {
org.apache.tomcat.core.BufferedServletOutputStream bsos =
(org.apache.tomcat.core.BufferedServletOutputStream) os;
if (bsos.isUsingWriter()) {
Trace.Log(this, tmGet, 5, OutputStream is using Writer);
bsos.setUsingWriter(false);
}
}
Re: [PATCH] Catalina JNDIRealm - binding as the user
I was planning to fail authentication if more than one entry is found. At 09:58 16/05/01, you wrote: John Holman wrote: As said before I'd like to add the ability to search the directory for the user's dn to cover cases when a fixed pattern will not work, but will wait to see the fate of this patch before going ahead. Regarding the search, then bind authentication; what would be the suggested behaviour when there are more than one returned dn from the search? Should one try to authenticate as each of these, or automatically assume not authenticated? -- - Torgeir
Re: web_app in jakarta-tomcat-connectors ?
On Wed, 16 May 2001, Pier P. Fumagalli wrote: [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: [+1] Let's move mod_webapp and all its related stuff in jakarta-connectors. +1 The stuff is not ready ( neither the new mod_jk for 4.0 nor mod_webapp ), and when it is - tomcat-dev should decide which one will be used in 4.0. Isn't it how it works ? Yeah, however that doesn't force anyone to give up his work, or should we start debating on 3.x being a dead end??? :) :) :) I don't think there is anything to debate about that. All we know is that we have a release plan for a 3.3 release, a plan for a 4.0 release using a different code base - and commiters will decide what code base will be used for 5.0 ( it may be a completely different one - who knows ? ). Anyone is free to try new ideas - and to ignore existing code and reinvent the weels. And anyone is free to choose the codebase he thing has the best chances for long-term and work on it. But tomcat-dev must decide what is used in a certain release - and making mod_webapp the default for 4.0 is not fair. When you feel it's ready we can of course vote on it - and if indeed it's better I would be happy to use it in 3.x also. I believe mod_jk has more chances - so that's where I'll put my free development time ( if I find any :-). Costin This way it'll be fair - and you'll get your code used because and if it'll be better than mod_jk, not because it is the default for 4.0. Ok, I'm going to shut up now otherwise we'll end up in the same old flamewar. What-EVER.
cvs commit: jakarta-tomcat-connectors/jk/src/java/org/apache/ajp AjpRequest.java
seguin 01/05/16 10:08:57
Modified:jk/src/java/org/apache/ajp AjpRequest.java
Log:
added javadocs.
Revision ChangesPath
1.2 +72 -2
jakarta-tomcat-connectors/jk/src/java/org/apache/ajp/AjpRequest.java
Index: AjpRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/src/java/org/apache/ajp/AjpRequest.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- AjpRequest.java 2001/05/15 15:22:28 1.1
+++ AjpRequest.java 2001/05/16 17:08:50 1.2
@@ -65,13 +65,23 @@
import java.util.LinkedList;
import java.util.Iterator;
+/**
+ * Encapsulates an ajp request.
+ *
+ * When an ajp request is handled, it is decoded into an
+ * codeAjpRequest/code that can then be used by an adaptor
+ * and/or connector to process the request.
+ */
public class AjpRequest {
+// scheme constants
public static final String SCHEME_HTTP = http;
public static final String SCHEME_HTTPS = https;
-
+
+// an empty iterator
private final static Iterator emptyItr = new LinkedList().iterator();
+// request attributes
MessageBytes method = new MessageBytes();
MessageBytes protocol = new MessageBytes();
MessageBytes requestURI = new MessageBytes();
@@ -92,7 +102,7 @@
LinkedList cookies = new LinkedList();
/**
- * recylce this Request
+ * Recycles this object and readies it further use.
*/
public void recycle() {
method.recycle();
@@ -115,62 +125,122 @@
cookies.clear();
}
+/**
+ * Get the method.
+ * @return the method
+ */
public MessageBytes getMethod() {
return method;
}
+/**
+ * Get the protocol
+ * @return the protocol
+ */
public MessageBytes getProtocol() {
return protocol;
}
+/**
+ * Get the request uri
+ * @return the request uri
+ */
public MessageBytes getRequestURI() {
return requestURI;
}
+/**
+ * Get the remote address
+ * @return the remote address
+ */
public MessageBytes getRemoteAddr() {
return remoteAddr;
}
+/**
+ * Get the remote host
+ * @return the remote host
+ */
public MessageBytes getRemoteHost() {
return remoteHost;
}
+/**
+ * Get the server name
+ * @return the server name
+ */
public MessageBytes getServerName() {
return serverName;
}
+/**
+ * Get the server port
+ * @return the server port
+ */
public int getServerPort() {
return serverPort;
}
+/**
+ * Get the remote user
+ * @return the remote user
+ */
public MessageBytes getRemoteUser() {
return remoteUser;
}
+/**
+ * Get the auth type
+ * @return the auth type
+ */
public MessageBytes getAuthType() {
return authType;
}
+/**
+ * Get the query string
+ * @return the query string
+ */
public MessageBytes getQueryString() {
return queryString;
}
+/**
+ * Get the jvm route
+ * @return the jvm route
+ */
public MessageBytes getJvmRoute() {
return jvmRoute;
}
+/**
+ * Get the scheme
+ * @return the scheme
+ */
public String getScheme() {
return scheme;
}
+/**
+ * Get whether the request is secure or not.
+ * @return codetrue/code if the request is secure.
+ */
public boolean getSecure() {
return secure;
}
+/**
+ * Get the content length
+ * @return the content length
+ */
public int getContentLength() {
return contentLength;
}
+/**
+ * Get the content type
+ * @return the content type
+ */
public MessageBytes getContentType() {
return contentType;
}
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http HttpRequestLine.java
remm01/05/16 10:52:26
Modified:catalina/src/share/org/apache/catalina/connector/http
HttpRequestLine.java
Log:
- The array allocated for the protocol was too big (the wrong constant was used).
Patch submitted by Martijn Koster mak at greenhills.co.uk
Revision ChangesPath
1.3 +5 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpRequestLine.java
Index: HttpRequestLine.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpRequestLine.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- HttpRequestLine.java 2000/11/24 19:55:20 1.2
+++ HttpRequestLine.java 2001/05/16 17:52:17 1.3
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpRequestLine.java,v
1.2 2000/11/24 19:55:20 remm Exp $
- * $Revision: 1.2 $
- * $Date: 2000/11/24 19:55:20 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpRequestLine.java,v
1.3 2001/05/16 17:52:17 remm Exp $
+ * $Revision: 1.3 $
+ * $Date: 2001/05/16 17:52:17 $
*
*
*
@@ -75,7 +75,7 @@
* HTTP request line enum type.
*
* @author Remy Maucherat
- * @version $Revision: 1.2 $ $Date: 2000/11/24 19:55:20 $
+ * @version $Revision: 1.3 $ $Date: 2001/05/16 17:52:17 $
*/
final class HttpRequestLine {
@@ -98,7 +98,7 @@
public HttpRequestLine() {
this(new char[INITIAL_METHOD_SIZE], 0, new char[INITIAL_URI_SIZE], 0,
- new char[INITIAL_URI_SIZE], 0);
+ new char[INITIAL_PROTOCOL_SIZE], 0);
}
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves RequestFilterValve.java
remm01/05/16 10:57:28
Modified:catalina/src/share/org/apache/catalina/connector
HttpRequestBase.java HttpResponseBase.java
RequestBase.java ResponseBase.java
catalina/src/share/org/apache/catalina/connector/http
HttpProcessor.java
catalina/src/share/org/apache/catalina/connector/http10
HttpProcessor.java
catalina/src/share/org/apache/catalina/core
ApplicationContext.java
ApplicationFilterConfig.java StandardContext.java
StandardContextMapper.java StandardHost.java
StandardWrapperValve.java
catalina/src/share/org/apache/catalina/loader Extension.java
catalina/src/share/org/apache/catalina/realm
MemoryRealm.java
catalina/src/share/org/apache/catalina/servlets
DefaultServlet.java InvokerServlet.java
SsiInvokerServlet.java WebdavServlet.java
catalina/src/share/org/apache/catalina/util RequestUtil.java
catalina/src/share/org/apache/catalina/util/ssi
SsiMediator.java
catalina/src/share/org/apache/catalina/valves
RequestFilterValve.java
Log:
- Replace calls to indexOf(x) by indexOf('x'), and lastIndexOf(x) by
lastIndexOf('x').
Patch submitted by Martijn Koster mak at greenhills.co.uk
Revision ChangesPath
1.25 +5 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpRequestBase.java
Index: HttpRequestBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpRequestBase.java,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- HttpRequestBase.java 2001/05/14 04:51:16 1.24
+++ HttpRequestBase.java 2001/05/16 17:55:21 1.25
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpRequestBase.java,v
1.24 2001/05/14 04:51:16 craigmcc Exp $
- * $Revision: 1.24 $
- * $Date: 2001/05/14 04:51:16 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpRequestBase.java,v
1.25 2001/05/16 17:55:21 remm Exp $
+ * $Revision: 1.25 $
+ * $Date: 2001/05/16 17:55:21 $
*
*
*
@@ -101,7 +101,7 @@
* be implemented.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.24 $ $Date: 2001/05/14 04:51:16 $
+ * @version $Revision: 1.25 $ $Date: 2001/05/16 17:55:21 $
*/
public class HttpRequestBase
@@ -612,7 +612,7 @@
String contentType = getContentType();
if (contentType == null)
contentType = ;
-int semicolon = contentType.indexOf(;);
+int semicolon = contentType.indexOf(';');
if (semicolon = 0)
contentType = contentType.substring(0, semicolon).trim();
if (POST.equals(getMethod()) (getContentLength() 0)
1.33 +5 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java
Index: HttpResponseBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- HttpResponseBase.java 2001/05/14 04:51:16 1.32
+++ HttpResponseBase.java 2001/05/16 17:55:25 1.33
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
1.32 2001/05/14 04:51:16 craigmcc Exp $
- * $Revision: 1.32 $
- * $Date: 2001/05/14 04:51:16 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
1.33 2001/05/16 17:55:25 remm Exp $
+ * $Revision: 1.33 $
+ * $Date: 2001/05/16 17:55:25 $
*
*
*
@@ -100,7 +100,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.32 $ $Date: 2001/05/14 04:51:16 $
+ * @version $Revision: 1.33 $ $Date: 2001/05/16 17:55:25 $
*/
public class HttpResponseBase
@@ -692,7 +692,7 @@
String path = url;
String query = ;
- int question = url.indexOf(?);
+ int question = url.indexOf('?');
if (question = 0) {
path = url.substring(0, question);
query = url.substring(question);
1.14 +5 -5
Re: Webapp initialization (tomcat 4)
Glenn == Glenn Nielsen [EMAIL PROTECTED] writes: Glenn Tomcat 4.0 supports JNDI and JDBC DataSource pooling. I Glenn configure a named JNDI JDBC DataSource in the Glenn DefaultContext .. /, which is then available to all web Glenn applications for a Host. Glenn Here is an example from my server.xml (sensitive paramater Glenn data replaced with generic) Thanks, this looks like the way to do it. I guess I have to put my implementing class in $CATALINA_HOME/classes? Or in $CATALINA_HOME/lib/classes?!? Is this, and the Resource tag, somewhere documented? for example I'm wondering about the auth= attribute. -- Peter Mutsaers | Dübendorf| UNIX - Live free or die [EMAIL PROTECTED] | Switzerland | Sent via FreeBSD 4.3-stable
Tomcat 3.3 Milestone 3 status
Hi All, I'm in the process of preparing Tomcat 3.3 Milestone 3. Please consider the MAIN branch of jakarta-tomcat frozen for the time being. The current hold up is that mod_jk will serve JSP source for URL's that end with .jsp%20. As soon as I fix this, the Milestone 3 release will soon follow. I'll announce when Tomcat 3.3 development is unfrozen. Cheers, Larry P.S. Marc, a quick scan of mod_jk code didn't reveal differences that would suggest that mod_jk in Tomat 3.2.2 doesn't also have this problem. If there is already a fix, please let me know. Or, if not, let me know if you want me to port my fix. __ Larry Isaacs [EMAIL PROTECTED] SAS Institute Inc.
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java
craigmcc01/05/16 12:27:54
Modified:catalina/src/share/org/apache/catalina/authenticator
AuthenticatorBase.java
Log:
Previous integration update missed some needed logic. Will restore the current
working version momentarily.
Revision ChangesPath
1.16 +22 -78
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java
Index: AuthenticatorBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- AuthenticatorBase.java2001/05/16 01:43:54 1.15
+++ AuthenticatorBase.java2001/05/16 19:27:48 1.16
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java,v
1.15 2001/05/16 01:43:54 craigmcc Exp $
- * $Revision: 1.15 $
- * $Date: 2001/05/16 01:43:54 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java,v
1.16 2001/05/16 19:27:48 craigmcc Exp $
+ * $Revision: 1.16 $
+ * $Date: 2001/05/16 19:27:48 $
*
*
*
@@ -66,8 +66,6 @@
import java.io.IOException;
-import java.net.MalformedURLException;
-import java.net.URL;
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.security.Principal;
@@ -121,7 +119,7 @@
* requests. Requests of any other type will simply be passed through.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.15 $ $Date: 2001/05/16 01:43:54 $
+ * @version $Revision: 1.16 $ $Date: 2001/05/16 19:27:48 $
*/
@@ -481,8 +479,9 @@
if (!checkUserData(hrequest, hresponse, constraint)) {
if (debug = 1)
log( Failed checkUserData() test);
-// ASSERT: Authenticator already set the appropriate
-// HTTP status code, so we do not have to do anything special
+((HttpServletResponse) hresponse.getResponse()).sendError
+(HttpServletResponse.SC_FORBIDDEN,
+ ((HttpServletRequest) hrequest.getRequest()).getRequestURI());
return;
}
@@ -491,13 +490,13 @@
if (debug = 1)
log( Calling authenticate());
if (!authenticate(hrequest, hresponse, config)) {
-if (debug = 1)
-log( Failed authenticate() test);
+ if (debug = 1)
+ log( Failed authenticate() test);
// ASSERT: Authenticator already set the appropriate
// HTTP status code, so we do not have to do anything special
return;
}
-}
+ }
// Perform access control based on the specified role(s)
if (constraint.getAuthConstraint()) {
@@ -506,11 +505,11 @@
if (!accessControl(hrequest, hresponse, constraint)) {
if (debug = 1)
log( Failed accessControl() test);
-// ASSERT: AccessControl method has already set the appropriate
+// ASSERT: Access control method has already set the appropriate
// HTTP status code, so we do not have to do anything special
return;
}
-}
+ }
// Any and all specified constraints have been satisfied
if (debug = 1)
@@ -645,77 +644,22 @@
throws IOException {
// Is there a relevant user data constraint?
- if (constraint == null) {
-if (debug = 2)
- log( No applicable security constraint defined);
+ if (constraint == null)
return (true);
-}
String userConstraint = constraint.getUserConstraint();
- if (userConstraint == null) {
-if (debug = 2)
- log( No applicable user data constraint defined);
+ if (userConstraint == null)
return (true);
-}
- if (userConstraint.equals(Constants.NONE_TRANSPORT)) {
-if (debug = 2)
-log( User data constraint has no restrictions);
+ if (userConstraint.equals(Constants.NONE_TRANSPORT))
return (true);
-}
// Validate the request against the user data constraint
- if (request.getRequest().isSecure()) {
-if (debug = 2)
-log( User data constraint already satisfied);
-return (true);
-}
-
-// Initialize variables we need to determine the appropriate action
-HttpServletRequest hrequest =
-
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java
craigmcc01/05/16 12:30:44
Modified:catalina/src/share/org/apache/catalina/authenticator
AuthenticatorBase.java
Log:
Undo the previous change, back to 1.15 equivalent.
Revision ChangesPath
1.17 +78 -22
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java
Index: AuthenticatorBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- AuthenticatorBase.java2001/05/16 19:27:48 1.16
+++ AuthenticatorBase.java2001/05/16 19:30:38 1.17
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java,v
1.16 2001/05/16 19:27:48 craigmcc Exp $
- * $Revision: 1.16 $
- * $Date: 2001/05/16 19:27:48 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java,v
1.17 2001/05/16 19:30:38 craigmcc Exp $
+ * $Revision: 1.17 $
+ * $Date: 2001/05/16 19:30:38 $
*
*
*
@@ -66,6 +66,8 @@
import java.io.IOException;
+import java.net.MalformedURLException;
+import java.net.URL;
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.security.Principal;
@@ -119,7 +121,7 @@
* requests. Requests of any other type will simply be passed through.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.16 $ $Date: 2001/05/16 19:27:48 $
+ * @version $Revision: 1.17 $ $Date: 2001/05/16 19:30:38 $
*/
@@ -479,9 +481,8 @@
if (!checkUserData(hrequest, hresponse, constraint)) {
if (debug = 1)
log( Failed checkUserData() test);
-((HttpServletResponse) hresponse.getResponse()).sendError
-(HttpServletResponse.SC_FORBIDDEN,
- ((HttpServletRequest) hrequest.getRequest()).getRequestURI());
+// ASSERT: Authenticator already set the appropriate
+// HTTP status code, so we do not have to do anything special
return;
}
@@ -490,13 +491,13 @@
if (debug = 1)
log( Calling authenticate());
if (!authenticate(hrequest, hresponse, config)) {
- if (debug = 1)
- log( Failed authenticate() test);
+if (debug = 1)
+log( Failed authenticate() test);
// ASSERT: Authenticator already set the appropriate
// HTTP status code, so we do not have to do anything special
return;
}
- }
+}
// Perform access control based on the specified role(s)
if (constraint.getAuthConstraint()) {
@@ -505,11 +506,11 @@
if (!accessControl(hrequest, hresponse, constraint)) {
if (debug = 1)
log( Failed accessControl() test);
-// ASSERT: Access control method has already set the appropriate
+// ASSERT: AccessControl method has already set the appropriate
// HTTP status code, so we do not have to do anything special
return;
}
- }
+}
// Any and all specified constraints have been satisfied
if (debug = 1)
@@ -644,22 +645,77 @@
throws IOException {
// Is there a relevant user data constraint?
- if (constraint == null)
+ if (constraint == null) {
+if (debug = 2)
+ log( No applicable security constraint defined);
return (true);
+}
String userConstraint = constraint.getUserConstraint();
- if (userConstraint == null)
+ if (userConstraint == null) {
+if (debug = 2)
+ log( No applicable user data constraint defined);
return (true);
- if (userConstraint.equals(Constants.NONE_TRANSPORT))
+}
+ if (userConstraint.equals(Constants.NONE_TRANSPORT)) {
+if (debug = 2)
+log( User data constraint has no restrictions);
return (true);
+}
// Validate the request against the user data constraint
- if (!request.getRequest().isSecure()) {
- ((HttpServletResponse) response.getResponse()).sendError
- (HttpServletResponse.SC_BAD_REQUEST,
- sm.getString(authenticator.userDataConstraint));
- return (false);
- }
- return (true);
+ if (request.getRequest().isSecure()) {
+if (debug = 2)
+
Re: Jasper performance
on 5/16/01 1:11 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: The code generation stage is not significant - compared with the javac compilation. Some people are even using XSLT at runtime ( not that this is a good idea ) - so I doubt it'll have such a significant impact on development mode ( if it's ok for a runtime page, it should be ok for a developer ). In addition, for pure jsp ( if no java fragment is used ) it would be possible to use the same technique as XSLTC ( now part of xalan ) - and generate the bytecode directly ( since most of the generated code is glue ) - and avoid the javac. Of course, the big goal is to allow some taglib optimzations ( create alternate implementations for common-used tags, with same behavior but generating code directly ) - and that's why XSLT is need. The good news about JSP is that it is a specification. People can use a different implementation if they are not happy with one, or use one for development and one for deployment. ( I have a feeling Cocoon2 and Resin are both using XSLT in developing the pages - so I guess we will be safe, both are doing OK ) Costin Costin, Once again, you impress me with your inability to understand a word of what I'm talking about. So, let me close this discussion with this: If the speed of generating a .java file (or directly to a .class file) from JSP ends up taking more resources (ie: memory) and more time after the conversion to using XSLT as the transformation step, I will forward your comments above to you again and tell you I told you so. I welcome the same response from you. As for your comments about Cocoon2, well, if you actually look at it, it is dog slow and *extremely* resource intensive. The only reason why there is *any* performance out of it is because there is a shit load of caching and compiled XSLT that goes on. This is something that I fear the development of JSP pages will not be able to take advantage of in the same way and as a result, development performance will suffer compared with what it is at today. I find it funny that I seem to be the only one who cares about this issue. :-) p.s. Over in Turbine land, we have a lot of experience with the dynamic generation of Java code and have found that using Texen has been a most favorable experience. It would be most humorous to me to see Velocity used to generate .java files from .jsp input. :-) http://jakarta.apache.org/velocity/texen.html -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ymtd/ymtd.html
cvs commit: jakarta-tomcat/src/native/mod_jk/common jk_uri_worker_map.c
larryi 01/05/16 13:49:35
Modified:src/native/mod_jk/common jk_uri_worker_map.c
Log:
Fix bug in check_security_fraud() and add .suffix to .suffix. and
suffix/ already being checked.
Minor updates to log output.
Revision ChangesPath
1.5 +8 -7 jakarta-tomcat/src/native/mod_jk/common/jk_uri_worker_map.c
Index: jk_uri_worker_map.c
===
RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/common/jk_uri_worker_map.c,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- jk_uri_worker_map.c 2001/04/23 11:20:24 1.4
+++ jk_uri_worker_map.c 2001/05/16 20:49:25 1.5
@@ -65,7 +65,7 @@
* servlet container. *
* *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.4 $ *
+ * Version: $Revision: 1.5 $ *
***/
#include jk_pool.h
@@ -111,7 +111,8 @@
* fumble and return the jsp content.
*
* To solve that we will check for path info following the suffix, we
- * will also check that the end of the uri is not .suffix.
+ * will also check that the end of the uri is not .suffix.,
+ * .suffix/, or .suffix .
*/
static int check_security_fraud(jk_uri_worker_map_t *uw_map,
const char *uri,
@@ -129,9 +130,9 @@
if('.' != *(suffix_start - 1)) {
continue;
} else {
-char *after_suffix = suffix_start +
strlen(uw_map-maps[i].suffix) + 1;
+char *after_suffix = suffix_start +
strlen(uw_map-maps[i].suffix);
-if((('.' == *after_suffix) || ('/' == *after_suffix))
+if((('.' == *after_suffix) || ('/' == *after_suffix) || (' ' ==
*after_suffix))
(0 == strncmp(uw_map-maps[i].context, uri,
uw_map-maps[i].ctxt_len))) {
/*
* Security violation !!!
@@ -356,7 +357,7 @@
uri = clean_uri;
}
- jk_log(l, JK_LOG_DEBUG, Attempting to map URI %s\n, uri);
+ jk_log(l, JK_LOG_DEBUG, Attempting to map URI '%s'\n, uri);
for(i = 0 ; i uw_map-size ; i++) {
if(uw_map-maps[i].ctxt_len longest_match) {
@@ -370,7 +371,7 @@
if(strlen(uri) == uw_map-maps[i].ctxt_len) {
jk_log(l,
JK_LOG_DEBUG,
-jk_uri_worker_map_t::map_uri_to_worker, Found an exact
match %s -%s\n,
+jk_uri_worker_map_t::map_uri_to_worker, Found an exact
match %s - %s\n,
uw_map-maps[i].worker_name,
uw_map-maps[i].context );
return uw_map-maps[i].worker_name;
@@ -431,7 +432,7 @@
if(fraud = 0) {
jk_log(l, JK_LOG_EMERG,
- In jk_uri_worker_map_t::map_uri_to_worker, found a security
fraud in [%s]\n,
+ In jk_uri_worker_map_t::map_uri_to_worker, found a security
fraud in '%s'\n,
uri);
return uw_map-maps[fraud].worker_name;
}
cvs commit: jakarta-tomcat/src/native/jk jk_uri_worker_map.c
larryi 01/05/16 13:54:43
Modified:src/native/jk Tag: tomcat_32 jk_uri_worker_map.c
Log:
Fix bug in check_security_fraud() and add .suffix to .suffix. and
suffix/ already being checked.
Revision ChangesPath
No revision
No revision
1.3.2.1 +5 -4 jakarta-tomcat/src/native/jk/Attic/jk_uri_worker_map.c
Index: jk_uri_worker_map.c
===
RCS file: /home/cvs/jakarta-tomcat/src/native/jk/Attic/jk_uri_worker_map.c,v
retrieving revision 1.3
retrieving revision 1.3.2.1
diff -u -r1.3 -r1.3.2.1
--- jk_uri_worker_map.c 2000/05/29 12:53:24 1.3
+++ jk_uri_worker_map.c 2001/05/16 20:54:37 1.3.2.1
@@ -65,7 +65,7 @@
* servlet container. *
* *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.3 $ *
+ * Version: $Revision: 1.3.2.1 $ *
***/
#include jk_pool.h
@@ -111,7 +111,8 @@
* fumble and return the jsp content.
*
* To solve that we will check for path info following the suffix, we
- * will also check that the end of the uri is not .suffix.
+ * will also check that the end of the uri is not .suffix.,
+ * .suffix/, or .suffix .
*/
static int check_security_fraud(jk_uri_worker_map_t *uw_map,
const char *uri,
@@ -129,9 +130,9 @@
if('.' != *(suffix_start - 1)) {
continue;
} else {
-char *after_suffix = suffix_start +
strlen(uw_map-maps[i].suffix) + 1;
+char *after_suffix = suffix_start +
strlen(uw_map-maps[i].suffix);
-if((('.' == *after_suffix) || ('/' == *after_suffix))
+if((('.' == *after_suffix) || ('/' == *after_suffix) || (' ' ==
*after_suffix))
(0 == strncmp(uw_map-maps[i].context, uri,
uw_map-maps[i].ctxt_len))) {
/*
* Security violation !!!
Re: web_app in jakarta-tomcat-connectors ?
[EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: On Wed, 16 May 2001, Pier P. Fumagalli wrote: [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: [+1] Let's move mod_webapp and all its related stuff in jakarta-connectors. +1 The stuff is not ready ( neither the new mod_jk for 4.0 nor mod_webapp ), and when it is - tomcat-dev should decide which one will be used in 4.0. Isn't it how it works ? Yeah, however that doesn't force anyone to give up his work, or should we start debating on 3.x being a dead end??? :) :) :) I don't think there is anything to debate about that. All we know is that we have a release plan for a 3.3 release, a plan for a 4.0 release using a different code base - and commiters will decide what code base will be used for 5.0 ( it may be a completely different one - who knows ? ). Anyone is free to try new ideas - and to ignore existing code and reinvent the weels. And anyone is free to choose the codebase he thing has the best chances for long-term and work on it. But tomcat-dev must decide what is used in a certain release - and making mod_webapp the default for 4.0 is not fair. When you feel it's ready we can of course vote on it - and if indeed it's better I would be happy to use it in 3.x also. I believe mod_jk has more chances - so that's where I'll put my free development time ( if I find any :-). One cannot even write a little joke that someone will start nitpicking him... Bah... Apparently smileys got lost in my message... Pier
Re: [PATCH] configure.in for jakarta-tomcat-connectors
Clere Jean-Frederic FSC EP LP COM 5 wrote:
Hi,
I have added the detection of the JAVA_HOME and OS that will be need for the jni
connector.
It is a copy of acinclude.m4 of JServ and some improvements. ;=)
Please check it and commit it.
Cheers
Jean-frederic
Oops... I have suddenly remember that the attachement was missing.
Jean-frederic
Index: configure.in
===
RCS file: /home/cvs/mirror/jakarta-tomcat-connectors/jk/src/native/configure.in,v
retrieving revision 1.1
diff -u -r1.1 configure.in
--- configure.in2001/05/15 10:16:32 1.1
+++ configure.in2001/05/16 16:07:04
@@ -68,6 +68,179 @@
AC_MSG_RESULT(no apxs given)
])
+dnl it is copied from the configure of JServ ;=)
+dnl and adapted.
+
+dnl Find the JDK
+dnl Results go in JAVA_HOME
+dnl Also sets JAVA_PLATFORM to 1 for 1.1 and to 2 for 1.2
+
+AC_MSG_CHECKING([for JDK location (please wait)])
+
+dnl The order is: --with-java-home first, environment second, guessed value third.
+
+dnl This is a safe default. Could screw up on the security features, but
+dnl oh well, this is what --with-java2 is for.
+
+if ${TEST} -n ${JAVA_HOME} ; then
+ JAVA_HOME_ENV=${JAVA_HOME}
+else
+ JAVA_HOME_ENV=
+fi
+JAVA_HOME=
+JAVA_PLATFORM=1
+
+AC_ARG_WITH(java-home,
+[ --with-java-home=DIR Where is your JDK root directory.],
+[
+
+# This stuff works if the command line parameter --with-java-home was
+# specified, so it takes priority rightfully.
+
+JAVA_HOME=${withval}
+
+if ${TEST} ! -d ${JAVA_HOME} ; then
+AC_MSG_ERROR(Not a directory: ${JAVA_HOME})
+fi
+
+AC_MSG_RESULT(${JAVA_HOME})
+
+],
+[
+# This works if the parameter was NOT specified, so it's a good time
+# to see what the enviroment says.
+
+# Since Sun uses JAVA_HOME a lot, we check it first and ignore the
+# JAVA_HOME, otherwise just use whatever JAVA_HOME was specified.
+
+if ${TEST} -n ${JAVA_HOME_ENV} ; then
+
+JAVA_HOME=${JAVA_HOME_ENV}
+AC_MSG_RESULT(${JAVA_HOME_ENV} from environment)
+fi
+])
+
+if ${TEST} -z ${JAVA_HOME} ; then
+
+# Oh well, nobody set neither JAVA_HOME nor JAVA_HOME, have to guess
+
+# The following code is based on the code submitted by Henner Zeller
+# for ${srcdir}/src/scripts/package/rpm/ApacheJServ.spec
+
+# Two variables will be set as a result:
+#
+# JAVA_HOME
+# JAVA_PLATFORM
+AC_MSG_CHECKING([Try to guess JDK location])
+
+
+for JAVA_PREFIX in \
+ /usr/local \
+ /usr/local/lib \
+ /usr \
+ /usr/lib \
+/opt \
+ /
+do
+for JAVA_PLATFORM in 3 2 1 ;
+do
+
+for subversion in .9 .8 .7 .6 .5 .4 .3 .2 .1 ;
+do
+for VARIANT in java java- jdk jdk-;
+do
+
+GUESS=${JAVA_PREFIX}/${VARIANT}1.${JAVA_PLATFORM}${subversion}
+dnlAC_MSG_CHECKING([${GUESS}])
+
+if ${TEST} -d ${GUESS}/bin \
+ ${TEST} -d ${GUESS}/include ; then
+
+JAVA_HOME=${GUESS}
+AC_MSG_RESULT([${GUESS}])
+break
+fi
+
+done
+
+if ${TEST} -n ${JAVA_HOME} ; then
+break;
+fi
+
+done
+
+if ${TEST} -n ${JAVA_HOME} ; then
+break;
+fi
+
+done
+
+if ${TEST} -n ${JAVA_HOME} ; then
+break;
+fi
+
+done
+
+if ${TEST} -n ${JAVA_HOME} ; then
+
+dnl Just to have the messages looking uniformly
+
+AC_MSG_CHECKING(Java platform)
+AC_MSG_RESULT([guess ${JAVA_PLATFORM}])
+fi
+
+
+else
+
+AC_MSG_CHECKING(Java platform)
+
+AC_ARG_WITH(java-platform,
+[ --with-java-platform=VAL Force the Java platorm
+ (value is 1 for 1.1.x or 2 for 1.2.x or greater)],
+[
+dnl This requires a bit of tweaking to be handled properly, but
+dnl the default is good enough
+
+JAVA_PLATFORM=2
+])
+
+AC_MSG_RESULT(forced Java ${JAVA_PLATFORM})
+
+fi
+
+if ${TEST} -z ${JAVA_HOME} ; then
+
+AC_MSG_ERROR([JDK home not found, please specify one with --with-java-home option
+(run ./configure --help for more options)])
+fi
+dnl end of JServ ;=)
+AC_SUBST(JAVA_HOME)
+
+dnl guess OS = OS_TYPE for jni_md.h
+AC_ARG_WITH(os-type,
+[ --with-os-type=NAME Where is your JDK
Re: Webapp initialization (tomcat 4)
Peter Mutsaers wrote: Glenn == Glenn Nielsen [EMAIL PROTECTED] writes: Glenn Tomcat 4.0 supports JNDI and JDBC DataSource pooling. I Glenn configure a named JNDI JDBC DataSource in the Glenn DefaultContext .. /, which is then available to all web Glenn applications for a Host. Glenn Here is an example from my server.xml (sensitive paramater Glenn data replaced with generic) Thanks, this looks like the way to do it. I guess I have to put my implementing class in $CATALINA_HOME/classes? Or in $CATALINA_HOME/lib/classes?!? $CATALINA_HOME/common/lib or $CATALINA_HOME/common/classes Is this, and the Resource tag, somewhere documented? for example I'm wondering about the auth= attribute. The only docs I know of at this time are the examples in server.xml or the source. -- Peter Mutsaers | Dübendorf| UNIX - Live free or die [EMAIL PROTECTED] | Switzerland | Sent via FreeBSD 4.3-stable -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
RE: Tomcat 3.3 Milestone 3 status
Larry, I just tested this with 3.2.2b5 using Apache, mod_jk and AJP12 and the .jsp%20 problem does indeed exist. When running stand-alone the request returns a 404 error, but with mod_jk the JSP source is returned. If you could port your fix into tomcat_32 that would be great. Let me know what you find. -Original Message- From: Larry Isaacs [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 16, 2001 2:22 PM To: '[EMAIL PROTECTED]' Subject: Tomcat 3.3 Milestone 3 status Hi All, I'm in the process of preparing Tomcat 3.3 Milestone 3. Please consider the MAIN branch of jakarta-tomcat frozen for the time being. The current hold up is that mod_jk will serve JSP source for URL's that end with .jsp%20. As soon as I fix this, the Milestone 3 release will soon follow. I'll announce when Tomcat 3.3 development is unfrozen. Cheers, Larry P.S. Marc, a quick scan of mod_jk code didn't reveal differences that would suggest that mod_jk in Tomat 3.2.2 doesn't also have this problem. If there is already a fix, please let me know. Or, if not, let me know if you want me to port my fix. __ Larry Isaacs [EMAIL PROTECTED] SAS Institute Inc.
Re: Jasper performance
On Wed, 16 May 2001, Jon Stevens wrote: Costin, Once again, you impress me with your inability to understand a word of what I'm talking about. So, let me close this discussion with this: No problem, I'm not that good at explaining either. If the speed of generating a .java file (or directly to a .class file) from JSP ends up taking more resources (ie: memory) and more time after the conversion to using XSLT as the transformation step, I will forward your comments above to you again and tell you I told you so. I welcome the same response from you. And I tried to explain: the xslt transformation is not significant compared with the javac compilation ( it may add 5-10% extra ), and may end up saving the javac in some cases - which would be a significant speed improvement. And I also tried to explain: JSP doens't take more resources, a particular implementation ( generator ) may take more resources. The current java-only generator will still be available, there are many ways to compile the JSP page - and xslt has some benefits you can't get otherwise. As for your comments about Cocoon2, well, if you actually look at it, it is dog slow and *extremely* resource intensive. The only reason why there is *any* performance out of it is because there is a shit load of caching and compiled XSLT that goes on. This is something that I fear the development of JSP pages will not be able to take advantage of in the same way and as a result, development performance will suffer compared with what it is at today. Caching is good and will be done anyway ( at least for runtime ). Generating code is supposed to be resource intensive if you expect reasonable runtime performance - and I haven't heared too many people complaining Resin is too slow. I find it funny that I seem to be the only one who cares about this issue. :-) Yes, I find it funny too. Costin
cvs commit: jakarta-tomcat-connectors/jk/src/java/org/apache/ajp/tomcat4 Ajp13Request.java
seguin 01/05/16 16:23:43
Modified:jk build.xml
jk/src/java/org/apache/ajp Ajp13.java Ajp13Packet.java
AjpRequest.java
jk/src/java/org/apache/ajp/tomcat4 Ajp13Request.java
Removed: jk/src/java/org/apache/ajp MessageBytes.java
Log:
make use of new util stuff (copied from tomcat 3.3)
Revision ChangesPath
1.3 +19 -1 jakarta-tomcat-connectors/jk/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/build.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- build.xml 2001/05/15 15:20:43 1.2
+++ build.xml 2001/05/16 23:23:27 1.3
@@ -3,9 +3,11 @@
!-- = Initialize Property Values === --
property name=tomcat4.home value=../../jakarta-tomcat-4.0/build/
property name=servletapi.home value=../../jakarta-servletapi-4/dist/
+property name=tomcat-util.home value=../util/build/
property name=catalina.jar value=${tomcat4.home}/server/lib/catalina.jar/
property name=servlet.jar value=${servletapi.home}/lib/servlet.jar/
+property name=tomcat-util.jar
value=${tomcat-util.home}/lib/tomcat-util.jar/
property name=jk.build value=${basedir}/build/
@@ -19,7 +21,7 @@
javac srcdir=src/java
destdir=${jk.build}/classes
-classpath=${catalina.jar}:${servlet.jar}
+classpath=${tomcat-util.jar}:${catalina.jar}:${servlet.jar}
deprecation=on
debug=on
optimize=off
@@ -39,6 +41,22 @@
basedir=${jk.build}/classes
/
/target
+
+!-- BUILD: Create Jk Javadocs === --
+target name=javadoc
+delete dir=${jk.build}/javadoc/
+ mkdir dir=${jk.build}/javadoc/
+ javadoc packagenames=org.apache.tomcat.util.*
+ sourcepath=src/java
+ destdir=${jk.build}/javadoc
+ author=true
+ version=true
+ windowtitle=Jk Connector Documentation
+ doctitle=Jk Connector
+ bottom=Copyright #169; 2001 Apache Software Foundation. All
Rights Reserved.
+ /
+/target
+
target name=clean
delete dir=${jk.build}/
1.2 +41 -49jakarta-tomcat-connectors/jk/src/java/org/apache/ajp/Ajp13.java
Index: Ajp13.java
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/src/java/org/apache/ajp/Ajp13.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Ajp13.java2001/05/15 15:22:22 1.1
+++ Ajp13.java2001/05/16 23:23:30 1.2
@@ -66,6 +66,9 @@
import java.net.Socket;
import java.util.Enumeration;
+import org.apache.tomcat.util.buf.MessageBytes;
+import org.apache.tomcat.util.buf.ByteChunk;
+import org.apache.tomcat.util.http.MimeHeaders;
/**
* Represents a single, persistent connection between the web server and
@@ -303,25 +306,26 @@
// XXX Awful return values
boolean isSSL = false;
-int contentLength = -1;
// Translate the HTTP method code to a String.
byte methodCode = msg.getByte();
-req.method.setString(methodTransArray[(int)methodCode - 1]);
+req.method.setString( methodTransArray[(int)methodCode - 1] );
-msg.getMessageBytes(req.protocol);
+msg.getMessageBytes(req.protocol);
msg.getMessageBytes(req.requestURI);
+
msg.getMessageBytes(req.remoteAddr);
msg.getMessageBytes(req.remoteHost);
msg.getMessageBytes(req.serverName);
req.serverPort = msg.getInt();
+
isSSL = msg.getBool();
// Decode headers
+ MimeHeaders headers = req.headers;
int hCount = msg.getInt();
for(int i = 0 ; i hCount ; i++) {
-MessageBytes hName = new MessageBytes();
-MessageBytes hValue = new MessageBytes();
+String hName = null;
// Header names are encoded as either an integer code starting
// with 0xA0, or as a normal string (in which case the first
@@ -329,38 +333,28 @@
int isc = msg.peekInt();
int hId = isc 0xFF;
+ MessageBytes vMB=null;
isc = 0xFF00;
if(0xA000 == isc) {
msg.getInt(); // To advance the read position
-hName.setString(headerTransArray[hId - 1]);
+hName = headerTransArray[hId - 1];
+ vMB= headers.addValue( hName );
} else {
-msg.getMessageBytes(hName);
-
cvs commit: jakarta-tomcat/src/tests/webpages/WEB-INF test-tomcat.xml
larryi 01/05/16 17:09:09
Modified:src/tests/webpages/WEB-INF test-tomcat.xml
Log:
A few more test cases to check if JSP source is served
Revision ChangesPath
1.30 +31 -1 jakarta-tomcat/src/tests/webpages/WEB-INF/test-tomcat.xml
Index: test-tomcat.xml
===
RCS file: /home/cvs/jakarta-tomcat/src/tests/webpages/WEB-INF/test-tomcat.xml,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- test-tomcat.xml 2001/05/15 13:09:16 1.29
+++ test-tomcat.xml 2001/05/17 00:09:06 1.30
@@ -16,7 +16,7 @@
early tests.
--
- property name=revision value=$Revision: 1.29 $ /
+ property name=revision value=$Revision: 1.30 $ /
property name=host value=127.0.0.1 /
property name=port value=8080 /
property name=outputType value=text /
@@ -1114,6 +1114,36 @@
/target
target name=security_chk
+ gtest description=This URL should return 404 Not Found
+ request=GET /test/jsp/HelloWorld.jsp. HTTP/1.0
+ returnCode=${http.protocol} 404
+ /
+
+ gtest description=This URL should return 404 Not Found
+ request=GET /test/jsp/HelloWorld.jsp%2E HTTP/1.0
+ returnCode=${http.protocol} 404
+ /
+
+ gtest description=This URL should return 404 Not Found
+ request=GET /test/jsp/HelloWorld.jsp%252E HTTP/1.0
+ returnCode=${http.protocol} 404
+ /
+
+ gtest description=This URL should return 404 Not Found
+ request=GET /test/jsp/HelloWorld.jsp/ HTTP/1.0
+ returnCode=${http.protocol} 404
+ /
+
+ gtest description=This URL should return 404 Not Found
+ request=GET /test/jsp/HelloWorld.jsp%5C HTTP/1.0
+ returnCode=${http.protocol} 404
+ /
+
+ gtest description=This URL should return 404 Not Found
+ request=GET /test/jsp/HelloWorld.jsp%255C HTTP/1.0
+ returnCode=${http.protocol} 404
+ /
+
gtest description=This URL should return 404 Not Found
request=GET /test/jsp/HelloWorld.jsp%20 HTTP/1.0
returnCode=${http.protocol} 404
Re: Jasper performance
on 5/16/01 4:02 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Yet another template generation language ??? #foreach ??? Costin, what rock have you been sleeping under for the last 5 years? Velocity is simply a cleaner implementation of WebMacro. It isn't YATGL. Also, there is a reason for the #foreach... http://jakarta.apache.org/velocity/ymtd/ymtd-hosting.html Explain how you are going to fix that little problem Mr. Smart Ass. Yes, that's really humorous... but I guess I'll stick with W3C's templating language for a while :-) Oh yea, I forgot! The W3C knows everything and everything that comes from the W3C is *perfect*. XSLT is oh so great and perfect. Yea. Right. Open your eyes dude. -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ymtd/ymtd.html
Re: Jasper performance
On Wed, 16 May 2001, Jon Stevens wrote: on 5/16/01 4:02 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Yet another template generation language ??? #foreach ??? Costin, what rock have you been sleeping under for the last 5 years? Velocity is simply a cleaner implementation of WebMacro. It isn't YATGL. Sorry, from that example I didn't realized it's a webmacro ( there are not too many languages to use # this way ) - and to be honest it's not on the list of languages I use. Also, there is a reason for the #foreach... http://jakarta.apache.org/velocity/ymtd/ymtd-hosting.html Explain how you are going to fix that little problem Mr. Smart Ass. Well, ignoring the Ass part - if you are talking about allowing only a restricted set of tags and not allowing java code in the page - that can be done ( and it's not even difficult ). Yes, that's really humorous... but I guess I'll stick with W3C's templating language for a while :-) Oh yea, I forgot! The W3C knows everything and everything that comes from the W3C is *perfect*. XSLT is oh so great and perfect. Yea. Right. Open your eyes dude. Oh, yea, I forgot - you are smarter than W3C and everyone else :-) XSLT is not perfect - neither is HTTP or HTML or any other standard. But because Apache and many other organizations are implementing and using it - I think they'll be around for a while :-) Costin
Re: Jasper performance
On Wed, 16 May 2001, Jon Stevens wrote: may? Do you have empirical evidence of that or did you pull that out of your ass? I guess that concludes our discussion. Costin , and may end up saving the javac in some cases - which would be a significant speed improvement. Ah. Something else you pulled out of your ass. And I also tried to explain: JSP doens't take more resources, a particular implementation ( generator ) may take more resources. Once again, you don't listen very well. I'm not talking about JSP taking more resources, I'm talking about Jasper taking more resources. In case you missed it, Xalan is not a lightweight piece of Java code. The current java-only generator will still be available, there are many ways to compile the JSP page - and xslt has some benefits you can't get otherwise. Oh, so now you are going to support both generators? You are so amazing! Generating code is supposed to be resource intensive if you expect reasonable runtime performance Is it supposed to be more intensive than it currently is? You are talking about slowing things down at least another 5-10%...I'm sure your users will really love that. -jon
Re: Jasper performance
on 5/16/01 7:06 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Wed, 16 May 2001, Jon Stevens wrote: on 5/16/01 4:02 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Yet another template generation language ??? #foreach ??? Costin, what rock have you been sleeping under for the last 5 years? Velocity is simply a cleaner implementation of WebMacro. It isn't YATGL. Sorry, from that example I didn't realized it's a webmacro ( there are not too many languages to use # this way ) - and to be honest it's not on the list of languages I use. Once again...sleeping under a rock. if you are talking about allowing only a restricted set of tags and not allowing java code in the page - that can be done ( and it's not even difficult ). Right now? Today? Show me how you are going to implement that and not break the specification or all of the examples. Oh, yea, I forgot - you are smarter than W3C and everyone else :-) Did I say that? I don't think so. However, I am going to state that XSLT in its current form is lacking in many ways. XSLT is not perfect - neither is HTTP or HTML or any other standard. But because Apache and many other organizations are implementing and using it - I think they'll be around for a while :-) Costin Luckily Velocity also comes from the Apache Software Foundation so it will be around for a while as well. -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ymtd/ymtd.html
cvs commit: jakarta-tomcat-jasper/jasper34 - New directory
costin 01/05/16 20:18:11 jakarta-tomcat-jasper/jasper34 - New directory
cvs commit: jakarta-tomcat-jasper/jasper34/runtime - New directory
costin 01/05/16 20:18:17 jakarta-tomcat-jasper/jasper34/runtime - New directory
cvs commit: jakarta-tomcat-jasper/jasper34/runtime/org - New directory
costin 01/05/16 20:18:21 jakarta-tomcat-jasper/jasper34/runtime/org - New directory
cvs commit: jakarta-tomcat-jasper/jasper34/runtime/org/apache - New directory
costin 01/05/16 20:18:24 jakarta-tomcat-jasper/jasper34/runtime/org/apache - New directory
cvs commit: jakarta-tomcat-jasper/jasper34/runtime/org/apache/jasper34 - New directory
costin 01/05/16 20:18:27 jakarta-tomcat-jasper/jasper34/runtime/org/apache/jasper34 - New directory
cvs commit: jakarta-tomcat-jasper/jasper34/runtime/org/apache/jasper34/runtime - New directory
costin 01/05/16 20:18:31 jakarta-tomcat-jasper/jasper34/runtime/org/apache/jasper34/runtime - New directory
cvs commit: jakarta-tomcat-jasper/jasper34/runtime/org/apache/jasper34/runtime/res - New directory
costin 01/05/16 20:18:35 jakarta-tomcat-jasper/jasper34/runtime/org/apache/jasper34/runtime/res - New directory
status code 207
Hi, I need to send a status code of 207 as part of my WebDav-servlet response. But, Tomcat gives me a MissingResourceException because this status code is not defined in org.apache.core.LocalStrings.properties. How do I work around that? What is the standard way of adding custom status codes? Is there a way I can tell Tomcat to use my ResourceBundle that has this status code? snap-shot of the call-stack: java.util.MissingResourceException: Can't find resource for bundle java.util.PropertyResourceBundle, key sc.207 at java.util.ResourceBundle.getObject(ResourceBundle.java:322) at java.util.ResourceBundle.getString(ResourceBundle.java:298) at org.apache.tomcat.util.StringManager.getString(StringManager.java:136) at org.apache.tomcat.core.ResponseImpl.getMessage(ResponseImpl.java:575) at org.apache.tomcat.service.http.HttpResponseAdapter.endHeaders(HttpResponseAd apter.java:108) at org.apache.tomcat.core.BufferedServletOutputStream.sendHeaders(BufferedServl etOutputStream.java:126) at org.apache.tomcat.core.BufferedServletOutputStream.reallyFlush(BufferedServl etOutputStream.java:236) at org.apache.tomcat.core.BufferedServletOutputStream.flush(BufferedServletOutp utStream.java:230) Please mailto:[EMAIL PROTECTED] as I dont have subscription to this list. Any help is greatly appreciated. thanks a lot, Murthy
Re: [PATCH] Catalina JNDIRealm - binding as the user
My use of search then bind is searching for a non-DN user ID (like UID or mail, which is presumably unique) then binding witht he retrieved DN and password. Can you imagine making people type in X.500-style user names Martin Torgeir Veimo wrote: John Holman wrote: As said before I'd like to add the ability to search the directory for the user's dn to cover cases when a fixed pattern will not work, but will wait to see the fate of this patch before going ahead. Regarding the search, then bind authentication; what would be the suggested behaviour when there are more than one returned dn from the search? Should one try to authenticate as each of these, or automatically assume not authenticated? -- - Torgeir
Servlet Upload Data Corruption
Here's my first submission! It pertains to Tomcat-3.2.1 and looks to be
the same in 3.2.2.b4
I have some client code that sends a jar file to the servlet. The jar
file was getting corrupted. After much digging, I found a CVS commit to
Ajp13ConnectorRequest.java that mentioned a problem like this with the
doRead() method. It turns out the the same applies to the doRead(byte[],
int, int) method. The same problem exists in the Ajp12ConnectionHandler
for that byte array read. Single byte reads for both protocols work just
fine. I'm including the diffs for these classes to show what I'm talking
about. I may be called a developer now, but I'm certainly not a
commiter, so what is the procedure for getting this fix validated by
somebody else and put into the codebase?
Index: Ajp13ConnectorRequest.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic/Ajp13ConnectorRequest.java,v
retrieving revision 1.5.2.7
diff -r1.5.2.7 Ajp13ConnectorRequest.java
274c274,277
System.arraycopy(bodyBuff, pos, b, off, c);
---
//System.arraycopy(bodyBuff, pos, b, off, c);
for (int i=pos, j=off, d=c; d 0; i++, j++, d--) {
b[j] = (byte)(((char)bodyBuff[i])0xff);
}
What I've done here is to replace the array copy with a loop that does
the appropriate data conversion.
Index: Ajp12ConnectionHandler.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic/Ajp12ConnectionHandler.java,v
retrieving revision 1.28.2.4
diff -r1.28.2.4 Ajp12ConnectionHandler.java
542a543,549
public int read(byte b[], int off, int len) throws IOException {
int ret = super.read(b, off, len);
for (int i=0, j=off; ilen; i++, j++) {
b[j] = (byte)(((char)b[j])0xff);
}
return ret;
}
In this case, I over-rode the read method to convert the data after
calling the super.read
I'd like to see this stuff end up in 3.2.2.b5
Thanks,
David Kavanagh
