AW: Tag Pooling ( was: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked
on option, can it be minimize the synchronized calls, as a example. 1. Removing synchronized methods in TagPool 2. Adding a synchronize block on top of the jspService method, that get all needed tag instances 3. normal using the instances 4. Adding a synchronize block in finally block to put back the tag instances this can simply extended to support tagpool per unique tag/attribute combination in the same context. Torsten Fohrer -Ursprüngliche Nachricht- Von: Costin Manolache [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 21. Januar 2003 01:08 An: [EMAIL PROTECTED] Betreff: Tag Pooling ( was: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked Taking Glenn's post out of thread: Glenn Nielsen wrote: Per JSP Page (current) -- The current tag pool manages one or more pools of tags on a per JSP page basis. With a synchronized method call for each get/reuse pair for a TagHandler used in the page. That page could have as many current requests as Processor threads. The TagHandlerPool's for the JSP page could grow to the point where they have as many TagHandler elements as needed to handle the maximum number of concurrent requests (Threads). If we're going to keep the current around - we should at least increase the limit. Per JSP Page Thread Local - Switching this to ThreadLocal would remove all need for synchronized access for the TagHandlerPool get/reuse but significantly increase the memory usage. You end up with a TagHandlerPool for each thread, for each JSP page. Both of these could require enoubh memory to hold the number of TagHandler classes = Number of Threads * Number of JSP pages * Number of unique TagHandlers needed per JSP A mechanism to clean up unused pools could help reduce this ( similar with ThreadPool ). ( maybe combined with some JMX to give insight into how many pools and tags are in used - quite usefull ). This is the classical memory versus time - a choice that users should make for themself, depending on the application they run. A production site with a lot of memory and very high traffic on few pages may choose the speed. There are two other options based on managing a global tag pool rather than a per JSP page tag pool. If you have many JSP pages with custom tags there will be common tags/attributes used across all of them. Why not be able to reuse these TagHandler's across all the JSP pages instead of on a per JSP page basis. This could significantly reduce the number of instances of TagHandler's which have to be pooled, and the memory the consume. Consider the JSTL c:if tag and how many times it could get used across 20 different JSP pages. If this is still thread local - I'm +0 ( i.e. I won't implement it, but I think it's a great idea ). That would make it ( threads * maxTag ), where maxTag is the maximum number of one tag in any page. It shouldn't be hard - you'll need to pass the context and keep the ThreadLocal in the context. Of course - keep in mind that you need one pool for each tag+attribute_set ( another wise requirement..) Global -- TagHandlerPool's which are global and pool all unique TagHandler classes for all JSP pages. In this case you would require one synchronized call at the start of the JSP page to populate its local pool with reusable TagHandler's from the global pool. Then on JSP page exit return the TagHandler's from its local pool to the global. Requires two synchronized method calls per JSP page execution, but mimimizes the memory footprint of pooled tags. If by global you mean cross-context - I don't think it would work ( versioning, security, etc ). Global Thread Local --- TagHandlerPool's which are global within a thread and pool all unique TagHandler classes for all JSP pages which execute within the thread. No synchronized methods would be required for this design. This would have a smaller memory footprint than the Per JSP Page (current) and Per Jsp Page Thread Local tag pools, but use more memory than the Global tag pool. Again - if by global you mean per context, +1. Per server is too dangerous ( a thread can hold on the reference for a tag and access it when it is in used in a different context ). Of the four designs above I think the Global Thread Local design may be the best. It removes the need for synchronized get/reuse and has a smaller memory footprint than the Per JSP Page tag pool design. +1 for Context Thread Local ( eventually combined with some expiration strategy ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail:
RE: Tomcat 5 target JDK1.4?
In Java, the whole point is you can go switch out a VM, at a drop of a hat. I mean, JDK 1.5 is coming out. That's just moronic and plain wrong and if you truly believe that I'm feeling sorry for you. If you'd had any experience running live servers you'd know that changing API's _always_ have consequences. I'm worried about even changing trivial things like upgrading minor versions of XML parsers. To change the VM I rely on is a serious undertaking and certainly not done at a drop of a hat. But if I am the only one asking, maybe I am drunk. The thing is go to your IDE (IDEj) and flag target 1.4, do you see all the import changes? IDE? Flag target 1.4? That says it then. The first thing I ask programmers I hire is How do you prefer to program? What is your environment like? ... If the answer is along the lines of vi, emacs, notepad, zsh, bash, windows command line, then I feel much relieved... Martin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tag reuse performance [Was: Re: DO NOT REPLY [Bug 16001] - Tag.release()not invoked]
Costin Manolache wrote: Hans Bergsten wrote: Costin Manolache wrote: [...] In an ideal world, all core tags would be recyclable and garbage-free - that may allow them to run at comparable speed with a hard-coded page. I think it's more important to implement open coding of JSTL, i.e. generate if and for statement instead of using c:if and c:forEach tag handlers. That would really make a difference for all apps that use JSTL, while the potential gains from tag handler reuse depend on a lot of factors that varies between applications and the runtime environment. +1 - open coding is far better ( for performance ). Is the API/model for portable open coding defined and stable ? That would be by far the biggest improvement in JSP performance. Kin-Man told me it wasn't done yet (he mentioned the curent methods should stay, though), unfortunately. From what he said, he needed to write more tag plugins to see if he was able to implement JSTL tags with the current API. I agree it's definitely a good way to get around the problems with tags without adding too much complexity. In the end, I decided to talk about it a bit in a chapter of my book. What's really funny is that you can get rid of the tag handler, and write only the tag plugin. That's of course, if you don't care about portability, and you have the tag plugin able to handle all forms of you tag. But for people who use regular tag handlers - I think we need to fix the tag pool, and a fixed tag pool will improve the performance significantly. And if regular tags are used, for whatever reason, recycling should be taken into account - if people care a bit about performance. +1. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Jk connector and security roles (was: DO NOT REPLY [Bug 16253] - Security roles in web.xml do not work with IIS)
Hi, Security roles in web.xml do not work with IIS Btw, I guess that it is impossible to use roles when one has apache as front end also. --- Additional Comments From [EMAIL PROTECTED] 2003-01-20 15:18 --- The idea was to use NT UserGroups as Roles, but never reached to conclusion, that is to read that Info gathered from Native-NT at Java Land ( they are transmited to tomcat over the wire but tomcat doenst get them from the AJP13 packet), and use them as roles... I already wrote a Jk2Realm, which was supposed to check that if request role is one of the groups transmitted from native side (the groups are in HttpServletRequest.getAttribute(org.apache.tomcat.jk.roles)) but then I noticed that servlet request is not available in Realm.hasRole. So, maybe the right approach would be to add role information into CoyotePrincipal and just check against that in my Jk2Realm ? Also, to make my Jk2Realm to work I had to modify mbeans-descriptors.xml under catalina - which didn't feel right because the Jk2Realm kind of belongs to jakarta-connectors, doesn't it ? I'm willing to make this work but as you can see, I need some ideas how to proceeed. Ari Suutari / Syncron Tech Oy Lappeenranta, Finland -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16290] New: - Unresolved entities in included JSP file
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16290. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16290 Unresolved entities in included JSP file Summary: Unresolved entities in included JSP file Product: Tomcat 4 Version: 4.1.18 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hello, I have a probleme with JSP pages written in XML. The entities defined in a DTD for a JSP page (i.e index.jsp) doesn't apply to pages included from this jsp (i.e menu.jsp). Nothing in JSP specification 1.2 explain how to handle this case AFAIK, but in xml, i think that the DTd must apply to all the node of the document, including the nodes added during the construction of the page by inclusion. Sample test case File test_include.jsp : ?xml version=1.0 encoding=iso-8859-1? !DOCTYPE toto [ !ENTITY nbsp #160; ] jsp:root xmlns:jsp=http://java.sun.com/JSP/Page; version=1.2 div pnbsp;/p jsp:directive.include file=test_included.jsp/ /div /jsp:root File test_included.jsp : pnbsp;/p When i access to test_include.jsp : XML Parsing Error: undefined entity Location: http://localhost:8080/test_include.jsp Line Number 1, Column 17: divp /ppnbsp;/p/div ^ I have the same error with a jsp:include markup. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Why unpackWars=true default?
Would it be better to remove unpackWARs from tomcat5 since there isn't that much of a concern for backwards compatibilty on major releases? -Tim It should always be at least an option to deploy WAR files without unpacking them. Systematically unpacking WARs would cause problems: the unpacked version is always used in preference to the packed version by Tomcat, so if unpackWARs=true, then overwriting the original .war file has no effect (because of the preference for using the directory if it exists), making upgrade deployment of webapps very problematic, leading to lots of support calls for us (I replaced the WAR file, but nothing happens!). It seems like a bad idea in many cases (obviously not all) to allow modifications within the webapp itself on production deployments (small sites and development releases of webapps are examples where this wouldn't always apply). All custom data in our apps is either stored in the user.home directory, the preferences API, JNDI, or whatever. We tend to consider the .war file like an .exe or executable JAR file. - Chris -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 5 target JDK1.4?
Howdy, The first thing I ask programmers I hire is How do you prefer to program? What is your environment like? ... If the answer is along the lines of vi, emacs, notepad, zsh, bash, windows command line, then I feel much relieved... Wow, that's kind of amazing -- I use the exact same question and like the same answers ;) Yoav Shapira Millennium ChemInformatics -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16294] New: - Configurable URL Decoding.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16294. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16294 Configurable URL Decoding. Summary: Configurable URL Decoding. Product: Tomcat 4 Version: Unknown Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Currently URLs are decoded with a hard coded UTF8 encoding. (Apparently this value is also hardcoded in several classes.) This is per se a bad thing. Additionally, there are valid reasons for wanting to use other encodings. (Cf. http://issues.apache.org/bugzilla/show_bug.cgi?id=15810). Correspondingly, catalina would profit from having a centrally configurable URL decoding. (Of course similar points apply to other cases of encoding and hard coded values in general.) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Why unpackWars=true default?
Howdy, always apply). All custom data in our apps is either stored in the user.home directory, the preferences API, JNDI, or whatever. We tend to consider the .war file like an .exe or executable JAR file. And I think this is where my interest comes from. Your considerations are exactly the opposite of Costin's (I think it was Costin anyways), who considers the .war file a *deployment* format only, like an RPM or a Windows Installer file, not to be run as an executable. I think a lot of users are confused on this point. That's not tomcat's fault by any means. I think tomcat goes above and beyond the spec with its support for packed/unpacked wars, XML app descriptors, and the whole automatic app deployment feature. Personally, I think of a .war as a deployment format. I think what the server does with it (e.g. unpack, copy into a database in Oracle iAS, etc.) is an implementation detail that users shouldn't know about. Thanks everyone for answering my original question. It was very interesting to read responses from the developers. Yoav Shapira Millennium ChemInformatics -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tag Pooling ( was: Re: DO NOT REPLY [Bug 16001] - Tag.release()not invoked
Costin Manolache wrote: Taking Glenn's post out of thread: Glenn Nielsen wrote: Per JSP Page (current) -- The current tag pool manages one or more pools of tags on a per JSP page basis. With a synchronized method call for each get/reuse pair for a TagHandler used in the page. That page could have as many current requests as Processor threads. The TagHandlerPool's for the JSP page could grow to the point where they have as many TagHandler elements as needed to handle the maximum number of concurrent requests (Threads). If we're going to keep the current around - we should at least increase the limit. Per JSP Page Thread Local - Switching this to ThreadLocal would remove all need for synchronized access for the TagHandlerPool get/reuse but significantly increase the memory usage. You end up with a TagHandlerPool for each thread, for each JSP page. Both of these could require enoubh memory to hold the number of TagHandler classes = Number of Threads * Number of JSP pages * Number of unique TagHandlers needed per JSP A mechanism to clean up unused pools could help reduce this ( similar with ThreadPool ). ( maybe combined with some JMX to give insight into how many pools and tags are in used - quite usefull ). This is the classical memory versus time - a choice that users should make for themself, depending on the application they run. A production site with a lot of memory and very high traffic on few pages may choose the speed. There are two other options based on managing a global tag pool rather than a per JSP page tag pool. If you have many JSP pages with custom tags there will be common tags/attributes used across all of them. Why not be able to reuse these TagHandler's across all the JSP pages instead of on a per JSP page basis. This could significantly reduce the number of instances of TagHandler's which have to be pooled, and the memory the consume. Consider the JSTL c:if tag and how many times it could get used across 20 different JSP pages. If this is still thread local - I'm +0 ( i.e. I won't implement it, but I think it's a great idea ). That would make it ( threads * maxTag ), where maxTag is the maximum number of one tag in any page. It shouldn't be hard - you'll need to pass the context and keep the ThreadLocal in the context. Of course - keep in mind that you need one pool for each tag+attribute_set ( another wise requirement..) Global Let me rename this: Context Global -- -- TagHandlerPool's which are global and pool all unique TagHandler classes for all JSP pages. In this case you would require one synchronized call at the start of the JSP page to populate its local pool with reusable TagHandler's from the global pool. Then on JSP page exit return the TagHandler's from its local pool to the global. Requires two synchronized method calls per JSP page execution, but mimimizes the memory footprint of pooled tags. If by global you mean cross-context - I don't think it would work ( versioning, security, etc ). No, Global means global within a single webapp but pools tags for all JSP pages within a context. There are too many problems trying to pool cross-context due to each context having its own WebappClassLoader. Global Thread Local Let me rename this: Context Global Thread Local --- --- TagHandlerPool's which are global within a thread and pool all unique TagHandler classes for all JSP pages which execute within the thread. No synchronized methods would be required for this design. This would have a smaller memory footprint than the Per JSP Page (current) and Per Jsp Page Thread Local tag pools, but use more memory than the Global tag pool. Again - if by global you mean per context, +1. Per server is too dangerous ( a thread can hold on the reference for a tag and access it when it is in used in a different context ). Yes, Global means global within a single webapp but pools tags for all JSP pages within the context. There are too many problems trying to pool cross-context due to each context having its own WebappClassLoader. Of the four designs above I think the Global Thread Local design may be the best. It removes the need for synchronized get/reuse and has a smaller memory footprint than the Per JSP Page tag pool design. +1 for Context Thread Local ( eventually combined with some expiration strategy ). Was that a +1 to the renamed Context Global Thread Local? Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Making PureTLS work
Hi, I was wondering if people among the happy few who got PureTLS (0.9b3) running with Tomcat 4.1 or 5.0 post some kind of small HOWTO. I'm running Linux (RH 7.3, with IBM 1.4.0 or Sun 1.4.1). I read on the PureTLS website (err, sorry webpage) that it supported OpenSSL certs. So I should be able to reuse the certs I generated for mod_ssl ? Anyway, that's for later. In order to avoid making mistakes, I reused the .pem files I found in the distribution. After tweaking my server.xml to point at the right files (of course, I had to read the sources to know how to do it), I got the following exceptions: - with IBM JDK: Caused by: java.lang.InternalError: java.security.NoSuchAlgorithmException: class configured for Cipher: com.ibm.crypto. provider.DESedeCipher is not a subclass of xjava.security.Cipher at COM.claymoresystems.crypto.PEMData.readPEMObject(Unknown Source) at COM.claymoresystems.crypto.EAYEncryptedPrivateKey.createPrivateKey(Unknown Source) at COM.claymoresystems.ptls.SSLContext.loadEAYKeyFile(Unknown Source) at COM.claymoresystems.ptls.SSLContext.loadEAYKeyFile(Unknown Source) at org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.init(PureTLSSocketFactory.java:165) at org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.createSocket(PureTLSSocketFactory.java:104) at org.apache.tomcat.util.net.PoolTcpEndpoint.initEndpoint(PoolTcpEndpoint.java:275) - with Sun JDK: java.io.IOException: PKCS#5: Invalid number of padding bytes at org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.init(PureTLSSocketFactory.java:175) at org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.createSocket(PureTLSSocketFactory.java:104) at org.apache.tomcat.util.net.PoolTcpEndpoint.initEndpoint(PoolTcpEndpoint.java:275) at org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:150) If PureTLS isn't compatible with IBM JVM, then fine, but I can't see its usefulness. As for the error with Sun VM, I don't know what to do (there doesn't seem to be any docs at all anywhere) ... Any ideas ? Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16297] New: - PureTLS failing to initialize
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16297. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16297 PureTLS failing to initialize Summary: PureTLS failing to initialize Product: Tomcat 4 Version: 4.1.19 Platform: PC OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: Connector:Coyote HTTP/1.1 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm running Linux (RH 7.3, with IBM 1.4.0 or Sun 1.4.1) with PureTLS 0.9b3. I read on the PureTLS website (err, sorry webpage) that it supported OpenSSL certs. So I should be able to reuse the certs I generated for mod_ssl ? Anyway, that's for later. In order to avoid making mistakes, I reused the .pem files I found in the distribution. After tweaking my server.xml to point at the right files (of course, I had to read the sources to know how to do it), I got the following exceptions: - with IBM JDK: Caused by: java.lang.InternalError: java.security.NoSuchAlgorithmException: class configured for Cipher: com.ibm.crypto. provider.DESedeCipher is not a subclass of xjava.security.Cipher at COM.claymoresystems.crypto.PEMData.readPEMObject(Unknown Source) at COM.claymoresystems.crypto.EAYEncryptedPrivateKey.createPrivateKey(Unknown Source) at COM.claymoresystems.ptls.SSLContext.loadEAYKeyFile(Unknown Source) at COM.claymoresystems.ptls.SSLContext.loadEAYKeyFile(Unknown Source) at org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.init(PureTLSSocketFactory.java:165) at org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.createSocket(PureTLSSocketFactory.java:104) at org.apache.tomcat.util.net.PoolTcpEndpoint.initEndpoint(PoolTcpEndpoint.java:275) - with Sun JDK: java.io.IOException: PKCS#5: Invalid number of padding bytes at org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.init(PureTLSSocketFactory.java:175) at org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.createSocket(PureTLSSocketFactory.java:104) at org.apache.tomcat.util.net.PoolTcpEndpoint.initEndpoint(PoolTcpEndpoint.java:275) at org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:150) The connector configuration is: Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8443 minProcessors=5 maxProcessors=75 enableLookups=true acceptCount=100 debug=0 scheme=https secure=true useURIValidationHack=false disableUploadTimeout=true Factory className=org.apache.coyote.tomcat4.CoyoteServerSocketFactory keystoreFile=conf/server.pem randomFile=conf/random.pem rootFile=conf/root.pem clientAuth=false protocol=TLS SSLImplementation=org.apache.tomcat.util.net.puretls.PureTLSImplementation/ /Connector -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] bug 14436 - RequestDispatcher Drops Query String
This is regarding (alleged) bug 14436 - RequestDispatcher Drops Query
String
Noticed 14436 in the Bug Database. We had two situations that were almost
identical. One where the resource path to dispatch to (a servlet) had its
own query string .. the JSP page that the servlet then forwarded to was
unable to see the query string from the original, dispatching request.
And one where a dynamically included JSP page was not able to see request
parameters from the page it was included in (unless they were explicitly
passed in using jsp:param).
The following patch fixed both situations, so am including it in case it's
useful for anyone else.
Whether or not it fixes 14436, or is the behavior required by the spec, is
something I haven't had time to look into. As is how far this works with
nested dispatches .. the existing code stores separate references to
appRequest, outerRequest etc .. not sure if a proper fix will need to store
appQueryString, outerQueryString, etc, rather than just concatenating them
together ?
Anyway, hope it helps :)
Cheers,
John
PS - this is the first time I've sent in a patch (or indeed contributed to
the list) so if I'm doing anything wrong please let me know. I gotta learn
(!)
Index: ApplicationDispatcher.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/co
re/ApplicationDispatcher.java,v
retrieving revision 1.30
diff -u -r1.30 ApplicationDispatcher.java
--- ApplicationDispatcher.java 9 Jun 2002 05:45:04 - 1.30
+++ ApplicationDispatcher.java 19 Jan 2003 12:16:53 -
@@ -811,7 +811,23 @@
this.outerResponse = response;
this.including = including;
+// Workaround for (alleged) bug 14436 - the resource we're
dispatching to doesn't
+// otherwise see the query string of the request we're dispatching
from ..
+if (request instanceof HttpServletRequest) {
+String requestQueryString =
((HttpServletRequest)request).getQueryString();
+
+if (requestQueryString != null) {
+if (this.queryString == null || this.queryString.length()
== 0) {
+this.queryString = requestQueryString;
+}
+else {
+this.queryString += + requestQueryString;
+}
+}
+}
}
+
/**
Hello,
I'm using TC 4.1.12 on Win 2k. I'm using the TC Coyote Connector.
I've checked the Servlet v2.3 spec and the behavior I'm seeing in TC seems
to
go against the spec. In general, the problem is that the original query
string
is not properly aggregated when a servlet is invoked using a
RequestDispatcher
where and the target servlet has its own query string. Here's an example:
I have a servlet called servletA. Let's say servletA is invoked from a
browser with this URL:
http://localhost/tst/ServletA?x=1
Within servletA we create a RequestDispatcher for servletB and then
forward
to servletB like this:
RequestDispatcher rd = request.getRequestDispatcher(servletB);
rd.forward(request, response);
In servletB, a call to request.getQueryString() returns the string
x=1.
In other words, servletB is able to see the query string used to
invoke servletA. Okay, so far, so good.
Now, here's the problem: If servletA appends a query string to servletB
when creating the RequestDispatcher like this:
RequestDispatcher rd = request.getRequestDispatcher(servletB?z=1);
servletB will only see the query string, z=1, it will *no longer* see
the x=1 query string.
What I *expect* to see in servletB is a query string x=1z=1 -- i.e.,
*both* query strings.
Let me quote from SRV.8.1.1 (Servlet 2.3): Parameters specified in the
query
string used to create the RequestDispatcher take precedence over other
parameters of the same name passed to the included servlet.
In my example, the parameter names are *not* the same (x and z) so the
z
parameter should not take precedence over x. Also, the quote above refers
to
the included servlet. I believe this generically refers to forwarded
servlets
as well. The example in the spec just happens to be using include() rather
than
forward().
Finally, I would like to mention what happens if you use the
RequestDispatcher.include() method rather than forward(). Using my example
above, if you change forward() to include(), servletB will only see the
x=1
query string. It will *never* see the z=1.
One last quote from the servlet spec (SRV.8.4.1): The request dispatching
mechanism is responsible for aggregating query string parameters when
forwarding or including responses.
So, can you confirm that this is a bug?
Thanks very much...
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6007] - JSP-servlet cache is not deleted
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6007. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6007 JSP-servlet cache is not deleted --- Additional Comments From [EMAIL PROTECTED] 2003-01-21 15:59 --- I just read this bug, and it seems that there is a simple solution. The notion of doing checksums is calculationally intensive, and therefore unacceptable, but you don't need a check sum. All you need is the date on the JSP file. Store it in a file called foo.class.jspdate and compare that date to the one on the JSP.. if it differs + or - recompile. One might even be able to add this information directly into the generated .java (and thus .class) file as a constant int where it can be checked without another file access. If the extra file access solution needs to be turned off for production make this check only happen if tomcat is started with soemthing like a -devel flag or somesuch. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 5 target JDK1.4?
This is off topic, but I do the same. Glenn Shapira, Yoav wrote: Howdy, The first thing I ask programmers I hire is How do you prefer to program? What is your environment like? ... If the answer is along the lines of vi, emacs, notepad, zsh, bash, windows command line, then I feel much relieved... Wow, that's kind of amazing -- I use the exact same question and like the same answers ;) Yoav Shapira Millennium ChemInformatics -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16299] New: - admin page gives a HTTP 500 error
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16299. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16299 admin page gives a HTTP 500 error Summary: admin page gives a HTTP 500 error Product: Tomcat 4 Version: 4.1.18 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Webapps:Administration AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have tried this with j2sdk1.4.0 and j2sdk1.4.1. I have installed Tomcat 4.1.18 Tomcat starts up fine. When i try to go to the Admin page 127.0.0.1:8080/admin, I get HTTP 500: type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception org.apache.jasper.JasperException: Unable to compile class for JSP An error occurred at line: 6 in the jsp file: /header.jsp Generated servlet error: [javac] Compiling 1 source file C:\Program Files\Apache Group\Tomcat 4.1 \work\Standalone\localhost\admin\login_jsp.java:11: cannot access java.lang.Object An error occurred at line: 6 in the jsp file: /header.jsp Generated servlet error: bad class file: C:\j2sdk1.4.0\jre\lib\rt.jar(java/lang/Object.class) class file has wrong version 48.0, should be 47.0 Please remove or make sure it appears in the correct subdirectory of the classpath. private static java.util.Vector _jspx_includes; ^ 1 error at org.apache.jasper.compiler.DefaultErrorHandler.javacError (DefaultErrorHandler.java:130) at org.apache.jasper.compiler.ErrorDispatcher.javacError (ErrorDispatcher.java:293) at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:340) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:352) at org.apache.jasper.JspCompilationContext.compile (JspCompilationContext.java:474) at org.apache.jasper.servlet.JspServletWrapper.service (JspServletWrapper.java:184) at org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServlet.java:295) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:260) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(StandardPipeline.java:643) at org.apache.catalina.authenticator.AuthenticatorBase.invoke (AuthenticatorBase.java:550) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke (StandardContext.java:2415) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke (ErrorDispatcherValve.java:170) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at
RE: Making PureTLS work
This list is for development of the Tomcat please forward to tomcat-user etc etc ;) Martin (sorry, couldn't stop myself) -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: 21 January 2003 15:04 To: Tomcat Developers List Subject: Making PureTLS work Hi, I was wondering if people among the happy few who got PureTLS (0.9b3) running with Tomcat 4.1 or 5.0 post some kind of small HOWTO. I'm running Linux (RH 7.3, with IBM 1.4.0 or Sun 1.4.1). I read on the PureTLS website (err, sorry webpage) that it supported OpenSSL certs. So I should be able to reuse the certs I generated for mod_ssl ? Anyway, that's for later. In order to avoid making mistakes, I reused the .pem files I found in the distribution. After tweaking my server.xml to point at the right files (of course, I had to read the sources to know how to do it), I got the following exceptions: - with IBM JDK: Caused by: java.lang.InternalError: java.security.NoSuchAlgorithmException: class configured for Cipher: com.ibm.crypto. provider.DESedeCipher is not a subclass of xjava.security.Cipher at COM.claymoresystems.crypto.PEMData.readPEMObject(Unknown Source) at COM.claymoresystems.crypto.EAYEncryptedPrivateKey.createPrivat eKey(Unknown Source) at COM.claymoresystems.ptls.SSLContext.loadEAYKeyFile(Unknown Source) at COM.claymoresystems.ptls.SSLContext.loadEAYKeyFile(Unknown Source) at org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.init(P ureTLSSocketFactory.java:165) at org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.create Socket(PureTLSSocketFactory.java:104) at org.apache.tomcat.util.net.PoolTcpEndpoint.initEndpoint(PoolTc pEndpoint.java:275) - with Sun JDK: java.io.IOException: PKCS#5: Invalid number of padding bytes at org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.init(P ureTLSSocketFactory.java:175) at org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.create Socket(PureTLSSocketFactory.java:104) at org.apache.tomcat.util.net.PoolTcpEndpoint.initEndpoint(PoolTc pEndpoint.java:275) at org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:150) If PureTLS isn't compatible with IBM JVM, then fine, but I can't see its usefulness. As for the error with Sun VM, I don't know what to do (there doesn't seem to be any docs at all anywhere) ... Any ideas ? Remy -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 5 target JDK1.4?
V. Cekvenich wrote: For TC 4 OK, but TC5 will have tested 4 vendors JVM 1.4. Most people run JDK 1.4 now. There is at least one person which didn't run JDK 1.4, me, since the JDK 1.4 is not available on my iSeries. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 5 target JDK1.4?
V. Cekvenich wrote: Glenn Nielsen wrote: V. Cekvenich wrote: For TC 4 OK, but TC5 will have tested 4 vendors JVM 1.4. Most people run JDK 1.4 now. Perhaps you do, but where is the data to support your claim above that most people run JDK 1.4? Going around to clients site. What are you running.. Those who have systems in production and have spent alot of time developing applications which are hosted on those systems can't do a major upgrade like JVM 1.3 - JVM 1.4 at the drop of a hat. Drop of the hat == when is TC5 due? Anyway, no one is arguing my side that we must have progress. JRockit, a popular VM is JDK 1.4. And IBM has a download that supports AS400 on 1.4, and Apple is coming out. In Java, the whole point is you can go switch out a VM, at a drop of a hat. I mean, JDK 1.5 is coming out. iSeries got support for 1.4 ? I just discovered it but I didn't see how to get it on my V5R2 and there is not a major announce of it on iseries site. BTW, why should we make JDK 1.4 mandatory ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 5 target JDK1.4?
I use Idea. I should start learning vi :-) ( well, I do use emacs and vi a lot - but not for java, so I may still have a chance ... ) Costin Glenn Nielsen wrote: This is off topic, but I do the same. Glenn Shapira, Yoav wrote: Howdy, The first thing I ask programmers I hire is How do you prefer to program? What is your environment like? ... If the answer is along the lines of vi, emacs, notepad, zsh, bash, windows command line, then I feel much relieved... Wow, that's kind of amazing -- I use the exact same question and like the same answers ;) Yoav Shapira Millennium ChemInformatics -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 3597] - Tomcat shutting down takes ages
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 21, 2003 11:00 AM To: [EMAIL PROTECTED] Subject:DO NOT REPLY [Bug 6007] - JSP-servlet cache is not deleted DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6007. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3597 --- Additional Comments From [EMAIL PROTECTED] 2003-01-21 15:59 --- I think we're experiencing something very similar to what's happened here, only to a lesser extend. We're using SUN's JVM (build 1.3.1_01) on W2K, what happened when we were trying out Tomcat 4.0.5 / 4.0.6/ 4.1.x is that when shutting down Tomcat, there would be a delay of around 30 to 40 secs. We've always used Tomcat 4.0.1 and don't have this delay issue when shutting down. We've since installed JDK1.4.1 and the delay when shutting down TC 405/406/41x no longer exists. I wonder if this relates to the same thread.interrupt() bug possibily exists in SUN's JDK131? Anybody else has had similar experience? The dillema of running JDK141 is that it has some other bugs that prevent our application from working properly. Any comments would be greatly appreciated. Jindong. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 5 target JDK1.4?
Costin Manolache wrote: I use Idea. I should start learning vi :-) ( well, I do use emacs and vi a lot - but not for java, so I may still have a chance ... ) I use vi for at least 14 years, but for java dev I turned to eclipse last year, and it's hard to reswicth to vi ;) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 5 target JDK1.4?
Martin Algesten wrote: I use vi for at least 14 years, but for java dev I turned to eclipse last year, and it's hard to reswicth to vi ;) Wow! I tried to use Borland J something or another a long time ago and got to frustrated that I didn't have control over what I was doing... what are the advantages? Very fast navigation if you work with hundreds of classes. Code completion that works ( and is context sensitive, displays param info as you type, etc ). Refactoring ( rename or move something and it'll find all usages and replace them ). Find who uses or implements something. I only used vi 12 years, and emacs for about 7 - but I don't think I can turn back. ( eclipse looks nice, but it needs real key customization. Netbeans is even nicer - but too slow for my laptop ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Jasper, JMX and JSR77
JSR77 defines a certain model - in particular a WebModule must include an attribute servlets[] that lists all the servlets in the webapp, and it also requires on JMX mbean per servlet. ( tomcat uses that to provide all kind of performance and statistical info ). The problem is - JSPs are not visible, since Jasper creates them internally. One solution is to turn JspServletWrapper into an interface, with a GenericServletWrapper impl ( the current code ) and a mechanism to create container-specific wrappers. A TomcatServletWrapper can hook JSP servlets into JMX and it may also provide future tomcat-specific optimizations ( like bypassing JspServlet - by registering the ServletWrapper directly into the mapper ). Questions: - do we want to do that ( there is some extra complexity and some work ) ? Does anyone care about JSR77 support in tomcat ? - where should TomcatServletWrapper live - jasper can have an optional dependency on catalina, or catalina can have an optional dependency on jasper. - should we extend JMX support to other jasper components - to report things like compilation times, tag pool usage, tag usage, etc ? - anyone willing to help, or I'm alone :-) ? Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
strange messages in tomcat 4.1.18
Hello, I apologize for posting this question to this group, but I have been unable to get an answer in the tomcat-user group. My catalina.out logs are full of the following messages: Jan 21, 2003 10:31:41 AM org.apache.jk.common.ChannelSocket processConnection INFO: server has been restarted or reset this connection Jan 21, 2003 10:31:42 AM org.apache.jk.common.ChannelSocket processConnection INFO: server has been restarted or reset this connection Jan 21, 2003 10:31:43 AM org.apache.jk.common.ChannelSocket processConnection INFO: server has been restarted or reset this connection Jan 21, 2003 10:31:45 AM org.apache.jk.common.ChannelSocket processConnection INFO: server has been restarted or reset this connection Jan 21, 2003 10:31:47 AM org.apache.jk.common.ChannelSocket processConnection INFO: server has been restarted or reset this connection Assuming these are non-harmful messages (are they?), is there a way to turn them off, so that they're not flooding my logs? They appear to happen everytime an apache/mod_jk/mod_jk2 worker creates a connection to Tomcat. Thanks, Raiden -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper, JMX and JSR77
I have looked at JSR 77, but not in depth. I am all for instrumenting Tomcat using JMX where it makes sense. And will help when/if I have time. Glenn Costin Manolache wrote: JSR77 defines a certain model - in particular a WebModule must include an attribute servlets[] that lists all the servlets in the webapp, and it also requires on JMX mbean per servlet. ( tomcat uses that to provide all kind of performance and statistical info ). The problem is - JSPs are not visible, since Jasper creates them internally. One solution is to turn JspServletWrapper into an interface, with a GenericServletWrapper impl ( the current code ) and a mechanism to create container-specific wrappers. A TomcatServletWrapper can hook JSP servlets into JMX and it may also provide future tomcat-specific optimizations ( like bypassing JspServlet - by registering the ServletWrapper directly into the mapper ). Questions: - do we want to do that ( there is some extra complexity and some work ) ? Does anyone care about JSR77 support in tomcat ? - where should TomcatServletWrapper live - jasper can have an optional dependency on catalina, or catalina can have an optional dependency on jasper. - should we extend JMX support to other jasper components - to report things like compilation times, tag pool usage, tag usage, etc ? - anyone willing to help, or I'm alone :-) ? Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Making PureTLS work
Eric Rescorla wrote: Remy Maucherat [EMAIL PROTECTED] writes: Hi, I was wondering if people among the happy few who got PureTLS (0.9b3) running with Tomcat 4.1 or 5.0 post some kind of small HOWTO. I'm running Linux (RH 7.3, with IBM 1.4.0 or Sun 1.4.1). I read on the PureTLS website (err, sorry webpage) that it supported OpenSSL certs. So I should be able to reuse the certs I generated for mod_ssl ? Yes. If PureTLS isn't compatible with IBM JVM, then fine, but I can't see its usefulness. It shouldn't be incompatible. What's going on here is a provider conflict. You need to ensure that Cryptix is ahead of whatever IBM provider you ahve installed. That is possible, I didn't think of setting Cryptix as endorsed. I did try it with PureTLS, though. I had similar problem with JSSE and the IBM VM. As for the error with Sun VM, I don't know what to do (there doesn't seem to be any docs at all anywhere) ... Hmmm The Sun error looks to me like a standard password conflict. Are you sure you have the right password? Mm, I'll check. Since I couldn't find what type of certificate it needed, I decided to try first with the ones included with the PureTLS distribution. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java
costin 2003/01/21 11:44:42
Modified:jasper2/src/share/org/apache/jasper JspC.java
Log:
Support for packages in precompiled servlets - otherwise all go to the
same package and we get conflicts.
Revision ChangesPath
1.21 +8 -5
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java
Index: JspC.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- JspC.java 31 Dec 2002 14:01:17 - 1.20
+++ JspC.java 21 Jan 2003 19:44:42 - 1.21
@@ -547,7 +547,10 @@
targetClassName = null;
}
if (targetPackage != null) {
-clctxt.setServletPackageName(targetPackage);
+int baseLen=jspUri.lastIndexOf(/);
+if( baseLen 0 ) baseLen=0;
+String packageSubs= jspUri.substring(0, baseLen).replace( '/', '.'
);
+clctxt.setServletPackageName( targetPackage + . + packageSubs);
}
setupContext(clctxt);
@@ -593,7 +596,7 @@
} else if (dieLevel != NO_DIE_LEVEL) {
dieOnExit = true;
}
-throw new JasperException( e );
+throw new JasperException( Error compiling + file, e );
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Making PureTLS work
Remy Maucherat [EMAIL PROTECTED] writes: Eric Rescorla wrote: If PureTLS isn't compatible with IBM JVM, then fine, but I can't see its usefulness. It shouldn't be incompatible. What's going on here is a provider conflict. You need to ensure that Cryptix is ahead of whatever IBM provider you ahve installed. That is possible, I didn't think of setting Cryptix as endorsed. I did try it with PureTLS, though. PureTLS needs Cryptix. I had similar problem with JSSE and the IBM VM. Java crypto support could be a lot better. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java
[EMAIL PROTECTED] wrote:
costin 2003/01/21 11:44:42
Modified:jasper2/src/share/org/apache/jasper JspC.java
Log:
Support for packages in precompiled servlets - otherwise all go to the
same package and we get conflicts.
Thanks for finally fixing this, but please use the patch I submitted for
BugID 14302 instead, since it handles special characters in the path
as well. The TagLibraryInfoImpl patch (same BugID) is also required to
support TLDs located in JAR files.
Hans
Revision ChangesPath
1.21 +8 -5 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java
Index: JspC.java
===
RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- JspC.java 31 Dec 2002 14:01:17 - 1.20
+++ JspC.java 21 Jan 2003 19:44:42 - 1.21
@@ -547,7 +547,10 @@
targetClassName = null;
}
if (targetPackage != null) {
-clctxt.setServletPackageName(targetPackage);
+int baseLen=jspUri.lastIndexOf(/);
+if( baseLen 0 ) baseLen=0;
+String packageSubs= jspUri.substring(0, baseLen).replace( '/', '.' );
+clctxt.setServletPackageName( targetPackage + . + packageSubs);
}
setupContext(clctxt);
@@ -593,7 +596,7 @@
} else if (dieLevel != NO_DIE_LEVEL) {
dieOnExit = true;
}
-throw new JasperException( e );
+throw new JasperException( Error compiling + file, e );
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
Hans Bergsten[EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com/
Author of O'Reilly's JavaServer Pages, covering JSP 1.2 and JSTL 1.0
Details athttp://TheJSPBook.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12196] - request.getRemoteUser() returns null for AJP request with remote username
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12196. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12196 request.getRemoteUser() returns null for AJP request with remote username --- Additional Comments From [EMAIL PROTECTED] 2003-01-21 20:26 --- I'm a bit confused about tomcatAuthentication=false. It existed as an option in the Coyote connector at least up to version 4.1.12. Remy says the workaround is to put tomcatAuthentication=false in the jk2.properties. However, Dan Dexter has reported that this doesn't work and I am using mod_jk, not jk2. How do I make getRemoteUser() to work with mod_jk and the latest versions of Tomcat using the Coyote connector? Jake -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16308] New: - Session.invalidate() does not release sessions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16308. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16308 Session.invalidate() does not release sessions Summary: Session.invalidate() does not release sessions Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi I have web application in which I have a logout page where I call session.invalidate(). This does not seem to work and session count just keeps rising as more users access the application and even if they logout the count does not go down. The session count does go down after session timeout time is reached. But still tomcat never releases memory though, it just keeps growing and ultimately crash with out of memory error. I monitored this uing tomcats manager application's manager/list call The problem here is 1. Tomcat does not release sessions that are invalidated. 2. Tomcat does not release memory after the sessions that are released after session timeouts. 3. Tomcat persists the sessions from previous run too. Please help -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 5 target JDK1.4?
I use vi for at least 14 years, but for java dev I turned to eclipse last year, and it's hard to reswicth to vi ;) Wow! I tried to use Borland J something or another a long time ago and got to frustrated that I didn't have control over what I was doing... what are the advantages? Martin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java
Sorry, I didn't see the patch - I was precompiling the admin and
hit the problem.
BTW - why don't you fix it yourself - you are committer AFAIK :-) ?
Costin
Hans Bergsten wrote:
[EMAIL PROTECTED] wrote:
costin 2003/01/21 11:44:42
Modified:jasper2/src/share/org/apache/jasper JspC.java
Log:
Support for packages in precompiled servlets - otherwise all go to the
same package and we get conflicts.
Thanks for finally fixing this, but please use the patch I submitted for
BugID 14302 instead, since it handles special characters in the path
as well. The TagLibraryInfoImpl patch (same BugID) is also required to
support TLDs located in JAR files.
Hans
Revision ChangesPath
1.21 +8 -5
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java
Index: JspC.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v
retrieving revision 1.20 retrieving revision 1.21
diff -u -r1.20 -r1.21
--- JspC.java 31 Dec 2002 14:01:17 - 1.20
+++ JspC.java 21 Jan 2003 19:44:42 - 1.21
@@ -547,7 +547,10 @@
targetClassName = null;
}
if (targetPackage != null) {
-clctxt.setServletPackageName(targetPackage);
+int baseLen=jspUri.lastIndexOf(/);
+if( baseLen 0 ) baseLen=0;
+String packageSubs= jspUri.substring(0,
baseLen).replace( '/', '.' );
+clctxt.setServletPackageName( targetPackage + . +
packageSubs);
}
setupContext(clctxt);
@@ -593,7 +596,7 @@
} else if (dieLevel != NO_DIE_LEVEL) {
dieOnExit = true;
}
-throw new JasperException( e );
+throw new JasperException( Error compiling + file, e );
}
}
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED] For additional
commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16234] - Click on the context node in administration webapps generates an error
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16234. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16234 Click on the context node in administration webapps generates an error [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2003-01-21 21:21 --- Cannot reproduce. Can anyone reproduce the error? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16234] - Click on the context node in administration webapps generates an error
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16234. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16234 Click on the context node in administration webapps generates an error --- Additional Comments From [EMAIL PROTECTED] 2003-01-21 21:35 --- I've redownloaded a version of tomcat 4.1.19 and replaced the $TOMCAT_HOME/server of my installation with the one contained in the archive, and it solved my problem... It was certainly an installation problem... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PROPOSAL] Replace Jasper's logging facility with commons-logging
Jasper currently uses its own private logging facility implemented in the org.apache.jasper.logging package. This is inconsistent with the way the other Tomcat subsystems perform logging (by leveraging the commons-logging package). Proposal is to remove org.apache.jasper.logging, and replace calls to it with calls to the commons-logging APIs. Comments? Jan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java
Costin Manolache wrote:
Sorry, I didn't see the patch - I was precompiling the admin and
hit the problem.
BTW - why don't you fix it yourself - you are committer AFAIK :-) ?
There's a simple reason: it's been so long since I was actively involved
in the development that I (a) want to lurk a bit before I start
making commits, and (b) I've lost my password/key/procedures and
haven't had the time to figure it all out again ;-)
I _will_ start committing again, but I hope you can have some patience
and apply a few patches I submit in the bug database database until
then.
Hans
Hans Bergsten wrote:
[EMAIL PROTECTED] wrote:
costin 2003/01/21 11:44:42
Modified:jasper2/src/share/org/apache/jasper JspC.java
Log:
Support for packages in precompiled servlets - otherwise all go to the
same package and we get conflicts.
Thanks for finally fixing this, but please use the patch I submitted for
BugID 14302 instead, since it handles special characters in the path
as well. The TagLibraryInfoImpl patch (same BugID) is also required to
support TLDs located in JAR files.
Hans
Revision ChangesPath
1.21 +8 -5
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java
Index: JspC.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v
retrieving revision 1.20 retrieving revision 1.21
diff -u -r1.20 -r1.21
--- JspC.java 31 Dec 2002 14:01:17 - 1.20
+++ JspC.java 21 Jan 2003 19:44:42 - 1.21
@@ -547,7 +547,10 @@
targetClassName = null;
}
if (targetPackage != null) {
-clctxt.setServletPackageName(targetPackage);
+int baseLen=jspUri.lastIndexOf(/);
+if( baseLen 0 ) baseLen=0;
+String packageSubs= jspUri.substring(0,
baseLen).replace( '/', '.' );
+clctxt.setServletPackageName( targetPackage + . +
packageSubs);
}
setupContext(clctxt);
@@ -593,7 +596,7 @@
} else if (dieLevel != NO_DIE_LEVEL) {
dieOnExit = true;
}
-throw new JasperException( e );
+throw new JasperException( Error compiling + file, e );
}
}
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED] For additional
commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
Hans Bergsten[EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com/
Author of O'Reilly's JavaServer Pages, covering JSP 1.2 and JSTL 1.0
Details athttp://TheJSPBook.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Replace Jasper's logging facility with commons-logging
Jan Luehe wrote: Jasper currently uses its own private logging facility implemented in the org.apache.jasper.logging package. This is inconsistent with the way the other Tomcat subsystems perform logging (by leveraging the commons-logging package). Proposal is to remove org.apache.jasper.logging, and replace calls to it with calls to the commons-logging APIs. Comments? +0. Do you suggest this for TC 5 only, or also for TC 4.1? Hans -- Hans Bergsten[EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com/ Author of O'Reilly's JavaServer Pages, covering JSP 1.2 and JSTL 1.0 Details athttp://TheJSPBook.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Replace Jasper's logging facility with commons-logging
Jan Luehe wrote: Jasper currently uses its own private logging facility implemented in the org.apache.jasper.logging package. This is inconsistent with the way the other Tomcat subsystems perform logging (by leveraging the commons-logging package). Proposal is to remove org.apache.jasper.logging, and replace calls to it with calls to the commons-logging APIs. Comments? Finally... Thanks Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Replace Jasper's logging facility with commons-logging
Hans, Jasper currently uses its own private logging facility implemented in the org.apache.jasper.logging package. This is inconsistent with the way the other Tomcat subsystems perform logging (by leveraging the commons-logging package). Proposal is to remove org.apache.jasper.logging, and replace calls to it with calls to the commons-logging APIs. Comments? +0. Do you suggest this for TC 5 only, or also for TC 4.1? Mainly for TC 5, but if there is enough interest, I can apply the changes to TC 4.1 as well. Jan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Replace Jasper's logging facility with commons-logging
Jasper currently uses its own private logging facility implemented in the org.apache.jasper.logging package. This is inconsistent with the way the other Tomcat subsystems perform logging (by leveraging the commons-logging package). Proposal is to remove org.apache.jasper.logging, and replace calls to it with calls to the commons-logging APIs. Comments? +1 Amy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java
costin 2003/01/21 14:49:53
Modified:jasper2/src/share/org/apache/jasper JspC.java
Log:
Use Hans version of the patch.
Revision ChangesPath
1.22 +118 -67
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java
Index: JspC.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- JspC.java 21 Jan 2003 19:44:42 - 1.21
+++ JspC.java 21 Jan 2003 22:49:53 - 1.22
@@ -4,10 +4,10 @@
* $Date$
*
*
- *
+ *
* The Apache Software License, Version 1.1
*
- * Copyright (c) 1999 The Apache Software Foundation. All rights
+ * Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -15,7 +15,7 @@
* are met:
*
* 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
+ *notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
@@ -23,15 +23,15 @@
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
- *any, must include the following acknowlegement:
- * This product includes software developed by the
+ *any, must include the following acknowlegement:
+ * This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Tomcat, and Apache Software
*Foundation must not be used to endorse or promote products derived
- *from this software without prior written permission. For written
+ *from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
@@ -57,7 +57,7 @@
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
- */
+ */
package org.apache.jasper;
@@ -78,7 +78,7 @@
import org.apache.jasper.compiler.TagPluginManager;
/**
- * Shell for the jspc compiler. Handles all options associated with the
+ * Shell for the jspc compiler. Handles all options associated with the
* command line and creates compilation contexts which it then compiles
* according to the specified options.
*
@@ -99,11 +99,11 @@
lt;path refid=myjars/gt;
lt;/classpathgt;
lt;/taskdefgt;
-
-lt;jasper2 verbose=0
+
+lt;jasper2 verbose=0
package=my.package
uriroot=${webapps.dir}/${webapp.name}
- webXmlFragment=${build.dir}/generated_web.xml
+ webXmlFragment=${build.dir}/generated_web.xml
outputDir=${webapp.dir}/${webapp.name}/WEB-INF/src/my/package /gt;
/pre
*
@@ -113,9 +113,9 @@
*/
public class JspC implements Options {
-public static final String DEFAULT_IE_CLASS_ID =
+public static final String DEFAULT_IE_CLASS_ID =
clsid:8AD9C840-044E-11D1-B3E9-00805F499D93;
-
+
public static final String SWITCH_VERBOSE = -v;
public static final String SWITCH_QUIET = -q;
public static final String SWITCH_OUTPUT_DIR = -d;
@@ -148,8 +148,8 @@
// future direction
//public static final String SWITCH_XML_OUTPUT = -xml;
-
-
+
+
boolean largeFile = false;
boolean mappedFile = false;
@@ -160,7 +160,7 @@
String ieClassId = DEFAULT_IE_CLASS_ID;
String targetPackage;
-
+
String targetClassName;
String uriBase;
@@ -174,11 +174,11 @@
boolean compile=false;
String compiler=null;
-
+
boolean dirset;
-
+
boolean classDebugInfo=true;
-
+
Vector extensions;
Vector pages = new Vector();
@@ -193,7 +193,7 @@
static PrintStream log;
JspCServletContext context;
-
+
/**
* Cache for the TLD locations
*/
@@ -209,7 +209,7 @@
// isn't this why we are running jspc?
return true;
}
-
+
public boolean getLargeFile() {
return largeFile;
}
@@ -233,7 +233,7 @@
public Object getProtectionDomain() {
return null;
}
Re: Tomcat 5 target JDK1.4?
iSeris has JDK 1.4 download from IBM, that is my point. (BEA, and Apple have it as well so we have multi source). Today when you download Tomcat 4 you have the 1.4 LE edition just loook at the site Also downloading a jar, ex: http://jdbc.postgresql.org/download.html have 1.4 required. Today! TC5 is ways of. And I think everyone can agree that JDK1.4 is more stable than 1.3. .V Henri Gomez wrote: V. Cekvenich wrote: For TC 4 OK, but TC5 will have tested 4 vendors JVM 1.4. Most people run JDK 1.4 now. There is at least one person which didn't run JDK 1.4, me, since the JDK 1.4 is not available on my iSeries. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/admin/defaultcontext defaultcontext.jsp
amyroh 2003/01/21 15:16:37 Modified:webapps/admin/defaultcontext defaultcontext.jsp Log: Complete the accessibility requirement for section 508. Revision ChangesPath 1.3 +27 -27 jakarta-tomcat-4.0/webapps/admin/defaultcontext/defaultcontext.jsp Index: defaultcontext.jsp === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/defaultcontext/defaultcontext.jsp,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- defaultcontext.jsp19 Sep 2002 22:56:05 - 1.2 +++ defaultcontext.jsp21 Jan 2003 23:16:37 - 1.3 @@ -37,9 +37,9 @@ /logic:equal /div /td - td width=19% -div align=right - controls:actions + td align=right nowrap +div class=page-title-text + controls:actions label=Default Context Actions controls:action selected=true bean:message key=actions.available.actions/ /controls:action controls:action disabled=true - /controls:action /controls:actions @@ -68,10 +68,10 @@ controls:databean:message key=service.value//controls:data /controls:row -controls:row labelStyle=table-label-text dataStyle=table-normal-text +controls:row labelStyle=table-label-text dataStyle=table-normal-text styleId=cookies controls:labelbean:message key=context.cookies/:/controls:label controls:data -html:select property=cookies +html:select property=cookies styleId=cookies bean:define id=booleanVals name=defaultContextForm property=booleanVals/ html:options collection=booleanVals property=value labelProperty=label/ @@ -79,10 +79,10 @@ /controls:data /controls:row -controls:row labelStyle=table-label-text dataStyle=table-normal-text +controls:row labelStyle=table-label-text dataStyle=table-normal-text styleId=crosscontext controls:labelbean:message key=context.cross.context/:/controls:label controls:data -html:select property=crossContext +html:select property=crossContext styleId=crosscontext bean:define id=booleanVals name=defaultContextForm property=booleanVals/ html:options collection=booleanVals property=value labelProperty=label/ @@ -90,10 +90,10 @@ /controls:data /controls:row - controls:row labelStyle=table-label-text dataStyle=table-normal-text + controls:row labelStyle=table-label-text dataStyle=table-normal-text styleId=reloadable controls:labelbean:message key=context.reloadable/:/controls:label controls:data -html:select property=reloadable +html:select property=reloadable styleId=reloadable bean:define id=booleanVals name=defaultContextForm property=booleanVals/ html:options collection=booleanVals property=value labelProperty=label/ @@ -101,10 +101,10 @@ /controls:data /controls:row - controls:row labelStyle=table-label-text dataStyle=table-normal-text + controls:row labelStyle=table-label-text dataStyle=table-normal-text styleId=swallowoutput controls:labelbean:message key=context.swallowOutput/:/controls:label controls:data -html:select property=swallowOutput +html:select property=swallowOutput styleId=swallowoutput bean:define id=booleanVals name=defaultContextForm property=booleanVals/ html:options collection=booleanVals property=value labelProperty=label/ @@ -112,10 +112,10 @@ /controls:data /controls:row - controls:row labelStyle=table-label-text dataStyle=table-normal-text + controls:row labelStyle=table-label-text dataStyle=table-normal-text styleId=usenaming controls:labelbean:message key=context.usenaming/:/controls:label controls:data -html:select property=useNaming +html:select property=useNaming styleId=usenaming bean:define id=booleanVals name=defaultContextForm property=booleanVals/ html:options collection=booleanVals property=value labelProperty=label/ @@ -147,17 +147,17 @@ controls:databean:message key=service.value//controls:data /controls:row -controls:row labelStyle=table-label-text dataStyle=table-normal-text
cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.1.txt
amyroh 2003/01/21 15:19:56 Modified:.RELEASE-NOTES-4.1.txt Log: Tomcat 4 admin webapp is now accessible and passes section 508. Revision ChangesPath 1.51 +4 -1 jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt Index: RELEASE-NOTES-4.1.txt === RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt,v retrieving revision 1.50 retrieving revision 1.51 diff -u -r1.50 -r1.51 --- RELEASE-NOTES-4.1.txt 17 Jan 2003 10:09:29 - 1.50 +++ RELEASE-NOTES-4.1.txt 21 Jan 2003 23:19:56 - 1.51 @@ -62,6 +62,9 @@ [4.1.19] Documentation: Added printer friendly versions of the documents. +[4.1.19] Administration Webapp: + Complete the accessibility requirements to pass section 508. + - Catalina New Features: - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java
costin 2003/01/21 15:24:51
Modified:jasper2/src/share/org/apache/jasper JspC.java
Log:
Use the patch submited by Hans ( at least the part related to package ).
I modified it so that if a package is specified, it is used as prefix.
The second patch - I'm not sure what it does.
Revision ChangesPath
1.23 +4 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java
Index: JspC.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- JspC.java 21 Jan 2003 22:49:53 - 1.22
+++ JspC.java 21 Jan 2003 23:24:50 - 1.23
@@ -548,7 +548,7 @@
targetClassName = null;
}
if (targetPackage != null) {
-clctxt.setServletPackageName( targetPackage + . +
+clctxt.setServletPackageName( targetPackage +
toPackageName(jspUri));
} else {
clctxt.setServletPackageName( toPackageName(jspUri));
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/admin/WEB-INF web.xml
costin 2003/01/21 15:25:29 Modified:webapps/admin/WEB-INF web.xml Log: Add a small XML comment - it'll be replaced with the generated web.xml fragment. Revision ChangesPath 1.6 +2 -0 jakarta-tomcat-catalina/webapps/admin/WEB-INF/web.xml Index: web.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/admin/WEB-INF/web.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- web.xml 20 Nov 2002 00:14:07 - 1.5 +++ web.xml 21 Jan 2003 23:25:28 - 1.6 @@ -90,6 +90,8 @@ load-on-startup2/load-on-startup /servlet + !--GENERATED_JSPS-- + !-- Action Servlet Mapping -- servlet-mapping servlet-nameaction/servlet-name -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
looking for a recent isapi_redirector2.dll
Hello, Has anyone recently compiled isapi_redirector2.dll (aka IIS JK2 connector)? It seems that the binary version available at Tomcat Connectors site is quite old and does not include the recent upload-corrupter bugfix (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15278). It would be cool if someone who has recently compiled it could send it (or post an URL) as it can be a nightmare for unexpierenced C user (that's me!) to compile the IIS connector from source! Thanks, -Andris Spruds -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 build.xml
costin 2003/01/21 15:25:56
Modified:.build.xml
Log:
Update to match gump dir naming.
Revision ChangesPath
1.67 +1 -1 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.66
retrieving revision 1.67
diff -u -r1.66 -r1.67
--- build.xml 21 Jan 2003 00:26:09 - 1.66
+++ build.xml 21 Jan 2003 23:25:56 - 1.67
@@ -22,7 +22,7 @@
property name=tomcat.projectvalue=jakarta-tomcat-5 /
property name=catalina.project value=jakarta-tomcat-catalina /
property name=jtc.project value=jakarta-tomcat-connectors /
- property name=jasper.projectvalue=jakarta-tomcat-jasper /
+ property name=jasper.projectvalue=jakarta-tomcat-jasper_tc5 /
property name=cvs.base
value=${basedir}/../
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Precompiled jsps
Finally - the precompilation for /admin works, just use ant build-admin-precompile The jsp-examples should be precompiled too ( unless they're intended to show how slow jsp can be on the first request). After more looking at the code - I think it is a bit too complicated to add the JMX to jasper ( at least for my current free time ). However it works perfectly fine with the precompiled jsps - and IMO any decent production server should precompile the jsps ( and get JMX as yet another benefit of doing so ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 5 target JDK1.4?
This might start a bit of a flame-fest here, and if so I appologize, but I feel that this is a valid point. A lot of people have been critizing V. Cekvenich for his suggestion, and one of the common reasons given was: Those who have systems in production and have spent alot of time developing applications which are hosted on those systems can't do a major upgrade like JVM 1.3 - JVM 1.4 at the drop of a hat. This particular version of the argument was posted by Glenn, and I believe he's correct in stating this. However, if you can't do a major upgrade like JVM 1.3 - JVM 1.4 at the drop of a hat, why would you consider a major upgrade like Tomcat 4.X - Tomcat 5 at the drop of a hat? The many other arguments against requiring 1.4 notwithstanding (and I'm not attempting to refute _any_ of them here), it would seem to me that testing a major version change of Tomcat + a JVM change wouldn't incur much more overhead than testing a major version change of Tomcat alone. Does anyone have any comments/opinions/counterarguments? Or should I just shut my trap and concentrate on the other reasons requiring J2SE 1.4 is a bad idea ;-) Sean Reilly Software Architect, Point2 Technologies, Inc. (306) 955-1855 [EMAIL PROTECTED] -Original Message- From: V. Cekvenich [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 21, 2003 5:04 PM To: [EMAIL PROTECTED] Subject: Re: Tomcat 5 target JDK1.4? iSeris has JDK 1.4 download from IBM, that is my point. (BEA, and Apple have it as well so we have multi source). Today when you download Tomcat 4 you have the 1.4 LE edition just loook at the site Also downloading a jar, ex: http://jdbc.postgresql.org/download.html have 1.4 required. Today! TC5 is ways of. And I think everyone can agree that JDK1.4 is more stable than 1.3. .V Henri Gomez wrote: V. Cekvenich wrote: For TC 4 OK, but TC5 will have tested 4 vendors JVM 1.4. Most people run JDK 1.4 now. There is at least one person which didn't run JDK 1.4, me, since the JDK 1.4 is not available on my iSeries. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
luehe 2003/01/21 15:45:19 Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java Log: Modified code generated for jsp:plugin to be well-formed. Example: Previous format of generated code: COMMENT EMBED ... NOEMBED /COMMENT pUnable to start plugin./p /NOEMBED/EMBED New format of generated code: COMMENT EMBED ... / NOEMBED pUnable to start plugin./p /NOEMBED /COMMENT Revision ChangesPath 1.151 +9 -7 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java Index: Generator.java === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v retrieving revision 1.150 retrieving revision 1.151 diff -u -r1.150 -r1.151 --- Generator.java17 Jan 2003 01:21:16 - 1.150 +++ Generator.java21 Jan 2003 23:45:18 - 1.151 @@ -1447,13 +1447,11 @@ if (n.getBody() != null) n.getBody().visit(new ParamVisitor(false)); - out.printil(out.write( + quote() + );); + out.printil(out.write( + quote(/) + );); out.printil(out.write(\\\n\);); out.printil(out.write( + quote(NOEMBED) + );); out.printil(out.write(\\\n\);); - out.printil(out.write( + quote(/COMMENT) + );); - out.printil(out.write(\\\n\);); /* * Fallback @@ -1463,8 +1461,12 @@ out.printil(out.write(\\\n\);); } - out.printil(out.write( + quote(/NOEMBED/EMBED) + );); + out.printil(out.write( + quote(/NOEMBED) + );); + out.printil(out.write(\\\n\);); + + out.printil(out.write( + quote(/COMMENT) + );); out.printil(out.write(\\\n\);); + out.printil(out.write( + quote(/OBJECT) + );); out.printil(out.write(\\\n\);); -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java
[EMAIL PROTECTED] wrote:
costin 2003/01/21 15:24:51
Modified:jasper2/src/share/org/apache/jasper JspC.java
Log:
Use the patch submited by Hans ( at least the part related to package ).
I modified it so that if a package is specified, it is used as prefix.
The second patch - I'm not sure what it does.
You mean the o.a.j.compiler.TagLibraryInfoImpl.java patch, right?
As I mentioned briefly in my last comment for the bug, it fixes a
problem with TLDs packaged in JAR files. Without this patch, you get
an NPE for this case (the problem described by bug #13212).
The code the patch removes is admittedly a mystery to me (why is a
leading slash only removed if a URLClassLoader is used? Isn't this
always the case?) and I don't remember why it failed for TLDs in
JAR files (maybe path is null?). In all my tests, however, this patch
fixes #13212 and has not caused any side-effects.
Hans
Revision ChangesPath
1.23 +4 -4 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java
Index: JspC.java
===
RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- JspC.java 21 Jan 2003 22:49:53 - 1.22
+++ JspC.java 21 Jan 2003 23:24:50 - 1.23
@@ -548,7 +548,7 @@
targetClassName = null;
}
if (targetPackage != null) {
-clctxt.setServletPackageName( targetPackage + . +
+clctxt.setServletPackageName( targetPackage +
toPackageName(jspUri));
} else {
clctxt.setServletPackageName( toPackageName(jspUri));
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
Hans Bergsten[EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com/
Author of O'Reilly's JavaServer Pages, covering JSP 1.2 and JSTL 1.0
Details athttp://TheJSPBook.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Why unpackWars=true default?
On Tue, Jan 21, 2003 at 09:14:29AM -0500, Shapira, Yoav wrote: consider the .war file like an .exe or executable JAR file. And I think this is where my interest comes from. Your considerations are exactly the opposite of Costin's (I think it was Costin anyways), who considers the .war file a *deployment* format only, like an RPM or a Windows Installer file, not to be run as an executable. I thought the raison d'etre of war's was acting like a single .exe. Or at least the default -- just as you're not expected to unpack jars. Matt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15851] - Parser generates a NullPointerException for invalid use case of jsp:attribute instead of a useful message.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15851. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15851 Parser generates a NullPointerException for invalid use case of jsp:attribute instead of a useful message. [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-01-22 01:49 --- The test page jsp:attribute jsp:attribute name=name someattr /jsp:attribute jsp:body someattrvalue /jsp:body /jsp:attribute is not a valid page. The compiler's error message jsp:attribute must be the subelement of a standard or custom action is valid. If the page is modified so that jsp:attribute is nested in a standard action, such as jsp:include jsp:attribute jsp:attribute name=name someattr /jsp:attribute jsp:body someattrvalue /jsp:body /jsp:attribute /jsp:include then the compiler will generate the message a jsp:attribute standard action cannot be nested within another jsp:attribute standard action as expected. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Replace Jasper's logging facility with commons-logging
Jan Luehe wrote: Hans, Jasper currently uses its own private logging facility implemented in the org.apache.jasper.logging package. This is inconsistent with the way the other Tomcat subsystems perform logging (by leveraging the commons-logging package). Proposal is to remove org.apache.jasper.logging, and replace calls to it with calls to the commons-logging APIs. +1 Comments? +0. Do you suggest this for TC 5 only, or also for TC 4.1? Mainly for TC 5, but if there is enough interest, I can apply the changes to TC 4.1 as well. Fine by me to port the switch to commons-logging to Jasper 2 for Tomcat 4.1. :-) Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Replace Jasper's logging facility with commons-logging
+1 I strongly echo Jan Luehe. Jan Luehe [EMAIL PROTECTED] wrote:Jasper currently uses its own private logging facility implemented in the org.apache.jasper.logging package. This is inconsistent with the way the other Tomcat subsystems perform logging (by leveraging the commons-logging package). Proposal is to remove org.apache.jasper.logging, and replace calls to it with calls to the commons-logging APIs. Comments? Jan -- To unsubscribe, e-mail: For additional commands, e-mail: - Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now
Re: [PROPOSAL] Replace Jasper's logging facility with commons-logging
+1 -- Jeanfrancois Jan Luehe wrote: Jasper currently uses its own private logging facility implemented in the org.apache.jasper.logging package. This is inconsistent with the way the other Tomcat subsystems perform logging (by leveraging the commons-logging package). Proposal is to remove org.apache.jasper.logging, and replace calls to it with calls to the commons-logging APIs. Comments? Jan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Replace Jasper's logging facility with commons-logging
But would it be a nice idea to use Log 4J through out tomcat? comments.. Jan Luehe [EMAIL PROTECTED] wrote:Jasper currently uses its own private logging facility implemented in the org.apache.jasper.logging package. This is inconsistent with the way the other Tomcat subsystems perform logging (by leveraging the commons-logging package). Proposal is to remove org.apache.jasper.logging, and replace calls to it with calls to the commons-logging APIs. Comments? Jan -- To unsubscribe, e-mail: For additional commands, e-mail: - Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now
DO NOT REPLY [Bug 3774] - Error loading web.xml on root context when specified in server.xml file on Windows
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3774. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3774 Error loading web.xml on root context when specified in server.xml file on Windows [EMAIL PROTECTED] changed: What|Removed |Added Version|4.0 Final |4.0.4 Beta 1 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
