RE: RE: RE: Problem in Transferring session between http and https on Net scape
I think you are right. But there is already a service running on port 80. But i'm anable to find which service is running at port 80.Is there any way from where we can find which service is running on a particular port? Deepak Raina INTIQUA India B-65 Okhla Industrial Area - I New Delhi 110 020 Main: +91-11-681 2931 Fax: +91-11-681-0023 [EMAIL PROTECTED] http://www.intiqua.com > -Original Message- > From: Peter Johnson [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, May 23, 2001 11:58 AM > To: [EMAIL PROTECTED] > Subject: Re: RE: RE: Problem in Transferring session between http and > https on Net scape > > The standard ports are 80 and 443. > > I'd guess that on the production version of you app you will be running > on 80 and 443. This will only be a problem while developing. > > Peter. > > - Original Message - > From: Deepak Raina <[EMAIL PROTECTED]> > Date: Tuesday, May 22, 2001 11:23 pm > Subject: RE: RE: Problem in Transferring session between http and https > on Net scape > > > Well we are running http on 8085 and https on 8443? > >Isn't these there standard ports? > >we are trying liks this > > > >http://machineip:8085 & https://machineip:8443 > > > > > >Deepak Raina > >INTIQUA India > >B-65 Okhla Industrial Area - I > >New Delhi 110 020 > >Main: +91-11-681 2931 > >Fax: +91-11-681-0023 > >[EMAIL PROTECTED] > >http://www.intiqua.com > > > > INTIQUA India Intelligent solutions, Quality Execution Note: The information and data contained in this message (and attachments) may be privileged and confidential and protected from disclosure to any party or parties apart from the intended recipient. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.
RE: Problem in Transferring session between http and https on Net scape
I believe you are abusing [EMAIL PROTECTED] now. Go to http://jakarta.apache.org/site/mail.html and read Summary: Do not abuse resources in order to get help. Casper - Original Message - From: "Deepak Raina" <[EMAIL PROTECTED]> > I think you are right. But there is already a service running on port 80. > But i'm anable to find which service is running at port 80.Is there any way > from where we can find which service is running on a particular port? > > Deepak Raina > INTIQUA India > B-65 Okhla Industrial Area - I > New Delhi 110 020 > Main: +91-11-681 2931 > Fax: +91-11-681-0023 > [EMAIL PROTECTED] > http://www.intiqua.com >
Re: New Tomcat web site
Great job Marc! Marc Saegesser wrote: > > The jakarta-tomcat-site repository has been created and populated. The > Jakarta web site has been updated to point to the new stuff. The README.txt > file in the root directory has basic instructions. > > I claim no great ability at site design or word-smithing so consider this a > merely a jumping off point. If you see something you don't like please > change it. All Tomcat committers have access to this repository. > > Enjoy. > > Marc Saegesser -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Tomcat4 Default Error Handling
Sounds like something to add to the Tomcat 4 todo list. I see this as something that could be configurable at the , , , or . With the ability to specify a Handler or static page for both HTTP status codes and Exceptions. These could be overridden by a web applications web.xml. Regards, Glenn "Craig R. McClanahan" wrote: > > On Tue, 22 May 2001, Glenn Nielsen wrote: > > > Is there a way change the default way Tomcat 4 handles reporting of > > errors to a remote user that can be configured globally? I would > > like to set the default behaviour to something less intimidating than > > a stack trace inc ase a customer hasn't configured error handling in > > their JSP pages or web application web.xml. > > > > There isn't anything global at the moment. Part of the challenge is that > most of the things you might *like* to do are pretty application specific. > > One approach we can consider is to pull out the logic that generates the > default error pages (it's in StandardWrapperValve) into separate > system-level servlets - or something similar - that you can > configure. Then we could add a Context-level configuration property that > let you select the correct handler. > > > Regards, > > > > Glenn > > > > Craig -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Jasper performance/3.3 tag pooling
Rickard Öberg wrote: > > [EMAIL PROTECTED] wrote: > > > > We know the pool is synchronized and that may create problems under heavy > > > > load, and we know how to fix this ( by using a per/thread pool without > > > > synchronization ). > > > > > > That is one solution, but what do you do with the pool after page > > > request? > > > > I'm not sure I understand. Each thread has a number of associated objects > > that are recycled and reused - a Request object will "stick" with a > > thread. > > > > Same can be done for the tag pools - except that this may use a lot of > > memory ( but less than allocating/freeing ). It is possible to use a > > middle ground, or tune this - but for maximum performance you can have a > > local pool in each Request. > > What I was considering is this: a pool is a managed resource, since it > can shrink and grow. After a page request, you will want to reuse the > pool and its contents, but you can't stick the contents into a global > pool, because at next request how are you to know how many instances of > a tag to put in the request-associated pool. I.e., thread-associated > pools perform local optimizations per request/page, but for pools to be > of any use they need to do global optimizations, i.e. pool the tags in a > global pool. Otherwise you'll have lots of pools of tags and no way to > manage them globally. > > Example: > Page request. No pools created yet. > Page uses tag "foo" 10 times. Pool, associated with request/thread, > created containing one "foo" tag instance. > Concurrent page request with the above. > Page uses tag "foo" 5 times. Another pool, associated with > request/thread, created containing one "foo" tag instance. > Both requests end: what to do with the pools? > 1 Keep separate, each containing one instance > 2 Merge so that there is only one pool for "foo" tags > If 1, then there's no way to do proper global optimizations, i.e. say > "don't create more than x tag instances". > If 2, then at next request, what should the page associated "foo" pool > contain? 1 tag instance, 2 tag instances..? The only way to really know > is for the page to do its thing, and pull the tags from the global pool. > And then you're in "synch" land again. > > Do you understand now? I realize the above is a bit fuzzy... > > > > I hope that Costin will be able to reproduce what I found. > > > > I hope not :-) > > > > Again - thanks for doing the tests and checking the code, and hope to see > > more contributions and maybe few patches :-) > > Jasper performance is a high priority thing for us (nr 1. on our "system > performance fixing" list actually), so if possible, absolutely. I can't > say I've delved that far into Jasper yet though. It was a bit hard to > read. > > > IMHO the right answer is "depends". And it depends on the actual use case, > > on how many objects are created and where the synchronization occurs. For > > tomcat, where we expect hundred of concurent requests and each would > > create almost a hundred object ( that was the case in 3.0 ) - I doubt any > > VM could make a difference. > > Have you then considered the middle way I proposed, where each page > creates the tags it needs, but only once. In my experience, the > performance kills is in iterative and recursive use of tags, e.g.: > > > > which will create one "foo" tag per iteration in 3.2. *That's* the > biggest problem IMHO. Creating the "iterate" and "foo" tag once for that > page is not, considering that the overhead of managing pools of these > tag instances is more resource draining, and hard to do properly on a > global scale. > I just had an idea (dangerous things) regarding tag pooling optimizations. When Jasper translates a page it should be able to generate information about which tag handler classes it needs, and for each tag handler, the profile of the attribute/value pairs. At runtime Jasper could make one call to a tag pooling synchronized method to get all available instances of the tag handlers it needs. Any tag handlers/attribute profiles it couldn't obtain, it would have to create. Then it would manage its own local tag pool during the execution of the request. On termination of the request, after the page has been committed to the remote client, it would make one call to a tag pooling synchronized method to recycle/add the tag handlers it used. So there would only be 2 synchronized methods per page for implementing tag pooling regardless of how many tags are used. And you have the benifits of minimizing JVM memory usage by sharing a global JVM tag pool. Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Jasper performance/3.3 tag pooling
Glenn Nielsen wrote: > I just had an idea (dangerous things) regarding tag pooling optimizations. > > When Jasper translates a page it should be able to generate information > about which tag handler classes it needs, and for each tag handler, the > profile of the attribute/value pairs. At runtime Jasper could make one call > to a tag pooling synchronized method to get all available instances of the tag >handlers > it needs. Any tag handlers/attribute profiles it couldn't obtain, it would have > to create. Then it would manage its own local tag pool during the execution > of the request. On termination of the request, after the page has been committed > to the remote client, it would make one call to a tag pooling synchronized > method to recycle/add the tag handlers it used. So there would only be 2 > synchronized methods per page for implementing tag pooling regardless of > how many tags are used. And you have the benifits of minimizing JVM memory > usage by sharing a global JVM tag pool. I would be ok with that, as long as I can set the size of the pool to be zero, since I don't trust Java coders to outperform the optimizations done by the JVM as outlined in earlier posts. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of "Mastering RMI" Email: [EMAIL PROTECTED]
README.configure for jakarta-tomcat-connectors
Hi, I have started to write a README for the configure of the jakarta-tomcat-connectors/jk/src/native. Find it enclosed. Several features are not yet supported, but I will try to go on with --with-apache (static module). Any comments? Cheers Jean-frederic Installation It is possible to use autoconf for configuration and installation. To create jakarta-tomcat-connectors's autoconf script, you will need libtool 1.3.3 or higher, and autoconf 2.13 or newer. Those tools will not be required if you are just using a package downloaded from apache.org, they are only required for developers. To configure jakarta-tomcat-connectors run the following commands. ./autoconf (not required unless you are a developer) ./configure [autoconf arguments] [jakarta-tomcat-connectors arguments] make * make install jakarta-tomcat-connectors arguments --- JVM related parameters: --with-java-home=DIR DIR is the patch to the JDK root directory. Something like: /opt/java/jdk12 --with-os-type[=SUBDIR] SUBDIR is the os-type subdirectory, normaly configure should guess it correctly. * --with-arch-type[=SUBDIR] SUBDIR is the arch subdirectory, normaly configure should guess it correctly. --with-java-platform=VAL VAL is the Java platform 1 is 1.1.x and 2 is 1.2.x. It is guessed correctly. Apache related parameters: --with-apxs[=FILE] FILE is the location of the apxs tool. Default is finding apxs in PATH. It builds a shared Apache module. It detects automaticly the Apache version. (2.0 and 1.3) * --with-apache=DIR DIR is the path where apache sources are located. DIR is something like: /home/apache/apache_1.3.19 It builds a static Apache module. APR: * --with-apr=DIR DIR is the location of APR. APR means Apache Portable Runtime. (That is not Apache-2.0!) Note it needs a compiled APR! (for APRVARS and APR includes). APR is code is "protected" by #ifdef HAVE_APR ... #endif JNI support: * --enable-jni Build the jni_connect.so. * Not yet supported.
RE: RE: RE: Problem in Transferring session between http and http s on Net scape
Title: RE: RE: RE: Problem in Transferring session between http and http s on Net scape If you're on a Un*x box, try netstat (options may vary depending on your Unix flavour): netstat -lp (l for listening, p for which programs are listening, it relies on /etc/services though) -Original Message- From: Deepak Raina [mailto:[EMAIL PROTECTED]] Sent: 23 May 2001 08:40 To: [EMAIL PROTECTED] Subject: RE: RE: RE: Problem in Transferring session between http and http s on Net scape I think you are right. But there is already a service running on port 80. But i'm anable to find which service is running at port 80.Is there any way from where we can find which service is running on a particular port? Deepak Raina INTIQUA India B-65 Okhla Industrial Area - I New Delhi 110 020 Main: +91-11-681 2931 Fax: +91-11-681-0023 [EMAIL PROTECTED] http://www.intiqua.com > -Original Message- > From: Peter Johnson [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, May 23, 2001 11:58 AM > To: [EMAIL PROTECTED] > Subject: Re: RE: RE: Problem in Transferring session between http and > https on Net scape > > The standard ports are 80 and 443. > > I'd guess that on the production version of you app you will be running > on 80 and 443. This will only be a problem while developing. > > Peter. > > - Original Message - > From: Deepak Raina <[EMAIL PROTECTED]> > Date: Tuesday, May 22, 2001 11:23 pm > Subject: RE: RE: Problem in Transferring session between http and https > on Net scape > > > Well we are running http on 8085 and https on 8443? > > Isn't these there standard ports? > > we are trying liks this > > > > http://machineip:8085 & https://machineip:8443 > > > > > > Deepak Raina > > INTIQUA India > > B-65 Okhla Industrial Area - I > > New Delhi 110 020 > > Main: +91-11-681 2931 > > Fax: +91-11-681-0023 > > [EMAIL PROTECTED] > > http://www.intiqua.com > > > > INTIQUA India Intelligent solutions, Quality Execution Note: The information and data contained in this message (and attachments) may be privileged and confidential and protected from disclosure to any party or parties apart from the intended recipient. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. ** This e-mail (including any documents which may accompany it) contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any form of distribution, copying or use of this e-mail or the information in it or attached to it is strictly prohibited and may be unlawful. If you have received this e-mail in error please notify us immediately by e-mail to [EMAIL PROTECTED] or telephone +44 (0)207 940 1200 and delete the e-mail. Please advise immediately if you or your employer do not consent to Internet E-Mail for messages of this type. Information or opinions in this message that do not relate to the business of Windsor plc and/or subsidiary and/or associated companies shall be treated as neither given or endorsed by it. **
Tomcat 3.3 or 4.0 under Netbeans 3.2 anyone?
Is there anyone out there who has gotten Tomcat 3.3 or 4.0 working under Netbeans 3.2 IDE? It doesn't have to be very integrated with the IDE, I just want to debug my servlets, no JSP or anything... I tried, but due to the new (pretty advanced) classloading scheme, I'm not sure how to accomplish this... Can someone give some hints? Petr? Neeme
Help Anyone
I have written a Java app to change messages with an IBM server. Here´s how it works: it receives a set of parameters and makes a byte array that is sent via TCP/IP to the IBM server. If the message is accepted by the server a few seconds latter I get a repply. I have installed TomCat and it´s working great. Now here is what I would like to do (ANY HELP IS WELCOME): Create a JSP page where a user can insert some strings. Then send this strings to a bean. Now I would like my IBM Java app to go to the bean and get the stored values. Then I need it to run and get the reply from the server. After getting the reply from the IBM server I would store the results on a bean. Then I would send the stored IBM results back up to the Tomcat client. Here is where I am right now: the IBM java app is up and running. It is able to change messages with the IBM server. on the upper level I have been able to write JSP files deposit string values (inserted by the user) on a bean. I also am able to get those values. Now here is where I really need expert help: How can I run my java IBM app after depositing the values on the bean, and how can I send a reply up after getting a result from the IBM server?? Here is a ascii-matic: TomCat Client -> TomCat -> Bean now I woud go to the bean and do this: Bean -> Ibm Java App -> TCP/IP to IBM (send) then I would get a reply from the IBM server and leave the reply on another bean: Bean <- Ibm Java App <- TCP/IP to IBM (receive) And again back to the Tomcat client with a reply: TomCat Client <- TomCat <- Bean Again any kind help is welcome because I am doing this alone and I really need help. Thanks in advance. John
RE: [VOTE] Final release of Tomcat 3.2.2
I sent a vote earlier, but I don't see a copy from tomcat-dev. Sending it again in case is wasn't just my mail system that misplaced it. [X] +1. I agree with the proposal and I will help support the release. Larry > -Original Message- > From: Marc Saegesser [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 18, 2001 3:30 PM > To: [EMAIL PROTECTED] > Subject: [VOTE] Final release of Tomcat 3.2.2 > > > The latest beta cycle for Tomcat 3.2.2 has completed with no new bugs > identified. As the release manager I propose that we release > the tomcat_32 > branch as Tomcat 3.2.2. Please indicate your vote for the > release using the > ballot below. > > I will tabulate and post the results of this vote on Friday, > May 25. At > that time, if the vote has passed, I will tag, build and > distribute the > release. The vote must pass by majority approval which means > the proposal > must receive at least three +1 votes and more +1 votes than -1 votes. > > Marc Saegesser > > - > > Vote to release the tomcat_32 branch as Tomcat 3.2.2. > > [ ] +1. I agree with the proposal and I will help support > the release. > [ ] +0. I agree with the proposal but I will not be able > to help support the release. > [ ] -0. I don't agree with the proposal but I won't stop > the release. > [ ] -1. I disagree with the proposal and will explain my > reasons. > >
Re: Jasper performance/3.3 tag pooling
Glenn Nielsen wrote: [snip] > > I just had an idea (dangerous things) regarding tag pooling optimizations. > > When Jasper translates a page it should be able to generate information > about which tag handler classes it needs, and for each tag handler, the > profile of the attribute/value pairs. At runtime Jasper could make one call > to a tag pooling synchronized method to get all available instances of the tag >handlers > it needs. Any tag handlers/attribute profiles it couldn't obtain, it would have > to create. Then it would manage its own local tag pool during the execution > of the request. On termination of the request, after the page has been committed > to the remote client, it would make one call to a tag pooling synchronized > method to recycle/add the tag handlers it used. So there would only be 2 > synchronized methods per page for implementing tag pooling regardless of > how many tags are used. And you have the benifits of minimizing JVM memory > usage by sharing a global JVM tag pool. > that sparked something.. If we just bite the bullet and modify Jasper to correctly determine tag handler usage within a page (i.e. not get a new (from pool or "new") tag each time) then we can probably get the best of both worlds -- local reuse of tag handler variables (I don't like to call that a pool) plus application wide tag pooling. If application wide tag pooling is too expensive, then we can chunk it. Regardless, the per page reuse should be a big gain. Next step might be to determine if, in certain situations, we can not re-call tag setters. The spec says that attributes set should be "persistent". Rickard's test case would really benefit from setter optimization because most time was spent in body of setter methods. Any comments? btw, If i start tinkering, should I work with jasper34 or the 3.3 stuff? -casey > Regards, > > Glenn > > -- > Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| > MOREnet System Programming | * if iz ina coment. | > Missouri Research and Education Network | */ | > --
Re: Jasper performance/3.3 tag pooling
On Wed, 23 May 2001, Rickard Öberg wrote: > Jasper performance is a high priority thing for us (nr 1. on our "system > performance fixing" list actually), so if possible, absolutely. I can't > say I've delved that far into Jasper yet though. It was a bit hard to > read. I'm working on a refactoring of jasper, and "easy to read" is a big priority. It's moving a bit slower than I expected - now I'm back on planning stage after hearing so much bad things about using XSLT :-) But I think there are ways to make ( almost ) everyone happy. I hope in few weeks ( after JavaOne ) we'll have something that works for both 1.1 and 1.2 ( the first part of refactoring ), and we can start the fun part - optimizing it. > Have you then considered the middle way I proposed, where each page > creates the tags it needs, but only once. In my experience, the > performance kills is in iterative and recursive use of tags, e.g.: > > > > which will create one "foo" tag per iteration in 3.2. *That's* the > biggest problem IMHO. Creating the "iterate" and "foo" tag once for that > page is not, considering that the overhead of managing pools of these > tag instances is more resource draining, and hard to do properly on a > global scale. Yes, in-page reuse is where thread local pools would probably make the most difference. It's not only about the tag itself, it's also the ContentBody and few other internal elements that need to be recycled. ( recycling the JspWriterImpl had a very nice effect ). The main problem is to avoid one synchronized call for each tag ( "new" _is_also_ a synchronized call on most VMs - it synchronizes the heap !!! ). Tomcat3.3 has one synchronized call to get the worker thread from the pool - and that doesn't seem to show up in any performance tests. We could keep a pool of pools ( probably for each context ). The local pools can be unsynchronized - so we'll have only one sync per page. Each context will have a set of pools ( with the size == the largest number of concurent requests for that context ). And we can of course be agressive in shrinking the pools that were not used recently. We can try to do some of this in 3.3 space - or in a branch of 3.3 ( jasper34 is going to take a while, and I have a feeling you need results fast ). Regarding your application - I think we know the problem. There are few things you can do to reduce the memory use, and you could cache and recycle intermediary objects in each tag instance - you could benefit a lot from the reuse of the tags. The memory savings of the thread pooling are not helping your application yet ( since they are very small compared with the rest ), yet you pay the synchronization price ( a lot - since you make heavy use of tags ). With few changes in your app and few changes in the tag pool we could reverse the situation - but if you disable the pool there's little chance you could increase the performance above the current level. Costin
RE: Tomcat 3.3 or 4.0 under Netbeans 3.2 anyone?
ok, nevermind, I already found some help for this: http://www.netbeans.org/www-nbusers/msg06837.html Neeme > -Original Message- > From: Neeme Praks [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 23, 2001 3:13 PM > To: [EMAIL PROTECTED] > Subject: Tomcat 3.3 or 4.0 under Netbeans 3.2 anyone? > > > > Is there anyone out there who has gotten Tomcat 3.3 or 4.0 > working under > Netbeans 3.2 IDE? > It doesn't have to be very integrated with the IDE, I just > want to debug my > servlets, no JSP or anything... > > I tried, but due to the new (pretty advanced) classloading > scheme, I'm not > sure how to accomplish this... > > Can someone give some hints? Petr? > > Neeme
8 Patches for Win2k, Forte2.0 & JDK1.3.0_01
The following patches were made to get
jakarta-tomcat4.0-b5 to
compile and work properly in an environment using
Win2000,
JDK1.3.0_01 and Forte2.0 IDE.
Could an active developer please review and check
out/in the changes?
===
1) org.apache.catalina.authenticator.FormAuthenticate
The following enhancement allows the IE5.0 browser
to maintain the
correct URL in its history list. For example, if
browser fetches
'index.jsp' and tomcat returns 'login.jsp', then
when browser submits
username and password it sends a 'POST
j_security_check'. Method
'authenticate()' does its work and then restores
the original request
and returns. However, now the browser thinks that
page 'GET index.jsp'
is 'POST j_security_check' and using the
back/forward on the browser
will result in an error when we get back to the
'POST'.
My fix was to send a redirect to the original page
after authenticate
does its work.
/**
* Authenticate the user making this request,
based on the specified
* login configuration. Return true
if any specified
* constraint has been satisfied, or
false if we have
* created a response challenge already.
*
* @param request Request we are processing
* @param response Response we are creating
* @param login Login configuration describing how
authentication
* should be performed
*
* @exception IOException if an input/output error
occurs
*/
public boolean authenticate(HttpRequest request,
HttpResponse response,
LoginConfig config)
throws IOException {
. UNCHANGED .
if (restoreRequest(request, session)) {
if (debug >= 1)
log("Proceed to restored request");
/* Added code */
// If we merely serve the original
request, then IE5 browser
// shows "POST j_security_check" in
address field, and future
// "back" submits the POST rather than the
original GET.
// ToDo: the 'restoreRequest' above does
some extra/unnecessary
// work that could be cleaned up.
String uri =
hreq.getRequestURI()+"?"+hreq.getQueryString();
hres.sendRedirect(uri);
/* End added code */
return (true);// Perform
the original request
} else {
if (debug >= 1)
log("Restore of original request
failed");
hres.sendError(HttpServletResponse.SC_BAD_REQUEST);
//hres.flushBuffer();
return (false);
}
===
2) org.apache.catalina.core.ApplicationDispatcher
This implementation of RequestDispatcher makes a
call to the protected
service method of the servlet. I'm not sure why
it is doing that, but
as a servlet developer, I know I'm expecting
service calls to come
through the public method.
This change is needed to get Forte2.0 to compile
the file.
private void invoke(ServletRequest request,
ServletResponse response)
throws IOException,
ServletException {
UNCHANGED
// Call the service() method for the allocated
servlet instance
try {
if (servlet != null) {
/* REMOVED CODE ... */
/* The call to 'protected void
service(HttpServletRequest,HttpServletResponse)'
will not compile. This is a
protected method, so calls to service should go
through the public method.
Changed 5/17/01 to get it to compile.
if ((servlet instanceof
HttpServlet) &&
(hrequest != null) &&
(hresponse != null)) {
(HttpServlet
servlet).service(hrequest,hresponse);
} else {
servlet.service(request,
response);
} */
/* END REMOVED CODE */
/* added CODE */
servlet.service(request,
response);
/* END Added CODE */
}
} catch (IOException e) {
log(sm.getString("applicationDispatcher.serviceException",
wrapper.getName()), e);
ioException = e;
} catch (UnavailableException e) {
UNCHANGED
===
3) org.apache.catalina.startup.Catalina
This is an enhancement. Currently, usage is
reported if any of the
arguments are not defined, but at least one
argument is required
(eg run), and there is no usage call if no
arguments are supplied
protected boolean arguments(
Re: Tomcat 3.3 or 4.0 under Netbeans 3.2 anyone?
Neeme, I didn't try myself, but the basic scheme for debugging servlets is the following: 1) Modify the Tomcat startup script so JVM runs in the debugging mode - we use something like the following: C:\jdk1.3.1\jre\..\bin\java -classic -Xdebug -Xnoagent -Xrunjdwp:transport=d t_socket,address=pjiricka-ws:1180,suspend=y -Djava.compiler=NONE "-Xbootclasspath:C:\jdk1.3.1\jre\..\lib\tools.jar;C:\jdk1.3.1\jre\lib\rt.jar ;C:\jdk1.3.1\jre\lib\i18n.jar;C:\jdk1.3.1\jre\lib\sunrsasign.jar;C:\jdk1.3.1 \jre\classes;" ..etc, but this may differ based on your platform, JDK version etc. This involves a bit of magic, so you may have to play with it a bit. 2) Set breakpoints in the IDE where you want them 3) In NetBeans, choose Debug -> Attach, and in the "Attach" dialog choose Default Debugger (JPDA), SocketAttach, and port=1180 (the number you gave to the VM in the Xrunjdwp parameter. 4) Invoke requests from your web browser, the debugger should stop on the breakpoint. Of course there are many possible combinations, like you can use the JDK 1.1 debugging architecture (which is not as stable as JPDA, though), you can use shared memory access, etc. There is a good overview of possible options at http://java.sun.com/products/jpda/doc/conninv.html . I hope this helps. Petr - Original Message - From: "Neeme Praks" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, May 23, 2001 2:12 PM Subject: Tomcat 3.3 or 4.0 under Netbeans 3.2 anyone? > > Is there anyone out there who has gotten Tomcat 3.3 or 4.0 working under > Netbeans 3.2 IDE? > It doesn't have to be very integrated with the IDE, I just want to debug my > servlets, no JSP or anything... > > I tried, but due to the new (pretty advanced) classloading scheme, I'm not > sure how to accomplish this... > > Can someone give some hints? Petr? > > Neeme >
Re: 8 Patches for Win2k, Forte2.0 & JDK1.3.0_01
Peter Costello wrote: > > > === > 1) org.apache.catalina.authenticator.FormAuthenticate > >The following enhancement allows the IE5.0 browser > to maintain the >correct URL in its history list. For example, if > browser fetches >'index.jsp' and tomcat returns 'login.jsp', then > when browser submits >username and password it sends a 'POST > j_security_check'. Method >'authenticate()' does its work and then restores > the original request >and returns. However, now the browser thinks that > page 'GET index.jsp' >is 'POST j_security_check' and using the > back/forward on the browser >will result in an error when we get back to the > 'POST'. > >My fix was to send a redirect to the original page > after authenticate >does its work. > But what if the original request was not a GET, but rather a POST? How can you redirect to that? Cheers - Mark
Re: Jasper performance/3.3 tag pooling
On Wed, 23 May 2001, Casey Lucas wrote: > > btw, If i start tinkering, should I work with jasper34 or the 3.3 stuff? Difficult question... The problem with jasper34 is that it doesn't work yet ( the one in proposals/jasper34 - I still have to move it in the new repository ). Mea culpa - I tried to make big changes instead of the old slow evolution... I'll start importing the current jasper33 in the new repository and make sure it builds, and use it as the first step for 34. Then I'll stick with the step-by-step evolution. Merging with jasper40 and xslt can wait a bit. Costin > > -casey > > > > Regards, > > > > Glenn > > > > -- > > Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| > > MOREnet System Programming | * if iz ina coment. | > > Missouri Research and Education Network | */ | > > -- >
Re: 8 Patches for Win2k, Forte2.0 & JDK1.3.0_01
On Wed, 23 May 2001, Mark.Abbott wrote: > > > Peter Costello wrote: > > > > > > === > > 1) org.apache.catalina.authenticator.FormAuthenticate > > > >The following enhancement allows the IE5.0 browser > > to maintain the > >correct URL in its history list. For example, if > > browser fetches > >'index.jsp' and tomcat returns 'login.jsp', then > > when browser submits > >username and password it sends a 'POST > > j_security_check'. Method > >'authenticate()' does its work and then restores > > the original request > >and returns. However, now the browser thinks that > > page 'GET index.jsp' > >is 'POST j_security_check' and using the > > back/forward on the browser > >will result in an error when we get back to the > > 'POST'. > > > >My fix was to send a redirect to the original page > > after authenticate > >does its work. > > > > But what if the original request was not a GET, but rather > a POST? How can you redirect to that? > > Cheers - Mark > > > The change to use a redirect will be necessary to meet the new 2.3 spec requirements. However, Mark's point is critical -- if the original request is a POST, we still need this to work. That can be done, but it's a little more complicated than just the current patch. Craig
Re: servlet.jar and jsp.jar
On Tue, 22 May 2001, JULIEN,TIMOTHY (HP-NewJersey,ex2) wrote: > I see that Tomcat 4.0 is not yet using the new servlet.jar and jsp.jar that > were released on April 24 by SUN. > Yah, we're not. We use the one from jakarta-servletapi-4. > I think they are broken - servlet.jar is missing > javax.servlet.LocalStrings.properties, > javax.servlet.LocalStrings_es.properties, and > javax.servlet.http.LocalStrings.properties files. > > This causes javax.servlet.http.Cookie to fail to initialize at Class loading > time. > > just thought I'd bring this up since some devs on this list have some pull > with Sun > ;) > Forwarded to the correct folks to get this fixed :-). > Tim Julien > HP Middleware > Craig
cvs commit: jakarta-tomcat-4.0/jasper build.xml
craigmcc01/05/23 12:44:30 Modified:jasper build.xml Log: When revising the build procedure, I accidentally broke the copying of our special patched jaxp.jar and crimson.jar files to get around the package sealing violations. This fix restores them. Revision ChangesPath 1.19 +9 -1 jakarta-tomcat-4.0/jasper/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/jasper/build.xml,v retrieving revision 1.18 retrieving revision 1.19 diff -u -r1.18 -r1.19 --- build.xml 2001/05/22 01:59:05 1.18 +++ build.xml 2001/05/23 19:44:24 1.19 @@ -63,14 +63,22 @@ + + + + +
Re: Jasper performance/3.3 tag pooling
On Wed, 23 May 2001 [EMAIL PROTECTED] wrote:
> On Wed, 23 May 2001, Casey Lucas wrote:
>
> >
> > btw, If i start tinkering, should I work with jasper34 or the 3.3 stuff?
>
> Difficult question...
>
> The problem with jasper34 is that it doesn't work yet ( the one in
> proposals/jasper34 - I still have to move it in the new repository ). Mea
> culpa - I tried to make big changes instead of the old slow evolution...
>
> I'll start importing the current jasper33 in the new repository and make
> sure it builds, and use it as the first step for 34. Then I'll stick with
> the step-by-step evolution. Merging with jasper40 and xslt can wait a bit.
>
I know Costin loves evolutionary change :-), and it's certainly a valid
approach to Jasper.
But there is also another approach we should consider - a green-field
recoding of at least some of the major components (conforming to an
agreed-upon overall architecture, of course).
What has struck me about the custom tags pooling question is that we're
trying to make a non-optimizing compiler into an optimizing compiler "from
the ground up", rather than taking advantage of the decades of compiler
writing experience and designing one from the top down.
Just as a for instance about why we might want to consider this, let's
look at a mythical "iterate" tag with a nested tag inside:
Today, Jasper will do a "new FooTag()" plus all of the associated tag
setup, inside the loop, 1000 times. Tomorrow, using tag pooling can mean
that there will only be at most one create, but you've still got the
allocate/deallocate overhead plus the redundant setXxxx calls.
However, it's perfectly legal for the pseudo-code generated by this page
to look like this (see the examples in the JSP spec):
IterateTag iteratetag = new IterateTag(); // or allocate from a pool
iterateTag.setPageContext(...);
iterateTag.setParent(null);
iterateTag.setFrom(0);
itearteTag.setTo(999);
FooTag fooTag = new FooTag(); // Or allocate from a pool
fooTag.setPageContext(...); // Lifted out of the loop
fooTag.setParent(iterateTag); // Lifted out of the loop
fooTag.setName("bar");// Lifted out of the loop
... iterate-start implementation ... {
fooTag.setValue(expression);
fooTag.doStartTag();
fooTag.doEndTag();
} ... iterate-end implementation ...
fooTag.release();
fooTag = null; // or recycle to a pool
iterateTag.release();
iterateTag = null; // or recycle to a pool
In other words, you pay either *one* object creation or *one*
allocate/deallocate for the tag instance, and you don't waste your
time doing stuff inside the loop that only needs to be done once.
Optimizing compilers can be made smart enough to do things like this, as
long as you take the time to build in the appropriate knowledge of the
language (in this case, JSP syntax and semantics) that you are
translating. If you happened to take a compiler class along a degree
path, this kind of thing will probably look familiar.
I think we owe it to ourselves to consider whether a completely new
effort, at least for the compiler, might get us to better results
(probably with less overall development effort) than an evolutionary
approach based on the current code.
NOTE: For most of the rest of the overall problem (the PageContext
implementation, how Jasper fits in with the servlet container, and so
on) evolution is probably a very reasonable strategy. On the compiler,
though, I'm not so sure.
>
> Costin
>
Craig
Tomcat 3.2.2 problem with string resources
I just noticed that facade/RequestDispatcherImpl.java uses the strings defined in core/LocalStrings*.properties, where rdi.forward.ise is defined, but it also tries to use strings that aren't defined there. They are dispatcher.includeException dispatcher.forwardException both of which are actually defined in resources/LocalStrings*properties. I would send a patch, but I don't know if the intent is to use the strings from core or resources. To use core, the "dispatcher.includeException" and "dispatcher.forwardException" strings need to be moved into the core LocalStrings files. To use resources, the "rdi.forward.ise" needs to be moved into the resources LocalStrings files and the RequestDispatcherImpl.java needs to be modified to get a StringManager for the resources package instead of the core package. I don't think this is applicable to Tomcat 3.3 or 4.0, but maybe if there is ever a 3.2.3 release it can be included. Shawn -- Shawn McMurdo mailto:[EMAIL PROTECTED] Lutris Technologieshttp://www.lutris.com Enhydra.Orghttp://www.enhydra.org
New to Tomcat
Title: New to Tomcat Hi, I am an experienced java developer that would like to get involved in Tomcat's development. I have a couple of questions. It appears from the posts that development is mostly done in Forte's IDE. Is this correct? The bigger question, I have downloaded the source code and am currently familiarizing myself with it. Once I have done that any suggestions on where to go from there would be appreciated. Thanks.
Re: windows 2K + IIS 5.0 + cgi program + HTTP connection Keep Alive doesn't work
Scott, Thank you very much for your help! I've posted my question to both tomcat-user and tomcat-dev newsgroup before I sent to you. Here I'll tell more about my program: System: Client Firewall --- [ Web Server - cgi program - mux server ] --- Another Server the data flow for each HTTP POST request as follows (obtained from LanWatch32): The firewall(Raptor) HTTP proxy tends to send one POST request in two parts: HTTP header + HTTP content client(firewall) Web Server cgi program + mux server POST path to cgi program HTTP 1.1 other headers> Connection: Keep-Alive <--- HTTP 1.1 100 continue .. HTTP content > it may take cgi program 1ms --- 100ms to process and send back HTTP reply < HTTP 1.1 200 OK .. other headers Connection: close HTTP content It happens both on Windows NT + IIS 4.0 and on Windows 2000 Server + IIS 5.0. My program works with Apache + Linux, the connection is never closed if set accordingly. My questions are: What's the parameters related to HTTP 1.1 connection? How to change them? Appreciate very much your kind help! Xuemei - Original Message - From: Scott Stahlman <[EMAIL PROTECTED]> To: xuemei <[EMAIL PROTECTED]> Sent: Saturday, May 19, 2001 1:01 PM Subject: RE: windows 2K + IIS 5.0 + cgi program + HTTP connection Keep Alive doesn't work Sorry for the late reply. Can you post this question on the newsgroup? It would be a great help, as you can probably imagine I must account for how I spend my time and posting this to the newsgroup allows us to do that. But see if http://support.microsoft.com/support/kb/articles/Q195/1/79.asp helps you at all. Thanks, Scott -Original Message- From: xuemei [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 16, 2001 4:20 AM To: Scott Stahlman Subject: windows 2K + IIS 5.0 + cgi program + HTTP connection Keep Alive doesn't work Hi, Scott I found your email address from the IIS Newsgroup. Sorry to bother you, but I really need some help soon. I just begin to use windows 2k Server and IIS 5.0 for my cgi program. The problem is that the HTTP connection Keep Alive is ON(by default), and the POST request to my cgi program also ask for Connection: Keep-Alive, but IIS always close the connection after sending reply to each request. There's no error at all, and even data is sent back though it's expired to Sender. How can I make HTTP 1.1 persistent connection work with IIS 5.0 on Windows 2000 Server? In fact, I have same problem with IIS 4.0 on NT 4.0 Server. Thank you very very much for your kind help! Xuemei
FW: New to Tomcat
Title: FW: New to Tomcat Hi, I am an experienced java developer that would like to get involved in Tomcat's development. I have a couple of questions. It appears from the posts that development is mostly done in Forte's IDE. Is this correct? The bigger question, I have downloaded the source code and am currently familiarizing myself with it. Once I have done that any suggestions on where to go from there would be appreciated. Thanks.
Re: New to Tomcat
How to get involved -- http://jakarta.apache.org/site/getinvolved.html Amy Will Nelson wrote: > > > Hi, I am an experienced java developer that would like to get involved > in Tomcat's development. I have a couple of questions. > > It appears from the posts that development is mostly done in Forte's > IDE. Is this correct? > The bigger question, I have downloaded the source code and am > currently familiarizing myself with it. Once I have done that any > suggestions on where to go from there would be appreciated. > > Thanks.
Fw: windows 2K + IIS 5.0 + cgi program + HTTP connection Keep Alive doesn't work
Hi, The clear POST data flow is attached as a file. Thanks! Xuemei - Original Message - From: xuemei <[EMAIL PROTECTED]> To: Scott Stahlman <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, May 23, 2001 5:37 PM Subject: Re: windows 2K + IIS 5.0 + cgi program + HTTP connection Keep Alive doesn't work > Scott, > > Thank you very much for your help! > I've posted my question to both tomcat-user and tomcat-dev newsgroup before > I sent to you. > > Here I'll tell more about my program: > > System: > Client Firewall --- [ Web Server - cgi program - mux server ] --- > Another Server > > the data flow for each HTTP POST request as follows (obtained from > LanWatch32): > > The firewall(Raptor) HTTP proxy tends to send one POST request in two parts: > HTTP header + HTTP content > > > client(firewall) > Web Server cgi program + mux server > > POST path to cgi program HTTP 1.1 > other headers> > Connection: Keep-Alive > > > <--- HTTP > 1.1 100 continue > > .. > > > HTTP content > > it may take cgi program > > 1ms --- 100ms to process > > and send back HTTP reply > > > < > HTTP 1.1 200 OK > > .. other headers > > Connection: close > > HTTP content > > > > It happens both on Windows NT + IIS 4.0 and on Windows 2000 Server + IIS > 5.0. > > My program works with Apache + Linux, the connection is never closed if set > accordingly. > > My questions are: > What's the parameters related to HTTP 1.1 connection? How to change them? > > Appreciate very much your kind help! > > > Xuemei > > > > > > > > > > > > > > > > - Original Message - > From: Scott Stahlman <[EMAIL PROTECTED]> > To: xuemei <[EMAIL PROTECTED]> > Sent: Saturday, May 19, 2001 1:01 PM > Subject: RE: windows 2K + IIS 5.0 + cgi program + HTTP connection Keep Alive > doesn't work > > > Sorry for the late reply. Can you post this question on the newsgroup? > It would be a great help, as you can probably imagine I must account for > how I spend my time and posting this to the newsgroup allows us to do > that. > But see if > http://support.microsoft.com/support/kb/articles/Q195/1/79.asp helps you > at all. > > > Thanks, > Scott > > -Original Message- > From: xuemei [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 16, 2001 4:20 AM > To: Scott Stahlman > Subject: windows 2K + IIS 5.0 + cgi program + HTTP connection Keep Alive > doesn't work > > Hi, Scott > > I found your email address from the IIS Newsgroup. > Sorry to bother you, but I really need some help soon. > > I just begin to use windows 2k Server and IIS 5.0 for my cgi program. > The problem is that the HTTP connection Keep Alive is ON(by default), > and the POST request to my cgi program also ask for Connection: > Keep-Alive, > but IIS always close the connection after sending reply to each request. > There's > no error at all, and even data is sent back though it's expired to > Sender. > > How can I make HTTP 1.1 persistent connection work with IIS 5.0 on > Windows > 2000 Server? In fact, I have same problem with IIS 4.0 on NT 4.0 > Server. > > Thank you very very much for your kind help! > > Xuemei > > > > > > POSTdataflow.doc
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core ApplicationDispatcher.java
craigmcc01/05/23 14:53:02
Modified:catalina/src/share/org/apache/catalina/core
ApplicationDispatcher.java
Log:
Change the way that the servlet's service() method is invoked to match the
way this is done in ApplicationFilterChain when a top-level servlet is
called. This should avoid compiler complaints on
Win2k/Forte2.0/JDK1.3.0_01.
NOTE: Researching this issue points out a small optimization that can
take place in ApplicationFilterChain for SingleThreadModel servlets - see
next patch.
PR: Patch #2 of the "8 Patches" email on 23 May 2001
Submitted by: Peter Costello <[EMAIL PROTECTED]>
Revision ChangesPath
1.17 +10 -9
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
Index: ApplicationDispatcher.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- ApplicationDispatcher.java2001/05/12 04:56:54 1.16
+++ ApplicationDispatcher.java2001/05/23 21:53:01 1.17
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java,v
1.16 2001/05/12 04:56:54 craigmcc Exp $
- * $Revision: 1.16 $
- * $Date: 2001/05/12 04:56:54 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java,v
1.17 2001/05/23 21:53:01 craigmcc Exp $
+ * $Revision: 1.17 $
+ * $Date: 2001/05/23 21:53:01 $
*
*
*
@@ -98,7 +98,7 @@
* javax.servlet.ServletResponseWrapper.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.16 $ $Date: 2001/05/12 04:56:54 $
+ * @version $Revision: 1.17 $ $Date: 2001/05/23 21:53:01 $
*/
final class ApplicationDispatcher
@@ -561,11 +561,12 @@
// Call the service() method for the allocated servlet instance
try {
if (servlet != null) {
- if ((servlet instanceof HttpServlet) &&
- (hrequest != null) && (hresponse != null))
- ((HttpServlet) servlet).service(hrequest, hresponse);
- else
- servlet.service(request, response);
+if ((hrequest != null) && (hresponse != null)) {
+servlet.service((HttpServletRequest) request,
+(HttpServletResponse) response);
+} else {
+servlet.service(request, response);
+}
}
} catch (IOException e) {
log(sm.getString("applicationDispatcher.serviceException",
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core ApplicationFilterChain.java
craigmcc01/05/23 15:01:07
Modified:catalina/src/share/org/apache/catalina/core
ApplicationFilterChain.java
Log:
It is not necessary to synchronize the service() call of a
SingleThreadModel servlet, since StandardWrapper.allocate() already
ensured that the instance we have has not been allocated to any other
thread.
Revision ChangesPath
1.8 +7 -21
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationFilterChain.java
Index: ApplicationFilterChain.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationFilterChain.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- ApplicationFilterChain.java 2001/05/10 18:28:33 1.7
+++ ApplicationFilterChain.java 2001/05/23 22:01:05 1.8
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationFilterChain.java,v
1.7 2001/05/10 18:28:33 craigmcc Exp $
- * $Revision: 1.7 $
- * $Date: 2001/05/10 18:28:33 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationFilterChain.java,v
1.8 2001/05/23 22:01:05 craigmcc Exp $
+ * $Revision: 1.8 $
+ * $Date: 2001/05/23 22:01:05 $
*
*
*
@@ -77,7 +77,6 @@
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
-import javax.servlet.SingleThreadModel;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.catalina.InstanceEvent;
@@ -93,7 +92,7 @@
* method itself.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.7 $ $Date: 2001/05/10 18:28:33 $
+ * @version $Revision: 1.8 $ $Date: 2001/05/23 22:01:05 $
*/
final class ApplicationFilterChain implements FilterChain {
@@ -245,23 +244,10 @@
servlet);
if ((request instanceof HttpServletRequest) &&
(response instanceof HttpServletResponse)) {
-if (servlet instanceof SingleThreadModel) {
-synchronized (servlet) {
-servlet.service((HttpServletRequest) request,
-(HttpServletResponse) response);
-}
-} else {
-servlet.service((HttpServletRequest) request,
-(HttpServletResponse) response);
-}
+servlet.service((HttpServletRequest) request,
+(HttpServletResponse) response);
} else {
-if (servlet instanceof SingleThreadModel) {
-synchronized (servlet) {
-servlet.service(request, response);
-}
-} else {
-servlet.service(request, response);
-}
+servlet.service(request, response);
}
support.fireInstanceEvent(InstanceEvent.AFTER_SERVICE_EVENT,
servlet);
Re: Jasper performance/3.3 tag pooling
On Wed, 23 May 2001, Craig R. McClanahan wrote: > I know Costin loves evolutionary change :-), and it's certainly a valid > approach to Jasper. > > But there is also another approach we should consider - a green-field > recoding of at least some of the major components (conforming to an > agreed-upon overall architecture, of course). > NOTE: For most of the rest of the overall problem (the PageContext > implementation, how Jasper fits in with the servlet container, and so > on) evolution is probably a very reasonable strategy. On the compiler, > though, I'm not so sure. If we are talking about the compiler ( or code generator ): I partially agree, the current architecture will get a lot of pressure from more complex optimizations or tricks. But before we can even start to change the generator we need to do the initial refactoring and get the other components in order ( runtime, etc). We can also get some optimizations in, and use that to learn what's needed from a new generator architecture. I just don't think the new generator can happen in a 3.4 space - my goal is just to enable an effort to rewrite it, and gather as much information as possible about it's requirements. In any case - whatever happens in the current generator with regard to generated code will still be usefull for any new generator architecture. And if certain optimizations can't be done - that's even better, because it would help us understand what's needed. I had big hopes for an XSLT based generator, and I still think it may be a good way to implement the code generator - and I hope to hear other ideas. Costin
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup Catalina.java
craigmcc01/05/23 15:06:33
Modified:catalina/src/share/org/apache/catalina/startup Catalina.java
Log:
If an attempt is made to execute Catalina with no command line parameters
at all (or an unrecognized parameter), display a usage message and exit.
PR: Patch #3 of the "8 Patches" email on 23 May 2001
Submitted by: Peter Costello <[EMAIL PROTECTED]>
Revision ChangesPath
1.22 +10 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java
Index: Catalina.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- Catalina.java 2001/05/04 20:45:55 1.21
+++ Catalina.java 2001/05/23 22:06:31 1.22
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
1.21 2001/05/04 20:45:55 bip Exp $
- * $Revision: 1.21 $
- * $Date: 2001/05/04 20:45:55 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
1.22 2001/05/23 22:06:31 craigmcc Exp $
+ * $Revision: 1.22 $
+ * $Date: 2001/05/23 22:06:31 $
*
*
*
@@ -97,7 +97,7 @@
*
*
* @author Craig R. McClanahan
- * @version $Revision: 1.21 $ $Date: 2001/05/04 20:45:55 $
+ * @version $Revision: 1.22 $ $Date: 2001/05/23 22:06:31 $
*/
public class Catalina {
@@ -223,6 +223,11 @@
boolean isConfig = false;
+if (args.length < 1) {
+usage();
+return (false);
+}
+
for (int i = 0; i < args.length; i++) {
if (isConfig) {
configFile = args[i];
@@ -242,6 +247,7 @@
stopping = true;
} else {
usage();
+return (false);
}
}
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/xml XmlMapper.java
craigmcc01/05/23 15:19:52
Modified:catalina/src/share/org/apache/catalina/util/xml
XmlMapper.java
Log:
Do not print double debug messages when processing a method setter that
declares zero arguments (and thus takes its method argument from the
nested body of the current tag).
PR: Patch #4 of the "8 Patches" email on 23 May 2001
Submitted by: Peter Costello <[EMAIL PROTECTED]>
Revision ChangesPath
1.6 +2 -2
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/xml/XmlMapper.java
Index: XmlMapper.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/xml/XmlMapper.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- XmlMapper.java2000/11/24 22:36:25 1.5
+++ XmlMapper.java2001/05/23 22:19:49 1.6
@@ -873,7 +873,7 @@
}
m.invoke( parent, realParam );
- if(ctx.getDebug() > 0 ) {
+ if ((ctx.getDebug() > 0) && (paramC > 0)) {
// debug
StringBuffer sb=new StringBuffer();
sb.append("" + parent.getClass().getName() + "." + mName + "( " );
@@ -882,7 +882,7 @@
sb.append(params[i]);
}
sb.append(")");
- if( ctx.getDebug() > 0 ) ctx.log(sb.toString());
+ ctx.log(sb.toString());
}
}
}
cvs commit: jakarta-tomcat-4.0/webapps/examples/WEB-INF/classes/filters RequestDumperFilter.java
craigmcc01/05/23 15:26:19
Modified:webapps/examples/WEB-INF/classes/filters
RequestDumperFilter.java
Log:
Deal with the fact that request.getCookies() can return null.
PR: Patch #5 from the "8 Patches" message on 23 May 2001
Submitted by: Peter Costello <[EMAIL PROTECTED]>
Revision ChangesPath
1.5 +6 -4
jakarta-tomcat-4.0/webapps/examples/WEB-INF/classes/filters/RequestDumperFilter.java
Index: RequestDumperFilter.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/webapps/examples/WEB-INF/classes/filters/RequestDumperFilter.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- RequestDumperFilter.java 2001/03/17 00:39:30 1.4
+++ RequestDumperFilter.java 2001/05/23 22:26:17 1.5
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/webapps/examples/WEB-INF/classes/filters/RequestDumperFilter.java,v
1.4 2001/03/17 00:39:30 craigmcc Exp $
- * $Revision: 1.4 $
- * $Date: 2001/03/17 00:39:30 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/webapps/examples/WEB-INF/classes/filters/RequestDumperFilter.java,v
1.5 2001/05/23 22:26:17 craigmcc Exp $
+ * $Revision: 1.5 $
+ * $Date: 2001/05/23 22:26:17 $
*
*
*
@@ -89,7 +89,7 @@
* to assist in debugging problems.
*
* @author Craig McClanahan
- * @version $Revision: 1.4 $ $Date: 2001/03/17 00:39:30 $
+ * @version $Revision: 1.5 $ $Date: 2001/05/23 22:26:17 $
*/
public final class RequestDumperFilter implements Filter {
@@ -183,6 +183,8 @@
HttpServletRequest hrequest = (HttpServletRequest) request;
writer.println(" contextPath=" + hrequest.getContextPath());
Cookie cookies[] = hrequest.getCookies();
+if (cookies == null)
+cookies = new Cookie[0];
for (int i = 0; i < cookies.length; i++) {
writer.println("cookie=" + cookies[i].getName() +
"=" + cookies[i].getValue());
Re: 8 Patches for Win2k, Forte2.0 & JDK1.3.0_01
On Wed, 23 May 2001, Peter Costello wrote: > The following patches were made to get > jakarta-tomcat4.0-b5 to > compile and work properly in an environment using > Win2000, > JDK1.3.0_01 and Forte2.0 IDE. > > Could an active developer please review and check > out/in the changes? > Hi Peter, Thanks for supplying these patches. I've taken care of the easy ones (2, 3, 4, 5) and wanted to update you on the status of the others: (1) As was briefly discussed on the list, more is going to be necessary than just using a redirect in order to ensure that a POST transaction that triggers form-based login is handled correctly. I'm going to continue working on that. (6) This was recently fixed (since Beta 5), and should work correctly in recent nightly builds. You might want to wait until tonight, to make sure that the other fixes now work for you. (7) This code compiles for me on Windows using JDK 1.3.0_02 (not using Forte, but I don't think that matters). Would it be possible for you to try that version (and/or 1.3.1)? I know there were some recent bugfixes related to inner classes, and I think these were the revs that fixed them. (8) As you've observed, the code in JspServlet is a little, um, er, obtuse :-). I want to spend some more time understanding what's actually happening here before changing anything. Craig McClanahan
Re: Jasper performance/3.3 tag pooling
Costin & Craig, I agree with both of you. The optimizations that Craig mentioned are exactly the ones that I was hoping to add. Yes, the least fun part will probably be adding to the existing generator code. But, until a new generating architecture is in place, I think it would be good to go ahead and try to add the code to the existing jasper. When the next gen jasper gets a lot of momentum, we can add the tag related optimizations to it. -casey [EMAIL PROTECTED] wrote: > > On Wed, 23 May 2001, Craig R. McClanahan wrote: > > > I know Costin loves evolutionary change :-), and it's certainly a valid > > approach to Jasper. > > > > But there is also another approach we should consider - a green-field > > recoding of at least some of the major components (conforming to an > > agreed-upon overall architecture, of course). > > > NOTE: For most of the rest of the overall problem (the PageContext > > implementation, how Jasper fits in with the servlet container, and so > > on) evolution is probably a very reasonable strategy. On the compiler, > > though, I'm not so sure. > > If we are talking about the compiler ( or code generator ): I partially > agree, the current architecture will get a lot of pressure from more > complex optimizations or tricks. > > But before we can even start to change the generator we need to do the > initial refactoring and get the other components in order ( runtime, etc). > We can also get some optimizations in, and use that to learn what's needed > from a new generator architecture. > > I just don't think the new generator can happen in a 3.4 space - my goal > is just to enable an effort to rewrite it, and gather as much information > as possible about it's requirements. > > In any case - whatever happens in the current generator with regard to > generated code will still be usefull for any new generator architecture. > And if certain optimizations can't be done - that's even better, because > it would help us understand what's needed. > > I had big hopes for an XSLT based generator, and I still think it may be a > good way to implement the code generator - and I hope to hear other > ideas. > > Costin
Re: Jasper performance/3.3 tag pooling
Casey, We hope to freeze 3.3 for a release in the next weeks. If you feel the changes are reasonably small and will not create problems - you can still do it. What about: 1. We copy the code from 3.3 as it is in jasper34 area ( except that we rename the package ). 2. We make sure it builds and runs in 3.3 - with a minimal set of changes: - copy jasper34.jar in lib/container - edit server.xml and replace with 3. You can start making the optimizations, and I can start doing the refactoring, making sure we keep everything functional. 4. In time we can merge the changes from 4.0, add the new interfaces proposed by Mel, add a new generator and so on - while making sure the tests are passing and jasper is stable. This is unlikely to be finished before 3.3 is released, but we can make sure we keep passing all the test suites and we can release milestones of jasper34 for who needs the performance enhancements. When the code is ready we can make a 3.3.1 release and replace the old jasper ( and same for when ajp14 is ready ). What I tried in proposals/jasper34 is just wrong and against the basic ideas of "evolution" - and I realize that. Just give me 2 days, I need to finish with xalan ( we just had the 2.1.0 release and I need to finish my work on it ) Costin On Wed, 23 May 2001, Casey Lucas wrote: > > Costin & Craig, > > I agree with both of you. The optimizations that Craig mentioned are > exactly the ones that I was hoping to add. Yes, the least fun part > will probably be adding to the existing generator code. But, until a > new generating architecture is in place, I think it would be good to > go ahead and try to add the code to the existing jasper. > > When the next gen jasper gets a lot of momentum, we can add the > tag related optimizations to it. > > -casey > > [EMAIL PROTECTED] wrote: > > > > On Wed, 23 May 2001, Craig R. McClanahan wrote: > > > > > I know Costin loves evolutionary change :-), and it's certainly a valid > > > approach to Jasper. > > > > > > But there is also another approach we should consider - a green-field > > > recoding of at least some of the major components (conforming to an > > > agreed-upon overall architecture, of course). > > > > > NOTE: For most of the rest of the overall problem (the PageContext > > > implementation, how Jasper fits in with the servlet container, and so > > > on) evolution is probably a very reasonable strategy. On the compiler, > > > though, I'm not so sure. > > > > If we are talking about the compiler ( or code generator ): I partially > > agree, the current architecture will get a lot of pressure from more > > complex optimizations or tricks. > > > > But before we can even start to change the generator we need to do the > > initial refactoring and get the other components in order ( runtime, etc). > > We can also get some optimizations in, and use that to learn what's needed > > from a new generator architecture. > > > > I just don't think the new generator can happen in a 3.4 space - my goal > > is just to enable an effort to rewrite it, and gather as much information > > as possible about it's requirements. > > > > In any case - whatever happens in the current generator with regard to > > generated code will still be usefull for any new generator architecture. > > And if certain optimizations can't be done - that's even better, because > > it would help us understand what's needed. > > > > I had big hopes for an XSLT based generator, and I still think it may be a > > good way to implement the code generator - and I hope to hear other > > ideas. > > > > Costin >
CGI perl on Windows
Was anyone able to run CGI perl scripts on Windows via Apache successfully? I couldn't get it to work even though I have perl interpreter installed on my windows machine. I can run perl scripts fine on command line but not through CGI using Apache. I couldn't find any docs on Apache limiting this restriction on Windows either. As I am concluding CGI feature addition to Tomcat 4, I'm having problem with running perl scripts via Runtime.exec() on Windows. It works fine on Unix, however, I can't seem to create process using the perl interpreter. I get IOException error=193 which means "not a valid Win32 application." Perl interpreter is in my PATH, and works fine on command line. But why not using Runtime.exec()? What's the correct behavior for Apache? If Apache allows this limitation on Windows, then I guess it's okay to have the same limitation running CGI on tomcat as well. I'm thinking that not many people use CGI perl on Windows. Amy
Re: Jasper performance/3.3 tag pooling
I think the changes will be too big to add before the 3.3 freeze. I like your alternative and will start bashing the jsp->java files to get something optimal before changing the jasper34 generator code. I'll let you know when I have something that looks interesting so that it can be discussed before taking the time to modify the generator code. -casey [EMAIL PROTECTED] wrote: > > Casey, > > We hope to freeze 3.3 for a release in the next weeks. If you feel the > changes are reasonably small and will not create problems - you can still > do it. > > What about: > > 1. We copy the code from 3.3 as it is in jasper34 area ( except that we > rename the package ). > > 2. We make sure it builds and runs in 3.3 - with a minimal set of changes: > - copy jasper34.jar in lib/container > - edit server.xml and replace with > > 3. You can start making the optimizations, and I can start doing the > refactoring, making sure we keep everything functional. > > 4. In time we can merge the changes from 4.0, add the new interfaces > proposed by Mel, add a new generator and so on - while making sure the > tests are passing and jasper is stable. > > This is unlikely to be finished before 3.3 is released, but we can make > sure we keep passing all the test suites and we can release milestones of > jasper34 for who needs the performance enhancements. > > When the code is ready we can make a 3.3.1 release and replace the old > jasper ( and same for when ajp14 is ready ). > > What I tried in proposals/jasper34 is just wrong and against the basic > ideas of "evolution" - and I realize that. > > Just give me 2 days, I need to finish with xalan ( we just had the 2.1.0 > release and I need to finish my work on it ) > > Costin > > On Wed, 23 May 2001, Casey Lucas wrote: > > > > > Costin & Craig, > > > > I agree with both of you. The optimizations that Craig mentioned are > > exactly the ones that I was hoping to add. Yes, the least fun part > > will probably be adding to the existing generator code. But, until a > > new generating architecture is in place, I think it would be good to > > go ahead and try to add the code to the existing jasper. > > > > When the next gen jasper gets a lot of momentum, we can add the > > tag related optimizations to it. > > > > -casey > > > > [EMAIL PROTECTED] wrote: > > > > > > On Wed, 23 May 2001, Craig R. McClanahan wrote: > > > > > > > I know Costin loves evolutionary change :-), and it's certainly a valid > > > > approach to Jasper. > > > > > > > > But there is also another approach we should consider - a green-field > > > > recoding of at least some of the major components (conforming to an > > > > agreed-upon overall architecture, of course). > > > > > > > NOTE: For most of the rest of the overall problem (the PageContext > > > > implementation, how Jasper fits in with the servlet container, and so > > > > on) evolution is probably a very reasonable strategy. On the compiler, > > > > though, I'm not so sure. > > > > > > If we are talking about the compiler ( or code generator ): I partially > > > agree, the current architecture will get a lot of pressure from more > > > complex optimizations or tricks. > > > > > > But before we can even start to change the generator we need to do the > > > initial refactoring and get the other components in order ( runtime, etc). > > > We can also get some optimizations in, and use that to learn what's needed > > > from a new generator architecture. > > > > > > I just don't think the new generator can happen in a 3.4 space - my goal > > > is just to enable an effort to rewrite it, and gather as much information > > > as possible about it's requirements. > > > > > > In any case - whatever happens in the current generator with regard to > > > generated code will still be usefull for any new generator architecture. > > > And if certain optimizations can't be done - that's even better, because > > > it would help us understand what's needed. > > > > > > I had big hopes for an XSLT based generator, and I still think it may be a > > > good way to implement the code generator - and I hope to hear other > > > ideas. > > > > > > Costin > >
Re: CGI perl on Windows
i would guess the problems you are running into are related to .pl file types not being associated with the perl executable. what distribution of perl are you using? it's been a while... but the last time i installed perl on windows, i used the active state dist (http://www.activestate.com/) and i believe the installer set up the association. generally, perl dist's on windows have at the very least a script that will set up this association. i suppose you could also create the association yourself, by right-clicking on a .pl file, selecting "Open with...", then selecting the perl exe and checking the "Always use this program to open these files" checkbox. Amy Roh wrote: > > Was anyone able to run CGI perl scripts on Windows via Apache > successfully? I couldn't get it to work even though I have perl > interpreter installed on my windows machine. I can run perl scripts > fine on command line but not through CGI using Apache. I couldn't find > any docs on Apache limiting this restriction on Windows either. > > As I am concluding CGI feature addition to Tomcat 4, I'm having problem > with running perl scripts via Runtime.exec() on Windows. It works fine > on Unix, however, I can't seem to create process using the perl > interpreter. I get IOException error=193 which means "not a valid Win32 > application." Perl interpreter is in my PATH, and works fine on command > line. But why not using Runtime.exec()? > > What's the correct behavior for Apache? If Apache allows this > limitation on Windows, then I guess it's okay to have the same > limitation running CGI on tomcat as well. I'm thinking that not many > people use CGI perl on Windows. > > Amy
Re: CGI perl on Windows
Kevin, thanks for the suggestion. However, the association is already set up. I'm using the same ActivePerl from ActiveState. All my perl files with .pl have a little yellow cute symbols which mean the association is there already. Amy - Original Message - From: "kevin seguin" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, May 23, 2001 8:26 PM Subject: Re: CGI perl on Windows > i would guess the problems you are running into are related to .pl file > types not being associated with the perl executable. what distribution > of perl are you using? it's been a while... but the last time i > installed perl on windows, i used the active state dist > (http://www.activestate.com/) and i believe the installer set up the > association. generally, perl dist's on windows have at the very least a > script that will set up this association. i suppose you could also > create the association yourself, by right-clicking on a .pl file, > selecting "Open with...", then selecting the perl exe and checking the > "Always use this program to open these files" checkbox. > > Amy Roh wrote: > > > > Was anyone able to run CGI perl scripts on Windows via Apache > > successfully? I couldn't get it to work even though I have perl > > interpreter installed on my windows machine. I can run perl scripts > > fine on command line but not through CGI using Apache. I couldn't find > > any docs on Apache limiting this restriction on Windows either. > > > > As I am concluding CGI feature addition to Tomcat 4, I'm having problem > > with running perl scripts via Runtime.exec() on Windows. It works fine > > on Unix, however, I can't seem to create process using the perl > > interpreter. I get IOException error=193 which means "not a valid Win32 > > application." Perl interpreter is in my PATH, and works fine on command > > line. But why not using Runtime.exec()? > > > > What's the correct behavior for Apache? If Apache allows this > > limitation on Windows, then I guess it's okay to have the same > > limitation running CGI on tomcat as well. I'm thinking that not many > > people use CGI perl on Windows. > > > > Amy >
[PATCH] Bug fix for #1678
This is the fix for ServletInputStream.read() bug.
#1678: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1678
The change is in Ajp13ConnectorRequest.java. This one is obviously
the one which has not been tested with a binary data.
I made this patch for 3.2.1.
Index: Ajp13ConnectorRequest.java
===
RCS file:
jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Ajp13ConnectorRequest.java,v
retrieving revision 1.1
diff -u -r1.1 Ajp13ConnectorRequest.java
--- Ajp13ConnectorRequest.java 2001/05/23 22:41:09 1.1
+++ Ajp13ConnectorRequest.java 2001/05/24 06:20:53
@@ -251,8 +251,12 @@
{
if(pos >= blen) {
refeelReadBuffer();
+ if (pos>= blen) {
+ // seems no data
+ return -1;
+ }
}
-return bodyBuff[pos++];
+return bodyBuff[pos++] & 0xff;
}
public int doRead(byte[] b, int off, int len) throws IOException
@@ -261,7 +265,6 @@
for(int i = off ; i < (len + off) ; i++) {
int a = doRead();
if(-1 == a) {
-System.out.println("Y");
return i-off;
}
b[i] = (byte)a;
