Re: Bug or feature?
Sorry for answering my own mail but I lost the thread and want to clarify some aspects with respect to Matts message. He wrote: --- This means that ALL roles can access this resource. When you specify *, you don't need to specify security-role below, but if you DO specify a role or roles, then it is necessary to define roles. At least, this is my impression from the specs. If you want your desired behavior, change role-name to use specialrole. --- Principally this sounds good and I'm aware of the solution but is this the specified behaviour? Again: what are security-role definitions good for? And again I'll refer to the spec - see below. Thomas Paradies wrote: Hi, I'm a little bit confused about the use of the security-role tag - generally and especially in Tomcat. The WebApp DTD refers for auth-constraint to this element commented as follows: ... The role-name used here must either correspond to the role-name of one of the security-role elements defined for this web application In TC the role-name in auth-constraint isn't verified against an corresponding security-role definition. (test: replace * by tomcat do not define a security-role) This is a MUST. , or be the specially reserved role-name * that is a compact syntax for indicating all roles in the web application. IMO this means that * is limited for indicating all roles in THE WEB APPLICATION and should not not do this for roles in other web applications even if the share the same realm. ... If no roles are defined, no user is allowed access to the portion of the web application described by the containing security-constraint... I understand this as a MUST. And no roles are defined relates in my eyes to the web application. Comments are welcome. I've tried to do this with Tomcat (4.1.16) but it didn't work as described. Tested with this web.xml (test.jsp also needed): ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app servlet servlet-nameRoleRef/servlet-name jsp-file/test.jsp/jsp-file /servlet servlet-mapping servlet-name RoleRef /servlet-name url-pattern /test /url-pattern /servlet-mapping security-constraint web-resource-collection web-resource-nameWebCollection/web-resource-name url-pattern/test/url-pattern /web-resource-collection auth-constraint role-name*/role-name /auth-constraint /security-constraint login-config auth-methodBASIC/auth-method realm-namedefault/realm-name /login-config !-- uncommenting security-role causes nothing -- security-role role-namespecialrole/role-name /security-role /web-app Only specialRole should have the permission to access the resource test.jsp, if uncommented no user should have this permission - but in Tomcat any role (e.g. tomcat, from global context) has in both cases the permission ... Is this wanted behaviour or is this a bug? Regards, Thomas Paradies -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] Regards, Thomas Paradies -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
I agree with Costin's interpretation of the Jakarta voting rules (even if I don't agree with his -0 on this particular vote :). Since it is a majority vote, justifying a -1 is optional. soapbox I'd like to point out that we have at least 3 non-binding +1 votes on this already. It seems that there is a community out there for a Servlet-only release, and IMHO, we should listen to them. /soapbox - Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, December 08, 2002 11:32 PM Subject: Re: [VOTE] minimal JSR 154 only distribution Jon Scott Stevens wrote: requirement in JSR 154 to provide the Admin Tool, I don't see how your argument is valid for what I'm proposing. A majority vote doesn't require arguments or validity of arguments. I like the idea or I don't like the idea is all that's needed. Valid arguments are required for a veto. I don't think it would be good for tomcat community if it will pass with 3 +1 votes, 2 -1 votes and one -0. I hope that more tomcat committers will send at least a +0 or -0, and even better +1 or -1. There is no need to get into too much debate - just yes and no would help. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Jeanfrancois Arcand wrote: Jon Scott Stevens wrote: Create a separate minimal JSR 154 only distribution of Tomcat 4.x: +1 [] 0 [] -1 [X] -jon (1) Jasper is very a very small jar file. (2) The Admin Tool should go with the minimal distribution of Tomcat. We decided to include JMX in Tomcat distribution...what's the point having JMX and not the Admin Tool? Maybe JSP is not required by all Tomcat users, but I'm sure a lot of them like to have the Admin Tool . If the vote actually passes, I'd like to have only one minimal Tomcat distribution, which would mean no admin and no Jasper (with separate optional Jasper binaries available). JMX can be used directly (using a MX4J connector + MC4J, assuming MC4J updates to MX4J 1.1.1 as we did) to administer the server, without the need to use the admin webapp. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15172] New: - put before get fails
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=15172. 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=15172 put before get fails Summary: put before get fails Product: Tomcat 4 Version: 4.0.6 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If I make a PUT request on my Servlet as first request to the web app i get a Bad Request, 400 error. If i do a GET request first and then a PUT my sevlet works. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Tomcat modules
Remy Maucherat wrote: Hi, I plan to reorganize the jakarta-tomcat-catalina repository as follows: - catalina folder: Catalina core; this depends on the servlet API - modules folders: Optional functionality and modules (one example is clustering), but which depends on the Catalina API; this does not directly depend on the servlet API Alternately, using another repository (j-t-modules) is possible, but just using a folder looks simpler, as there is an API dependency. I propose putting independent modules in j-t-connectors (like eventually some of the naming features). ballot +1 [ ] -1 [ ] /ballot +0 I'm pretty busy these days so I can't help even if this and the clustering are of very interest for me. Regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Jon Scott Stevens wrote: on 2002/12/7 9:37 AM, Glenn Nielsen [EMAIL PROTECTED] wrote: I will consider voting +1 if any of the other tomcat devs who want this will volunteer to be the release manager for the servlet only distribution. I would find this handy when using Tomcat as a SOAP server where JSP is not needed. Glenn Well this thread make some noise. I will volunteer to be the release manager. How will you synchronise with main branch ? Will you wait TC 5 release to make the SMALL TC5 distro or will you follow another cycle of release ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Pier Fumagalli wrote: On 8/12/02 0:43 Jon Scott Stevens [EMAIL PROTECTED] wrote: on 2002/12/7 4:25 PM, Pier Fumagalli [EMAIL PROTECTED] wrote: Jon, I'm very sorry mate, you're 4 months too late :-( I lost my fight about this very same topic back then... Maybe to late for your opinion, but honestly, I haven't been that impressed with Jetty. In my case it speeds up my stuff around 3/4 times faster. And the footprint is considerably slower... Depends on the app... I make benchs between TC 4.1.16 and latest jetty, and TC 4.1 was about 30% faster on servlet (didn't test JSP). I saw very little if any speed increase with Jetty and Scarab and I actually consider Jetty's distribution to be packed with more crud than Tomcat's...but maybe I'm just biased by Tomcat. At this point, I don't think that with JSR 154 and JSR 152 being separate, there is much that anyone here can say negative about distributing JSR 154 only engine. Clearly there is a demand. Clearly it is a good thing to have options. What think JCP about a JSR 154 only engine ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
jvmRoute as a property
Hi, I would to add a feature: Allow jvmRoute to be a system property. I have several Tomcat's using the same server.xml but I need a different sessionId for each Tomcat. The easy solution I have found is to use jmvRoute=SYSTEM and read the system property jmvRoute to have the jvmRoute I want. I have enclosed the corresponding patch. Should I commit it? Cheers Jean-frederic Index: catalina/src/share/org/apache/catalina/core/StandardEngine.java === RCS file: /home/cvs/mirror/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardEngine.java,v retrieving revision 1.15 diff -u -r1.15 StandardEngine.java --- catalina/src/share/org/apache/catalina/core/StandardEngine.java 2 May 2002 22:14:45 - 1.15 +++ catalina/src/share/org/apache/catalina/core/StandardEngine.java 9 Dec 2002 +08:56:06 - @@ -171,6 +171,7 @@ */ public void setDefaultHost(String host) { +this.log(setDefaultHost= + host); String oldDefaultHost = this.defaultHost; if (host == null) { this.defaultHost = null; @@ -191,7 +192,16 @@ */ public void setJvmRoute(String routeId) { this.log(setJvmRoute= + routeId); -jvmRouteId = routeId; +jvmRouteId = null; +if (SYSTEM.equals(routeId)) + this.log(setJvmRoute is SYSTEM!!!); +try { +jvmRouteId = System.getProperty(jvmRoute); +this.log(setJvmRoute read: + jvmRouteId); +} catch(Exception ex) { +} +if (jvmRouteId == null) +jvmRouteId = routeId; } -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jvmRoute as a property
jean-frederic clere wrote: Hi, I would to add a feature: Allow jvmRoute to be a system property. I have several Tomcat's using the same server.xml but I need a different sessionId for each Tomcat. The easy solution I have found is to use jmvRoute=SYSTEM and read the system property jmvRoute to have the jvmRoute I want. I have enclosed the corresponding patch. Should I commit it? The feature could be helpful, but the implementation is weird (if you don't call setJvmRoute, which AFAIK only happens when it is defined in server.xml, it will never get set). Probably the code should be put in the StandardEngine constructor or in its start method. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
What I would love to see is a tree of downloads where each one gains more and more features (it is additive). Such as: JSR-154 Implementation / \ Jasper Velocity / \ \ Admin Tool (JMX) Java Server Feces Scarab That way, you only need to download what you need. Bundles are easily created by simply picking off the branch of the tree that you want. If you want the Tomcat distribution with web based administration abilities, then you grab it at the Admin Tool level and so on. We can even build an ant based system which is able to help us manage the selection of components to include in the distribution. This would be similar to the way that we currently have jar repositories and dependencies, but on an application level. Click here to install Jasper, Struts, etc. Not only does this provide our users the ability to simply get what they need (and add it after the fact if they don't have it), it helps us focus on providing a pluggable system which is separate from the other systems (ie: clean dependencies). I personally think that this is a much cleaner way of providing distributions because it does not require people to learn or deal with things they do not care about. Options are a good thing. Let's not limit ourselves. One last point, we should be able to experiment around here. The negative votes have been based on biases about what I think about Jasper and my opinions. They are not based on the idea that experimentation is a good thing and I think that is just plain wrong and very closed minded. Who are you to decide what our users may or may not like? In the end, if things don't work out, then fine at least we learned something and we can move on to the next thing. What do we really have to loose here? -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15104] - sendRedirect() does not write the port on the redirect url
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=15104. 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=15104 sendRedirect() does not write the port on the redirect url [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2002-12-09 09:18 --- But with java code does not redirect using host header HttpURLConnection.setFollowRedirects(true); With this sentence in java, my program is not capable or doing the redirect. Maybe is a java implementation bug in 1.3.1? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10595] - Security Constraints not processed according to spec.
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=10595. 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=10595 Security Constraints not processed according to spec. [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2002-12-09 09:24 --- I have reed the specs 2.4 about this and compared it with the specs for 2.3. There are no real differences about this topic. But I found the problem in ignoring the Use of URL Paths. Therfore I have to reopen this BUG: The Spec state in SRV 11.1 Use of URL Paths ... 2. The container will recursively try to match the longest path-prefix: This is done by stepping down the path tree a directory at a time, using the / character as a path separator. The longest match determines the servlet selected. ... TOMCAT 4 is NOT doing this to resolve the URL of a security constraint. If TOMCAT 4 would do, than the order of the security constraints wouldn't make any difference (in my example). But as I said in my comment, TOMCAT is using the first match from the descriptor, even if there are more with LONGER path-prefix. If this would be fixed, then it will work the way one expects it (according to the specs). I was willed to send comments to the jsr expert group. But the problem is not the specs. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15104] - sendRedirect() does not write the port on the redirect url
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=15104. 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=15104 sendRedirect() does not write the port on the redirect url --- Additional Comments From [EMAIL PROTECTED] 2002-12-09 09:27 --- Ok fine. I think this is invalid and a user error. Please provide: - an easy to run test case - the full Tomcat configuration -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jvmRoute as a property
Remy Maucherat wrote: jean-frederic clere wrote: Hi, I would to add a feature: Allow jvmRoute to be a system property. I have several Tomcat's using the same server.xml but I need a different sessionId for each Tomcat. The easy solution I have found is to use jmvRoute=SYSTEM and read the system property jmvRoute to have the jvmRoute I want. I have enclosed the corresponding patch. Should I commit it? The feature could be helpful, but the implementation is weird (if you don't call setJvmRoute, which AFAIK only happens when it is defined in server.xml, it will never get set). Probably the code should be put in the StandardEngine constructor or in its start method. Ok, I will set the jvmRoute using the system property jmvRoute in the StandardEngine constructor. Remy -- 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 15143] - Unable to build mod_jk2 for apache-2.0.43 on solaris8
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=15143. 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=15143 Unable to build mod_jk2 for apache-2.0.43 on solaris8 [EMAIL PROTECTED] changed: What|Removed |Added Severity|Blocker |Minor Priority|Other |High -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15175] New: - Tomcat stops responding on solaris 8
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=15175. 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=15175 Tomcat stops responding on solaris 8 Summary: Tomcat stops responding on solaris 8 Product: Tomcat 4 Version: 4.0.4 Final Platform: Sun OS/Version: Other Status: NEW Severity: Blocker Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am using solaris 8 as OS, and sometime it stop working giving me the following output. , [INFO] Http11Protocol - -Initializing Coyote HTTP/1.1 on port 80 [INFO] Http11Protocol - -Initializing Coyote HTTP/1.1 on port 443 Starting service APP1 Apache Tomcat/4.0.4 [INFO] Http11Protocol - -Starting Coyote HTTP/1.1 on port 80 [INFO] Http11Protocol - -Starting Coyote HTTP/1.1 on port 443 Starting service APP2 Apache Tomcat/4.0.4 log4j:WARN No appenders could be found for logger (org.apache.axis.AxisEngine). log4j:WARN Please initialize the log4j system properly. Log4j Initialized [INFO] Http11Protocol - -SocketException reading request, ignored PoolTcpEndpoint: Endpoint ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=80] shutdown due to exception: java.lang.OutOfMemoryError java.lang.OutOfMemoryError no stack trace available PoolTcpEndpoint: Endpoint ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=443] shutdown due to exception: java.lang.OutOfMemoryError java.lang.OutOfMemoryError no stack trace available bash-2.03# ulimit -a core file size (blocks) unlimited data seg size (kbytes) unlimited file size (blocks) unlimited open files 256 pipe size (512 bytes) 10 stack size (kbytes) 8192 cpu time (seconds) unlimited max user processes 7893 virtual memory (kbytes) unlimited -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15175] - Tomcat stops responding on solaris 8
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=15175. 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=15175 Tomcat stops responding on solaris 8 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-12-09 10:46 --- Have you tried setting the java heap size? E.g. $ java -Xmx512m for 512MB of max heap. This is normally the problem when getting OutOfMemoryException. The shell limits are of little or no interest. Look at shell variables CATALINA_OPTS for Catalina and TOMCAT_OPTS for Tomcat 3. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 build.properties.default
remm2002/12/09 03:16:30 Modified:.build.properties.default Log: - Update to NSIS Beta 0. Hopefully, no more API changes from now on. Revision ChangesPath 1.54 +2 -2 jakarta-tomcat-5/build.properties.default Index: build.properties.default === RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v retrieving revision 1.53 retrieving revision 1.54 diff -u -r1.53 -r1.54 --- build.properties.default 5 Dec 2002 12:01:32 - 1.53 +++ build.properties.default 9 Dec 2002 11:16:29 - 1.54 @@ -182,7 +182,7 @@ nsis.home=${base.path}/nsis-2.0 nsis.exe=${nsis.home}/makensis.exe nsis.installoptions.dll=${nsis.home}/Plugins/InstallOptions.dll -nsis.loc=http://telia.dl.sourceforge.net/sourceforge/nsis/nsis20a7.exe +nsis.loc=http://telia.dl.sourceforge.net/sourceforge/nsis/nsis20b0.exe # - Struts, version 1.1 Beta 2 or later - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[4.1.17] Tag soon ?
I don't see any major issues with 4.1.16, so I plan to tag 4.1.17 (which hopefully would be the next stable build) tomorrow after a few more minor tweaks. There was a report made against JK 2 immediately after 4.1.16 Beta was announced. Can someone confirm there's no major issue with JK ? Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[4.1] Changes to base interfaces
Hi, Changing the API in the 4.1.x branch is not ok (at a bare minimum, not without asking/voting). A method addition was made on 11/30 to the org.apache.catalina.Manager interface. This could break compatibility with 3rd party managers, and apparently was made during an optimization effort, as part of a larger patch. I originally missed this in the commit message. I do not wish to include such an API change as part of the 4.1.x branch, and would want to see at least this portion of the patch (with dependencies; apparently there are many) reverted. This batch of experimental patches were committed in a stable branch (4.1.x), and as of now are still not ported in the development branch (5.0), so I assume development will still continue in 4.1.x, which is not a good idea. What I'd like to see happen, unless there is a good reason not to do so: - all the changes to the manager are reverted to the 4.1.16 version - the patches are committed to the jakarta-tomcat-catalina repository, where active development can continue without destabilizing the stable tree Thanks, Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15176] New: - oracle.xml.sql.OracleXMLSQLException: java.lang.ClassCastException
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=15176. 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=15176 oracle.xml.sql.OracleXMLSQLException: java.lang.ClassCastException Summary: oracle.xml.sql.OracleXMLSQLException: java.lang.ClassCastException Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: Catalina:Modules AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] According to the doc JNDI Datasource HOW-TO, i setup the connection pool using DBCP, everything is the same as what the doc shows except for the oracle sid and user/pass. But when i boot up tomcat, something happened. The page which use sql select is correct while if i use sql update function a OracleXMLSQLException occured, Which is caused by class cast i think. The sql statement including select,insert,update and delete all implemented with xdk for oracle. the logfile shows: StandardWrapperValve[Login]: Servlet.service() for servlet Login threw exception oracle.xml.sql.OracleXMLSQLException: java.lang.ClassCastException at oracle.xml.sql.dml.OracleXMLSave.saveXML(OracleXMLSave.java:2088) at oracle.xml.sql.dml.OracleXMLSave.updateXML(OracleXMLSave.java:1443) at XMLBean.execute(XMLBean.java:101) at ControlBean.setTime(ControlBean.java:491) at Login._jspService(Login.java:184) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:136) 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.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:2396) 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.valves.AccessLogValve.invoke (AccessLogValve.java:469) 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 org.apache.catalina.connector.http.HttpProcessor.process (HttpProcessor.java:1040) at org.apache.catalina.connector.http.HttpProcessor.run (HttpProcessor.java:1151) at java.lang.Thread.run(Thread.java:536) the 101 line of XMLBean.java is s.updateXML(Doc), s is a instance of OracleXMLSave and Doc is a string. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
adding content-type for Apache 2.0 jk/jk2
Hi, I'm playing currently with mod_jk + mod_deflate on Apache 2.0, and it seems it will be needed to set the content-type in response in Apache 2.0 to allow mod_deflate to compress only text/html, text/xml contents. It seems in that case will need to parse the tomcat response to set content-type accordingly with ap_set_content_type. What do you think about ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
hgomez 2002/12/09 05:19:18 Modified:jk/native/apache-2.0 mod_jk.c Log: Make jk works with filters in Apache 2.0, ie mod_deflate and AddOutputFilterByType DEFLATE text/html. Revision ChangesPath 1.62 +5 -2 jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c Index: mod_jk.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v retrieving revision 1.61 retrieving revision 1.62 diff -u -r1.61 -r1.62 --- mod_jk.c 6 Dec 2002 18:54:45 - 1.61 +++ mod_jk.c 9 Dec 2002 13:19:17 - 1.62 @@ -240,7 +240,10 @@ if(!strcasecmp(header_names[h], Content-type)) { char *tmp = apr_pstrdup(r-pool, header_values[h]); ap_content_type_tolower(tmp); -r-content_type = tmp; +/* It should be done like this in Apache 2.0 */ +/* This way, Apache 2.0 will be able to set the output filter */ +/* and it make jk useable with deflate using AddOutputFilterByType DEFLATE text/html */ +ap_set_content_type(r, tmp); } else if(!strcasecmp(header_names[h], Location)) { #ifdef AS400 /* Fix escapes in Location Header URL*/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/conf server.xml
remm2002/12/09 05:22:40 Modified:catalina/src/conf server.xml Log: - Port connector configuration tweaks. Revision ChangesPath 1.67 +7 -6 jakarta-tomcat-4.0/catalina/src/conf/server.xml Index: server.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/server.xml,v retrieving revision 1.66 retrieving revision 1.67 diff -u -r1.66 -r1.67 --- server.xml8 Dec 2002 07:14:16 - 1.66 +++ server.xml9 Dec 2002 13:22:40 - 1.67 @@ -92,8 +92,8 @@ Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8080 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 - acceptCount=10 debug=0 connectionTimeout=2 - useURIValidationHack=false / + acceptCount=100 debug=0 connectionTimeout=2 + useURIValidationHack=false disableUploadTimeout=true / !-- Note : To disable connection timeouts, set connectionTimeout value to -1 -- @@ -102,8 +102,8 @@ Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8443 minProcessors=5 maxProcessors=75 enableLookups=true -acceptCount=10 debug=0 scheme=https secure=true - useURIValidationHack=false +acceptCount=100 debug=0 scheme=https secure=true + useURIValidationHack=false disableUploadTimeout=true Factory className=org.apache.coyote.tomcat4.CoyoteServerSocketFactory clientAuth=false protocol=TLS / /Connector @@ -130,8 +130,9 @@ Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8082 minProcessors=5 maxProcessors=75 enableLookups=true - acceptCount=10 debug=0 connectionTimeout=2 - proxyPort=80 useURIValidationHack=false / + acceptCount=100 debug=0 connectionTimeout=2 + proxyPort=80 useURIValidationHack=false + disableUploadTimeout=true / -- !-- Define a non-SSL legacy HTTP/1.1 Test Connector on port 8083 -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/webapp/apache-2.0 mod_webapp.c
hgomez 2002/12/09 05:22:45 Modified:webapp/apache-2.0 mod_webapp.c Log: Make webapp works with filters in Apache 2.0, ie mod_deflate and AddOutputFilterByType DEFLATE text/html. NB: My first webapp commit ;-) Revision ChangesPath 1.12 +7 -2 jakarta-tomcat-connectors/webapp/apache-2.0/mod_webapp.c Index: mod_webapp.c === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/apache-2.0/mod_webapp.c,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- mod_webapp.c 13 Jun 2002 11:06:47 - 1.11 +++ mod_webapp.c 9 Dec 2002 13:22:45 - 1.12 @@ -309,7 +309,12 @@ if (type==NULL) return; -req-content_type=apr_pstrdup(req-pool,type); +/*req-content_type=apr_pstrdup(req-pool,type); */ +/* It should be done like this in Apache 2.0 */ +/* This way, Apache 2.0 will be able to set the output filter */ +/* and it make webapp useable with deflate using AddOutputFilterByType DEFLATE text/html */ +ap_set_content_type(req, apr_pstrdup(req-pool,type)); + apr_table_add(req-headers_out,Content-Type,apr_pstrdup(req-pool,type)); } -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/resources/confinstall server_2.xml
remm2002/12/09 05:22:55 Modified:resources/confinstall server_2.xml Log: - Port connector configuration tweaks. Revision ChangesPath 1.6 +6 -6 jakarta-tomcat-4.0/resources/confinstall/server_2.xml Index: server_2.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/resources/confinstall/server_2.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- server_2.xml 13 Jun 2002 21:42:26 - 1.5 +++ server_2.xml 9 Dec 2002 13:22:55 - 1.6 @@ -1,7 +1,7 @@ minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 - acceptCount=10 debug=0 connectionTimeout=2 - useURIValidationHack=false / + acceptCount=100 debug=0 connectionTimeout=2 + useURIValidationHack=false disableUploadTimeout=true / !-- Note : To disable connection timeouts, set connectionTimeout value to -1 -- @@ -10,8 +10,8 @@ Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8443 minProcessors=5 maxProcessors=75 enableLookups=true -acceptCount=10 debug=0 scheme=https secure=true - useURIValidationHack=false +acceptCount=100 debug=0 scheme=https secure=true + useURIValidationHack=false disableUploadTimeout=true Factory className=org.apache.coyote.tomcat4.CoyoteServerSocketFactory clientAuth=false protocol=TLS / /Connector @@ -37,8 +37,8 @@ !-- Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8082 minProcessors=5 maxProcessors=75 - enableLookups=true - acceptCount=10 debug=0 connectionTimeout=2 + enableLookups=true disableUploadTimeout=true + acceptCount=100 debug=0 connectionTimeout=2 proxyPort=80 useURIValidationHack=false / -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 jk_service_apache2.c
hgomez 2002/12/09 05:23:20 Modified:jk/native2/server/apache2 jk_service_apache2.c Log: Make jk2 works with filters in Apache 2.0, ie mod_deflate and AddOutputFilterByType DEFLATE text/html. Revision ChangesPath 1.33 +5 -2 jakarta-tomcat-connectors/jk/native2/server/apache2/jk_service_apache2.c Index: jk_service_apache2.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/jk_service_apache2.c,v retrieving revision 1.32 retrieving revision 1.33 diff -u -r1.32 -r1.33 --- jk_service_apache2.c 22 Nov 2002 16:04:06 - 1.32 +++ jk_service_apache2.c 9 Dec 2002 13:23:19 - 1.33 @@ -105,7 +105,10 @@ if( val!=NULL ) { char *tmp = apr_pstrdup(r-pool, val); ap_content_type_tolower(tmp); -r-content_type = tmp; +/* It should be done like this in Apache 2.0 */ +/* This way, Apache 2.0 will be able to set the output filter */ +/* and it make jk useable with deflate using AddOutputFilterByType DEFLATE text/html */ +ap_set_content_type(r, tmp); } val= headers-get( env, headers, Last-Modified); if( val!=NULL ) { -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[GUMP] Build Failure - jakarta-tomcat-catalina
This email is autogenerated from the output from: http://cvs.apache.org/builds/gump/2002-12-09/jakarta-tomcat-catalina.html Buildfile: build.xml deploy-prepare: [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build deploy-static: deploy-catalina: [echo] Target: Catalina - Deploy ... flags: flags.display: [echo] --- Build environment for Catalina --- [echo] If ${property_name} is displayed, then the property is not set) [echo] --- Build options --- [echo] full.dist=${full.dist} [echo] build.sysclasspath=only [echo] compile.debug=${compile.debug} [echo] compile.deprecation=${compile.deprecation} [echo] compile.optimize=${compile.optimize} [echo] --- Ant Flags --- [echo] style task available (required)=true [echo] --- JDK --- [echo] jdk.1.2.present=true [echo] jdk.1.3.present=true [echo] jdk.1.4.present=true [echo] --- Source Dependencies --- [echo] jtc.home.present=true [echo] --- Required Libraries --- [echo] beanutils.present=true [echo] collections.present=true [echo] digester.present=true [echo] jaxp.present=true [echo] jndi.present=true [echo] logging.present=true [echo] regexp.present=true [echo] --- Optional Libraries --- [echo] dbcp.present=true [echo] jaas.present=true [echo] javamail.present=true [echo] jmx.present=true [echo] jsse.present=true [echo] jta.present=true [echo] junit.present=true [echo] lang.present=${lang.present} [echo] launcher.present=${launcher.present} [echo] launcher.bootstrap.present=${launcher.bootstrap.present} [echo] ldap.present=true [echo] modeler.present=true [echo] pool.present=true [echo] tyrex.present=${tyrex.present} [echo] --- Required JARs --- [echo] jndi.jar.present(except JDK 1.3+)=true [echo] regexp.jar.present=true [echo] servlet-api.jar.present=true [echo] xerces2.jars.present(except JDK 1.4+)=true [echo] --- Optional JARs --- [echo] dbcp.jar.present=true [echo] jaas.jar.present=true [echo] javamail.jar.present=true [echo] jdbc20ext.jar.present=true [echo] jmx.jar.present=true [echo] jta.jar.present=true [echo] junit.jar.present=${junit.jar.present} [echo] modeler.jar.present=true [echo] pool.jar.present=true [echo] tyrex.jar.present=${tyrex.jar.present} [echo] --- Conditional compilation flags --- [echo] compile.dbcp=true [echo] compile.jaas=true [echo] compile.javamail=true [echo] compile.jmx=true [echo] compile.jndi=true [echo] compile.jsse=true [echo] compile.jta=true [echo] compile.junit=true [echo] compile.ldap=true [echo] compile.ssi=true [echo] compile.tyrex=${compile.tyrex} [echo] --- Distribution flags --- [echo] copy.dbcp.jar=true [echo] copy.jmx.jar=true [echo] copy.launcher.jars=${copy.launcher.jars} [echo] copy.logging.jar=true [echo] copy.modeler.jar=true [echo] copy.pool.jar=true build-prepare: [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/bin [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/common/classes [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/common/lib [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/common/endorsed [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/conf [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/logs [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/server/classes [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/server/lib [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/shared/classes [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/shared/lib [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/work [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/temp copy-dbcp.jar: [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-catalina/build/common/lib copy-jmx.jar: [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-catalina/build/server/lib [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-catalina/build/server/lib copy-launcher.jars: copy-modeler.jar: [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-catalina/build/server/lib copy-pool.jar: [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-catalina/build/common/lib copy-xerces2.jars: [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-catalina/build/common/endorsed build-static: [copy] Copying 13 files to
cvs commit: jakarta-tomcat-connectors/jk/native2 CHANGES.txt
hgomez 2002/12/09 05:27:20 Modified:jk/native2 CHANGES.txt Log: comment change Revision ChangesPath 1.7 +5 -2 jakarta-tomcat-connectors/jk/native2/CHANGES.txt Index: CHANGES.txt === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/CHANGES.txt,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- CHANGES.txt 27 Nov 2002 17:12:40 - 1.6 +++ CHANGES.txt 9 Dec 2002 13:27:20 - 1.7 @@ -2,7 +2,10 @@ Last modified at [$Date$] Changes with JK2 2.0.3: - +* jk2 set correctly the content-type in Apache 2.0, + making it ready to works with mod_deflate and AddOutputFilterByType + [Henri Gomez] + Changes with JK2 2.0.2: * Fix the bug 14293. Thanks to Martin Kraemer for his help. [Jean-Frederic Clere] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native CHANGES.txt
hgomez 2002/12/09 05:28:55 Modified:jk/native CHANGES.txt Log: comment changes Revision ChangesPath 1.5 +10 -1 jakarta-tomcat-connectors/jk/native/CHANGES.txt Index: CHANGES.txt === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/CHANGES.txt,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- CHANGES.txt 25 Nov 2002 15:29:38 - 1.4 +++ CHANGES.txt 9 Dec 2002 13:28:55 - 1.5 @@ -1,6 +1,15 @@ JAKARTA TOMCAT CONNECTORS (JK) CHANGELOG:-*-text-*- Last modified at [$Date$] +Changes with JK 1.2.2: +* jk set correctly the content-type in Apache 2.0, + making it ready to works with mod_deflate and AddOutputFilterByType + [hgomez] +* jk will check result of get_endpoint and handle a failure. + This call can fail if the allocation for the endpoint fails because of low memory conditions + causing a dereference of NULL when we try and access the endpoint + [mmanders] + Changes with JK 1.2.1: * Don't send initial chunk for chunked encoding, fix #14282 [costin] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1] Changes to base interfaces
Remy Maucherat wrote: Hi, Changing the API in the 4.1.x branch is not ok (at a bare minimum, not without asking/voting). A method addition was made on 11/30 to the org.apache.catalina.Manager interface. This could break compatibility with 3rd party managers, and apparently was made during an optimization effort, as part of a larger patch. I originally missed this in the commit message. I am the gulty for changing the Manager interface. The problem is the createSession is called when reading the stored sessions in the store the result is quite bad... I have to look for another way for fixing the problem. (That needs time). I do not wish to include such an API change as part of the 4.1.x branch, and would want to see at least this portion of the patch (with dependencies; apparently there are many) reverted. This batch of experimental patches were committed in a stable branch (4.1.x), and as of now are still not ported in the development branch (5.0), so I assume development will still continue in 4.1.x, which is not a good idea. What I'd like to see happen, unless there is a good reason not to do so: - all the changes to the manager are reverted to the 4.1.16 version That is not a big problem. - the patches are committed to the jakarta-tomcat-catalina repository, where active development can continue without destabilizing the stable tree. Ok. I will do this part today. Thanks, Remy -- 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: [VOTE] minimal JSR 154 only distribution
Jeanfrancois Arcand wrote: Jon Scott Stevens wrote: Create a separate minimal JSR 154 only distribution of Tomcat 4.x: +1 [] 0 [] -1 [X] -jon (1) Jasper is very a very small jar file. (2) The Admin Tool should go with the minimal distribution of Tomcat. We decided to include JMX in Tomcat distribution...what's the point having JMX and not the Admin Tool? Maybe JSP is not required by all Tomcat users, but I'm sure a lot of them like to have the Admin Tool . Not to pick on Jean Francois, but many times I have seen tomcat devs discuss what the users want or use when discussing features. I have no real idea what features tomcat users use or what features they want, other than anecdotal. Are there any facts behind the statement but I'm sure a lot of them like to have the Admin Tool.? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Patch for isapi_redirector2
Hi, I have made a patch which solves a problem I had last week--isapi_redirector sometimes corrupted data sent by the client. I'm not sure where to send the patch, I hope I don't abuse this list by submitting it here. Someone more intimate with the code might want to make a better patch, the code that follows solves the problem but is not very elegant. I have added code that makes sure the content_length field in jk_ws_service_t gets updated for each call to jk2_service_iis_read. I have used version 2.0.2 of JK2. Joakim Strom Excosoft === int jk2_requtil_readFully(jk_env_t *env, jk_ws_service_t *s, unsigned char *buf, unsigned len) { unsigned rdlen = 0; unsigned padded_len = len; long content_read = s-content_read; // Patch Dec 9, 2002. Save value to restore later if (s-is_chunked s-no_more_chunks) { return 0; } if (s-is_chunked) { /* Corner case: buf must be large enough to hold next * chunk size (if we're on or near a chunk border). * Pad the length to a reasonable value, otherwise the * read fails and the remaining chunks are tossed. */ padded_len = (len CHUNK_BUFFER_PAD) ? len : len - CHUNK_BUFFER_PAD; } while(rdlen padded_len) { unsigned this_time = 0; if(s-read(env, s, buf + rdlen, len - rdlen, this_time)) { return -1; } s-content_read += this_time; // Patch Dec 9, 2002. // Make sure content_read gets incremented // if this loop runs more than once if(0 == this_time) { if (s-is_chunked) { s-no_more_chunks = 1; /* read no more */ } break; } rdlen += this_time; } s-content_read = content_read; // Patch Dec 9, 2002. Reset the value before returning return (int)rdlen; } -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] minimal JSR 154 only distribution
As an end user. I don't use the admin tool, don't know what it is. I do use both JSP and Servlets. M -Original Message- From: Glenn Nielsen [mailto:[EMAIL PROTECTED]] Sent: 09 December 2002 14:06 To: Tomcat Developers List Subject: Re: [VOTE] minimal JSR 154 only distribution Jeanfrancois Arcand wrote: Jon Scott Stevens wrote: Create a separate minimal JSR 154 only distribution of Tomcat 4.x: +1 [] 0 [] -1 [X] -jon (1) Jasper is very a very small jar file. (2) The Admin Tool should go with the minimal distribution of Tomcat. We decided to include JMX in Tomcat distribution...what's the point having JMX and not the Admin Tool? Maybe JSP is not required by all Tomcat users, but I'm sure a lot of them like to have the Admin Tool . Not to pick on Jean Francois, but many times I have seen tomcat devs discuss what the users want or use when discussing features. I have no real idea what features tomcat users use or what features they want, other than anecdotal. Are there any facts behind the statement but I'm sure a lot of them like to have the Admin Tool.? -- 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: [VOTE] minimal JSR 154 only distribution
I have interest in the admin tool - but I don't trust it yet and for my production work - and I am still stuck on the 4.0.X series. I think the admin tool is essential for a full distribution - but useless in a minimal distribution. The user base wanting the min distribution already have the know-how to do what ever they need and the admin app would get in the way. For the new user - the admin tool is very important as a guide for simple changes in an simple manner until they get experience with manipulating server.xml themselves. I went through the same experience with weblogic 6. The admin tool was nice - but once I knew the XML attributes to place in their config files - the admin interface was (mostly) useless. I believe the same will be the same for tomcat users. The use of the admin app will be inversely proportional to the user's skill level. Additionaly, if I create Listeners or other custom classes which need configured in server.xml - I don't want to use the admin app. I'd rather hand write the file myself. I am sure most admins in the same predicament would feel the same. In a nutshell - I think the admin app is helpful to new users. Personally - I don't have enough experience with it to judge if it is better than just editing server.xml by hand. -Tim Glenn Nielsen wrote: Jeanfrancois Arcand wrote: Jon Scott Stevens wrote: Create a separate minimal JSR 154 only distribution of Tomcat 4.x: +1 [] 0 [] -1 [X] -jon (1) Jasper is very a very small jar file. (2) The Admin Tool should go with the minimal distribution of Tomcat. We decided to include JMX in Tomcat distribution...what's the point having JMX and not the Admin Tool? Maybe JSP is not required by all Tomcat users, but I'm sure a lot of them like to have the Admin Tool . Not to pick on Jean Francois, but many times I have seen tomcat devs discuss what the users want or use when discussing features. I have no real idea what features tomcat users use or what features they want, other than anecdotal. Are there any facts behind the statement but I'm sure a lot of them like to have the Admin Tool.? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1.17] Tag soon ?
It seeems that we are doing very frequent point releases of Tomcat 4.1.16. Yet haven't had a stable release since 4.1.12. Reviewing the release notes I don't see any difference between CVS HEAD and 4.1.16 except for my recent addition of the DataSource Realm. Why tag 4.1.17 when there are so few changes? Glenn Remy Maucherat wrote: I don't see any major issues with 4.1.16, so I plan to tag 4.1.17 (which hopefully would be the next stable build) tomorrow after a few more minor tweaks. There was a report made against JK 2 immediately after 4.1.16 Beta was announced. Can someone confirm there's no major issue with JK ? Remy -- 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: [4.1] Changes to base interfaces
jean-frederic clere wrote: Remy Maucherat wrote: Hi, Changing the API in the 4.1.x branch is not ok (at a bare minimum, not without asking/voting). A method addition was made on 11/30 to the org.apache.catalina.Manager interface. This could break compatibility with 3rd party managers, and apparently was made during an optimization effort, as part of a larger patch. I originally missed this in the commit message. I am the gulty for changing the Manager interface. The problem is the createSession is called when reading the stored sessions in the store the result is quite bad... I have to look for another way for fixing the problem. (That needs time). Ok, no problem. The idea is that I missed the fact that there was also a change to the base API, so it's best to do the whole in the development branch. I do not wish to include such an API change as part of the 4.1.x branch, and would want to see at least this portion of the patch (with dependencies; apparently there are many) reverted. This batch of experimental patches were committed in a stable branch (4.1.x), and as of now are still not ported in the development branch (5.0), so I assume development will still continue in 4.1.x, which is not a good idea. What I'd like to see happen, unless there is a good reason not to do so: - all the changes to the manager are reverted to the 4.1.16 version That is not a big problem. - the patches are committed to the jakarta-tomcat-catalina repository, where active development can continue without destabilizing the stable tree. Ok. I will do this part today. Thanks a lot :) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1.17] Tag soon ?
Glenn Nielsen wrote: It seeems that we are doing very frequent point releases of Tomcat 4.1.16. Yet haven't had a stable release since 4.1.12. Reviewing the release notes I don't see any difference between CVS HEAD and 4.1.16 except for my recent addition of the DataSource Realm. Why tag 4.1.17 when there are so few changes? Because: - I usually update the release notes right before tagging, so the changes are actually more significant - feedback on 4.1.16 has been uneventful, so we should try to get a stable release to replace 4.1.12 ASAP, as many bugs have been fixed since then Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] minimal JSR 154 only distribution
Jon, Create a separate minimal JSR 154 only distribution of Tomcat 4.x: +0, i could be +1 but i'm out of time to offer any help in tomcat as a whole, and of course for this particular proposal, but i dont see anything wrong in it, more i do see it as another step, in the GTU Path ( GTU stand for Great Tomcat Unification :).. Saludos, Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves PersistentValve.java
jfclere 2002/12/09 07:05:55 Modified:catalina/src/share/org/apache/catalina Manager.java catalina/src/share/org/apache/catalina/session FileStore.java JDBCStore.java PersistentManagerBase.java Removed: catalina/src/share/org/apache/catalina/valves PersistentValve.java Log: Rollback the Manager interface changes and associated changes. DO NOT except the persistentManagers to work correctly with 4.1.x. Revision ChangesPath 1.8 +4 -11 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Manager.java Index: Manager.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Manager.java,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- Manager.java 30 Nov 2002 12:43:14 - 1.7 +++ Manager.java 9 Dec 2002 15:05:55 - 1.8 @@ -184,13 +184,6 @@ public void addPropertyChangeListener(PropertyChangeListener listener); /** - * Get a session from the recycled ones or create a new empty one. - * The PersistentManager manager does not need to create session data - * because it reads it from the Store. - */ -public Session createEmptySession(); - -/** * Construct and return a new session object, based on the default * settings specified by this Manager's properties. The session * id will be assigned by this method, and available via the getId() 1.10 +5 -5 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/FileStore.java Index: FileStore.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/FileStore.java,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- FileStore.java30 Nov 2002 12:43:14 - 1.9 +++ FileStore.java9 Dec 2002 15:05:55 - 1.10 @@ -333,7 +333,7 @@ try { StandardSession session = -(StandardSession) manager.createEmptySession(); +(StandardSession) manager.createSession(); session.readObjectData(ois); session.setManager(manager); return (session); 1.8 +5 -5 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/JDBCStore.java Index: JDBCStore.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/JDBCStore.java,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- JDBCStore.java30 Nov 2002 12:43:14 - 1.7 +++ JDBCStore.java9 Dec 2002 15:05:55 - 1.8 @@ -538,7 +538,7 @@ if(ois != null) { try { -_session = (StandardSession) manager.createEmptySession(); +_session = (StandardSession) manager.createSession(); _session.readObjectData(ois); _session.setManager(manager); } finally { 1.12 +4 -13 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java Index: PersistentManagerBase.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- PersistentManagerBase.java30 Nov 2002 12:43:14 - 1.11 +++ PersistentManagerBase.java9 Dec 2002 15:05:55 - 1.12 @@ -660,15 +660,6 @@ } -/** - * Remove this Session from the active Sessions for this Manager, - * but not from the Store. (Used by the PersistentValve) - * - * @param session Session to be removed - */ -public void removeSuper(Session session) { -super.remove (session); -} /** * Save all currently active sessions in the appropriate persistence -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Ignacio J. Ortega wrote: Jon, Create a separate minimal JSR 154 only distribution of Tomcat 4.x: +0, i could be +1 but i'm out of time to offer any help in tomcat as a whole, and of course for this particular proposal, but i dont see anything wrong in it, more i do see it as another step, in the GTU Path ( GTU stand for Great Tomcat Unification :).. Nota that adopting modules for Tomcat could be a way to satisfy everybody needs. In such case I'm +1 to have a minimal Tomcat which will load modules to have JSP, JMX, admin supports. If anything could be set in server.xml, it will help have an uniq distribution, that everybody will be able to tune for its own use. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Remy Maucherat wrote: If the vote actually passes, I'd like to have only one minimal Tomcat distribution, which would mean no admin and no Jasper (with separate optional Jasper binaries available). JMX can be used directly (using a MX4J connector + MC4J, assuming MC4J updates to MX4J 1.1.1 as we did) to administer the server, without the need to use the admin webapp. Now - this is not nice ! I don't know why my proposal for a minimal tomcat that includes jsr152 and jsr154 shouldn't be allowed. Ok, I'll make a VOTE and try to gather the votes - hopefully I'll get at least 3 +1 votes ( and you'll at least -0 it :-). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1.17] Tag soon ?
Remy Maucherat wrote: Glenn Nielsen wrote: It seeems that we are doing very frequent point releases of Tomcat 4.1.16. Yet haven't had a stable release since 4.1.12. Reviewing the release notes I don't see any difference between CVS HEAD and 4.1.16 except for my recent addition of the DataSource Realm. Why tag 4.1.17 when there are so few changes? Because: - I usually update the release notes right before tagging, so the changes are actually more significant - feedback on 4.1.16 has been uneventful, so we should try to get a stable release to replace 4.1.12 ASAP, as many bugs have been fixed since then Remy Could you please update the release notes first before proposing a tag? That way others can better evaluate whether necessary changes have made it into CVS before you tag a new version. Thanks, Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Costin Manolache wrote: Remy Maucherat wrote: If the vote actually passes, I'd like to have only one minimal Tomcat distribution, which would mean no admin and no Jasper (with separate optional Jasper binaries available). JMX can be used directly (using a MX4J connector + MC4J, assuming MC4J updates to MX4J 1.1.1 as we did) to administer the server, without the need to use the admin webapp. Now - this is not nice ! I don't know why my proposal for a minimal tomcat that includes jsr152 and jsr154 shouldn't be allowed. Ok, I'll make a VOTE and try to gather the votes - hopefully I'll get at least 3 +1 votes ( and you'll at least -0 it :-). I'd really like to avoid the proliferation of too many distributions. The light distribution confused a lot of users who didn't know what they needed, from what I've seen (from what I've read on tc-user). To restate it: if we do a minimal version and it is voted to be Jasper less, then I think we shouldn't have a third minimal-but-with-Jasper distribution. Rather, I'd have a separate binary holding the Jasper JARs. That's just my preference anyway. BTW, in such vote, it should be Yes or No. If you don't care, then you shouldn't vote. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
Costin Manolache wrote: Since things may get confusing around here, I would like to have an official vote on my prior proposal. This is the list of included features: Libs: - JMX - JAAS - JNDI - digester ( and beanutils, collections it needs ). - modeler - ant ( used for startup and automation of some tasks ) - commons-logging When/if the JNDI-based abstraction of config files is ready we'll not need digester - but most likely it'll still be required by modeler, and also by jasper, so I don't think we can remove it. Tomcat: - subset of catalina ( non-deprecated interfaces and base impl that is required for tomcat to work ). - coyote - tomcat-util - http11/jk2 - all valves/etc that are required for tomcat to operate. - naming - jasper ( at least jasper runtime - but probably the whole thing ). Votes: [ ] +1 I like the idea, I might help [ ] -1 I don't like the idea, I won't help. +0,5 : I like the idea, but have little time to help these days. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: If the vote actually passes, I'd like to have only one minimal Tomcat distribution, which would mean no admin and no Jasper (with separate optional Jasper binaries available). JMX can be used directly (using a MX4J connector + MC4J, assuming MC4J updates to MX4J 1.1.1 as we did) to administer the server, without the need to use the admin webapp. Now - this is not nice ! I don't know why my proposal for a minimal tomcat that includes jsr152 and jsr154 shouldn't be allowed. Ok, I'll make a VOTE and try to gather the votes - hopefully I'll get at least 3 +1 votes ( and you'll at least -0 it :-). I'd really like to avoid the proliferation of too many distributions. The light distribution confused a lot of users who didn't know what they needed, from what I've seen (from what I've read on tc-user). To restate it: if we do a minimal version and it is voted to be Jasper less, then I think we shouldn't have a third minimal-but-with-Jasper distribution. Rather, I'd have a separate binary holding the Jasper JARs. That's just my preference anyway. BTW, in such vote, it should be Yes or No. If you don't care, then you shouldn't vote. What about using a minimal tomcat core with plugged modules to give access to jsp/jmx ? Will make both Costin, and Jon happy and let us have only one distribution with clear indication in server.xml on how to activate/desactive such module. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Jon Scott Stevens wrote: One last point, we should be able to experiment around here. The negative votes have been based on biases about what I think about Jasper and my opinions. They are not based on the idea that experimentation is a good thing and I think that is just plain wrong and very closed minded. Who are you to decide what our users may or may not like? In the end, if things don't work out, then fine at least we learned something and we can move on to the next thing. No Jon - my vote wasn't based on your biasses about jasper, but on the biasses of many members of the tomcat community. 5.0 was supposed to be the release we make togheter, as a united community based on consensus. There is one jakarta project where experimentation without consensus was the operating mode - and I certainly don't like the result. You may remember about the division of the tomcat community on 3.3/4.0 - and I don't think 69K of code ( jasper runtime ) would justify another division. What do we really have to loose here? Consensus. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Costin Manolache wrote: Jon Scott Stevens wrote: One last point, we should be able to experiment around here. The negative votes have been based on biases about what I think about Jasper and my opinions. They are not based on the idea that experimentation is a good thing and I think that is just plain wrong and very closed minded. Who are you to decide what our users may or may not like? In the end, if things don't work out, then fine at least we learned something and we can move on to the next thing. No Jon - my vote wasn't based on your biasses about jasper, but on the biasses of many members of the tomcat community. 5.0 was supposed to be the release we make togheter, as a united community based on consensus. There is one jakarta project where experimentation without consensus was the operating mode - and I certainly don't like the result. You may remember about the division of the tomcat community on 3.3/4.0 - and I don't think 69K of code ( jasper runtime ) would justify another division. What do we really have to loose here? Consensus. People cannot agree on everything. Here, we're talking about relatively minor topics. This issue won't end up in a division of the community, but rather in one additional binary distribution based on the same codebase. I can live with that (well, as long as I'm not the one building them all ;-) ). If the lack of consensus spreads to more serious topics (like a 4.2.x branch), then I would agree it could be worrying. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15185] New: - problem with SSL and jdk1.4
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=15185. 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=15185 problem with SSL and jdk1.4 Summary: problem with SSL and jdk1.4 Product: Tomcat 4 Version: 4.0.6 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Blocker Priority: Other Component: Connector:HTTP/1.1 (deprecated) AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi, I have reported the following problem to Sun and they have answered this: Hi Thomas, This appears to be a problem with Tomcat. Could you please forward this bug to the jakarta bug database at http://jakarta.apache.org/site/bugs.html? They will analyze the problem and alert us if there is a bug in the jdk. Regards, Nathanael - Original Bug Report--- category : java release : 1.4.1 subcategory : classes_security type : bug synopsis : NoSuchMethodError using JSEE provided with jsdk1.4.1 and Tomcat4 description : FULL PRODUCT VERSION : java version 1.4.1_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01) Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) FULL OPERATING SYSTEM VERSION :Windows NT Version 4.0 A DESCRIPTION OF THE PROBLEM : Dear Sirs, I have tried to use Tomcat 4.6.0 with https and j2sdk1.4.1. The following problem occurs: java.lang.NoSuchMethodError: java.security.interfaces.RSAPrivateCrtKey.getPrivateExponent ()Ljava/math/BigInteger; at com.sun.net.ssl.internal.ssl.SunJSSE_bl.a(DashoA6275) at com.sun.net.ssl.internal.ssl.SunJSSE_be.init(DashoA6275) at com.sun.net.ssl.internal.ssl.SunJSSE_aw.a(DashoA6275) at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275) at com.sun.net.ssl.internal.ssl.AppInputStream.read(DashoA6275) at org.apache.catalina.connector.http.SocketInputStream.fill (SocketInputStream.java:593) at org.apache.catalina.connector.http.SocketInputStream.read (SocketInputStream.java:530) at org.apache.catalina.connector.http.SocketInputStream.readReq uestLine(SocketInputStream.java:199) at org.apache.catalina.connector.http.HttpProcessor.parseReques t(HttpProcessor.java:710) at org.apache.catalina.connector.http.HttpProcessor.process (HttpProcessor.java:974) at org.apache.catalina.connector.http.HttpProcessor.run (HttpProcessor.java:1125) at java.lang.Thread.run(Thread.java:536) With j2sdk1.3 and the same configuration there are no problems. REGRESSION. Last worked in version 1.3.1 STEPS TO FOLLOW TO REPRODUCE THE PROBLEM : 1.Install js2dk1.4.1 2.Install jakarta-tomcat-4.0.6-LE-jdk14.zip 3.Configure a https connector 4.Generate a key with the keytool as described in the manual 5.Run Tomcat 6.Start a Browser and use this URL https://localhost:8443 EXPECTED VERSUS ACTUAL BEHAVIOR : You should get the welcome site of Tomcat4, but you get nothing because the connention hangs. In the catlina_log you get the entry above ERROR MESSAGES/STACK TRACES THAT OCCUR : java.lang.NoSuchMethodError: java.security.interfaces.RSAPrivateCrtKey.getPrivateExponent() Ljava/math/BigInteger; at com.sun.net.ssl.internal.ssl.SunJSSE_bl.a(DashoA6275) at com.sun.net.ssl.internal.ssl.SunJSSE_be.init(DashoA6275) at com.sun.net.ssl.internal.ssl.SunJSSE_aw.a(DashoA6275) at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275) at com.sun.net.ssl.internal.ssl.AppInputStream.read(DashoA6275) at org.apache.catalina.connector.http.SocketInputStream.fill (SocketInputStream.java:593) at org.apache.catalina.connector.http.SocketInputStream.read (SocketInputStream.java:530) at org.apache.catalina.connector.http.SocketInputStream.readRequestLine (SocketInputStream.java:199) at org.apache.catalina.connector.http.HttpProcessor.parseRequest (HttpProcessor.java:710) at org.apache.catalina.connector.http.HttpProcessor.process (HttpProcessor.java:974) at org.apache.catalina.connector.http.HttpProcessor.run (HttpProcessor.java:1125) at java.lang.Thread.run(Thread.java:536) REPRODUCIBILITY : This bug can be reproduced always. -- BEGIN SOURCE -- Please get the source from the jakarta project. -- END SOURCE -- workaround : suggested_val : cust_name : Thomas Thomas cust_email : [EMAIL PROTECTED] jdcid : tmaesing1 keyword : webbug company : BGS
RE: Patch for isapi_redirector2
Hola Joakim: I'm not sure where to send the patch, I hope I don't abuse this list by submitting it here. Thanks !!, please read http://jakarta.apache.org/site/source.html to know to do it, and the format needed.. You can send it to this mail list and/or post it in bugzilla to, dont forget to put a [Patch] prefix in the summary line of the bug and the Re: of the message. BTW: I would do it in both ways, to ensure it gets correctly archived and managed... so nobody could say that your contribution was not seen.. :) Saludos, Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Jon Scott Stevens wrote: What I would love to see is a tree of downloads where each one gains more and more features (it is additive). Such as: JSR-154 Implementation / \ Jasper Velocity / \ \ Admin Tool (JMX) Java Server Feces Scarab That way, you only need to download what you need. Bundles are easily created by simply picking off the branch of the tree that you want. If you want the Tomcat distribution with web based administration abilities, then you grab it at the Admin Tool level and so on. We can even build an ant based system which is able to help us manage the selection of components to include in the distribution. This would be similar to the way that we currently have jar repositories and dependencies, but on an application level. Click here to install Jasper, Struts, etc. Not only does this provide our users the ability to simply get what they need (and add it after the fact if they don't have it), it helps us focus on providing a pluggable system which is separate from the other systems (ie: clean dependencies). I personally think that this is a much cleaner way of providing distributions because it does not require people to learn or deal with things they do not care about. Options are a good thing. Let's not limit ourselves. Youy don't need to learn JSP/Admin Tool if you don't use it. The actual Tomcat installation doesn't require you to learn the Admin Tool or JSP One last point, we should be able to experiment around here. The negative votes have been based on biases about what I think about Jasper and my opinions. They are not based on the idea that experimentation is a good thing and I think that is just plain wrong and very closed minded. Who are you to decide what our users may or may not like? In the end, if things don't work out, then fine at least we learned something and we can move on to the next thing. I'm with this group since August, and did not see any post from you since last week. So my vote is certainly not based on your biaises :-). And I am not using the Admin Tool at all personnaly What do we really have to loose here? Simplicity. But since we don't have any statistic about the user (what we want, what he use when he download Tomcat), it is hard to prove he doesn't use JSP/Admin Tool/JMX, and hard to prove he doesn't use it. -jon -- Jeanfrancois -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Glenn Nielsen wrote: Jeanfrancois Arcand wrote: Jon Scott Stevens wrote: Create a separate minimal JSR 154 only distribution of Tomcat 4.x: +1 [] 0 [] -1 [X] -jon (1) Jasper is very a very small jar file. (2) The Admin Tool should go with the minimal distribution of Tomcat. We decided to include JMX in Tomcat distribution...what's the point having JMX and not the Admin Tool? Maybe JSP is not required by all Tomcat users, but I'm sure a lot of them like to have the Admin Tool . Not to pick on Jean Francois, but many times I have seen tomcat devs discuss what the users want or use when discussing features. I have no real idea what features tomcat users use or what features they want, other than anecdotal. Are there any facts behind the statement but I'm sure a lot of them like to have the Admin Tool.? No, there aren't. Just based on my reading of Tomcat-users(IMBW). But can we say that as well with JSP (people don't need it ?). If yes, then I will change my vote and help building a minimal distribution without JSP. -- Jeanfrancois -- 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 3888] - WebappClassLoader: Lifecycle error : CL stopped
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=3888. 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=3888 WebappClassLoader: Lifecycle error : CL stopped [EMAIL PROTECTED] changed: What|Removed |Added OS/Version|MacOS X |All Platform|Macintosh |All --- Additional Comments From [EMAIL PROTECTED] 2002-12-09 17:23 --- I also confirm that it occurs with Tomcat 4.0.3 and 4.1.12. I don't use log4j. My platform is a PC with Windows NT 4. It seems to happen only when the webapp is restarted (because of a class or property file changed) I'll try to track what has been done when it happens -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15105] - pushBody()/popBody() error on tomcat 4.1.12
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=15105. 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=15105 pushBody()/popBody() error on tomcat 4.1.12 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Additional Comments From [EMAIL PROTECTED] 2002-12-09 17:42 --- Lets verify all together the code :D On the file PageContentImpl.java we have the two methods public BodyContent pushBody() { depth++; if (depth = outs.length) { BodyContent[] newOuts = new BodyContentImpl[depth + 1]; for (int i = 0; i outs.length; i++) { newOuts[i] = outs[i]; } newOuts[depth] = new BodyContentImpl(out); outs = newOuts; } out = outs[depth]; return outs[depth]; } public JspWriter popBody() { depth--; if (depth = 0) { out = outs[depth]; } else { out = baseOut; } return out; } As we can see on the code if we make two calls to pushBody(), then the array outs will have two body outs A and B. If we make a popBody, then depth will be decremented, but the B object is not removed from the outs array, then if I make another pushBody() (this should create a new out object C, this is not done), the outs array will have again two objects, but the second object will not be a new one, it will be the previous B object. Then what will be in the second element will be the new content plus previous content from B object,that is, the new content will be appended. Is not this the way it should work ? That is, create a new object when we make a pushBody() OR clear the old object when we make a popBody(). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
Remy Maucherat wrote: Votes: [ ] +1 I like the idea, I might help [ ] -1 I don't like the idea, I won't help. I'll have to vote -1 until the other vote completes, and then, I'll either be: - +1 if Jon's proposal doesn't pass - -1 if Jon proposal is accepted, unless Jasper is removed from the list I think this is at least unfair. I started the discussion on minimal tomcat before Jon's vote. I was trying to get a consensus and opinions to shape the proposal. Jon jumped in with the vote. I don't think who proposes the vote first wins is the best solution, I don't think we are even talking about the same thing ( Jon wants a JSR154-only, I'm proposing a minimal tomcat ). I don't see why a vote on Jon's proposal would affect my proposal ( or any future vote ). As I said, I'd like to limit to 2 maximum the amount of Tomcat binary distributions (I think two is too much, actually, but still is acceptable). Then make a proposal that maximum 2 tomcat binary distribution should be allowed. But even in this case - I think I am allowed to propose that one of the distributions ( the small one ) includes jasper runtime and is not called jsr154 only. Even if Jon's vote is passing. If your -1 vote on minimal tomcat ( that includes jasper ) is based on concerns that we'll have too many distributions - I agree it's a valid reason, and I know you don't need a reason to vote -1. I have no problem with a vote on minimal tomcat to not include jasper compiler ( or even jasper runtime ) - if this gets a majority of votes than it can happen. The reverse is a bit more difficult - i.e. we can't include jasper in a JSR154 only ( as Jon proposed ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1.17] Tag soon ?
Remy Maucherat wrote: I don't see any major issues with 4.1.16, so I plan to tag 4.1.17 (which hopefully would be the next stable build) tomorrow after a few more minor tweaks. There was a report made against JK 2 immediately after 4.1.16 Beta was announced. Can someone confirm there's no major issue with JK ? I made the report and I can confirm that it still isn't working. I'm using exacly the same configuration as for 4.1.12 and 4.1.14 both of which work. There's some fixes we're looking for in the new release so I've been monitoring the list. Should I raise a bug instead of emailing the list? -- Regards, M Martin Sillence PR Newswire DL +44 (0)1865 78 5065 F +44 (0)1865 78 5100 W www.prnewswire.eu.com --- Any views or opinions are solely those of the author and do not necessarily represent those of PR Newswire Europe. The e-mail contents are intended only for addressee and may contain confidential and/or privileged material. If you are not the intended recipient, please do not read, copy, use or disclose this communication and notify the sender. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Henri Gomez wrote: What about using a minimal tomcat core with plugged modules to give access to jsp/jmx ? There is already some support for that ( server/webapps is very similar with the 3.3 modules - i.e. trusted components ). It'll need few changes to deal with the loader issues ( i.e. they should be included in the server loader - quite easy ). The option I preffer for that is to use JMX. Each pluggin will be an mbean that is loaded using either an mlet-like or via a deployment descriptor ( server/webapps is also fine - using webapps as plugin units ). JMX notifications can be easily used to have the plugin loading/unloading very flexible. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15189] New: - Error message provided when jsp:param element is not used properly is misleading
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=15189. 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=15189 Error message provided when jsp:param element is not used properly is misleading Summary: Error message provided when jsp:param element is not used properly is misleading Product: Tomcat 5 Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Jasper2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Example: test.jsp -- jsp:param name=param1 value=value1 / %-- end of JSP --% When Jasper processes this page the following error message is returned: 'The action is not a recognizable standard action.' This is somewhat misleading since jsp:param is a valid standard action, but the usage context is incorrect. I would like to request that the parser be enhanced to handle such cases so that meaningful error messages can be provided. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/cluster JGCluster.java JGManager.java ReplicatedSession.java ReplicationStream.java SerializablePrincipal.java SessionMessage.java
Remy wrote: I'd like to get the save/restore on shutdown features of the std manager, and can't really see any major problem it would cause. could be a little tricky. how would you do this without getting the nodes out of sync. then, when a server joins a cluster, there is a possibility that some sessions might not get replicated correctly, because a state transfer has to happen. Thanks to Bela Ban pointing this out and later in the future, instead of having every node keep a copy of the session, just use primary and secondary servers for the cluster data. So only two servers are active members of the cluster ? nope, it would be more weblogic style, so all servers are members of the cluster, but data only gets replicated between two of them. Is a cluster with let's say 6 members really too expensive network wise (assuming a dedicated gig ether link between the cluster members) ? depends on how much data is being transferred. so the answer could be yes and no, the current implementation is more expensive than the primary/secondary solution I was talking about. Anyway, I think by far the most important feature to add is a TCP or HTTP redirector, possibly written with NBIO. Until then, the clustering doesn't have much practical interest (usless you're willing to buy additional expensive hardware; could squid get the job done, BTW ?). you mean a software load balancer, there are a bunch of them out there already. I use my homegrown in Java. I'm ok with proposing you as a committer, provided you accept to respect I would like to continue the work on this. I think that Bela and myself would be a big resource to Tomcat clustering. Filip -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tomcat without DOS Window on Win XP, i.e. like an NT Service?
Anyone know how to start Tomcat without the DOS window on Win XP? Micael --- This electronic mail transmission and any accompanying documents contain information belonging to the sender which may be confidential and legally privileged. This information is intended only for the use of the individual or entity to whom this electronic mail transmission was sent as indicated above. If you are not the intended recipient, any disclosure, copying, distribution, or action taken in reliance on the contents of the information contained in this transmission is strictly prohibited. If you have received this transmission in error, please delete the message. Thank you -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat without DOS Window on Win XP, i.e. like an NT Service?
-Original Message- From: micael [mailto:[EMAIL PROTECTED]] Sent: Monday, December 09, 2002 1:11 PM To: [EMAIL PROTECTED] Subject: Tomcat without DOS Window on Win XP, i.e. like an NT Service? Anyone know how to start Tomcat without the DOS window on Win XP? Micael So-called NT services should still work on Win XP. I haven't done it myself, but some of my coworkers have. -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
mod_jk/mod_jk2 binaries for FreeBSD and Apache 2.0.43
Please, can you send me JK/JK2 binaries for Apache 2.0.43 FreeBSD ? thanks, Andy ---should provide new binaries for JK and JK2. I'll do JK/JK2 for Linux boxes (and FreeBSD) Who could do the same for Windows, Netware and Solaris ? BTW, I'm still waiting an account on moof to build a MacOSX version. --- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session ManagerBase.java
remm2002/12/09 11:07:36 Modified:catalina/src/share/org/apache/catalina/session ManagerBase.java Log: - Add missing commit for the cluster features. Revision ChangesPath 1.6 +16 -6 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/ManagerBase.java Index: ManagerBase.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/ManagerBase.java,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- ManagerBase.java 9 Dec 2002 15:57:43 - 1.5 +++ ManagerBase.java 9 Dec 2002 19:07:36 - 1.6 @@ -643,7 +643,7 @@ if (session != null) session.setManager(this); else -session = new StandardSession(this); +session = getNewSession(); return(session); } @@ -715,6 +715,15 @@ // -- Protected Methods + +/** + * Get new session class to be used in the doLoad() method. + */ +protected StandardSession getNewSession() { +return new StandardSession(this); +} + + protected void getRandomBytes( byte bytes[] ) { // Generate a byte array containing a session identifier if( devRandomSource!=null randomIS==null ) { @@ -735,7 +744,8 @@ Random random = getRandom(); getRandom().nextBytes(bytes); } - + + /** * Generate and return a new session identifier. */ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/clusterJGCluster.java JGManager.java ReplicatedSession.java ReplicationStream.javaSerializablePrincipal.java SessionMessage.java
Filip Hanik wrote: Remy wrote: I'd like to get the save/restore on shutdown features of the std manager, and can't really see any major problem it would cause. could be a little tricky. how would you do this without getting the nodes out of sync. After reloading and passivating, the node will pull the list of sessions from the monitor. I agree this could end up out of sync, but this is a useful feature, otherwise the sessions go with the cluster. then, when a server joins a cluster, there is a possibility that some sessions might not get replicated correctly, because a state transfer has to happen. Thanks to Bela Ban pointing this out and later in the future, instead of having every node keep a copy of the session, just use primary and secondary servers for the cluster data. So only two servers are active members of the cluster ? nope, it would be more weblogic style, so all servers are members of the cluster, but data only gets replicated between two of them. Ok, why not. Is a cluster with let's say 6 members really too expensive network wise (assuming a dedicated gig ether link between the cluster members) ? depends on how much data is being transferred. so the answer could be yes and no, the current implementation is more expensive than the primary/secondary solution I was talking about. Obviously. It's a lot simpler of course ;-) Anyway, I think by far the most important feature to add is a TCP or HTTP redirector, possibly written with NBIO. Until then, the clustering doesn't have much practical interest (usless you're willing to buy additional expensive hardware; could squid get the job done, BTW ?). you mean a software load balancer, there are a bunch of them out there already. I use my homegrown in Java. Yes, I mean that. If it is useful and works, maybe you'd want to add it in JG or contribute it to Tomcat. I'm ok with proposing you as a committer, provided you accept to respect I would like to continue the work on this. I think that Bela and myself would be a big resource to Tomcat clustering. Ok, I will nominate you then. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
Costin Manolache wrote: Remy Maucherat wrote: Votes: [ ] +1 I like the idea, I might help [ ] -1 I don't like the idea, I won't help. I'll have to vote -1 until the other vote completes, and then, I'll either be: - +1 if Jon's proposal doesn't pass - -1 if Jon proposal is accepted, unless Jasper is removed from the list I think this is at least unfair. I started the discussion on minimal tomcat before Jon's vote. I was trying to get a consensus and opinions to shape the proposal. Jon jumped in with the vote. I don't think who proposes the vote first wins is the best solution, I don't think we are even talking about the same thing ( Jon wants a JSR154-only, I'm proposing a minimal tomcat ). I don't see why a vote on Jon's proposal would affect my proposal ( or any future vote ). As I said, I'd like to limit to 2 maximum the amount of Tomcat binary distributions (I think two is too much, actually, but still is acceptable). Then make a proposal that maximum 2 tomcat binary distribution should be allowed. But even in this case - I think I am allowed to propose that one of the distributions ( the small one ) includes jasper runtime and is not called jsr154 only. Even if Jon's vote is passing. If your -1 vote on minimal tomcat ( that includes jasper ) is based on concerns that we'll have too many distributions - I agree it's a valid reason, and I know you don't need a reason to vote -1. I have no problem with a vote on minimal tomcat to not include jasper compiler ( or even jasper runtime ) - if this gets a majority of votes than it can happen. The reverse is a bit more difficult - i.e. we can't include jasper in a JSR154 only ( as Jon proposed ) I agree this is unfair for your vote, and should be an independent issue. I'm reverting to my previous vote then (it was +1). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
Votes: [X] +1 I like the idea, I might help [ ] -1 I don't like the idea, I won't help. Costin -- Jeanfrancois -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
on 2002/12/9 7:16 AM, Costin Manolache [EMAIL PROTECTED] wrote: Votes: [ ] +1 I like the idea, I might help [ ] -1 I don't like the idea, I won't help. +0 I don't have time to help, but I like the idea. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/9 7:27 AM, Remy Maucherat [EMAIL PROTECTED] wrote: I'd really like to avoid the proliferation of too many distributions. I don't agree with that. There is nothing wrong with giving users choices. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/9 7:32 AM, Henri Gomez [EMAIL PROTECTED] wrote: What about using a minimal tomcat core with plugged modules to give access to jsp/jmx ? Will make both Costin, and Jon happy and let us have only one distribution with clear indication in server.xml on how to activate/desactive such module. That does not make me happy. You are missing my point. Read the subject line of this message. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/9 7:51 AM, Costin Manolache [EMAIL PROTECTED] wrote: No Jon - my vote wasn't based on your biasses about jasper, but on the biasses of many members of the tomcat community. So, you speak for these people? I don't think so. 5.0 was supposed to be the release we make togheter, as a united community based on consensus. My proposal has nothing to do with that. There is one jakarta project where experimentation without consensus was the operating mode - and I certainly don't like the result. You may remember about the division of the tomcat community on 3.3/4.0 - and I don't think 69K of code ( jasper runtime ) would justify another division. I find it really funny that you are now forced to work on 4.x. Consensus. What consensus? This has nothing to do with which container to use. It has everything to do with giving people options. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/9 8:21 AM, Remy Maucherat [EMAIL PROTECTED] wrote: People cannot agree on everything. Here, we're talking about relatively minor topics. This issue won't end up in a division of the community, but rather in one additional binary distribution based on the same codebase. I can live with that (well, as long as I'm not the one building them all ;-) ). If the lack of consensus spreads to more serious topics (like a 4.2.x branch), then I would agree it could be worrying. Remy Finally, Remy is starting to see the light. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/9 9:14 AM, Jeanfrancois Arcand [EMAIL PROTECTED] wrote: I personally think that this is a much cleaner way of providing distributions because it does not require people to learn or deal with things they do not care about. Options are a good thing. Let's not limit ourselves. Youy don't need to learn JSP/Admin Tool if you don't use it. The actual Tomcat installation doesn't require you to learn the Admin Tool or JSP Read what I wrote again. I said Learn or deal with and I made no specific point about the JSP/Admin Tool. I'm with this group since August, and did not see any post from you since last week. So my vote is certainly not based on your biaises :-). You vote is based on a lack of history and a view of the larger picture. Simplicity. But since we don't have any statistic about the user (what we want, what he use when he download Tomcat), it is hard to prove he doesn't use JSP/Admin Tool/JMX, and hard to prove he doesn't use it. Exactly my point. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
on 2002/12/9 9:37 AM, Costin Manolache [EMAIL PROTECTED] wrote: I don't see why a vote on Jon's proposal would affect my proposal ( or any future vote ). I agree. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
on 2002/12/9 9:37 AM, Costin Manolache [EMAIL PROTECTED] wrote: Then make a proposal that maximum 2 tomcat binary distribution should be allowed. I will -1 this vote. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/cluster JGCluster.java JGManager.java ReplicatedSession.java ReplicationStream.java SerializablePrincipal.java SessionMessage.java
After reloading and passivating, the node will pull the list of sessions from the monitor. I agree this could end up out of sync, but this is a useful feature, otherwise the sessions go with the cluster. actually, once I have the primary/secondary implementation, the secondary server can store the sessions to file. you just gave me an idea :)) Filip ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect www.filip.net -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Monday, December 09, 2002 11:13 AM To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/cluster JGCluster.java JGManager.java ReplicatedSession.java ReplicationStream.java SerializablePrincipal.java SessionMessage.java Filip Hanik wrote: Remy wrote: I'd like to get the save/restore on shutdown features of the std manager, and can't really see any major problem it would cause. could be a little tricky. how would you do this without getting the nodes out of sync. then, when a server joins a cluster, there is a possibility that some sessions might not get replicated correctly, because a state transfer has to happen. Thanks to Bela Ban pointing this out and later in the future, instead of having every node keep a copy of the session, just use primary and secondary servers for the cluster data. So only two servers are active members of the cluster ? nope, it would be more weblogic style, so all servers are members of the cluster, but data only gets replicated between two of them. Ok, why not. Is a cluster with let's say 6 members really too expensive network wise (assuming a dedicated gig ether link between the cluster members) ? depends on how much data is being transferred. so the answer could be yes and no, the current implementation is more expensive than the primary/secondary solution I was talking about. Obviously. It's a lot simpler of course ;-) Anyway, I think by far the most important feature to add is a TCP or HTTP redirector, possibly written with NBIO. Until then, the clustering doesn't have much practical interest (usless you're willing to buy additional expensive hardware; could squid get the job done, BTW ?). you mean a software load balancer, there are a bunch of them out there already. I use my homegrown in Java. Yes, I mean that. If it is useful and works, maybe you'd want to add it in JG or contribute it to Tomcat. I'm ok with proposing you as a committer, provided you accept to respect I would like to continue the work on this. I think that Bela and myself would be a big resource to Tomcat clustering. Ok, I will nominate you then. Remy -- 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: [VOTE] minimal JSR 154 only distribution
Jon Scott Stevens wrote: on 2002/12/9 7:51 AM, Costin Manolache [EMAIL PROTECTED] wrote: No Jon - my vote wasn't based on your biasses about jasper, but on the biasses of many members of the tomcat community. So, you speak for these people? I don't think so. No, I speak for myself. I like and use jasper - and I think the tomcat official releases should include both tomcat and jasper. Just like you don't speak for the users. 5.0 was supposed to be the release we make togheter, as a united community based on consensus. My proposal has nothing to do with that. 2 -1 and one -0 vote versus 3 +1 votes doesn't look like a consensus. If Sun or anyone else wants to release a JSR154-only product - they can do it and we should make it easy to do so. I don't think we should do it ( as tomcat community ). I heard the argument about user choice and freedom to experiment on avalon ( to justify everyone releasing his own container ). I think their current attempt to have a single product is a move in the right direction. Consensus. What consensus? This has nothing to do with which container to use. It has everything to do with giving people options. Is Apache http having n different releases with all the possible combinations of modules ( to give users choice ) ? They include all the modules in the httpd repository ( some disabled by default ). That also goes against my proposal for minimal tomcat as well - and supports Remy's argument that we should have one release. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] Update Tomcat-Admin-ja ResourceFile
Hi, Tomcat Commiters, This patch updates a Japanese resource file of Tomcat Administration Tool. (ApplicationResources_ja.properties) I translated the messages modified/added between 4.1.7 and 4.1.16. I made it as such: $ diff -u \ jakarta-tomcat-4.1.16-beta-LE-jdk14-original/server/webapps/admin/WEB-INF/cl asses/org/apache/webapp/admin/ApplicationResources_ja.properties \ jakarta-tomcat-4.1.16-beta-LE-jdk14-new/server/webapps/admin/WEB-INF/classes /org/apache/webapp/admin/ApplicationResources_ja.properties \ tomcat-admin-ja-res4.1.16.patch I hope you take this patch. Thanks. --- MORIGUCHI Hirokazu [EMAIL PROTECTED],[EMAIL PROTECTED] tomcat-admin-ja-res4.1.16.patch Description: Binary data ApplicationResources_ja.properties Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Jon Scott Stevens wrote: If Sun or anyone else wants to release a JSR154-only product - they can do it and we should make it easy to do so. I don't think we should do it ( as tomcat community ). Why? So far, you haven't even given a real reason. That may be because every reason you don't like is not real. So far you qualified as invalid every reason that everyone mentioned. You are so funny! How quickly you seem to change your mind. Go back and I have a feeling almost everyone changed his mind in some issues in the last 2 years. You seem to be one exception, and I don't know if this is a good thing :-) Is Apache http having n different releases with all the possible combinations of modules ( to give users choice ) ? They include all the modules in the httpd repository ( some disabled by default ). They don't distribute PHP. So, why should we distribute JSP? PHP is not developed by the httpd community. ( but php.apache.org ). Jasper is developed by the tomcat community - same mailing list, same avail list. Anyway - as long as Bill is supporting the no-jasper release, I won't change my vote to -1 ( but keep it -0). I haven't contributed that much to jasper - and it's up to jasper people to decide what they feel ( by voting +1 or -1 ). Costin -- 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 Parser.java
luehe 2002/12/09 13:51:57 Modified:jasper2/src/share/org/apache/jasper/compiler Parser.java Log: Standard syntax: - Added uri and local name to custom action attributes. - Enforce restriction that if a dynamic attribute has a prefix that doesn't map to a namespace (taglib), a translation error is caused. Revision ChangesPath 1.42 +26 -8 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java Index: Parser.java === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java,v retrieving revision 1.41 retrieving revision 1.42 diff -u -r1.41 -r1.42 --- Parser.java 5 Dec 2002 17:56:43 - 1.41 +++ Parser.java 9 Dec 2002 21:51:56 - 1.42 @@ -199,11 +199,29 @@ * Note: JSP and XML spec does not allow while spaces around Eq. It is * added to be backward compatible with Tomcat, and with other xml parsers. */ -private boolean parseAttribute(AttributesImpl attrs) throws JasperException { - String name = parseName(); - if (name == null) +private boolean parseAttribute(AttributesImpl attrs) + throws JasperException { + + // Get the qualified name + String qName = parseName(); + if (qName == null) return false; + // Determine prefix and local name components + String localName = qName; + String uri = ; + int index = qName.indexOf(':'); + if (index != -1) { + String prefix = qName.substring(0, index); + TagLibraryInfo tagLibInfo = (TagLibraryInfo) taglibs.get(prefix); + if (tagLibInfo == null) { + err.jspError(reader.mark(), + jsp.error.attribute.invalidPrefix, prefix); + } + uri = tagLibInfo.getURI(); + localName = qName.substring(index+1); + } + reader.skipSpaces(); if (!reader.matches(=)) err.jspError(reader.mark(), jsp.error.attribute.noequal); @@ -218,8 +236,8 @@ watchString = %; watchString = watchString + quote; - String attr = parseAttributeValue(watchString); - attrs.addAttribute(, name, name, CDATA, attr); + String attrValue = parseAttributeValue(watchString); + attrs.addAttribute(uri, localName, qName, CDATA, attrValue); return true; } -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
oracle 9i jdbc driver -- class12.zip or class12.jar
Hello, I just installed the Tomcat package, and now try to find oracle 9i jdbc driver, class12.zip or class12.jar. Does any one know the path to download this file? I am using PC version Oracle 9i. Thank you very much. Ping 12/9/02 __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15201] New: - ClassCastException in JkCoyoteHandler.action() with SSL
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=15201. 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=15201 ClassCastException in JkCoyoteHandler.action() with SSL Summary: ClassCastException in JkCoyoteHandler.action() with SSL Product: Tomcat 4 Version: 4.1.16 Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This is seen using the just-released Debian 4.1.16-1 package. (I haven't been able to build Tomcat yet.) I get the following in my catalina.out log: --- 0 [main] INFO common.ChannelSocket - JK2: ajp13 listening on localhost/127.0.0.1:8009 300 [main] INFO server.JkMain - Jk running ID=0 time=20/4751 config=/usr/share/tomcat4/conf/jk2.properties --- When I try to connect, over SSL via Apache, I get the following addition: --- 32394 [Thread-4] ERROR server.JkCoyoteHandler - Error in action code java.lang.ClassCastException at org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:382) at org.apache.coyote.Response.action(Response.java:216) at org.apache.coyote.tomcat4.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:310) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:221) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:261) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:360) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:604) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:562) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:679) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:533) at java.lang.Thread.run(Thread.java:536) --- There seem to be no ill effects, though. The request completes anyway. The configuration hasn't changed from my earlier 4.1.12 installation. -- 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/resources messages.properties messages_fr.properties
luehe 2002/12/09 14:17:32 Modified:jasper2/src/share/org/apache/jasper/compiler Parser.java jasper2/src/share/org/apache/jasper/resources messages.properties messages_fr.properties Log: Fixed Bugzilla 15189: Error message provided when jsp:param element is not used properly is misleading Revision ChangesPath 1.43 +9 -7 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java Index: Parser.java === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java,v retrieving revision 1.42 retrieving revision 1.43 diff -u -r1.42 -r1.43 --- Parser.java 9 Dec 2002 21:51:56 - 1.42 +++ Parser.java 9 Dec 2002 22:17:32 - 1.43 @@ -1165,7 +1165,7 @@ *| 'plugin'StdActionContent *| 'element' StdActionContent */ -private void parseAction(Node parent) throws JasperException { +private void parseStandardAction(Node parent) throws JasperException { Mark start = reader.mark(); if (reader.matches(include)) { @@ -1196,8 +1196,10 @@ parsePlugin(parent); } else if (reader.matches(element)) { parseElement(parent); + } else if (reader.matches(param)) { + err.jspError(start, jsp.error.param.invalidUse); } else { - err.jspError(start, jsp.error.badaction); + err.jspError(start, jsp.error.badStandardAction); } } @@ -1447,7 +1449,7 @@ } else if (reader.matches(${)) { parseELExpression(parent); } else if (reader.matches(jsp:)) { - parseAction(parent); + parseStandardAction(parent); } else if (!parseCustomTag(parent)) { parseTemplateText(parent); } @@ -1501,7 +1503,7 @@ } else if (reader.matches(${)) { parseELExpression(parent); } else if (reader.matches(jsp:)) { - parseAction(parent); + parseStandardAction(parent); } else if (!parseCustomTag(parent)) { parseTemplateText(parent); } 1.65 +4 -2 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties Index: messages.properties === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties,v retrieving revision 1.64 retrieving revision 1.65 diff -u -r1.64 -r1.65 --- messages.properties 6 Dec 2002 19:11:53 - 1.64 +++ messages.properties 9 Dec 2002 22:17:32 - 1.65 @@ -103,6 +103,7 @@ jsp.error.attempt_to_clear_flushed_buffer=Error: Attempt to clear a buffer that's already been flushed jsp.error.overflow=Error: JSP Buffer overflow jsp.error.paramexpected=Expected \param\ tag with \name\ and \value\ attributes +jsp.error.param.invalidUse=The jsp:param action must not be used outside the jsp:include, jsp:forward, or jsp:params elements jsp.error.closeindividualparam=param tag needs to be closed with \/\ jsp.error.closeparams=param tag needs to be closed with /params jsp.error.plugin.notype=type not declared in jsp:plugin @@ -291,7 +292,7 @@ jsp.error.could.not.add.taglibraries=Could not add tag one or more libraries. jsp.error.duplicate.name.jspattribute=The attribute {0} specified in the standard or custom action also appears as the value of the name attribute in the enclosed jsp:attribute jsp.error.not.in.template={0} not allowed in a template text body. -jsp.error.badaction=The action is not a recognizable standard action. +jsp.error.badStandardAction=The action is not a recognizable standard action. jsp.error.tagdirective.badbodycontent=Invalid body-content ({0}) in tag directive jsp.error.page.config_pagedir_encoding_conflict=Page-encoding specified in jsp-property-group ({0}) is different from that specified in page directive ({1}) jsp.error.page.prolog_pagedir_encoding_conflict=Page-encoding specified in XML prolog ({0}) is different from that specified in page directive ({1}) @@ -339,3 +340,4 @@ jsp.error.tagfile.badSuffix=Missing \.tag\ suffix in tag file path {0} jsp.error.tagfile.illegalPath=Missing \/WEB-INF/tags\ or \/META-INF/tags\ in tag file path {0} jsp.error.plugin.wrongRootElement=Name of root element in {0} different from {1} +jsp.error.attribute.invalidPrefix=The attribute prefix {0} does not correspond to any imported tag library 1.7 +2 -2 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_fr.properties Index: messages_fr.properties === RCS file:
DO NOT REPLY [Bug 15189] - Error message provided when jsp:param element is not used properly is misleading
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=15189. 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=15189 Error message provided when jsp:param element is not used properly is misleading [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- 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 Validator.java
luehe 2002/12/09 14:26:10 Modified:jasper2/src/share/org/apache/jasper/compiler Validator.java Log: When verifying that a custom action does not have any invalid attributes, take the attributes' URI into account. Revision ChangesPath 1.56 +28 -4 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java Index: Validator.java === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java,v retrieving revision 1.55 retrieving revision 1.56 diff -u -r1.55 -r1.56 --- Validator.java8 Nov 2002 19:55:47 - 1.55 +++ Validator.java9 Dec 2002 22:26:10 - 1.56 @@ -361,6 +361,7 @@ private ErrorDispatcher err; private TagInfo tagInfo; private ClassLoader loader; + private Hashtable taglibs; // A FunctionMapper, used to validate EL expressions. private FunctionMapper functionMapper; @@ -442,6 +443,7 @@ */ ValidateVisitor(Compiler compiler) { this.pageInfo = compiler.getPageInfo(); + this.taglibs = pageInfo.getTagLibraries(); this.err = compiler.getErrorDispatcher(); this.tagInfo = compiler.getCompilationContext().getTagInfo(); this.loader = compiler.getCompilationContext().getClassLoader(); @@ -679,10 +681,32 @@ = new Node.JspAttribute[attrs.getLength() + namedAttributeNodes.size()]; Hashtable tagDataAttrs = new Hashtable(attrs.getLength()); + TagLibraryInfo tagLibInfo = + (TagLibraryInfo) taglibs.get(n.getPrefix()); + String uri = tagLibInfo.getURI(); for (int i=0; iattrs.getLength(); i++) { boolean found = false; for (int j=0; tldAttrs != null jtldAttrs.length; j++) { - if (attrs.getQName(i).equals(tldAttrs[j].getName())) { + /* + * A custom action and its declared attributes always + * belong to the same namespace, which is identified by + * the prefix name of the custom tag invocation. + * For example, in this invocation: + * my:test a=1 b=2 c=3/, the action + * test and its attributes a, b, and c all belong + * to the namespace identified by the prefix my. + * The above invocation would be equivalent to: + * my:test my:a=1 my:b=2 my:c=3/ + * An action attribute may have a prefix different from + * that of the action invocation only if the underlying + * tag handler supports dynamic attributes, in which case + * the attribute with the different prefix is considered a + * dynamic attribute. + */ + if (attrs.getLocalName(i).equals(tldAttrs[j].getName()) + (attrs.getURI(i) == null + || attrs.getURI(i).length() == 0 + || attrs.getURI(i) == uri)) { if (tldAttrs[j].canBeRequestTime()) { Class expectedType = String.class; try { -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
On 9/12/02 3:59 Jeanfrancois Arcand [EMAIL PROTECTED] wrote: (2) The Admin Tool should go with the minimal distribution of Tomcat. We decided to include JMX in Tomcat distribution...what's the point having JMX and not the Admin Tool? Maybe JSP is not required by all Tomcat users, but I'm sure a lot of them like to have the Admin Tool . That is what I'm asking myself... What's the point in all this useless crap? Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Update Tomcat-Admin-ja ResourceFile
Sorry, I made a bit mistake. This attachment file is correct. Thanks. MORIGUCHI Hirokazu [EMAIL PROTECTED] wrote: Hi, Tomcat Commiters, This patch updates a Japanese resource file of Tomcat Administration Tool. (ApplicationResources_ja.properties) I translated the messages modified/added between 4.1.7 and 4.1.16. I made it as such: $ diff -u \ jakarta-tomcat-4.1.16-beta-LE-jdk14-original/server/webapps/admin/WEB-INF/cl asses/org/apache/webapp/admin/ApplicationResources_ja.properties \ jakarta-tomcat-4.1.16-beta-LE-jdk14-new/server/webapps/admin/WEB-INF/classes /org/apache/webapp/admin/ApplicationResources_ja.properties \ tomcat-admin-ja-res4.1.16.patch I hope you take this patch. Thanks. --- MORIGUCHI Hirokazu [EMAIL PROTECTED],[EMAIL PROTECTED] --- MORIGUCHI Hirokazu [EMAIL PROTECTED],[EMAIL PROTECTED] tomcat-admin-ja-res4.1.16b.patch Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
On 9/12/02 9:16 Jon Scott Stevens [EMAIL PROTECTED] wrote: What I would love to see is a tree of downloads where each one gains more and more features (it is additive). Such as: JSR-154 Implementation / \ Jasper Velocity / \ \ Admin Tool (JMX) Java Server Feces Scarab Jon... That spelling of JSF is (C) and TM Pier 2002 :-) Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
On 9/12/02 17:14 Jeanfrancois Arcand [EMAIL PROTECTED] wrote: Youy don't need to learn JSP/Admin Tool if you don't use it. The actual Tomcat installation doesn't require you to learn the Admin Tool or JSP As I said 6 or so months ago... That thing is a security hole as big as the Empire State Building... As most of the stuff that make up tomcat... We have some bugs in JSR-154, few in Jasper, few in JSSI, few in CGI... All together it makes a load of em... If someone can come up with a Servlet-only distribution, at least I won't get holes from all the other (totally useless) components... Pier (a _user_ now) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
On 9/12/02 15:16 Costin Manolache [EMAIL PROTECTED] wrote: Since things may get confusing around here, I would like to have an official vote on my prior proposal. This is the list of included features: Libs: - JMX - JAAS - JNDI - digester ( and beanutils, collections it needs ). - modeler - ant ( used for startup and automation of some tasks ) - commons-logging When/if the JNDI-based abstraction of config files is ready we'll not need digester - but most likely it'll still be required by modeler, and also by jasper, so I don't think we can remove it. Tomcat: - subset of catalina ( non-deprecated interfaces and base impl that is required for tomcat to work ). - coyote - tomcat-util - http11/jk2 - all valves/etc that are required for tomcat to operate. - naming - jasper ( at least jasper runtime - but probably the whole thing ). Votes: [ ] +1 I like the idea, I might help [ ] -1 I don't like the idea, I won't help. I remember that when I proposed the same thing (roughly) and wanted to call it Tomcat-HA or something like it, you said: If possible, please also change the name - unless ASF gives you permission to use tomcat name in your product. I _love_ fairness and justice in this world... What-EVER! Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Pier Fumagalli wrote: On 9/12/02 17:14 Jeanfrancois Arcand [EMAIL PROTECTED] wrote: Youy don't need to learn JSP/Admin Tool if you don't use it. The actual Tomcat installation doesn't require you to learn the Admin Tool or JSP As I said 6 or so months ago... That thing is a security hole as big as Can you give me an example of a security hole? I would be interested to fix those holes the Empire State Building... As most of the stuff that make up tomcat... We have some bugs in JSR-154, few in Jasper, few in JSSI, few in CGI... All together it makes a load of em... Yes, you are right (think about Windoses). Is the reason to have an only 154 distribution is security? That a very different story... If someone can come up with a Servlet-only distribution, at least I won't get holes from all the other (totally useless) components... True. But if Jasper/AdminTool/etc. are secure, then that doesn't that no a good reason IMO. -- Jeanfrancois Pier (a _user_ now) -- 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/resources messages.properties messages_es.properties messages_fr.properties messages_ja.properties
luehe 2002/12/09 15:27:04 Modified:jasper2/src/share/org/apache/jasper/compiler Validator.java jasper2/src/share/org/apache/jasper/resources messages.properties messages_es.properties messages_fr.properties messages_ja.properties Log: Fixed Bugtraq 4790760: A translation-time error is not generated if the 'name' attribute of jsp:param is an expression Revision ChangesPath 1.57 +12 -5 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java Index: Validator.java === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java,v retrieving revision 1.56 retrieving revision 1.57 diff -u -r1.56 -r1.57 --- Validator.java9 Dec 2002 22:26:10 - 1.56 +++ Validator.java9 Dec 2002 23:27:03 - 1.57 @@ -476,6 +476,13 @@ public void visit(Node.ParamAction n) throws JasperException { JspUtil.checkAttributes(Param action, n, paramActionAttrs, err); + // make sure the value of the 'name' attribute is not a + // request-time expression + if (isExpression(n, n.getAttributes().getValue(name))) { + err.jspError(n, + jsp.error.attribute.standard.non_rt_with_expr, + name, jsp:param); + } n.setValue(getJspAttribute(value, null, null, n.getAttributeValue(value), java.lang.String.class, null, @@ -739,7 +746,7 @@ // Make sure its value does not contain any. if (isExpression(n, attrs.getValue(i))) { err.jspError(n, - jsp.error.attribute.non_rt_with_expr, + jsp.error.attribute.custom.non_rt_with_expr, tldAttrs[j].getName()); } jspAttrs[i] @@ -976,7 +983,7 @@ * Checks to see if the given attribute value represents a runtime or * EL expression. */ - private boolean isExpression(Node.CustomTag n, String value) { + private boolean isExpression(Node n, String value) { if ((n.isXmlSyntax() value.startsWith(%=)) || (!n.isXmlSyntax() value.startsWith(%=)) || (value.indexOf(${) != -1 !pageInfo.isELIgnored())) 1.66 +3 -2 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties Index: messages.properties === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties,v retrieving revision 1.65 retrieving revision 1.66 diff -u -r1.65 -r1.66 --- messages.properties 9 Dec 2002 22:17:32 - 1.65 +++ messages.properties 9 Dec 2002 23:27:03 - 1.66 @@ -297,7 +297,8 @@ jsp.error.page.config_pagedir_encoding_conflict=Page-encoding specified in jsp-property-group ({0}) is different from that specified in page directive ({1}) jsp.error.page.prolog_pagedir_encoding_conflict=Page-encoding specified in XML prolog ({0}) is different from that specified in page directive ({1}) jsp.error.page.prolog_config_encoding_conflict=Page-encoding specified in XML prolog ({0}) is different from that specified in jsp-property-group ({1}) -jsp.error.attribute.non_rt_with_expr=According to TLD, attribute {0} does not accept any expressions +jsp.error.attribute.custom.non_rt_with_expr=According to TLD, attribute {0} does not accept any expressions +jsp.error.attribute.standard.non_rt_with_expr=The {0} attribute of the {1} standard action does not accept any expressions jsp.error.scripting.variable.missing_name=Unable to determine scripting variable name from attribute {0} jasper.error.emptybodycontent.nonempty=According to TLD, tag {0} must be empty, but is not jsp.error.tagfile.var_name_given_equals_attr_name=In tag file {0}, the name-given attribute ({1}) of a variable directive equals the name attribute of an attribute directive 1.25 +2 -2 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_es.properties Index: messages_es.properties === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_es.properties,v retrieving revision 1.24 retrieving revision 1.25 diff -u -r1.24 -r1.25 --- messages_es.properties2 Dec 2002 11:21:00 - 1.24 +++
Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
Pier Fumagalli wrote: On 9/12/02 15:16 Costin Manolache [EMAIL PROTECTED] wrote: Since things may get confusing around here, I would like to have an official vote on my prior proposal. This is the list of included features: Libs: - JMX - JAAS - JNDI - digester ( and beanutils, collections it needs ). - modeler - ant ( used for startup and automation of some tasks ) - commons-logging When/if the JNDI-based abstraction of config files is ready we'll not need digester - but most likely it'll still be required by modeler, and also by jasper, so I don't think we can remove it. Tomcat: - subset of catalina ( non-deprecated interfaces and base impl that is required for tomcat to work ). - coyote - tomcat-util - http11/jk2 - all valves/etc that are required for tomcat to operate. - naming - jasper ( at least jasper runtime - but probably the whole thing ). Votes: [ ] +1 I like the idea, I might help [ ] -1 I don't like the idea, I won't help. I remember that when I proposed the same thing (roughly) and wanted to call it Tomcat-HA or something like it, you said: If possible, please also change the name - unless ASF gives you permission to use tomcat name in your product. Can you point to the proposal you made on tomcat-dev and the vote results to your proposal ? Are you saying you made such a proposal and it was voted down ? Or it was approved and I didn't allowed you to call it whatever tomcat-dev decided ? My comment was in the context of a product named Tomcat-high-availability that wasn't voted by the tomcat-dev. It doesn't matter if it is a revolution or minimal or whatever it does - it shouldn't be named tomcat-anything without ASF or tomcat-dev permission. If this proposal doesn't pass I won't do it somewhere else and call it tomcat-minimal. Costin I _love_ fairness and justice in this world... What-EVER! Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
On 9/12/02 23:06 Jeanfrancois Arcand [EMAIL PROTECTED] wrote: Pier Fumagalli wrote: On 9/12/02 17:14 Jeanfrancois Arcand [EMAIL PROTECTED] wrote: Youy don't need to learn JSP/Admin Tool if you don't use it. The actual Tomcat installation doesn't require you to learn the Admin Tool or JSP As I said 6 or so months ago... That thing is a security hole as big as Can you give me an example of a security hole? I would be interested to fix those holes They come up every now and then... That's why Costin wanted that all-private for your eyes only noone who is not cross checked with the FBI gets in security mailing list, right?... Want a list of the past ones? http://search.cert.org/query.html?col=certadvcol=incnotescol=vulnotesht=0 qp=qt=tomcatqs=qc=pw=100%25ws=1la=enqm=0st=1nh=25lk=1rf=2rq=0s i=1 (err, page 1 out of 24)... the Empire State Building... As most of the stuff that make up tomcat... We have some bugs in JSR-154, few in Jasper, few in JSSI, few in CGI... All together it makes a load of em... Yes, you are right (think about Windoses). Is the reason to have an only 154 distribution is security? That a very different story... For me it is... For others it might be a different reason... I joined Apache because of a friend, you because of your employer... SO? Reasons are different, outcome is the same... If someone can come up with a Servlet-only distribution, at least I won't get holes from all the other (totally useless) components... True. But if Jasper/AdminTool/etc. are secure, then that doesn't that no a good reason IMO. Ehemm... With 24 pages of vulnerability notes? Ha.. Hahaha Hahahaha! :-) Rule of the thumb #1... Not even public class Main public static void Main(String argv[]) { System.out.println(This program doesn't have a bug); } } Doesn't have a bug, allright? Because to execute that little statement my proc actually does some bazillion operations, and god knows how many INC, ADD, SUB and MUL my proc does to get that out... So, rule of the thumb #2. No software ever written is _ever_ secure (Just consider that the Boeing 777 software - which is the most secure OS on this planet as far as research goes - Has only one bug every 180.000 lines of code)... Now, don't tell me that ALL that collection of cruft doesn't have a bug... It's just that we are lucky and noone found them yet (given enough eyes... Linus says)... To sum up: rule of the thumb #3, less code, less bugs (you folks from Sun preach that all over your Solaris Blueprints stuff, I learnt it when your employer was paying my salary). So, please, don¹t come up on a mailing list saying that is secure, just say that noone has found a bug yet, because that (and only that) is the truth... Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
On 9/12/02 23:38 Costin Manolache [EMAIL PROTECTED] wrote: Pier Fumagalli wrote: On 9/12/02 15:16 Costin Manolache [EMAIL PROTECTED] wrote: Since things may get confusing around here, I would like to have an official vote on my prior proposal. This is the list of included features: Libs: - JMX - JAAS - JNDI - digester ( and beanutils, collections it needs ). - modeler - ant ( used for startup and automation of some tasks ) - commons-logging When/if the JNDI-based abstraction of config files is ready we'll not need digester - but most likely it'll still be required by modeler, and also by jasper, so I don't think we can remove it. Tomcat: - subset of catalina ( non-deprecated interfaces and base impl that is required for tomcat to work ). - coyote - tomcat-util - http11/jk2 - all valves/etc that are required for tomcat to operate. - naming - jasper ( at least jasper runtime - but probably the whole thing ). Votes: [ ] +1 I like the idea, I might help [ ] -1 I don't like the idea, I won't help. I remember that when I proposed the same thing (roughly) and wanted to call it Tomcat-HA or something like it, you said: If possible, please also change the name - unless ASF gives you permission to use tomcat name in your product. Can you point to the proposal you made on tomcat-dev and the vote results to your proposal ? Are you saying you made such a proposal and it was voted down ? Or it was approved and I didn't allowed you to call it whatever tomcat-dev decided ? My comment was in the context of a product named Tomcat-high-availability that wasn't voted by the tomcat-dev. It doesn't matter if it is a revolution or minimal or whatever it does - it shouldn't be named tomcat-anything without ASF or tomcat-dev permission. If this proposal doesn't pass I won't do it somewhere else and call it tomcat-minimal. You're better than me in scavanging through EyeBrowse... :-) Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
Pier Fumagalli wrote: I remember that when I proposed the same thing (roughly) and wanted to call it Tomcat-HA or something like it, you said: If possible, please also change the name - unless ASF gives you permission to use tomcat name in your product. Can you point to the proposal you made on tomcat-dev and the vote results to your proposal ? Are you saying you made such a proposal and it was voted down ? Or it was approved and I didn't allowed you to call it whatever tomcat-dev decided ? My comment was in the context of a product named Tomcat-high-availability that wasn't voted by the tomcat-dev. It doesn't matter if it is a revolution or minimal or whatever it does - it shouldn't be named tomcat-anything without ASF or tomcat-dev permission. If this proposal doesn't pass I won't do it somewhere else and call it tomcat-minimal. You're better than me in scavanging through EyeBrowse... :-) It's hard to find something that doesn't exist. I hate the practice of using old postings as arguments in most cases - it's normal for people to change their minds. But in this case you keep making false statements, and not only here. It should be quite easy to look for a [VOTE] or [PROPOSAL] that you made and was voted on tomcat-dev. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
on 2002/12/9 3:58 PM, Costin Manolache [EMAIL PROTECTED] wrote: It's hard to find something that doesn't exist. ? I hate the practice of using old postings as arguments in most cases - it's normal for people to change their minds. There is a difference between changing your mind and making up the rules as you go along. But in this case you keep making false statements, and not only here. It should be quite easy to look for a [VOTE] or [PROPOSAL] that you made and was voted on tomcat-dev. Then find it. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
On 9/12/02 23:51 Pier Fumagalli [EMAIL PROTECTED] wrote: Ehemm... With 24 pages of vulnerability notes? Ha.. Hahaha Hahahaha! :-) Correction to self... Not 24 pages... 24 notes... (Ok, I have an eyesight test tomorrow morning at 10:20 in SOHO... I know, I know...) Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Pier Fumagalli wrote: They come up every now and then... That's why Costin wanted that all-private for your eyes only noone who is not cross checked with the FBI gets in security mailing list, right?... Wrong. The list is for all tomcat committers - and all security information will be posted after the fix is done. The list is created - and will hopefully be used next time a security problem is found. Ehemm... With 24 pages of vulnerability notes? Ha.. Hahaha Hahahaha! :-) Again ? There are 24 results - not 24 pages of results. And if you go down the page - many are not in tomcat. Try the same thing for apache. Yes - any code may have vulnerabilities, and the more code you have, the more bugs you'll have. We can only do our best so that our code has fewer bugs - but that shouldn't stop us from distributing the code we write ( i.e. tomcat and jasper ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
On 10/12/02 0:10 Jon Scott Stevens [EMAIL PROTECTED] wrote: But in this case you keep making false statements, and not only here. It should be quite easy to look for a [VOTE] or [PROPOSAL] that you made and was voted on tomcat-dev. Then find it. I believe it never even went to [VOTE]... Got shut down before.. I usually have the bad habit of asking others before proposing votes... And, well, sometimes I don't really use that [VOTE] or [PROPOSAL] thing... I just hope that open minded people will read and give opinions on a free-form text subject base... Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Pier Fumagalli wrote: On 9/12/02 23:06 Jeanfrancois Arcand [EMAIL PROTECTED] wrote: Pier Fumagalli wrote: On 9/12/02 17:14 Jeanfrancois Arcand [EMAIL PROTECTED] wrote: Youy don't need to learn JSP/Admin Tool if you don't use it. The actual Tomcat installation doesn't require you to learn the Admin Tool or JSP As I said 6 or so months ago... That thing is a security hole as big as Can you give me an example of a security hole? I would be interested to fix those holes They come up every now and then... That's why Costin wanted that all-private for your eyes only noone who is not cross checked with the FBI gets in security mailing list, right?... Not sure is the real reason. We were doing a Security Audit during that time and as a community, we where trying to find a better list to declare possible security issues and fix them before the public is informed. Want a list of the past ones? http://search.cert.org/query.html?col=certadvcol=incnotescol=vulnotesht=0 qp=qt=tomcatqs=qc=pw=100%25ws=1la=enqm=0st=1nh=25lk=1rf=2rq=0s i=1 (err, page 1 out of 24)... ;-) the Empire State Building... As most of the stuff that make up tomcat... We have some bugs in JSR-154, few in Jasper, few in JSSI, few in CGI... All together it makes a load of em... Yes, you are right (think about Windoses). Is the reason to have an only 154 distribution is security? That a very different story... For me it is... For others it might be a different reason... I joined Apache because of a friend, you because of your employer... SO? Reasons are different, outcome is the same... Yep. That why we are trying to reach concensus. If someone can come up with a Servlet-only distribution, at least I won't get holes from all the other (totally useless) components... True. But if Jasper/AdminTool/etc. are secure, then that doesn't that no a good reason IMO. Ehemm... With 24 pages of vulnerability notes? Ha.. Hahaha Hahahaha! :-) Rule of the thumb #1... Not even public class Main public static void Main(String argv[]) { System.out.println(This program doesn't have a bug); } } Doesn't have a bug, allright? Because to execute that little statement my proc actually does some bazillion operations, and god knows how many INC, ADD, SUB and MUL my proc does to get that out... So, rule of the thumb #2. No software ever written is _ever_ secure (Just consider that the Boeing 777 software - which is the most secure OS on this planet as far as research goes - Has only one bug every 180.000 lines of code)... Did I say that every software are secure? Your are right and I will not argument at all. But from your previous posting, I was under the impression you were aware of security holes Now, don't tell me that ALL that collection of cruft doesn't have a bug... It's just that we are lucky and noone found them yet (given enough eyes... Linus says)... I never say that and I will never says that. But I least I have try during the Security Audit to fix some of the obvious one. Still Tomcat is probably not enough secure (and will never be). My point is if you are aware of such obvious one, then let me know and I will fix them. But I don't think Tomcat is more secure without JSP I know, I know, what I think you don't care :-) To sum up: rule of the thumb #3, less code, less bugs (you folks from Sun preach that all over your Solaris Blueprints stuff, I learnt it when your employer was paying my salary). Wow, didn't know that... I've missed the chance to work with you :-) I should studies my Tomcat history and learn who is doing what, what biases he/she have, and then vote appropriatly. So, please, don¹t come up on a mailing list saying that is secure, just say that noone has found a bug yet, because that (and only that) is the truth... I agree my wording was not appropriate. Should say that in french next time :-) -- Jeanfrancois Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]