RE: Jk2 config
I'm thinking about: 1. JkSet NAME VALUE Will have exactly the same behavior as NAME=VALUE in a workers.properties file. All settings that you can do in workers.properties today could be done by JkSet, in httpd.conf. Or all settings could be done in workers.properties. For example JkLogLevel DEBUG will be now: JkSet logLevel DEBUG ( in httpd.conf ) or logLevel=DEBUG ( in workers.propertes ) +1 for JkSet = JkSet LogFile /var/log/httpd/mod_jk.log JkSet LogLevel DEBUG JkSet LogStampFormat %d/%m/%y JkSet HTTPSIndicator HTTPS JkSet CERTSIndicator SSL_CLIENT_CERT JkSet CIPHERIndicator SSL_CIPHER JkSet SESSIONIndicator SSL_SESSION_ID JkSet KEYSIZEIndicator SSL_CIPHER_USEKEYSIZE JkSet ExtractSSL TRUE The forward options : ? JkSet Forward SSLKeySize JkSet Forward URICompat JkSet Forward URICompatUnparsed JkSet Forward URIEscaped The first style is for people who prefer working with httpd.conf, the other one will be easier for IIS/iPlanet and may be easier to generate/edit. 2. JkWebapp NAME VALUE Set properties on a webapp level. Will be set at Location level. An equivalent setting will be in a uri-workers.properties ( or a better named one ), the same that we use for IIS. +1 JkMount is not doing anything special - it's the same efect as the properties file we use on IIS. Except that properties are easier to generate and will be consistent for all servers ( no longer need to generate 3 different styles ). -1, I'd like to keep the JkMount as it's absolutly mandatory for fine tuning (ie all examples servlet/jsp handled by TC) but static by Apache. It could be renamed to JkURIMount for example. Location will be used for performance, it uses the apache mapper instead of jk's. 3. JkServlet NAME VALUE Set properties per/servlet. I'm not yet finished with this one, we may not need it. What's the planned use for this one ? After jk2 is finalized and we're ready to drop jk1 we'll just implement a compat layer - the old options in jk1. That's what I did so far, but I think it's better to make the switch to a better model and keep that only for migration. What about : Jk(2)EnvVar ? Jk(2)MountCopy ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Bug report for Tomcat 3 [2002/02/25]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal EHN=Ehnancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 258|Unc|Nor|2000-11-27|response.SendRedirect() resets/destroys Cookies th| | 2478|Opn|Cri|2001-07-06|Passing Session variables between JSP's and Servle| | 4380|New|Enh|2001-10-23|Multiple ISAPI redirectors on single IIS website | | 4416|New|Maj|2001-10-25|URI En/Decoding not working | | 4551|Opn|Nor|2001-10-31|Ctx( /tt01 ): IOException in: R( /tt01 + /com/abc/| | 4615|New|Cri|2001-11-03|jsp compilation problem in iplanet version 4.1| | 4893|Unc|Blk|2001-11-15|Tomcat dies with following error..| | 4915|New|Blk|2001-11-16|Relocation error while loading mod_jk when startin| | 4980|New|Min|2001-11-20|Startup message indicates incorrect log file | | 4994|New|Nor|2001-11-21|Tomcat needs a mechanism for clean and certain shu| | 5064|New|Cri|2001-11-25|Socket write error when include files is more than| | 5108|New|Maj|2001-11-26|Docs for Tomcat 3.2.x appear to be for Tomcat 3.3 | | 5137|New|Nor|2001-11-27|Null pointer in class loader after attempting to r| | 5160|Unc|Maj|2001-11-28|'IllegalStateException' | | 5231|New|Nor|2001-12-02|Tomcat 3.2.4 does not start due to error in classp| | 5250|New|Min|2001-12-03|Load balancing workers do not correctly handle Coo| | 5261|New|Cri|2001-12-04|Directory Listing in Tomcat 3.2.4 | | 5331|New|Nor|2001-12-09|getPathInfo vs URL normalization | | 5510|New|Blk|2001-12-19|How to call ejb deployed in JBoss from Tomcat serv| | 5511|New|Nor|2001-12-19|Error upload files| | 5532|New|Nor|2001-12-20|underscore is wrong | | 5581|New|Cri|2001-12-24|java.lang.ArrayIndexOutOfBoundsException | | 5756|New|Nor|2002-01-08|jspc.bat exits with wrong ERRORLEVEL | | 5769|New|Nor|2002-01-09|NT Service display name should not be used as serv| | 5797|New|Nor|2002-01-10|UnCatched ? StringIndexOutOfBoundsException: Strin| | 5925|New|Cri|2002-01-19|Apache server hangs up and consumes 100% CPU resou| | 6002|New|Maj|2002-01-24|Disabling tomcatAuthentication=false for Ajp12Co| | 6027|New|Maj|2002-01-25|Tomcat Automatically shuts down as service | | 6088|New|Blk|2002-01-29|Too many custom tags? | | 6168|New|Blk|2002-02-01|double execution of java code in JSP | | 6214|New|Nor|2002-02-04|Problems on ClientAuth| | 6324|New|Nor|2002-02-08|Invalid POST requests through ajp13 cause 'garbage| | 6369|New|Nor|2002-02-11|jk_nt_service.exe does not set exit code | | 6448|New|Nor|2002-02-14|NullPointerException when docBase is missing | | 6451|New|Cri|2002-02-14|Stackoverflow | | 6478|New|Enh|2002-02-14|Default Tomcat Encoding | | 6488|Ver|Maj|2002-02-15|Error: 304. Apparent bug in default ErrorHandler c| | 6557|New|Maj|2002-02-19|isapi_redirector can not handle post request from | | 6604|New|Nor|2002-02-21|Request.getRemoteUser() throwing NullPointerExcept| | 6643|New|Blk|2002-02-22|Tom 3.3a or 3.31b1 : URLRewriting POST == 404 err| +-+---+---+--+--+ | Total 40 bugs | +---+ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Bug report for Tomcat 4 [2002/02/25]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal EHN=Ehnancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 821|Ver|Maj|2001-03-02|JSPC doesn't like NT paths| | 3509|Ass|Blk|2001-09-07|Apache 1.3.20 mod_webapp Tomcat 4b7 HANGS unde| | 3546|Ver|Min|2001-09-11|req.getDateHeader() can fail under load | | 3643|Ass|Enh|2001-09-16|Enable static-linking within Apache for WebApp mod| | 4042|Ass|Enh|2001-10-09|webapp component requires Port directive versus Li| | 4139|Ass|Enh|2001-10-12|mod_webapp build files for Win32 | | 4212|Ass|Enh|2001-10-16|How to configure Apache to serve static contents? | | 4350|Ass|Nor|2001-10-22|SSLAuthenticator did not associate SSO session| | 4352|Ass|Nor|2001-10-22|JDBCRealm does not work with CLIENT-CERT auth-meth| | 4371|Unc|Nor|2001-10-23|No responses on browsing root when using WarpConne| | 4386|Ass|Nor|2001-10-24|webapp1.0 will not install on Redhat 7.1 | | 4500|New|Nor|2001-10-29|isapi_redirect.dll does not pass Client certificat| | 4793|New|Blk|2001-11-11|mod_webapp connector doesn´t work | | 4829|Opn|Enh|2001-11-13|Automatic deployment of war files does not work pr| | 4930|New|Maj|2001-11-16|java.io.StreamCorruptedException: Type code out of| | 4954|New|Min|2001-11-19|When specifying CATALINA_BASE explicitly, that dir| | 4961|New|Nor|2001-11-19|JDBCStore problems with Oracle, others(?) | | 4964|New|Maj|2001-11-20|popBody() is called before doEndTag() is called in| | 5040|New|Nor|2001-11-23|EOFException when talking from applet to servlet v| | 5143|New|Enh|2001-11-27|Please allow to specify the cipher set for HTTPS c| | 5166|New|Min|2001-11-28|CATALINA_BASE config issues for RUNNING.txt | | 5199|New|Nor|2001-11-30|jsp:param in jsp:include section not correct | | 5229|New|Blk|2001-12-02|Session cannot unbind if using DistributedManager | | 5329|New|Nor|2001-12-08|NT Service exits startup before Tomcat is finished| | 5368|Ver|Nor|2001-12-11|StandardContextValve changes session state from ne| | 5383|New|Nor|2001-12-12|/etc/rc.d/init.d/tomcat4 on RedHat 6.1 fails | | 5402|New|Nor|2001-12-12|WarpConnection raise IOException | | 5405|New|Enh|2001-12-13|Powered by Tomcat | | 5446|Opn|Min|2001-12-16|Can't change webapp class loader (bug #5391 revisi| | 5471|New|Maj|2001-12-17|jspc -webapp option is broken due to namespace col| | 5488|New|Nor|2001-12-18|Parser error with language encoding Cp1252| | 5507|New|Cri|2001-12-19|Swapping sessions causes exceptions and it doesn't| | 5547|New|Nor|2001-12-20|isapi_redirect.dll not work with ajp1.3? | | 5551|New|Enh|2001-12-21|MANAGER: add system information query | | 5585|Opn|Nor|2001-12-24|Error page not displayed | | 5603|New|Min|2001-12-28|ServletContext.getResourcePaths() returns extra sl| | 5666|New|Min|2002-01-02|Implicit object _value on jsp pages | | 5704|Ass|Maj|2002-01-05|CgiServlet corrupting images? | | 5709|New|Nor|2002-01-06|HttpServletRequest.getHost returns web server addr| | 5735|New|Blk|2002-01-08|HTTP connector running out of processors under hea| | 5758|New|Nor|2002-01-08|Server-side includes do not work properly | | 5759|Opn|Maj|2002-01-09|CGI servlet mapping by extension *.cgi does not wo| | 5762|New|Maj|2002-01-09|CGI servlet misses to include port number in HTTP_| | 5764|New|Enh|2002-01-09|Key Information Missing--Automatic Application Dep| | 5784|New|Min|2002-01-10|org.apache.catalina.WELCOME_FILES attribute replac| | 5785|New|Nor|2002-01-10|XML request time attribute not generated correctly| | 5793|New|Nor|2002-01-10|variable element in tld with TagExtraInfo class | | 5795|New|Enh|2002-01-10|Catalina Shutdown relies on localhost causing prob| | 5814|Ver|Cri|2002-01-11|401 error code could not be populated by error-pag| | 5826|Opn|Min|2002-01-12|JSPC not recompiling modified files | | 5827|New|Cri|2002-01-13|DataInputStream.readInt returns wrong values | |
Fooling Javac
So I'm not going to claim this is portable, but shouldn't it be possible to provide a different implementation of java.io.FileSystem that reads files from the current ClassLoader and writes them to a buffer in memory? I'm assuming that javac uses java.io.File (anyone know?), so this would let you compile JSPs without constructing an external environment for them, or writing the source code or class file to the filesystem. The problem is that FileSystem is not public, and the method to get the current one is native, so you'd have to hack the rt.jar to get this to work. But it might be an interesting experiment to see if it even makes a noticeable difference. Aaron -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6648] New: - jakarta-servletapi build with java 1.4 javadoc errors
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=6648. 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=6648 jakarta-servletapi build with java 1.4 javadoc errors Summary: jakarta-servletapi build with java 1.4 javadoc errors Product: Tomcat 3 Version: 3.2.x Nightly Platform: PC OS/Version: Solaris Status: NEW Severity: Normal Priority: Other Component: Servlet AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Building the jakarta-servletapi Servlet 2.2 and JSP 1.1 javadocs using java 1.4 generates alot of javadoc errors. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6649] New: - jakarta-servletapi-4 build using java 1.4 javadoc errors
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=6649. 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=6649 jakarta-servletapi-4 build using java 1.4 javadoc errors Summary: jakarta-servletapi-4 build using java 1.4 javadoc errors Product: Tomcat 4 Version: Nightly Build Platform: PC OS/Version: Solaris Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Building the jakarta-servletapi-4 Servlet 2.3 and JSP 1.2 javadocs using java 1.4 generates alot of new javadoc errors. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6651] New: - Add -configtest option to Tomcat4 startup
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=6651. 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=6651 Add -configtest option to Tomcat4 startup Summary: Add -configtest option to Tomcat4 startup Product: Tomcat 4 Version: Nightly Build Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If you are using Tomcat 4 in a production environment you would like to minimize downtime. The only way to know that you made a mistake in your server.xml configuration is to actually stop and restart tomcat. Adding the startup option -configtest would only parse and verify the server.xml configuration and could be performed is Tomcat is running. This would allow you to verify any configuration changes before doing a tomcat stop/start with the new config. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6652] New: - Add ability to reload Tomcat without having to restart JVM
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=6652. 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=6652 Add ability to reload Tomcat without having to restart JVM Summary: Add ability to reload Tomcat without having to restart JVM Product: Tomcat 4 Version: Nightly Build Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Add the ability to reload Tomcat without having to restart JVM. In situations where you may only be changing Tomcat's configuration in server.xml and not changing any jar's in server/lib, common/lib, or shared/lib; allow Tomcat to be reloaded using new config without stopping JVM. When running Tomcat in a production environment using the java -server HotSpot option, hotspot optimizes its execution over time. Stopping Tomcat looses all these optimizations. Allowing Tomcat to be reloaded without stopping the JVM will make changing its configuration easier in a production environment. The reload will be faster than a stop/start because the JVM won't have to reload classes and you won't loose all the runtime optimizations done by HotSpot. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6621] - mod_webapp hangs when page is hit before the first page is finished loading
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=6621. 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=6621 mod_webapp hangs when page is hit before the first page is finished loading --- Additional Comments From [EMAIL PROTECTED] 2002-02-25 15:28 --- This bug only seems to occur only on a Windows platform. The page hangs during the transmission of binary items (ie. GIF images) from Tomcat to Apache across the WARP connector. I've tested it with the latest daily snapshots of apr and mod_webapp on a Win2K box as of Feb 24/02 and it's still broken. You can easily reproduce the problem (on a Windows box) by trying to access the /examples/jsp/index.html file that is included in the Tomcat examples directory (through Apache and the warp connector) . Versions used to reproduce this error: Tomcat: 4.0.2 final, Windows binary distribution. Apache: 1.3.23 final, Windows binary distribution. mod_webapp/apr: Built from source, daily snapshot as of Feb 23. Andrzej ([EMAIL PROTECTED]) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Accessing security credentials from a global valve.
Hi, I'm trying to write a Valve which can be used to automatically setup a security association with an external server (JBoss), using the security information from a Catalina realm. This necessitates getting access to the username and password used to authenticate the user making the request. This used to be trivial in Tomcat 3.2 (a few lines of code) but seems more complicated, if not impossible in Tomcat 4, which doesn't appear to provide easy access to the information - I can't actually work out whether it caches the password at all in fact. I've been looking at the code in AuthenticatorBase which appears to cache notes in the session object which could be used ?? However if I try and use these in a valve which is configured globally (not within a particular context) then there isn't a session available to access. Can anyone tell me if this is possible and if so give some hints about how I could go about it. cheers, Luke. P.S. Sent this from the wrong mail account initially. Apologies if it arrives twice. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6652] - Add ability to reload Tomcat without having to restart JVM
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=6652. 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=6652 Add ability to reload Tomcat without having to restart JVM [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-02-25 16:39 --- I think you can do that with the admin webapp (or if you can't right now, you'll be able to very soon). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jk2 config
On Mon, 25 Feb 2002, GOMEZ Henri wrote: JkSet LogFile /var/log/httpd/mod_jk.log I would use logFile, logLevel - current options in workers.properties start will small caps, and this can go in either w.properties and httpd.conf. The forward options : ? JkSet Forward SSLKeySize JkSet Forward URICompat JkSet Forward URICompatUnparsed JkSet Forward URIEscaped JkSet forward.SSLKeySize true JkSet uriCompat true JkSet uriCompatUnparsed true Or even better: JkSet sslKeySizeForward true JkSet uriForward compat/compatUnparsed/escaped JkMount is not doing anything special - it's the same efect as the properties file we use on IIS. Except that properties are easier to generate and will be consistent for all servers ( no longer need to generate 3 different styles ). -1, I'd like to keep the JkMount as it's absolutly mandatory for fine tuning (ie all examples servlet/jsp handled by TC) but static by Apache. It could be renamed to JkURIMount for example. JkMount is replaced by: urimap.properties or ( apache style ) Location /examples JkWebapp worker ajp13 /Location Location /examples/*.jsl JkHandler jakarta/jk2-servlet /Location or JkSet /examples/*.jsp ajp13 We can add a JkUriSet /examples/*.jsp ajp13 3. JkServlet NAME VALUE Set properties per/servlet. I'm not yet finished with this one, we may not need it. What's the planned use for this one ? Set properties per/uri - fine tunning, including setting the servlet name - the URI is mapped once by apache, there's no need for a second mapping in tomcat. What about: JkUriSet /uri name value to replace both JkWebapp and JkServlet ? Both are used to set properties associated with a uri - the worker name for the webapp, fine tunning for uris. What about : Jk(2)EnvVar ? Jk(2)MountCopy ? JkSet mountCopy true JkSet env.NAME DEFAULT_FALUE We could also use it in a Location context later JkUriSet env.NAME VALUE In this particular case it may be worth adding a JkEnv directive, but it _must_ have an equivalent in workers.properties and that means a JkSet equivalent too. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6651] - Add -configtest option to Tomcat4 startup
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=6651. 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=6651 Add -configtest option to Tomcat4 startup [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-02-25 16:45 --- Because of the way the digester works (and the XML mapper before it), there is no way we can parse the XML files without instantiating all the objects (contexts, etc). Also, a lot of the config parsing is triggered by startup events. I'm -1 for this proposal (too many changes, and I must also add I can't find a way to implement it). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6656] New: - WebappClassLoader does not load packages in javax.xml.*
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=6656. 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=6656 WebappClassLoader does not load packages in javax.xml.* Summary: WebappClassLoader does not load packages in javax.xml.* Product: Tomcat 4 Version: 4.0.2 Final Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Webapps AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The method WebappClassLoader.validate blocks out the loading of any classes belonging to javax.xml.* package in the webapps/lib and webapp/classes directory. This makes it impossible for a specific web application to use its own XML classes. Also, it makes it impossible for applications to do XSL transformation using javax.xml.transform.* classes. (We are using xalan for this). The work around would be putting the jar files in common/lib, but this is not ideal and prevents each webapp from having its own XML handling classes. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6656] - WebappClassLoader does not load packages in javax.xml.*
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=6656. 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=6656 WebappClassLoader does not load packages in javax.xml.* [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-02-25 16:53 --- *** This bug has been marked as a duplicate of 6374 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6374] - class not find for:org/w3c/dom/range/Range
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=6374. 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=6374 class not find for:org/w3c/dom/range/Range [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-02-25 16:53 --- *** Bug 6656 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6374] - class not find for:org/w3c/dom/range/Range
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=6374. 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=6374 class not find for:org/w3c/dom/range/Range [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2002-02-25 17:05 --- The method WebappClassLoader.validate blocks out the loading of any classes belonging to javax.xml.* as well as a few other XML related packages in the webapps/lib and webapp/classes directory. This makes it impossible for a specific web application to use its own XML classes. Also, it makes it impossible for applications to do XSL transformation using javax.xml.transform.* classes. (We are using xalan for this). The work around would be putting the jar files in common/lib, but this is not ideal and prevents each webapp from having its own XML handling classes. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6374] - class not find for:org/w3c/dom/range/Range
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=6374. 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=6374 class not find for:org/w3c/dom/range/Range [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-02-25 17:07 --- Please try to read the previous comments for this bug report. Thanks. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Compression Filter
The CompressionServletResponseWrapper class needs the following methods
added:
public void setHeader(String name, String value)
{
if (!Content-Length.equalsIgnoreCase(name))
super.setHeader(name,value);
}
public void setIntHeader(String name, int value)
{
if (!Content-Length.equalsIgnoreCase(name))
super.setIntHeader(name,value);
}
As it is valid for a servlet to set the content-length with a
setHeader call. In fact, for cached, frequently requests resources
it is better to reuse a String value of content-length than to
constantly convert the same length int to a String.
regards
--
Greg Wilkins[EMAIL PROTECTED] GB Phone: +44-(0)7092063462
Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631
http://www.mortbay.com AU Phone: +61-(0)2 98107029
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Accessing security credentials from a global valve.
Hi, I'm trying to write a Valve which can be used to automatically setup a security association with an external server (JBoss), using the security information from a Catalina realm. This necessitates getting access to the username and password used to authenticate the user making the request. This used to be trivial in Tomcat 3.2 (a few lines of code) but seems more complicated, if not impossible in Tomcat 4, which doesn't appear to provide easy access to the information - I can't actually work out whether it caches the password at all in fact. I've been looking at the code in AuthenticatorBase which appears to cache notes in the session object which could be used ?? However if I try and use these in a valve which is configured globally (not within a particular context) then there isn't a session available to access. Can anyone tell me if this is possible and if so give some hints about how I could go about it. cheers, Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
reload bug
Hi All, Has anyone experienced a long delay (7+ seconds) before a servlet change takes in tom cat 4? We have been finding a delay under windows 2k, but other versions of windows do not have this delay, as far as we can tell. Thanks! - DL -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6659] New: - HttpUtils.getRequestURL gives incorrect URL with web.xml redirected error pages
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=6659. 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=6659 HttpUtils.getRequestURL gives incorrect URL with web.xml redirected error pages Summary: HttpUtils.getRequestURL gives incorrect URL with web.xml redirected error pages Product: Tomcat 4 Version: 4.0.2 Final Platform: PC OS/Version: Windows 9x Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] We have a Invalid URL error page that is forwarded to using the error-code and exception-type elements of the web.xml. On that page we use the HttpUtils.getRequestURL (req) call to get the (invalid) requested URL for display. Under Tomcat 3.3a this works fine, under tomcat 4.0.2 this give the URL of the error page itself. I understand the entire HttpUtils class is deprecated under the Servlet 2.3 spec. And the replacement call HttpServletRequest.getRequestURL() appears to work fine on 4.0.2. But it would be great for our migration strategy is the deprecated call functioned the same. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Catalina with SecurityManager is possibly broken.
Hi all,
I found what I suppose to be a serious bug for whomever relays on running Catalina
with a
Security Manager. It's not a vulnerability but it has the potencial to break several
applications
like O'reilly's cos.jar ( upload ) and JSSE.
Description: security manager rules are not applied correctly to classes on /lib
directory
Here are the steps to reproduce:
Create 2 classes:
import java.io.*;
public class WriteFile {
public void write() throws IOException {
FileWriter fw = new FileWriter(/home/client/write_area/test.txt);
PrintWriter pw = new PrintWriter(fw);
pw.println(Testing security manager...);
pw.close();
fw.close();
}
}
( create a jar: jar -cvf WriteFile.jar WriteFile.class )
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import WriteFile;
public class SecManagerTest extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse res) throws
ServletException, IOException {
res.setContentType(text/html);
PrintWriter out = res.getWriter();
WriteFile wf = new WriteFile();
wf.write();
out.println(HTML);
out.println(BODY);
out.println(Security Manager works!!);
out.println(/BODY);
out.println(/HTML);
}
}
Insert these lines after the catalina.policy file
grant codeBase file:/home/client/- {
permission java.io.FilePermission /home/client/-, read,write,delete;
permission java.util.PropertyPermission *, read;
};
Start catalina with:
./catalina.sh start -security
* NOW THE TESTS
First test. Put WriteFile.class and SecManagerTest.class on /WEB-INF/classes
Try to execute the servlet. It works !!!
Second test. Put WriteFile.jar on /WEB-INF/lib ( and remove WriteFile.class from
/classes ! ).
Restart Catalina. Try to access the servlet:
java.security.AccessControlException: access denied (java.io.FilePermission
/home/client/write_area/teste.txt write)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:272)
at java.security.AccessController.checkPermission(AccessController.java:399)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
at java.lang.SecurityManager.checkWrite(SecurityManager.java:978)
at java.io.FileOutputStream.(FileOutputStream.java:96)
at java.io.FileOutputStream.(FileOutputStream.java:62)
at java.io.FileWriter.(FileWriter.java:38)
at WriteFile.write(WriteFile.java:7)
at SecManagerTest.doGet(SecManagerTest.java:13)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
(...)
In Tomcat 3.3 beta 1, it works perfectly.
There is definitely something wrong with the Security Manager in Catalina.
Webhosting companies ans users that depends on the security manager cannot fully use
Catalina ( again, everything works pretty well with Tomcat 3.3 ).
If you want me to test some patches let me know !!
Renato - Brazil
-
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
DO NOT REPLY [Bug 6660] New: - Catalina with SecurityManager is possibly broken.
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=6660.
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=6660
Catalina with SecurityManager is possibly broken.
Summary: Catalina with SecurityManager is possibly broken.
Product: Tomcat 4
Version: 4.0.2 Final
Platform: PC
OS/Version: Linux
Status: NEW
Severity: Critical
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Hi all,
I found what I suppose to be a serious bug for whomever relays on running
Catalina with a
Security Manager. It's not a vulnerability but it has the potencial to break
several applications
like O'reilly's cos.jar ( upload ) and JSSE.
Description: security manager rules are not applied correctly to classes
on /lib directory
Here are the steps to reproduce:
Create 2 classes:
import java.io.*;
public class WriteFile {
public void write() throws IOException {
FileWriter fw = new FileWriter(/home/client/write_area/test.txt);
PrintWriter pw = new PrintWriter(fw);
pw.println(Testing security manager...);
pw.close();
fw.close();
}
}
( create a jar: jar -cvf WriteFile.jar WriteFile.class )
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import WriteFile;
public class SecManagerTest extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse res) throws
ServletException, IOException {
res.setContentType(text/html);
PrintWriter out = res.getWriter();
WriteFile wf = new WriteFile();
wf.write();
out.println(HTML);
out.println(BODY);
out.println(Security Manager works!!);
out.println(/BODY);
out.println(/HTML);
}
}
Insert these lines after the catalina.policy file
grant codeBase file:/home/client/- {
permission java.io.FilePermission /home/client/-, read,write,delete;
permission java.util.PropertyPermission *, read;
};
Start catalina with:
./catalina.sh start -security
* NOW THE TESTS
First test. Put WriteFile.class and SecManagerTest.class on /WEB-INF/classes
Try to execute the servlet. It works !!!
Second test. Put WriteFile.jar on /WEB-INF/lib ( and remove WriteFile.class
from /classes ! ).
Restart Catalina. Try to access the servlet:
java.security.AccessControlException: access denied
(java.io.FilePermission /home/client/write_area/teste.txt write)
at java.security.AccessControlContext.checkPermission
(AccessControlContext.java:272)
at java.security.AccessController.checkPermission
(AccessController.java:399)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
at java.lang.SecurityManager.checkWrite(SecurityManager.java:978)
at java.io.FileOutputStream.(FileOutputStream.java:96)
at java.io.FileOutputStream.(FileOutputStream.java:62)
at java.io.FileWriter.(FileWriter.java:38)
at WriteFile.write(WriteFile.java:7)
at SecManagerTest.doGet(SecManagerTest.java:13)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
(...)
In Tomcat 3.3 beta 1, it works perfectly.
There is definitely something wrong with the Security Manager in Catalina.
Webhost companies that depends on the security manager cannot fully use
Catalina ( again, everything works pretty well with Tomcat 3.3 ).
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6552] - comments parsed in jsp pages
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=6552. 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=6552 comments parsed in jsp pages [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-02-25 18:31 --- JSP.2.6 specifies that % that appears in a scripting element has to be escaped as %\. The general philosophy for JSP syntax is to make it unnecessary for the parser to parse the body of the scripting elements. Without escaping %, the parser would terminate %! when it encounters the first %. The parser does not know about java comments. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6660] - Catalina with SecurityManager is possibly broken.
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=6660.
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=6660
Catalina with SecurityManager is possibly broken.
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||WORKSFORME
--- Additional Comments From [EMAIL PROTECTED] 2002-02-25 18:36 ---
The implementation of the Java SecurityManager is significantly different
between Tomcat 3.2/3.3 and Tomcat 4. The Tomcat 4 version implements much
finer control over granting permissions in the policy file. Even down to
granting permisions to individual classes within a jar.
jar's in /WEB-INF/lib have a completely different codeBase than classes in
/WEB-INF/classes.
To fix your problem add the following grant to your catalina.policy
grant codeBase jar:file:{path-to-webapp}/WEB-INF/lib/WriteFile.jar!/- {
permission java.io.FilePermission /home/client/-, read,write,delete;
permission java.util.PropertyPermission *, read;
};
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Problems with mod_webapp. Please read!
On Sat, 23 Feb 2002, Brian Millett wrote: On Fri, 2002-02-22 at 16:18, Erik Lotspeich wrote: Brian, In my previous e-mails I gave more details. My setup is this: Linux 2.4, glibc 2.1, JDK 1.3.1, Jakarta-tomcat 4.0.2, Apache 1.3.20, APR 20011211172103, mod_webapp 4.0.2. Does mod_webapp require a more recent version of Apache? Does it require JDK 1.4? I was under the impression that it would work with the setup that I had. Eric, did you compile webapp? Did you compile apache? What is in the apache error_log? What is in the tomcat/logs/apache log? Did you configure /webapp-info? I compiled both webapp and Apache from source. The error logs say nothing! The whole application (including Apache) crashes before Apache can print anything. I have made configuration file settings indicated by the minimal documentation. What do you mean by /webapp-info? Is there additional configuration that is necessary to keep the app from crashing? Santa Barbara? Must be nice. I grew up in Santa Ynez. Miss that ocean. It's definitely beautiful weather here. We're lucky. ;) Thanks, Erik. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Problems with mod_webapp. Please read!
Punky, I did run apachectl configtest. It claims that my configuration is correct. Thanks, Erik. On Mon, 25 Feb 2002, Punky Tse wrote: Erik, I have similar config. But I have no problem for it. Did you run apachectl configtest to prove your config is correct? Punky - Original Message - From: Erik Lotspeich [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Saturday, February 23, 2002 6:18 AM Subject: Re: Problems with mod_webapp. Please read! Brian, In my previous e-mails I gave more details. My setup is this: Linux 2.4, glibc 2.1, JDK 1.3.1, Jakarta-tomcat 4.0.2, Apache 1.3.20, APR 20011211172103, mod_webapp 4.0.2. Does mod_webapp require a more recent version of Apache? Does it require JDK 1.4? I was under the impression that it would work with the setup that I had. Thanks, Erik. On 22 Feb 2002, Brian P. Millett wrote: On Fri, 2002-02-22 at 15:58, Erik Lotspeich wrote: Is there anybody who has successfully built mod_webapp and gotten it to work properly? Yes, since you didn't say which platform, JVM, etc., I'll give you mine: RedHat 7.2, JDK 1.4, Jakarta-tomcat 4.0.2, Apache 2.0 b32 (works only with MPM=prefork) It works with velocity 1.2 cocoon 2.1 -- Erik Lotspeich | Lead Engineer ELC Technologies 1532 State Street Suite C Santa Barbara, CA 93101 [EMAIL PROTECTED] (805) 884.8300 phn (805) 884.8339 fax http://www.elctech.com/ - Privacy and Confidentiality Notice: The information contained in this electronic mail message is intended for the named recipient(s) only. It may contain privileged and confidential information. If you are not an intended recipient, you must not copy, forward, distribute or take any action in reliance on it. If you have received this electronic mail message in error, please notify the sender immediately. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Erik Lotspeich | Lead Engineer ELC Technologies 1532 State Street Suite C Santa Barbara, CA 93101 [EMAIL PROTECTED] (805) 884.8300 phn (805) 884.8339 fax http://www.elctech.com/ - Privacy and Confidentiality Notice: The information contained in this electronic mail message is intended for the named recipient(s) only. It may contain privileged and confidential information. If you are not an intended recipient, you must not copy, forward, distribute or take any action in reliance on it. If you have received this electronic mail message in error, please notify the sender immediately. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 6660] - Catalina with SecurityManager is possibly broken.
What if I want my users to put any *.jar files on /lib ( which will be controled by
the policy anyway... ) ? Do I need to configure each of them on catalina.policy and
then restart Tomcat ? ( this is not good... :(( ).
[EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=6660
Catalina with SecurityManager is possibly broken.
[EMAIL PROTECTED] changed:
What |Removed |Added
Status|NEW |RESOLVED
Resolution| |WORKSFORME
--- Additional Comments From [EMAIL PROTECTED] 2002-02-25 18:36 ---
The implementation of the Java SecurityManager is significantly different
between Tomcat 3.2/3.3 and Tomcat 4. The Tomcat 4 version implements much
finer control over granting permissions in the policy file. Even down to
granting permisions to individual classes within a jar.
jar's in /WEB-INF/lib have a completely different codeBase than classes in
/WEB-INF/classes.
To fix your problem add the following grant to your catalina.policy
grant codeBase jar:file:{path-to-webapp}/WEB-INF/lib/WriteFile.jar!/- {
permission java.io.FilePermission /home/client/-, read,write,delete;
permission java.util.PropertyPermission *, read;
};
--
To unsubscribe, e-mail:
For additional commands, e-mail:
-
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
DO NOT REPLY [Bug 6610] - Request-Time Attribute Expressions in XML-Syntax JSPs not working
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=6610. 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=6610 Request-Time Attribute Expressions in XML-Syntax JSPs not working [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-02-25 18:59 --- I tried a simple test, and it seemed to work. Did you set the rtexprvalue of the attibute in your tld to true? The default is false, so if you didn't set it to true, you'll get what you are getting now. If you still have problem with this, reopen the bug with a concrete test case: supply a war file! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 6660] - Catalina with SecurityManager is possibly broken.
What if I want my users to put any *.jar files on /lib ( which will be
controled by the policy anyway... ) ? Do I need to configure each of them
on
catalina.policy and then restart Tomcat ? ( this is not good... :(( ).
grant codeBase jar:file:{path-to-webapp}/WEB-INF/lib/WriteFile.jar!/- {
Doing: 'grant codeBase jar:file:{path-to-webapp}/WEB-INF/lib/-' should get
the job done.
Remy
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.1-dev WebappClassLoader and common/endorsed
I was wondering why the WebappClassLoader has the common/endorsed directory support in it. ? I don't understand what you're talking about here; the WCL doesn't have anything to do with endorsed or common. Right now, it (finally) complies with the spec, plus it has a very targetted class filter (to avoid classcasts on JNDI and the JAXP base classes). I can understand why the build and catalina.sh might have support for it, but not WebappClassloader. According to the following, replacement of endorsed standard API's is done by the JVM. http://java.sun.com/j2se/1.4/docs/guide/standards/index.html Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6443] - Jasper doesn't follow the spec in regards to the xml-view of a JSP page and whitespace handling semantics
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=6443. 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=6443 Jasper doesn't follow the spec in regards to the xml-view of a JSP page and whitespace handling semantics [EMAIL PROTECTED] changed: What|Removed |Added CC||tomcat- ||[EMAIL PROTECTED] AssignedTo|tomcat- |[EMAIL PROTECTED] |[EMAIL PROTECTED] | -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6662] New: - servlet context fails if webapp name smaller version of another webapp
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=6662. 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=6662 servlet context fails if webapp name smaller version of another webapp Summary: servlet context fails if webapp name smaller version of another webapp Product: Tomcat 4 Version: 4.0.2 Final Platform: PC OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Not sure I have the summary correct. We have both TheDataWeb and TheDataWeb_XXXs webapps in the webapp directory. A configuration service is provided by one of the webapps. It's accessed via a sc = getServletContext() followed by code that uses the sc.getContext() to pick up an attribute that's been stored in a context via getAttribute(blat); This works across webapps in 4.0.1 w/o crossContext in server.xml but has to have crossContext=true in server.xml in 4.0.2. That's not the 'bug' I'm working with. It works fine from TheDataWeb_X1 and TheDataWeb_X2 but _not_ from TheDataWeb. (following the above rules for crossContext). All I have to do is rename 'TheDataWeb' to something unique, i.e. 'TheDataWeb_X3' and, voila, the configuration information that's stored in the attribute is suddenly available the way it's been all along for the other, uniquely named, webapps. I'll be glad to provide any level of code detail. The problem is in both 4.0.1 and 4.0.2. When testing 4.0.2 I carefully setup crossContext=true for all webapps in server.xml, including the substring-not-unique-webapp-named webapp. The crossContext setup worked for all webapps except the substring-not-unique-webbapp-named webapp. Note that I'm not sure the crossContext default/setting has anything to do with this problem. Heitzso [EMAIL PROTECTED] or [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6443] - Jasper doesn't follow the spec in regards to the xml-view of a JSP page and whitespace handling semantics
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=6443. 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=6443 Jasper doesn't follow the spec in regards to the xml-view of a JSP page and whitespace handling semantics [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||LATER --- Additional Comments From [EMAIL PROTECTED] 2002-02-25 19:18 --- Jasper is not discarding white spaces that appear between elements. However, this is not high priority bug, and will be fixed with a new xml parser. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6432] - Jasper should validate that an XML-view of a JSP page conforms as much as possible based on the DTD supplied in JSP.B of the JSP 1.2 specification
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=6432. 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=6432 Jasper should validate that an XML-view of a JSP page conforms as much as possible based on the DTD supplied in JSP.B of the JSP 1.2 specification [EMAIL PROTECTED] changed: What|Removed |Added CC||tomcat- ||[EMAIL PROTECTED] AssignedTo|tomcat- |[EMAIL PROTECTED] |[EMAIL PROTECTED] | -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6643] - Tom 3.3a or 3.31b1 : URLRewriting POST == 404 error
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6643. 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=6643 Tom 3.3a or 3.31b1 : URLRewriting POST == 404 error [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-02-25 19:24 --- Section 8.1 of the servlet spec (either 2.2 or 2.3) states that you should pass a path to getRequestDispatcher, not a URL. If you don't call response.encodeURL on fenetreSuivante, everything will work fine. DisplayBagListServlet will still be able to access the correct session, since the session ID is already stored in the request object. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6663] New: - Adding trigger class in web app means that the class can not be found
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=6663. 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=6663 Adding trigger class in web app means that the class can not be found Summary: Adding trigger class in web app means that the class can not be found Product: Tomcat 4 Version: 4.0.2 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In my environment, I added a trigger class (e.g. javax.xml.*) in my web app. This causes the class loader to not find the class at all even if it is installed in one of the inherited class loaders. If this is added as a jar file,the jar is skipped but the class could still be found. However, if adding as a class file it will never be found because findClassInternal() method throws a ClassNotFoundExeption. This ClassNotFound is not intuitive. More intuitive would be what is done with the jar files, ignore the class in question (with a warning). If the code is operating according to spec, then more information/docs should be provided as to the real cause of the exception. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6376] - Improper import statement is generated when JSP page extends a custom class without package prefix
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=6376. 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=6376 Improper import statement is generated when JSP page extends a custom class without package prefix [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-02-25 19:34 --- When the extends attribute in a page directive specifies a top level class, i.e. one without a package, it is necessary to explicitly import that class, otherwise javac would assume that the extended class is in the same package as the generated servlet. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Problems with mod_webapp. Please read!
On Mon, 2002-02-25 at 12:54, Erik Lotspeich wrote: On Sat, 23 Feb 2002, Brian Millett wrote: Linux 2.4, glibc 2.1, JDK 1.3.1, Jakarta-tomcat 4.0.2, Apache 1.3.20, APR 20011211172103, mod_webapp 4.0.2. I compiled both webapp and Apache from source. The error logs say nothing! The whole application (including Apache) crashes before Apache can print anything. Ok, what commands (configure args, etc) did you use to compile apache webapp? Did you compile it as a DSO? You can put into the mod_webapp configurations a line: WebAppInfo /webapp-info that will be like the apache server-info url. -- Brian Millett Enterprise Consulting Group Shifts in paradigms (314) 205-9030 often cause nose bleeds. [EMAIL PROTECTED] Greg Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6663] - Adding trigger class in web app means that the class can not be found
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=6663. 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=6663 Adding trigger class in web app means that the class can not be found [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-02-25 19:46 --- Further investigation shows that the javax.xml.* trigger hides the ability for the webapp to introduce TRAX logic. The only workaround is to scope this at the common class loader -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 6660] - Catalina with SecurityManager is possibly broken.
Hi Remy,
Doing: grant codeBase jar:file:{path-to-webapp}/WEB-INF/lib/WriteFile.jar!/- {
worked fine
Doing: grant codeBase jar:file:{path-to-webapp}/WEB-INF/lib/- { did not worked.
(even tried: grant codeBase jar:file:{path-to-webapp}/WEB-INF/lib/-!/- { did not
worked. )
I'm reopening the bug report because if we can't grant permissions on all jars files
on the /lib it will a maintanance hell for wenhosting...
Thanks for the patience !
Renato.
Remy Maucherat [EMAIL PROTECTED] wrote: What if I want my users to put any *.jar
files on /lib ( which will be
controled by the policy anyway... ) ? Do I need to configure each of them
on
catalina.policy and then restart Tomcat ? ( this is not good... :(( ).
grant codeBase jar:file:{path-to-webapp}/WEB-INF/lib/WriteFile.jar!/- {
Doing: 'grant codeBase jar:file:{path-to-webapp}/WEB-INF/lib/-' should get
the job done.
Remy
--
To unsubscribe, e-mail:
For additional commands, e-mail:
-
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
DO NOT REPLY [Bug 6660] - Catalina with SecurityManager is possibly broken.
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=6660. 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=6660 Catalina with SecurityManager is possibly broken. [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-02-25 20:19 --- Sorry, my mistake, the URL specified for the codebase probably has to be a valid URL. I'm afraid this can't be fixed, then. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6663] - Adding trigger class in web app means that the class can not be found
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=6663. 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=6663 Adding trigger class in web app means that the class can not be found [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2002-02-25 20:25 --- Still think this is a bug. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6557] - isapi_redirector can not handle post request from netscape 4.7x
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=6557. 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=6557 isapi_redirector can not handle post request from netscape 4.7x --- Additional Comments From [EMAIL PROTECTED] 2002-02-25 20:30 --- i tried ajp13 for both tomcat3 and tomcat4. it seems worse, even ie can not connect to my servlet by calling both URLOpenStream()(an ie activex api) and NPN_PostURLNotify() (netscape plug api), which works fine with apache+tomcat. i send http requst with binary data in the body: 00 POST /InTether/s 50 4f 53 54 20 2f 49 6e 54 65 74 68 65 72 2f 73 16 ervlet/FileExcha 65 72 76 6c 65 74 2f 46 69 6c 65 45 78 63 68 61 32 ngeServer HTTP/1 6e 67 65 53 65 72 76 65 72 20 48 54 54 50 2f 31 48 .1..Accept: */*. 2e 31 0d 0a 41 63 63 65 70 74 3a 20 2a 2f 2a 0d 64 .Accept-Encoding 0a 41 63 63 65 70 74 2d 45 6e 63 6f 64 69 6e 67 80 : gzip, deflate. 3a 20 67 7a 69 70 2c 20 64 65 66 6c 61 74 65 0d 96 .User-Agent: Moz 0a 55 73 65 72 2d 41 67 65 6e 74 3a 20 4d 6f 7a 000112 illa/4.0 (compat 69 6c 6c 61 2f 34 2e 30 20 28 63 6f 6d 70 61 74 000128 ible; MSIE 6.0; 69 62 6c 65 3b 20 4d 53 49 45 20 36 2e 30 3b 20 000144 Windows NT 5.0; 57 69 6e 64 6f 77 73 20 4e 54 20 35 2e 30 3b 20 000160 InTetherAgent 0. 49 6e 54 65 74 68 65 72 41 67 65 6e 74 20 30 2e 000176 1/443e9c3c-7bb4- 31 2f 34 34 33 65 39 63 33 63 2d 37 62 62 34 2d 000192 4be8-9f79-656e21 34 62 65 38 2d 39 66 37 39 2d 36 35 36 65 32 31 000208 fff6f1)..Host: l 66 66 66 36 66 31 29 0d 0a 48 6f 73 74 3a 20 6c 000224 ocalhost:90..Con 6f 63 61 6c 68 6f 73 74 3a 39 30 0d 0a 43 6f 6e 000240 tent-Length: 4.. 74 65 6e 74 2d 4c 65 6e 67 74 68 3a 20 34 0d 0a 000256 Connection: Keep 43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 4b 65 65 70 000272 -Alive..Cache-Co 2d 41 6c 69 76 65 0d 0a 43 61 63 68 65 2d 43 6f 000288 ntrol: no-cache. 6e 74 72 6f 6c 3a 20 6e 6f 2d 63 61 63 68 65 0d 000304 .Cookie: JSESSIO 0a 43 6f 6f 6b 69 65 3a 20 4a 53 45 53 53 49 4f 000320 NID=97E25BFA89BD 4e 49 44 3d 39 37 45 32 35 42 46 41 38 39 42 44 000336 9B94AE94A9C65B8F 39 42 39 34 41 45 39 34 41 39 43 36 35 42 38 46 000352 0660 30 36 36 30 0d 0a 0d 0a ff ff ff ff but i caught exception in servlet: internal Server Error description server encountered an internal error (Internal Server Error) that prevented it from fulfilling this request and then IOException once i read from the request body the following are the log message from isapi.log: [Mon Feb 25 14:25:43 2002] [jk_isapi_plugin.c (657)]: HttpFilterProc started [Mon Feb 25 14:25:43 2002] [jk_isapi_plugin.c (705)]: In HttpFilterProc Virtual Host redirection of /localhost:90/InTether/servlet/FileExchangeServer [Mon Feb 25 14:25:43 2002] [jk_uri_worker_map.c (447)]: Into jk_uri_worker_map_t::map_uri_to_worker [Mon Feb 25 14:25:43 2002] [jk_uri_worker_map.c (464)]: Attempting to map URI '/localhost:90/InTether/servlet/FileExchangeServer' [Mon Feb 25 14:25:43 2002] [jk_uri_worker_map.c (570)]: jk_uri_worker_map_t::map_uri_to_worker, done without a match [Mon Feb 25 14:25:43 2002] [jk_isapi_plugin.c (711)]: In HttpFilterProc test Default redirection of /InTether/servlet/FileExchangeServer [Mon Feb 25 14:25:43 2002] [jk_uri_worker_map.c (447)]: Into jk_uri_worker_map_t::map_uri_to_worker [Mon Feb 25 14:25:43 2002] [jk_uri_worker_map.c (464)]: Attempting to map URI '/InTether/servlet/FileExchangeServer' [Mon Feb 25 14:25:43 2002] [jk_uri_worker_map.c (489)]: jk_uri_worker_map_t::map_uri_to_worker, Found a context match ajp13 - /InTether/ [Mon Feb 25 14:25:43 2002] [jk_isapi_plugin.c (721)]: HttpFilterProc [/InTether/servlet/FileExchangeServer] is a servlet url - should redirect to ajp13 [Mon Feb 25 14:25:43 2002] [jk_isapi_plugin.c (784)]: HttpFilterProc check if [/InTether/servlet/FileExchangeServer] is points to the web-inf directory [Mon Feb 25 14:25:43 2002] [jk_isapi_plugin.c (824)]: HttpExtensionProc started [Mon Feb 25 14:25:43 2002] [jk_worker.c (132)]: Into wc_get_worker_for_name ajp13 [Mon Feb 25 14:25:43 2002] [jk_worker.c (136)]: wc_get_worker_for_name, done found a worker [Mon Feb 25 14:25:43 2002] [jk_isapi_plugin.c (860)]: HttpExtensionProc got a worker for name ajp13 [Mon Feb 25 14:25:43 2002] [jk_ajp_common.c (1352)]: Into jk_worker_t::get_endpoint [Mon Feb 25 14:25:43 2002] [jk_ajp_common.c (1075)]: Into jk_endpoint_t::service [Mon Feb 25 14:25:43 2002] [jk_ajp_common.c (280)]: Into ajp_marshal_into_msgb [Mon Feb 25 14:25:43 2002] [jk_ajp_common.c (413)]: ajp_marshal_into_msgb - Done [Mon Feb 25 14:25:43 2002] [jk_ajp_common.c (612)]: sending to ajp13 #362 [Mon Feb 25 14:25:43 2002] [jk_ajp_common.c
Re: DO NOT REPLY [Bug 6660] - Catalina with SecurityManager is possibly broken.
If you can point me out where in Catalina code I could take a look, I'll appreciate. Also if you need a beta-tester for your application, you count on me. Thanks ! Glenn Nielsen [EMAIL PROTECTED] wrote: I also administer Tomcat for web hosting purposes and am aware of the problems configuring per web application policies. I have been working on a redesign of the SecurityManager implementation in Tomcat 4 which will make administration of these policies easier yet still allow very strict policy settings. I don't know when this will be ready. Glenn [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . 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=6660 Catalina with SecurityManager is possibly broken. [EMAIL PROTECTED] changed: What |Removed |Added Status|REOPENED |RESOLVED Resolution| |WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-02-25 20:19 --- Sorry, my mistake, the URL specified for the codebase probably has to be a valid URL. I'm afraid this can't be fixed, then. -- To unsubscribe, e-mail: For additional commands, e-mail: -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder | MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- To unsubscribe, e-mail: For additional commands, e-mail: - Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games
Re: Problems with mod_webapp. Please read!
Brian, I used --enable-shared=max and --enable-shared=most configure flags for Apache. Nothing too special. For webapp, I gave the following options: --with-tomcat --with-apr --with-apxs --enable-debug I compiled webapp as a DSO. My Apache configuration is as follows: # Insert code for mod_webapp LoadModule webapp_module libexec/mod_webapp.so AddModule mod_webapp.c IfModule mod_webapp.c WebAppConnection conn warp localhost:8008 WebAppDeploy examples conn /examples /IfModule I don't think that a WebAppInfo directive will make any difference since Apache won't even start, but I can give it a try. Thaks, Erik. On 25 Feb 2002, Brian P. Millett wrote: On Mon, 2002-02-25 at 12:54, Erik Lotspeich wrote: On Sat, 23 Feb 2002, Brian Millett wrote: Linux 2.4, glibc 2.1, JDK 1.3.1, Jakarta-tomcat 4.0.2, Apache 1.3.20, APR 20011211172103, mod_webapp 4.0.2. I compiled both webapp and Apache from source. The error logs say nothing! The whole application (including Apache) crashes before Apache can print anything. Ok, what commands (configure args, etc) did you use to compile apache webapp? Did you compile it as a DSO? You can put into the mod_webapp configurations a line: WebAppInfo /webapp-info that will be like the apache server-info url. k -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6669] New: - RealmBase imports, but doesn't need, SAX stuff
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=6669. 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=6669 RealmBase imports, but doesn't need, SAX stuff Summary: RealmBase imports, but doesn't need, SAX stuff Product: Tomcat 4 Version: Unknown Platform: All OS/Version: All Status: NEW Severity: Minor Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] RealmBase has an imports statement for org.xml.sax.AttributeList, but doesn't need it. Patch submitted RealmBaseImport.patch with subject [PATCH] MinimalTomcat, Coupling -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6670] New: - AuthenticatorBase uses StandardContext
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=6670. 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=6670 AuthenticatorBase uses StandardContext Summary: AuthenticatorBase uses StandardContext Product: Tomcat 4 Version: Unknown Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] o.a.c.authenticator.AuthenticatorBase casts its Context to a StandardContext in order to set the debug level. That means that AuthenticatorBase requires the presense of a StandardContext even if its not used. I've submitted a patch AuthBaseCast.patch under the subject [PATCH] MinimalTomcat, Coupling. The patch just removes the offending lines, but a better solution might be better to move the set/getDebug routines up into the Container interface. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6671] New: - Simple custom tag example uses old declaration style
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=6671. 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=6671 Simple custom tag example uses old declaration style Summary: Simple custom tag example uses old declaration style Product: Tomcat 4 Version: 4.0.2 Final Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Webapps AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Since this is the JSP 1.2 RI, it would be appropriate to use the new auto-discovery for TLDs introduced in JSP 1.2 instead of using taglib elements in the web.xml file. So I suggest removing all taglib elements from the web.xml file and fix the uri element in the TLD to match the taglib directive uri attribute in the sample JSP pages (one has example, the other examples) so that the auto-discovery features works. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
I posted to the dev list earlier about needing a small, relatively lightweight version of Catalina to embed into another program. I spent the weekend putting together something that more of less fits my needs. (My needs include a relatively small jar, plus no use of the local file system) I ended up with a 260k jarfile of the catalina classes, plus another 75k or so of new Container classes. I suspect there's at least another 100k that can be trimmed. I ran into a troubling amount of coupling between the various bits of Catalina. The o.a.catalina.* classes were fairly clean, but the implementation classes tended to know a lot about each other. That made reuse difficult, since inheriting from one of the core classes ended up bringing in pretty much every class (and external dependency) in Catalina. The implementation classes obviously need to know something about each other, but there are an awful lot of hardcoded assumptions. The large number of casts makes it very hard to figure out what depends on what. Instead of trying to make the core classes more generic, I ended up writing a new set of Containers and support classes. Using the existing Catalina code made that fairly easy, but much of the code re-use was necessarily of the cut-and-paste variety. There were a couple of especially inconvenient couplings that are probably worth fixing, one trivial and one a little more serious. I've submitted both of these as bugs. First, there's an uneeded import of org.xml.sax.AttributeList in o.a.c.realm.RealmBase. That one's not such a big deal since it doesn't matter at run time. The first of the attached patches removes it. Second, there's a cast to StandardContext in AuthenticatorBase. The cast is needed because AuthenticatorBase wants to use the same debug level as its associated Context, but Container doesn't expose the any set/getDebug methods. It would be good to get rid of the cast because it's the only place that BasicAuthenticator makes assumptions about the exact type of its Context. The second patch just gets rid of the StandardContext import and cast. A better solution might be to move set/getDebug up into Container. Adding a Debug interface would work too, but that seems like overkill. The MinimalTomcat code is definitely alpha quality, and it's only meant to support the particular subset of Catalina that I happen to need right at the moment. It is not, and is not intended to be, a complete reimplementation of the Catalina core classes. On the other hand, it's substantially smaller and less complicated, while retaining the same basic architecture. If anyone's interested, feel free to email me at the address below, or respond on the list. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com AuthBaseCast.patch Description: Binary data RealmBaseImport.patch Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6670] - AuthenticatorBase uses StandardContext
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=6670. 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=6670 AuthenticatorBase uses StandardContext [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement --- Additional Comments From [EMAIL PROTECTED] 2002-02-25 22:36 --- Since is uses an instanceof, it doesn't require that the associated context be a StandardContex, except at compilation time. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache13 jk_service_apache13.c mod_jk2.c
costin 02/02/25 14:44:36
Modified:jk/native2/server/apache13 mod_jk2.c
Added: jk/native2/server/apache13 jk_service_apache13.c
Log:
Added the service impl. for apache1.3
Few more fixes.
It now compiles and load fine.
Revision ChangesPath
1.2 +11 -44jakarta-tomcat-connectors/jk/native2/server/apache13/mod_jk2.c
Index: mod_jk2.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache13/mod_jk2.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- mod_jk2.c 23 Feb 2002 19:01:05 - 1.1
+++ mod_jk2.c 25 Feb 2002 22:44:36 - 1.2
@@ -59,7 +59,7 @@
* Description: Apache 1.3 plugin for Jakarta/Tomcat *
* Author: Gal Shachor [EMAIL PROTECTED] *
* Henri Gomez [EMAIL PROTECTED] *
- * Version: $Revision: 1.1 $ *
+ * Version: $Revision: 1.2 $ *
***/
/*
@@ -231,17 +231,13 @@
ap_get_module_config(s-module_config, jk2_module);
jk_workerEnv_t *workerEnv = serverEnv-workerEnv;
-jk_map_t *m=workerEnv-init_data;
-
env=workerEnv-globalEnv;
-value = jk2_map_replaceProperties(env, m, m-pool, value);
-
if( cmd-info != NULL ) {
-m-add(env, m, (char *)cmd-info, (char *)value );
+workerEnv-setProperty( env, workerEnv, (char *)cmd-info, (char *)value );
} else {
/* ??? Maybe this is a single-option */
-m-add(env, m, value, On );
+workerEnv-setProperty( env, workerEnv, value, On );
}
return NULL;
@@ -268,20 +264,11 @@
ap_get_module_config(s-module_config, jk2_module);
jk_workerEnv_t *workerEnv = serverEnv-workerEnv;
-jk_map_t *initData=workerEnv-init_data;
-
env=workerEnv-globalEnv;
-value = jk2_map_replaceProperties(env, initData, initData-pool, value);
-
-if(value==NULL)
-return NULL;
-
if( type==NULL || type[0]=='\0') {
/* Generic Jk2Set foo bar */
-initData-add(env, initData, ap_pstrdup( cmd-pool, name),
- ap_pstrdup( cmd-pool, value));
-/* fprintf( stderr, set2.init_data: %s %s\n, name, value ); */
+workerEnv-setProperty(env, workerEnv, name, value);
} else if( strcmp(type, env)==0) {
workerEnv-envvars_in_use = JK_TRUE;
workerEnv-envvars-put(env, workerEnv-envvars,
@@ -291,10 +278,7 @@
fprintf( stderr, set2.env %s %s\n, name, value );
} else if( strcmp(type, mount)==0) {
if (name[0] !='/') return Context must start with /;
-initData-put( env, initData,ap_pstrdup(cmd-pool,name),
-ap_pstrdup(cmd-pool,value), NULL );
-
-fprintf( stderr, set2.mount %s %s\n, name, value );
+workerEnv-setProperty( env, workerEnv, name, value );
} else {
fprintf( stderr, set2 error %s %s %s , type, name, value );
}
@@ -368,7 +352,7 @@
static void *jk2_create_dir_config(ap_pool *p, char *path)
{
jk_uriEnv_t *new =
-(jk_uriEnv_t *)apr_pcalloc(p, sizeof(jk_uriEnv_t));
+(jk_uriEnv_t *)ap_pcalloc(p, sizeof(jk_uriEnv_t));
fprintf(stderr, XXX Create dir config %s %p\n, path, new);
new-uri = path;
@@ -382,7 +366,7 @@
{
jk_uriEnv_t *base =(jk_uriEnv_t *)basev;
jk_uriEnv_t *add = (jk_uriEnv_t *)addv;
-jk_uriEnv_t *new = (jk_uriEnv_t *)apr_pcalloc(p,sizeof(jk_uriEnv_t));
+jk_uriEnv_t *new = (jk_uriEnv_t *)ap_pcalloc(p,sizeof(jk_uriEnv_t));
if( add-webapp == NULL ) {
add-webapp=base-webapp;
@@ -449,7 +433,7 @@
}
-newUri=(jk_uriEnv_t *)apr_pcalloc(p, sizeof(jk_uriEnv_t));
+newUri=(jk_uriEnv_t *)ap_pcalloc(p, sizeof(jk_uriEnv_t));
newUri-workerEnv=workerEnv;
@@ -526,6 +510,7 @@
int rc;
jk_env_t *env;
+
if(s-is_virtual)
return OK;
@@ -537,7 +522,7 @@
/* This is the first step */
env-l-jkLog(env, env-l, JK_LOG_INFO,
mod_jk.post_config() first invocation\n);
-apr_pool_userdata_set( INITOK, mod_jk_init, NULL, gPool );
+/* ap_pool_userdata_set( INITOK, mod_jk_init, NULL, gPool ); */
return OK;
}
@@ -636,7 +621,7 @@
}
/* XXX we should reuse the request itself !!! */
-jk2_service_apache2_factory( env, rPool, (void *)s,
+jk2_service_apache13_factory( env, rPool, (void *)s,
DO NOT REPLY [Bug 6211] - bug with jsp:plugin
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=6211. 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=6211 bug with jsp:plugin [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-02-25 22:46 --- Fixed in 4.0.3 and the nightly build. Thanks Olivier Billiard for the patch. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6670] - AuthenticatorBase uses StandardContext
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=6670. 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=6670 AuthenticatorBase uses StandardContext --- Additional Comments From [EMAIL PROTECTED] 2002-02-25 22:50 --- instanceof requires that the StandardContext class be _present_ at runtime, whether it's used or not. That makes AuthenticatorBase (and thus BasicAuthenticator) impossible to reuse outside the core Catalina classes. Since, outside of that one line, AuthenticatorBase is perfectly happy dealing with a generic Context, it would be nice to get rid of the restriction. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
I'm very interested. We should call it HouseCat. I'd like to find a home for it if it doesn't fit into tomcat. -Original Message- From: Christopher K.St.John [mailto:[EMAIL PROTECTED]] Sent: Monday, February 25, 2002 5:35 PM To: [EMAIL PROTECTED] Subject: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670 I posted to the dev list earlier about needing a small, relatively lightweight version of Catalina to embed into another program. I spent the weekend putting together something that more of less fits my needs. (My needs include a relatively small jar, plus no use of the local file system) I ended up with a 260k jarfile of the catalina classes, plus another 75k or so of new Container classes. I suspect there's at least another 100k that can be trimmed. I ran into a troubling amount of coupling between the various bits of Catalina. The o.a.catalina.* classes were fairly clean, but the implementation classes tended to know a lot about each other. That made reuse difficult, since inheriting from one of the core classes ended up bringing in pretty much every class (and external dependency) in Catalina. The implementation classes obviously need to know something about each other, but there are an awful lot of hardcoded assumptions. The large number of casts makes it very hard to figure out what depends on what. Instead of trying to make the core classes more generic, I ended up writing a new set of Containers and support classes. Using the existing Catalina code made that fairly easy, but much of the code re-use was necessarily of the cut-and-paste variety. There were a couple of especially inconvenient couplings that are probably worth fixing, one trivial and one a little more serious. I've submitted both of these as bugs. First, there's an uneeded import of org.xml.sax.AttributeList in o.a.c.realm.RealmBase. That one's not such a big deal since it doesn't matter at run time. The first of the attached patches removes it. Second, there's a cast to StandardContext in AuthenticatorBase. The cast is needed because AuthenticatorBase wants to use the same debug level as its associated Context, but Container doesn't expose the any set/getDebug methods. It would be good to get rid of the cast because it's the only place that BasicAuthenticator makes assumptions about the exact type of its Context. The second patch just gets rid of the StandardContext import and cast. A better solution might be to move set/getDebug up into Container. Adding a Debug interface would work too, but that seems like overkill. The MinimalTomcat code is definitely alpha quality, and it's only meant to support the particular subset of Catalina that I happen to need right at the moment. It is not, and is not intended to be, a complete reimplementation of the Catalina core classes. On the other hand, it's substantially smaller and less complicated, while retaining the same basic architecture. If anyone's interested, feel free to email me at the address below, or respond on the list. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com
RE: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
On Mon, 25 Feb 2002, Aaron Smuts wrote: Date: Mon, 25 Feb 2002 17:58:27 -0500 From: Aaron Smuts [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: RE: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670 I'm very interested. We should call it HouseCat. I'd like to find a home for it if it doesn't fit into tomcat. TomKitten? :-) Craig -Original Message- From: Christopher K.St.John [mailto:[EMAIL PROTECTED]] Sent: Monday, February 25, 2002 5:35 PM To: [EMAIL PROTECTED] Subject: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670 I posted to the dev list earlier about needing a small, relatively lightweight version of Catalina to embed into another program. I spent the weekend putting together something that more of less fits my needs. (My needs include a relatively small jar, plus no use of the local file system) I ended up with a 260k jarfile of the catalina classes, plus another 75k or so of new Container classes. I suspect there's at least another 100k that can be trimmed. I ran into a troubling amount of coupling between the various bits of Catalina. The o.a.catalina.* classes were fairly clean, but the implementation classes tended to know a lot about each other. That made reuse difficult, since inheriting from one of the core classes ended up bringing in pretty much every class (and external dependency) in Catalina. The implementation classes obviously need to know something about each other, but there are an awful lot of hardcoded assumptions. The large number of casts makes it very hard to figure out what depends on what. Instead of trying to make the core classes more generic, I ended up writing a new set of Containers and support classes. Using the existing Catalina code made that fairly easy, but much of the code re-use was necessarily of the cut-and-paste variety. There were a couple of especially inconvenient couplings that are probably worth fixing, one trivial and one a little more serious. I've submitted both of these as bugs. First, there's an uneeded import of org.xml.sax.AttributeList in o.a.c.realm.RealmBase. That one's not such a big deal since it doesn't matter at run time. The first of the attached patches removes it. Second, there's a cast to StandardContext in AuthenticatorBase. The cast is needed because AuthenticatorBase wants to use the same debug level as its associated Context, but Container doesn't expose the any set/getDebug methods. It would be good to get rid of the cast because it's the only place that BasicAuthenticator makes assumptions about the exact type of its Context. The second patch just gets rid of the StandardContext import and cast. A better solution might be to move set/getDebug up into Container. Adding a Debug interface would work too, but that seems like overkill. The MinimalTomcat code is definitely alpha quality, and it's only meant to support the particular subset of Catalina that I happen to need right at the moment. It is not, and is not intended to be, a complete reimplementation of the Catalina core classes. On the other hand, it's substantially smaller and less complicated, while retaining the same basic architecture. If anyone's interested, feel free to email me at the address below, or respond on the list. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
Aaron Smuts wrote: I'm very interested. We should call it HouseCat. I'd like to find a home for it if it doesn't fit into tomcat. I detest housecats, but I suppose that's not really the point :-) I'm not sure my is generally useful. The basic approach probably is, but maybe not the code. I personally don't really need all the run-time event stuff (not the servlet-spec events, the Catalina internal events). I don't need JSP. I don't need run-time parsing of the config server.xml and web.xml files. I don't need the full-on security architecture (so I don't need facades and I don't need SecurityManager code). I don't need (but kinda want) the JMX management interfaces. Etc. The code I've written is only useful if you're eliminating the exact same set of things I am. Otherwise, you bloat out until you're full-on Catalina again. (OTOH, projects like Galeon managed to find generally useful subsets of Mozilla, so there's an existence proof that such a thing is possible.) But if I'm the only one use Catalina as a framework instead of as a monolithic servlet container, it isn't going to work. There's too much pressure on developers to 'cheat' and tightly couple all the implementation classes. It's just easier that way. Right now, MinimalTomcat basically can't use anything within o.a.catalina.core, but eventually all the packages will be tightly linked unless there's some sort of incentive not to. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
What I'd like would be a Jakarta version of something small and simple like the oldest available Jetty version. -Original Message- From: Christopher K.St.John [mailto:[EMAIL PROTECTED]] Sent: Monday, February 25, 2002 6:58 PM To: [EMAIL PROTECTED] Subject: Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670 Aaron Smuts wrote: I'm very interested. We should call it HouseCat. I'd like to find a home for it if it doesn't fit into tomcat. I detest housecats, but I suppose that's not really the point :-) You're no friend of mine then. :) I'm not sure my is generally useful. The basic approach probably is, but maybe not the code. I personally don't really need all the run-time event stuff (not the servlet-spec events, the Catalina internal events). I don't need JSP. I don't need run-time parsing of the config server.xml and web.xml files. I don't need the full-on security architecture (so I don't need facades and I don't need SecurityManager code). I don't need (but kinda want) the JMX management interfaces. Etc. Sounds about like what I need. I need an engine to serve a simple servlet embedded in a cache server so I can clear the caches and monitor the regions. The code I've written is only useful if you're eliminating the exact same set of things I am. Otherwise, you bloat out until you're full-on Catalina again. (OTOH, projects like Galeon managed to find generally useful subsets of Mozilla, so there's an existence proof that such a thing is possible.) But if I'm the only one use Catalina as a framework instead of as a monolithic servlet container, it isn't going to work. There's too much pressure on developers to 'cheat' and tightly couple all the implementation classes. It's just easier that way. Right now, MinimalTomcat basically can't use anything within o.a.catalina.core, but eventually all the packages will be tightly linked unless there's some sort of incentive not to. Sounds like you'll have trouble when the parent package changes. You need something new and separate. Aaron -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED]
In memory replication - a non intrusive approach
Hi, first of all, my name is filip, hope you all are doing well. a few weeks back I wrote an email about clustering and if there was any initiative. I looked at the source code of Catalina, and it didn't appear to me that it was a complete implementation since it was using regular UDP packets without guaranteed delivery of messages between nodes. I implented an in memory session replication that works pretty well for me, at least in the tests that I have ran. I also wrote complete docs (with the source code published) that you can find on http://www.filip.net/tomcat/tomcat-javagroups.html I'd like to contribute this source to the Tomcat/Catalina project and continue to develop it from there. So I have my question for the developers of Tomcat is: Could I add this source to the source of Catalina and continue to contribute to the cluster implementation of Tomcat? Kindly let me know Filip ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect [EMAIL PROTECTED] www.filip.net -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6663] - Adding trigger class in web app means that the class can not be found
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=6663. 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=6663 Adding trigger class in web app means that the class can not be found [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-02-26 00:36 --- *** This bug has been marked as a duplicate of 6374 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6374] - class not find for:org/w3c/dom/range/Range
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=6374. 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=6374 class not find for:org/w3c/dom/range/Range [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-02-26 00:36 --- *** Bug 6663 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm RealmBase.java
remm02/02/25 16:49:22 Modified:catalina/src/share/org/apache/catalina/realm RealmBase.java Log: - Removed unused import. - Submitted by Christopher K. St. John. Revision ChangesPath 1.10 +4 -5 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/RealmBase.java Index: RealmBase.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/RealmBase.java,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- RealmBase.java9 Nov 2001 19:40:12 - 1.9 +++ RealmBase.java26 Feb 2002 00:49:22 - 1.10 @@ -1,7 +1,7 @@ /* - * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/RealmBase.java,v 1.9 2001/11/09 19:40:12 remm Exp $ - * $Revision: 1.9 $ - * $Date: 2001/11/09 19:40:12 $ + * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/RealmBase.java,v 1.10 2002/02/26 00:49:22 remm Exp $ + * $Revision: 1.10 $ + * $Date: 2002/02/26 00:49:22 $ * * * @@ -83,7 +83,6 @@ import org.apache.catalina.util.LifecycleSupport; import org.apache.catalina.util.StringManager; import org.apache.catalina.util.MD5Encoder; -import org.xml.sax.AttributeList; /** @@ -92,7 +91,7 @@ * location) are identical to those currently supported by Tomcat 3.X. * * @author Craig R. McClanahan - * @version $Revision: 1.9 $ $Date: 2001/11/09 19:40:12 $ + * @version $Revision: 1.10 $ $Date: 2002/02/26 00:49:22 $ */ public abstract class RealmBase -- 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/realm RealmBase.java
remm02/02/25 16:50:08 Modified:catalina/src/share/org/apache/catalina/realm Tag: tomcat_40_branch RealmBase.java Log: - Removed unused import. - Submitted by Christopher K. St. John. Revision ChangesPath No revision No revision 1.7.2.1 +4 -5 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/RealmBase.java Index: RealmBase.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/RealmBase.java,v retrieving revision 1.7 retrieving revision 1.7.2.1 diff -u -r1.7 -r1.7.2.1 --- RealmBase.java7 Sep 2001 20:45:12 - 1.7 +++ RealmBase.java26 Feb 2002 00:50:08 - 1.7.2.1 @@ -1,7 +1,7 @@ /* - * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/RealmBase.java,v 1.7 2001/09/07 20:45:12 ccain Exp $ - * $Revision: 1.7 $ - * $Date: 2001/09/07 20:45:12 $ + * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/RealmBase.java,v 1.7.2.1 2002/02/26 00:50:08 remm Exp $ + * $Revision: 1.7.2.1 $ + * $Date: 2002/02/26 00:50:08 $ * * * @@ -86,7 +86,6 @@ import org.apache.catalina.util.xml.SaxContext; import org.apache.catalina.util.xml.XmlAction; import org.apache.catalina.util.xml.XmlMapper; -import org.xml.sax.AttributeList; /** @@ -95,7 +94,7 @@ * location) are identical to those currently supported by Tomcat 3.X. * * @author Craig R. McClanahan - * @version $Revision: 1.7 $ $Date: 2001/09/07 20:45:12 $ + * @version $Revision: 1.7.2.1 $ $Date: 2002/02/26 00:50:08 $ */ public abstract class RealmBase -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6669] - RealmBase imports, but doesn't need, SAX stuff
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=6669. 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=6669 RealmBase imports, but doesn't need, SAX stuff [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-02-26 00:55 --- Please don't file a bug for this kind of stuff; submitting a patch is more than enough, and it minimizes the amount of traffic on tc-dev. Thanks. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6640] - The classpath is not evalueted
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=6640. 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=6640 The classpath is not evalueted [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-02-26 00:57 --- TC 4 will indeed ignore the system classpath. The second part of the bug is working fine for me (it would seem appropriate to post on tomcat-user to investigate). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: In memory replication - a non intrusive approach
Hi, first of all, my name is filip, hope you all are doing well. a few weeks back I wrote an email about clustering and if there was any initiative. I looked at the source code of Catalina, and it didn't appear to me that it was a complete implementation since it was using regular UDP packets without guaranteed delivery of messages between nodes. I implented an in memory session replication that works pretty well for me, at least in the tests that I have ran. I also wrote complete docs (with the source code published) that you can find on http://www.filip.net/tomcat/tomcat-javagroups.html I'd like to contribute this source to the Tomcat/Catalina project and continue to develop it from there. So I have my question for the developers of Tomcat is: Could I add this source to the source of Catalina and continue to contribute to the cluster implementation of Tomcat? Yes, why not. Note that the feature is: - a bit redundant with JK/JK2 load balancing, so it's not my top priority personally - currently in alpha/unsupported status If you want to fix it, then it would add more deployment options for a clustered Tomcat (that's good). Remy -- 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/ant DeployTask.java InstallTask.java ReloadTask.java RemoveTask.java StartTask.java StopTask.java
craigmcc02/02/25 17:24:33
Modified:catalina/src/share/org/apache/catalina/ant DeployTask.java
InstallTask.java ReloadTask.java RemoveTask.java
StartTask.java StopTask.java
Log:
Update Ant tasks to URLEncode the query parameters that are sent along with
the commands to the Manager webapp. This deals with issues like spaces in
the context path, which were not being deployed correctly.
FIXME - The code that maps a request URI to a context still chokes on a
space in the context path; that is the next thing to be fixed.
Revision ChangesPath
1.2 +5 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ant/DeployTask.java
Index: DeployTask.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ant/DeployTask.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- DeployTask.java 12 Feb 2002 22:14:01 - 1.1
+++ DeployTask.java 26 Feb 2002 01:24:33 - 1.2
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ant/DeployTask.java,v
1.1 2002/02/12 22:14:01 craigmcc Exp $
- * $Revision: 1.1 $
- * $Date: 2002/02/12 22:14:01 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ant/DeployTask.java,v
1.2 2002/02/26 01:24:33 craigmcc Exp $
+ * $Revision: 1.2 $
+ * $Date: 2002/02/26 01:24:33 $
*
*
*
@@ -67,6 +67,7 @@
import java.io.IOException;
import java.net.URL;
import java.net.URLConnection;
+import java.net.URLEncoder;
import org.apache.tools.ant.BuildException;
import org.apache.tools.ant.Task;
@@ -76,7 +77,7 @@
* the Tomcat manager application.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.1 $ $Date: 2002/02/12 22:14:01 $
+ * @version $Revision: 1.2 $ $Date: 2002/02/26 01:24:33 $
* @since 4.1
*/
public class DeployTask extends AbstractCatalinaTask {
@@ -142,7 +143,7 @@
} catch (IOException e) {
throw new BuildException(e);
}
-execute(/deploy?path= + this.path, stream,
+execute(/deploy?path= + URLEncoder.encode(this.path), stream,
application/octet-stream, contentLength);
}
1.3 +8 -7
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ant/InstallTask.java
Index: InstallTask.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ant/InstallTask.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- InstallTask.java 12 Feb 2002 22:14:01 - 1.2
+++ InstallTask.java 26 Feb 2002 01:24:33 - 1.3
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ant/InstallTask.java,v
1.2 2002/02/12 22:14:01 craigmcc Exp $
- * $Revision: 1.2 $
- * $Date: 2002/02/12 22:14:01 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ant/InstallTask.java,v
1.3 2002/02/26 01:24:33 craigmcc Exp $
+ * $Revision: 1.3 $
+ * $Date: 2002/02/26 01:24:33 $
*
*
*
@@ -63,6 +63,7 @@
package org.apache.catalina.ant;
+import java.net.URLEncoder;
import org.apache.tools.ant.BuildException;
import org.apache.tools.ant.Task;
@@ -72,7 +73,7 @@
* Tomcat manager application.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.2 $ $Date: 2002/02/12 22:14:01 $
+ * @version $Revision: 1.3 $ $Date: 2002/02/26 01:24:33 $
* @since 4.1
*/
public class InstallTask extends AbstractCatalinaTask {
@@ -144,14 +145,14 @@
(Must specify at least one of 'config' and 'war');
}
StringBuffer sb = new StringBuffer(/install?path=);
-sb.append(this.path);
+sb.append(URLEncoder.encode(this.path));
if (config != null) {
sb.append(config=);
-sb.append(config);
+sb.append(URLEncoder.encode(config));
}
if (war != null) {
sb.append(war=);
-sb.append(war);
+sb.append(URLEncoder.encode(war));
}
execute(sb.toString());
1.3 +6 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ant/ReloadTask.java
Index: ReloadTask.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ant/ReloadTask.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u
Re: DO NOT REPLY [Bug 6660] - Catalina with SecurityManager is possibly broken.
If you can point me out where in Catalina code I could take a look, I'll appreciate. Also if you need a beta-tester for your application, you count on me. No need to submit a patch; it is quite easy to set simpler URLs for the CodeSource location, but apprently Glenn likes the possibility to set per-class permissions (a feature I introduced by accident when coding the WCL). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
I posted to the dev list earlier about needing a small, relatively lightweight version of Catalina to embed into another program. I spent the weekend putting together something that more of less fits my needs. (My needs include a relatively small jar, plus no use of the local file system) I ended up with a 260k jarfile of the catalina classes, plus another 75k or so of new Container classes. I suspect there's at least another 100k that can be trimmed. The MinimalTomcat code is definitely alpha quality, and it's only meant to support the particular subset of Catalina that I happen to need right at the moment. It is not, and is not intended to be, a complete reimplementation of the Catalina core classes. On the other hand, it's substantially smaller and less complicated, while retaining the same basic architecture. If anyone's interested, feel free to email me at the address below, or respond on the list. Well, it's not that I want to advocate the competition, but it seems to me that Tomcat 3 is more useful for a MiniTomcat, mainly because it requires only JDK 1.1 (smaller JDK; J2ME is based on JDK 1.1, so maybe it could end up being a target; that was one of Costin's pet projects, actually). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
Aaron Smuts wrote: What I'd like would be a Jakarta version of something small and simple like the oldest available Jetty version. I'll take a look. Sounds like you'll have trouble when the parent package changes. You need something new and separate. Well, the org.apache.catalina package is fairly clean, and gives the impression that it will stay that way. It does depend on o.a.c.deploy, but those are mostly little struct-like utility classes for use during Digestion. It's classes like StandardWrapper that worry me. It comes very close to being generic, but has a hardcoded cast of its Context to StandardContext. It looks an awful lot like the cast was introduced during the addition of Filters in order to avoid an api change to the Context interface. Coupling StandardWrapper to StandardContext isn't necessarily unreasonable, especially if StandardWrapper was never meant to be used outside the whole StandardEngine/Host/Context/Wrapper setup, but it does signal that the Catalina core classes are not meant to be used outside the normal Catalina channels. I'm worried that the same sort of thing will happen with, for example, the realm and authorization packages. If it does, there's really no point in having MinimalTomcat use any of the Catalina classes at all except through cut and paste. Can one of the Catalina architects (Craig?) comment? Is it reasonable to try to use Catalina as a framework like that? Or am I swimming against the tide? In any case, tomorrow I'll whip up a sourceball of the current MinimalTomcat code and stick it out on the net somewhere. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 6660] - Catalina with SecurityManager is possibly broken.
Remy Maucherat wrote:
If you can point me out where in Catalina code I could take a look,
I'll
appreciate.
Also if you need a beta-tester for your application, you count on me.
No need to submit a patch; it is quite easy to set simpler URLs for the
CodeSource location, but apprently Glenn likes the possibility to set
per-class permissions (a feature I introduced by accident when coding
the
WCL).
I was just commenting on how it currently works. I really don't see a
need
to fine tune security down to the individual class in a jar.
Ok.
If the WebappClassLoader were changed so that policies granted as follows
worked I would be happy. Of course the code base for the web application
context and jar files would still be different due to how the
WebappClassLoader
works.
No, why ? I can create whatever I want for the SourceCode location. I would
have to add a new field to the ResourceEntry class, though (which doesn't
seem to be a big problem).
I was already considering changing it (as I wanted to be 100% compatible
with the URLClassLoader), but I didn't see any bug reason to do so.
grant codeBase=jar:file:{path-to-webapp}/WEB-INF/lib/some.jar {
// Some permissions for this jar
};
grant codeBase=jar:file:{path-to-webapp}/WEB-INF/lib/- {
// Some permissions for this jar
};
No, after the fix, it would be the same as for the URLClassLoader:
grant codeBase=file:{path-to-webapp}/WEB-INF/lib/some.jar {
// Some permissions for this jar
};
grant codeBase=file:{path-to-webapp}/WEB-INF/lib/- {
// Some permissions for the jars
};
Remy
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] - Tocmat 4, implement new Catalina SecurityManager Policy class
Due to recent questions about the SecurityManager implementation in Tomcat 4 I decided to post my proposal for overhauling how security policies are managed in Tomcat 4. This is something I have wanted to do for a while but has been sitting on the back burner as I have been very busy with other work (non open source) related projects.. Yes, I think it looks good, and full of useful features. The only thing is that IMO it should be integrated in the server.xml file and its child files. I don't see any reason to keep that in separate config files. I think I could implement it if I have some time, which is a possibility after I finish Coyote. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ant DeployTask.java InstallTask.java ReloadTask.java RemoveTask.java StartTask.java StopTask.java
craigmcc02/02/25 17:24:33 Modified:catalina/src/share/org/apache/catalina/ant DeployTask.java InstallTask.java ReloadTask.java RemoveTask.java StartTask.java StopTask.java Log: Update Ant tasks to URLEncode the query parameters that are sent along with the commands to the Manager webapp. This deals with issues like spaces in the context path, which were not being deployed correctly. FIXME - The code that maps a request URI to a context still chokes on a space in the context path; that is the next thing to be fixed. Yes, I tried it, and it indeed it doesn't work (bug 6286). I didn't even try to look at it, since I was worried by the possibility of reintroducing some URL-encoding security problems. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
Remy Maucherat wrote: Well, it's not that I want to advocate the competition, but it seems to me that Tomcat 3 is more useful for a MiniTomcat, mainly because it requires only JDK 1.1 (smaller JDK; J2ME is based on JDK 1.1, so maybe it could end up being a target; that was one of Costin's pet projects, actually). For my purposes, it's ok to assume 1.2, so that's not an issue. If Tomcat 4 isn't meant to be used like I'm using it, then I don't really understand the point of the generic interfaces in o.a.catalina. If StandardContext is the only possible Context implementation, what's the justification for a generic Context interface? The current architecture requires an awful lot of casts, and if the only configuration allowed is: StandardEngine/StandardHost/StandardContext/StandardWrapper then most of them are unnessary. What's the point of going through hoops with the generic interfaces if you know the exact types in advance? I understand that project goals can change, but the design of the apis (not to mention the javadocs) do seem to strongly imply that something like MinimalTomcat should be legit. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, February 25, 2002 5:29 PM Subject: Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670 I posted to the dev list earlier about needing a small, relatively lightweight version of Catalina to embed into another program. I spent the weekend putting together something that more of less fits my needs. (My needs include a relatively small jar, plus no use of the local file system) I ended up with a 260k jarfile of the catalina classes, plus another 75k or so of new Container classes. I suspect there's at least another 100k that can be trimmed. The MinimalTomcat code is definitely alpha quality, and it's only meant to support the particular subset of Catalina that I happen to need right at the moment. It is not, and is not intended to be, a complete reimplementation of the Catalina core classes. On the other hand, it's substantially smaller and less complicated, while retaining the same basic architecture. If anyone's interested, feel free to email me at the address below, or respond on the list. Well, it's not that I want to advocate the competition, but it seems to me that Tomcat 3 is more useful for a MiniTomcat, mainly because it requires only JDK 1.1 (smaller JDK; J2ME is based on JDK 1.1, so maybe it could end up being a target; that was one of Costin's pet projects, actually). The main problem that I would see is that you'd have to tweak some classes to get TC 3.3 to run disk-less. Otherwise, yes, Costin has done a lot of work towards letting you run TomKitten 3.3 on your toaster. 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: Problems with mod_webapp. Please read!
Erik, Have you set ServerName directive? Or any VirtualHost defined? Regards, Punky - Original Message - From: Erik Lotspeich [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, February 26, 2002 5:37 AM Subject: Re: Problems with mod_webapp. Please read! Brian, I used --enable-shared=max and --enable-shared=most configure flags for Apache. Nothing too special. For webapp, I gave the following options: --with-tomcat --with-apr --with-apxs --enable-debug I compiled webapp as a DSO. My Apache configuration is as follows: # Insert code for mod_webapp LoadModule webapp_module libexec/mod_webapp.so AddModule mod_webapp.c IfModule mod_webapp.c WebAppConnection conn warp localhost:8008 WebAppDeploy examples conn /examples /IfModule I don't think that a WebAppInfo directive will make any difference since Apache won't even start, but I can give it a try. Thaks, Erik. On 25 Feb 2002, Brian P. Millett wrote: On Mon, 2002-02-25 at 12:54, Erik Lotspeich wrote: On Sat, 23 Feb 2002, Brian Millett wrote: Linux 2.4, glibc 2.1, JDK 1.3.1, Jakarta-tomcat 4.0.2, Apache 1.3.20, APR 20011211172103, mod_webapp 4.0.2. I compiled both webapp and Apache from source. The error logs say nothing! The whole application (including Apache) crashes before Apache can print anything. Ok, what commands (configure args, etc) did you use to compile apache webapp? Did you compile it as a DSO? You can put into the mod_webapp configurations a line: WebAppInfo /webapp-info that will be like the apache server-info url. k -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Problems with mod_webapp. Please read!
Punky, Yes, I have set ServerName. If I don't set ServerName, then I get an error from Apache. Erik. On Tue, 26 Feb 2002, Punky Tse wrote: Erik, Have you set ServerName directive? Or any VirtualHost defined? Regards, Punky - Original Message - From: Erik Lotspeich [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, February 26, 2002 5:37 AM Subject: Re: Problems with mod_webapp. Please read! Brian, I used --enable-shared=max and --enable-shared=most configure flags for Apache. Nothing too special. For webapp, I gave the following options: --with-tomcat --with-apr --with-apxs --enable-debug I compiled webapp as a DSO. My Apache configuration is as follows: # Insert code for mod_webapp LoadModule webapp_module libexec/mod_webapp.so AddModule mod_webapp.c IfModule mod_webapp.c WebAppConnection conn warp localhost:8008 WebAppDeploy examples conn /examples /IfModule I don't think that a WebAppInfo directive will make any difference since Apache won't even start, but I can give it a try. Thaks, Erik. On 25 Feb 2002, Brian P. Millett wrote: On Mon, 2002-02-25 at 12:54, Erik Lotspeich wrote: On Sat, 23 Feb 2002, Brian Millett wrote: Linux 2.4, glibc 2.1, JDK 1.3.1, Jakarta-tomcat 4.0.2, Apache 1.3.20, APR 20011211172103, mod_webapp 4.0.2. I compiled both webapp and Apache from source. The error logs say nothing! The whole application (including Apache) crashes before Apache can print anything. Ok, what commands (configure args, etc) did you use to compile apache webapp? Did you compile it as a DSO? You can put into the mod_webapp configurations a line: WebAppInfo /webapp-info that will be like the apache server-info url. k -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Erik Lotspeich | Lead Engineer ELC Technologies 1532 State Street Suite C Santa Barbara, CA 93101 [EMAIL PROTECTED] (805) 884.8300 phn (805) 884.8339 fax http://www.elctech.com/ - Privacy and Confidentiality Notice: The information contained in this electronic mail message is intended for the named recipient(s) only. It may contain privileged and confidential information. If you are not an intended recipient, you must not copy, forward, distribute or take any action in reliance on it. If you have received this electronic mail message in error, please notify the sender immediately. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core Request.java
billbarker02/02/25 19:26:55
Modified:src/share/org/apache/tomcat/core Request.java
Log:
Fix NPE when using AccessLog without having a ROOT context defined.
Now we won't attempt to authenticate if we haven't (successfully) done a ContextMap
(in line with the servlet spec).
Fix for bug #6604
Reported by: John Swapceinski [EMAIL PROTECTED]
Revision ChangesPath
1.113 +14 -11jakarta-tomcat/src/share/org/apache/tomcat/core/Request.java
Index: Request.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Request.java,v
retrieving revision 1.112
retrieving revision 1.113
diff -u -r1.112 -r1.113
--- Request.java 10 Sep 2001 06:43:01 - 1.112
+++ Request.java 26 Feb 2002 03:26:55 - 1.113
@@ -562,20 +562,23 @@
public String getRemoteUser() {
if( notAuthenticated ) {
- notAuthenticated=false;
+ Context ctx = getContext();
+ if( ctx != null ) {
+ notAuthenticated=false;
- // Call all authentication callbacks. If any of them is able to
- // identify the user it will set the principal in req.
- int status=0;
- BaseInterceptor reqI[]= getContext().getContainer().
- getInterceptors(Container.H_authenticate);
- for( int i=0; i reqI.length; i++ ) {
- status=reqI[i].authenticate( this, response );
- if ( status != BaseInterceptor.DECLINED ) {
- break;
+ // Call all authentication callbacks. If any of them is able to
+ // identify the user it will set the principal in req.
+ int status=0;
+ BaseInterceptor reqI[]= ctx.getContainer().
+ getInterceptors(Container.H_authenticate);
+ for( int i=0; i reqI.length; i++ ) {
+ status=reqI[i].authenticate( this, response );
+ if ( status != BaseInterceptor.DECLINED ) {
+ break;
+ }
}
+ //context.log(Auth + remoteUser );
}
- //context.log(Auth + remoteUser );
}
return remoteUser;
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6604] - Request.getRemoteUser() throwing NullPointerException
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=6604. 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=6604 Request.getRemoteUser() throwing NullPointerException [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-02-26 03:29 --- This is now fixed in the CVS HEAD, and will appear in 3.3.1-RC1. Note, your error page will still not be called, since (according to Tomcat), the request isn't part of any defined webapp. (e.g. you don't have a ROOT context defined). It will send back Tomcat's default 404 page. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] - Tocmat 4, implement new Catalina SecurityManager Policy class
Remy Maucherat wrote: Due to recent questions about the SecurityManager implementation in Tomcat 4 I decided to post my proposal for overhauling how security policies are managed in Tomcat 4. This is something I have wanted to do for a while but has been sitting on the back burner as I have been very busy with other work (non open source) related projects.. Yes, I think it looks good, and full of useful features. Thanks. The only thing is that IMO it should be integrated in the server.xml file and its child files. I don't see any reason to keep that in separate config files. server.xml child files ?? Like the ones used for the admin and manager webapps (webapps/admin.xml and webapps/manager.xml). It's just as if that XML fragment was inserted in the server.xml file. I think I could implement it if I have some time, which is a possibility after I finish Coyote. Whats the timeline on that? Whenever I stop trying to fix bugs for one whole week. Of course, it's less a priority now that (unexpectedly) JK is out there and fully supported. I still have some design decisions to make for the Catalina wrapper (the HTTP stack itself looks good enough already). I originally wrote that proposal Jan 3, but was sitting on it because I was very busy with other projects. I have some time now to work on it. I'll see if I can flush out the design some more. No problem then, I was just suggesting that if you didn't have time. BTW, I have been testing Tomcat 4.1-dev built from CVS using java 1.4 with -security. Tomcat runs fine with the default catalina.policy, but fails when I use a more restrictive policy. I think the problem is in Java 1.4, I have filed a bug report on this. So for now, I am back to using java 1.3.1. I was very unhappy about 1.4 b3, which had lots of classloading issues. Thankfully, the RC and the final have been much better, but I'm not surprised there are still issues remaining in some more advanced use cases. What's the bugtraq number for your report ? Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 6660] - Catalina with SecurityManager is possibly broken.
Remy Maucherat wrote:
grant codeBase=jar:file:{path-to-webapp}/WEB-INF/lib/some.jar {
// Some permissions for this jar
};
grant codeBase=jar:file:{path-to-webapp}/WEB-INF/lib/- {
// Some permissions for this jar
};
No, after the fix, it would be the same as for the URLClassLoader:
grant codeBase=file:{path-to-webapp}/WEB-INF/lib/some.jar {
// Some permissions for this jar
};
grant codeBase=file:{path-to-webapp}/WEB-INF/lib/- {
// Some permissions for the jars
};
I would prefer it if the difference in codeBase were left in
WebappClassLoader.
I'm quite sure the StandardClassLoader which was used before was generating
the second type of source location URLs
(file:{path-to-webapp}/WEB-INF/lib/some.jar).
Here is the reason. The root context is the
codeBase for JSP pages. The JSP pages require all permissions that
any unerlying jar's need. Yet you may not want to grant all of the
jar files all the permissions a JSP page has. If the web app root
and the jars have the same codeBase there is no way to fine tune
your security policies.
By The root context is the codeBase for JSP pages, do you mean that the
source code URL is file:{path-to-webapp}/ ?
Of course this will be moot when my SecurityManager proposal is
implemented.
Remy
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat RELEASE-NOTES-3.3.1.txt
billbarker02/02/25 19:53:50 Modified:.RELEASE-NOTES-3.3.1.txt Log: Document fix for 6604 Revision ChangesPath 1.40 +4 -1 jakarta-tomcat/RELEASE-NOTES-3.3.1.txt Index: RELEASE-NOTES-3.3.1.txt === RCS file: /home/cvs/jakarta-tomcat/RELEASE-NOTES-3.3.1.txt,v retrieving revision 1.39 retrieving revision 1.40 diff -u -r1.39 -r1.40 --- RELEASE-NOTES-3.3.1.txt 24 Feb 2002 03:52:00 - 1.39 +++ RELEASE-NOTES-3.3.1.txt 26 Feb 2002 03:53:50 - 1.40 @@ -3,7 +3,7 @@ Release Notes = -$Id: RELEASE-NOTES-3.3.1.txt,v 1.39 2002/02/24 03:52:00 larryi Exp $ +$Id: RELEASE-NOTES-3.3.1.txt,v 1.40 2002/02/26 03:53:50 billbarker Exp $ This document describes the changes that have been made since the @@ -248,6 +248,9 @@ 6518 Fix an edge condition where in some cases a JSP file beginning with a number wouldn't get mangled correctly. + +6604 Fix a problem when using the AccessLog without a Default Context + defined. Configuration: -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
On Mon, 25 Feb 2002, Aaron Smuts wrote: What I'd like would be a Jakarta version of something small and simple like the oldest available Jetty version. You can probably use tomcat3.3: - it's small - about 1M ( excluding the parser, 800k if you don't include the jasper compiler - you'll still support precompiled jsps ). You can probably cut more if you remove unused modules. - it's fast - IMHO it's one of the fastest servlet containers around - it's simple - as simple as we were able to make it ( but no simpler :-). Almost anything can be replaced, including the servlet implementation ( facade ), loaders, loggers, connectors. In addition it'll run with almost any VM ( including GCJ/native, kaffe, with some changes J2ME ) and it's reasonably easy to embed it. It doesn't have features - except serving servlets as fast as it can. If you want features - probably you need something else. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: tomcat 4 apache mod_webapp welcome-file-list
Did anyone ever come up with an answer for this? I've searched exhaustively about this with no luck. Maybe I'm just missing something, but... I am experiencing the same thing with Tomcat 4.0.2-LE / JVM 1.4.0 / Apache 1.3.23. This is REALLY annoying, but if someone could tell me what I'm doing wrong, I'd love to know. Here is my web.xml: ?xml version=1.0 encoding=UTF-8? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN http://java.sun.com/j2ee/dtds/web-app_2_2.d td web-app servlet servlet-namePostMultipartServlet/servlet-name display-namePostMultipartServlet/display-name descriptionmultipart/form-data test servlet/description servlet-classorg.athlonia.servlet.test.PostMultipartServlet/servlet-class /servlet servlet-mapping servlet-namePostMultipartServlet/servlet-name url-pattern/PostMultipartServlet/url-pattern /servlet-mapping session-config session-timeout 30 /session-timeout /session-config welcome-file-list welcome-fileindex.html/welcome-file /welcome-file-list /web-app when I try to hit the page: http://localhost/multipart/ I get a page cannot be displayed error in IE 5.5, saying something about a dns error. If I do http://localhost/multipart/index.html, I get the desired page. My httpd.conf mod_webapp section looks like this: # # Webapp: Tomcat (Catalina) 4.0 connector # IfModule mod_webapp.c WebAppConnection warpConnection warp localhost:8008 WebAppDeploy examples warpConnection /examples/ WebAppDeploy multipart warpConnection /multipart/ /IfModule Let's see.. what else... My server.xml section looks like this: -- snip -- !-- Define an Apache-Connector Service -- Service name=Tomcat-Apache Connector className=org.apache.catalina.connector.warp.WarpConnector port=8008 minProcessors=5 maxProcessors=75 enableLookups=false appBase=/home/httpd/webapps acceptCount=10 debug=0/ !-- Replace localhost with what your Apache ServerName is set to -- Engine className=org.apache.catalina.connector.warp.WarpEngine name=Apache defaultHost=www.athlonia.org debug=0 !-- Global logger unless overridden at lower levels -- Logger className=org.apache.catalina.logger.FileLogger directory=/var/log/catalina prefix=apache_catalina_ suffix=.log timestamp=true/ !-- Because this Realm is here, an instance will be shared globally -- Realm className=org.apache.catalina.realm.MemoryRealm / !-- Define the default virtual host -- Host name=localhost debug=0 appBase=/home/httpd/webapps unpackWARs=false Valve className=org.apache.catalina.authenticator.SingleSignOn debug=0/ Valve className=org.apache.catalina.valves.AccessLogValve directory=/var/log/catalina prefix=localhost_access_ suffix=.log pattern=common/ Logger className=org.apache.catalina.logger.FileLogger directory=/var/log/catalina prefix=localhost_ suffix=.log timestamp=true/ !-- Multipart Test Webapp Context -- Context path=/multipart docBase=multipart.war debug=0 Logger className=org.apache.catalina.logger.FileLogger directory=/var/log/catalina prefix=webapp_localhost_multipart_ suffix=.log timestamp=true/ /Context /Host /Service -- snip -- Also, I noticed that the web.xml for the examples doesn't have a welcome-file-list section, but it's behavior seems correct, with the exception that it's index.html is in a /jsp or /servlet subdirectory. I tried removing the welcome-file-list section from my web.xml and still got the same incorrect behavior as with it in place. So... Any information would be much appreciated! Thanks. Kendal L. Montgomery ...the comPuter Wizard... [EMAIL PROTECTED] _-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_ Click here for Qwest's 5 cent State-to-State flat rate calling plan, plus get your own 800 number at no charge! http://qwesteferral.com/r.jsp?a=RyYO5xpYanlfVU541Lz2HA$$ _-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_ -Original Message- From: Dom [mailto:[EMAIL PROTECTED]] Sent: Friday, October 05, 2001 2:15 PM To: [EMAIL PROTECTED]; Tomcat Developer List Subject: tomcat 4 apache mod_webapp welcome-file-list Tomcat 4 + Apache + mod_webapp.so : It looks like welcome-file-list in web.xml doesn't work with web applications in virtual hosts ? Dom -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5647] - AJP13 connector will not pass authentication requests
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=5647. 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=5647 AJP13 connector will not pass authentication requests [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2002-02-26 06:47 --- Hello, I just downloaded nightly build Feb-25 to see if the Feb-16 fix worked. Using the IIS connector and the /security/protected example, I am still not being challenged by a login screen. Tomcat just jumps directly to the 403 unauthorized screen. Can anyone else confirm that this problem still exists? Mike -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
- Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, February 25, 2002 6:25 PM Subject: Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670 An additional, more subtle, cross-package dependency is probably also there -- assumptions about the implemented functionality, or the expected order of method calls, that might not always be clearly stated in the method JavaDocs. We'll want to review the code for these kinds of cases as well. This is the one that really bit me in porting ApacheConfig to 4.x. And, as a result, the 4.x ApacheConfig suffers from the same problem of making assumptions about the order of method calls. Saying that they might not always be clearly stated in the method JavaDocs is a gross understatement. Roughly half the time, the start event is fired at the beginning (allowing Listeners to change the config), and half the time it is fired at the end (allowing Listeners to react to the config). IMHO, the 3.3 event model is an improvement: where you have an init event (fired at the beginning of the start method), and a start event (fired at the end of the start method). As I said, this is IMHO. Attempts to start a flame-war will be quietly ignored. In any case, tomorrow I'll whip up a sourceball of the current MinimalTomcat code and stick it out on the net somewhere. I'd like to see what you've done so far. Craig -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
An additional, more subtle, cross-package dependency is probably also there -- assumptions about the implemented functionality, or the expected order of method calls, that might not always be clearly stated in the method JavaDocs. We'll want to review the code for these kinds of cases as well. This is the one that really bit me in porting ApacheConfig to 4.x. And, as a result, the 4.x ApacheConfig suffers from the same problem of making assumptions about the order of method calls. Saying that they might not always be clearly stated in the method JavaDocs is a gross understatement. Roughly half the time, the start event is fired at the beginning (allowing Listeners to change the config), and half the time it is fired at the end (allowing Listeners to react to the config). IMHO, the 3.3 event model is an improvement: where you have an init event (fired at the beginning of the start method), and a start event (fired at the end of the start method). It's not random, actually. The start event is sent to the listeners at the end of the ContainerBase.start method, which is right after all the children have been started. The only problem is with the server and service, where the start event is sent before (so it's not really useful except to configure things). Adding a before-start event and before-stop event is doable IMO. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
