Re: I have some new FormAuthenticator code for Tomcat.
Mark, Thanks for the reply. Sorry it took me a bit to get back to you on this. Comments inline. OK. I see this as just being a password that is so long that it has to be written down (eg on the USB key) and physically carried around by the user. There is an interesting debate here as to whether this is more or less secure than a 'good' pass-phrase... That is a valid debate, however, while I was just giving one example of what might be a possible authentication choice, RSA does recommend using such a key in combination with a username and password as a more secure authentication scheme. And with the current configuration of FormAuthentication, that's not a possible option. (see below for my reasons for implementing it as I have) Tomcat (and most other web containers) support BASIC, FORM, DIGEST and CLIENT-CERT. Can you give examples (in addition to the 1. above) of authentication types you'd like to see supported? Well, the one RSA recommends is one I would like to see supported. It is done through a form, but is not supported by FORM type. However, I think perhaps another way to look at it is not, what types can I think of, but, how can we make it more easily extensible (which I believe the API I created does) for future types that might be needed (but we haven't thought of just yet). But in addition to different ways to login, there could also be a case where there's a need for a user to simultaneously log in to multiple systems. Perhaps there is data or objects on a secure page that is pulled from another system that requires slightly different login information. Rather than forcing the user to login multiple times, we could make it possible to do it all in one form. And rather than requiring extra code that must be tied to every secure resource that checks if the user logged in to that separate system, we'd like to make it part of the regular authentication/security mechanism. Hashing is the most popular and archives the desired aims of protecting passwords. Can you give examples of other manipulations? Sure, Salting is another type of manipulation. Salting basically means combining a password with a random value as a counter measure to dictionary password attacks. The combined value can also then be hashed/encrypted. (There are other examples as well, such as allowing users to use a domain-neutral username but then to log them in to multiple domains, appending it to the username) But again, the main thing here is that we might not be able to think up all the ways right now, but why not make it extensible so they can be plugged in at a future time? 4. Portability...make your authentication components more web container neutral. I understand the benefits behind this, but there's a reason I've built it the way I have (and the developer API is still vendor neutral, more on that later...). To begin with, in Tomcat and other web servers, the concept of SingleSignOn allows developers to authenticate users across web contexts. This code is complex and has already been written for Tomcat, Jetty, etc. However, if the authentication implementation were to have no internal code connecting it to the web server's internal auth scheme (using j_security_check for example), there's no way to use SingleSignOn without rewriting it yourself. Doing so has a few repercussions. First, the Servlet/J2EE spec that handles authentication/authorization becomes unavailable to the web applications. That means, you cannot use the built-in mechanisms that use security-constraint and auth-constraint or security-role. Rewriting code to handle all that not only is unecessary (as it already exists) and complex, and means you cannot tie in to the specifications. As well, in JBoss (or any other application server) your login will not be automatically extended to the EJB realm (or other web contexts). You would have to write code to handle that as well. And that becomes a bit of a mess in part because you'd likely have to handle it using JNDI (which each app server/web server handles differently, especially in clustered situations). Making it vendor neutral in that manner is, in my mind, not such a clean solution. With regard to whether my code is vendor neutral, it is vendor neutral in the same way Java itself is. I have an implementation of an API for authentication that has an implementation for Tomcat (just as Java has a Windows, Linux, etc impl). In this API, developers have no direct knowledge of any Tomcat classes; it's all been abstracted. However, to make this possible in a default installation of Tomcat, I am suggesting that Tomcat make the FORM implementation pluggable (instead of being already set inside the jar), perhaps via a command-line property. That's really the only part of Tomcat that needs to change to make it more flexible/extensible. Thanks! - David __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection
I have some new FormAuthenticator code for Tomcat.
Hi, I've been working on some code for Form authentication in Tomcat that I think you all might be interested in. In addition to implementing the current J2EE/Servlet spec for authentication (i.e. j_security_check with two keys: j_username, j_password authenticated with the Realm), it also offers some major increases in authentication capabilities with the simple inclusion of an XML file in a web-context's WEB-INF folder. I created this flexible Form authentication with a main concern being that it be as non-intrusive on Catalina code and the Servlet spec as possible. To use this new code, only one line in a properties file needs to be changed: ( Authenticators.properties ) FORM=com.spiralgeneration.formauthentication.FormAuthenticator Obviously, if you are interested in the code, the above class' package would be changed to a Catalina package. While this API implementation does have a number of new classes, there are ZERO changes for any existing Catalina code (save for replacing FormAuthenticator with this new FormAuthenticator). The classes could even be kept in the current jar I've got them in. There is also no impact on the Servlet spec for Form authentication. There are ZERO changes to web.xml or any other deployment or code files of a web context. If a web application wants to use the usual username + password authentication, the Form authentication will act exactly as it does currently in Tomcat. If the web application wants to use the new form authentication, all that's needed is to include WEB-INF/form-authentication.xml. That's it. ALL web.xml configurations remain the same (e.g. securing pages is still done via security-constraint). However, with that XML file included the application gets the following capabilities: 1. Plug in any pre-authentication key manipulators (called KeyPreparer). For example, if a database stores all passwords in a one-way hash, you can register (in the XML) the password key to be prepared by your password-hashing KeyPreparer just prior to sending to an authenticator. (I have created an example of this) This offers a lot of flexibility in terms of storing login keys. If it were necessary to stop hashing passwords, the deployer could simply remove one line in an XML file and the KeyPreparer is unplugged. 2. Plug in any number of custom authenticators (called PluginAuthenticator). Currently, the only authentication possible in the Catalina implementation is a username and password to a Realm. With this implementation a web context could require a username, password and a file. Because this form authentication accepts multipart/form-data POSTs (it converts an uploaded file to java.io.InputStream), the web context could require that users carry a USB key ring (that has an encrypted file for example) so when they login from a remote computer (in a web browser) they can point an input of type=file to that file. The developers could then have two authenticators: 1. The default authentication (All PluginAuthenticators have controlled access to the Realm) which checks the username and password. 2. Their custom authenticator that checks an encrypted file matches the data stored for the username (they register for the username and file in XML). (I have created an example of this) 3. Create as many authentication keys (called SecurityRoleKeys) as needed. In the current authentication model, only a username and password are allowed. Here, a web context could (in XML) require a username, a password, a file, a random number and any other keys they wish. All keys can be given a class type to which they will be converted by the form authentication. For example, the username and password would likely be java.lang.String, the random number java.lang.Long and the file java.io.InputStream. (I have JavaDocs and an example XML file that show all the allowed types) So a KeyPreparer or PluginAuthenticator can expect a key to be a certain type. 4. Accept multipart/form-data POSTs. As mentioned above, this form authentication can handle login forms of enctype=multipart/form-data. As a result, it enables the ability to require file data for logins. For example, an encrypted certificate file installed on an external USB drive or locally on a hard drive. 5. Set a default secure page for logins with no saved request. Currently, if a user goes directly to the login page and logs in, Tomcat will throw an error, No web resource available at /j_security_check (or something like that). With this new form authentication, in the XML the deployer can set a default secure redirect page. For example, if the deployer sets the default page as /secure-default.jsp and a user goes directly to the login page and successfully authenticates, they'll be sent to /secure-default.jsp instead of getting an error. With all of the above capabilities, there are also quite a few configuration options. For example,
Re: I have some new FormAuthenticator code for Tomcat.
Hi Mark, Thanks for your comments. My responses inline. 1. Your reference to sending an encrypted user certificate file to the server demonstrates a lack of understanding of PKI that undermines my confidence that you know what you are doing when it comes to security. I think I wasn't being clear here. I didn't mean a certificate file as used in PKI. I was simply giving an example of some other type of data (besides a simple string) that could be used as an authentication key. The example was simply a file of any sort. 2. JAAS provides plug-in authentication. Sure it does, but NOT for FORM logins. Tomcat (and all other java web servers I've come across) allow only authenticating with a username and password. This gives flexibility with FORM logins working with Tomcat. 3. Password hashing is already supported. While password hashing may be supported, that is only ONE example of a manipulation that might be required on a key for authentication. Everytime a new mechanism arises, making a new implementation in Tomcat can create a bit of a mess, but with this form auth API, you can just plug it in. 4. The implementation is Tomcat specific and hence is non-portable. That's true in the short but as I said there was no change of Tomcat's code and the internal implementation of Tomcat is actually hidden from the Plugin classes. So it's actually quite easy to make an implementation of this for a number of web servers (and I'm actually making one for Jetty right now). So you could keep these classes as their own API that plugs in to Tomcat (which is how I made it. The only class Tomcat needs to know about is FormAuthenticator). David __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
mod_jk error handling question
I apologize for the cross post, but I didn't receive any responses from the user list so I thought I'd try here. Environment: Apache 2.0.52 mod_jk 1.2.7-beta-2 Tomcat 5.5.4 I've set up Tomcat with and AJP1.3 Connector to handle requests for web apps from Apache. I'd like to be able to set up an ErrorDocument directive for apache to forward the user to a custom error page when tomcat is unavailable. This page would inform the user that maintenance is being performed on the web app and so on. When I test this, the http status code that gets returned by mod_jk is 500 (internal server error). This seems too generic to me as it encompasses all kinds of other errors that mod_jk could experience. I was thinking that mod_jk should return 503 (service unavailable) instead when tomcat cannot be contacted. I modified apache-2.0/mod_jk.c (line 1858) to return HTTP_SERVICE_UNAVAILABLE instead of HTTP_INTERNAL_SERVICE_ERROR. With this change mod_jk now returns 503 when tomcat cannot be contacted, but I have no idea if this is the right place to make this change. Is there a better way to handle this or is this an acceptable change? I'd like to fix it with an Apache source code change as a last resort if possible. Any insight is appreciated. Regards, Jay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Michael Buryk/PUBS/STAFF/US/IEEE is out of the office.
I will be out of the office starting 10/19/2004 and will not return until 10/25/2004. I will respond to your message when I return. For any questions regarding the IEEE Job Site, please contact [EMAIL PROTECTED], or call Deb Grant at 732-981-3420, or e-mail her at [EMAIL PROTECTED] For questions about classified advertising in Spectrum magazine, contact Robert Zwick at 212-419-7765. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Michael Buryk/PUBS/STAFF/US/IEEE is out of the office.
I will be out of the office starting 09/08/2004 and will not return until 09/20/2004. I will respond to your message when I return. For any questions regarding the IEEE Job Site, please contact [EMAIL PROTECTED], or call Deb Grant at 732-981-3420, or e-mail her at [EMAIL PROTECTED] Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Michael Buryk/PUBS/STAFF/US/IEEE is out of the office.
I will be out of the office starting 09/02/2004 and will not return until 09/07/2004. I will respond to your message when I return. For any questions regarding the IEEE Job Site, please contact [EMAIL PROTECTED], or call Deb Grant at 732-981-3420, or e-mail her at [EMAIL PROTECTED] Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.4 release Monday 6/9
Monday came and went. Is there a new ETA? Glenn Nielsen wrote: So far there have been no problems reported with mod_jk 1.2.4 except for one minor documentation typo which has been fixed. If I don't see any problems reported from further testing before Monday I will make the mod_jk 1.2.4 source release and announcement. Thanks for all the help testing. Once the release is announced binaries can be and installed in the release directory. Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native CHANGES.txt
Didn't 1.2.4 also fix the hook precedence for Apache 2 from 1.2.3 where Alias and mod_jk did not get along? [In my testing it sure fixed this and it seems it should go into the change notes.] -- Jess Holle [EMAIL PROTECTED] wrote: glenn 2003/06/10 06:37:10 Modified:jk/native CHANGES.txt Log: Update changes for mod_jk 1.2.4 release Revision ChangesPath 1.13 +16 -4 jakarta-tomcat-connectors/jk/native/CHANGES.txt Index: CHANGES.txt === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/CHANGES.txt,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- CHANGES.txt 16 Mar 2003 02:59:43 - 1.12 +++ CHANGES.txt 10 Jun 2003 13:37:09 - 1.13 @@ -1,6 +1,15 @@ JAKARTA TOMCAT CONNECTORS (JK) CHANGELOG: -*-text-*- Last modified at [$Date$] +Changes with JK 1.2.4 +* Fix use of libtool for Apache mod_jk builds with more recent + versions of Apache 2. + [jfclere] +* Use reentrant version of strtok() for web server's which use + threads. This fixes a thread safe bug under Apache 2 and the + worker MPM. + [glenn] + Changes with JK 1.2.3: * Add the ability to configure JkLog to pipe its log output to an executable such as Apache rotatelogs or cronolog. Apache 2.0 only. @@ -11,13 +20,16 @@ let Apache handle processing the error returned by Tomcat. * Added the load balancer sticky_session property. If set to 0 requests with servlet SESSION ID's can be routed to any Tomcat - worker. Default is 1, sessions are sticky. [glenn] + worker. Default is 1, sessions are sticky. + [glenn] * Cleaned up detection and reporting of aborted client connections. This cleanup also makes sure that mod_jk does not pass any requests - on to Tomcat if the remote client aborted its connection. [glenn] + on to Tomcat if the remote client aborted its connection. + [glenn] * Fixed a bug in Apache 2.0 which caused a POST request forwarded to Tomcat to fail if it generated SSI directives which were post - processed by mod_include. [glenn] + processed by mod_include. + [glenn] * Fixed a bug in JkRequestLogFormat when printing the request URI that could cause a URI with hex escapes sequences to be formatted wrong. [glenn] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.4 release Monday 6/9
Without diffing the sources, can you point out whether this is solely in the build machinery or also involved a source code change? Glenn Nielsen wrote: A bug was reported with the linux build with Apache 2.0.46 with libtool. This has been fixed and an updated mod_jk 1.2.4 source distribution for testing is available at: http://cvs.apache.org/~glenn/jakarta-tomcat-connectors-jk-1.2.4-src.tar.gz Thanks Henri and JF for taking care of this. Glenn Glenn Nielsen wrote: So far there have been no problems reported with mod_jk 1.2.4 except for one minor documentation typo which has been fixed. If I don't see any problems reported from further testing before Monday I will make the mod_jk 1.2.4 source release and announcement. Thanks for all the help testing. Once the release is announced binaries can be and installed in the release directory. Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.4 test release distribution available
It works fine with Apache 2.0.46 on Windows. This includes the Alias use case that did not work with 1.2.3. I'll build against 1.3.27 on Solaris and AIX shortly. -- Jess Holle Glenn Nielsen wrote: Has anyone had a chance to build and test the mod_jk 1.2.4 distribution below? THe only person I heard from was Henri who reported a typo in the docs. It would be nice to build and test this on as many OS/web servers as possible before release. Thanks, Glenn Glenn Nielsen wrote: I have created a test mod_jk 1.2.4 distribution and placed it in my home page at: http://cvs.apache.org/~glenn/jakarta-tomcat-connectors-jk-1.2.4-src.tar.gz Please build and test this release. If there are no problems with it I will publish it as an official release. Thanks, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.4 test release distribution available
It works fine in very basic testing with Apache 1.3.27 EAPI on: * Windows * Solaris 8 * AIX 4.3.3 [Yes, I built and tested these against my EAPI (with MM as well on UNIX) Apache builds, but they're otherwise unaltered sources.] -- Jess Holle Jess M. Holle wrote: It works fine with Apache 2.0.46 on Windows. This includes the Alias use case that did not work with 1.2.3. I'll build against 1.3.27 on Solaris and AIX shortly. -- Jess Holle Glenn Nielsen wrote: Has anyone had a chance to build and test the mod_jk 1.2.4 distribution below? THe only person I heard from was Henri who reported a typo in the docs. It would be nice to build and test this on as many OS/web servers as possible before release. Thanks, Glenn Glenn Nielsen wrote: I have created a test mod_jk 1.2.4 distribution and placed it in my home page at: http://cvs.apache.org/~glenn/jakarta-tomcat-connectors-jk-1.2.4-src.tar.gz Please build and test this release. If there are no problems with it I will publish it as an official release. Thanks, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.4 test release distribution available
P.S. When do you think this could be elevated to an official release? Also, please make it very clear if anything beyond the docs, changes between the test release and the official. [Thanks.] -- Jess Holle Jess M. Holle wrote: It works fine in very basic testing with Apache 1.3.27 EAPI on: * Windows * Solaris 8 * AIX 4.3.3 [Yes, I built and tested these against my EAPI (with MM as well on UNIX) Apache builds, but they're otherwise unaltered sources.] -- Jess Holle Jess M. Holle wrote: It works fine with Apache 2.0.46 on Windows. This includes the Alias use case that did not work with 1.2.3. I'll build against 1.3.27 on Solaris and AIX shortly. -- Jess Holle Glenn Nielsen wrote: Has anyone had a chance to build and test the mod_jk 1.2.4 distribution below? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.4 test release distribution available
I also did quick, basic testing on HPUX 11 with good results. Jess M. Holle wrote: It works fine in very basic testing with Apache 1.3.27 EAPI on: * Windows * Solaris 8 * AIX 4.3.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Xerces 2 impact on startup
Given that Xerces is a heavier (byte-code-quantity-wise) implementation, I would guess that initial classload of this would take substantially longer than Crimson for starters. The more interesting/worrisome bit is if additional operations thereafter are much slower... Remy Maucherat wrote: Just an observation ... When I remove Xerces 2.3 and rely on the Crimson parser integrated in my new JDK (Sun 1.4.2 beta), startup time goes down 20%. Impressive difference (I would have thought the later 2.x releases would improve performance :-( ). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why does Tomcat use xerces under java 1.4 instead of the internaljvm classes?
BTW - in the web.xml files that I write I usually remove the declaration on the top ( to make sure the validation doesn't happen ). I can't recall which servlet engine I saw this in, but I have seen at least one servlet engine that rejected web.xml unless it contained the expected DTD declaration. [Personally I found that extraordinarily obnoxious -- but that's what you get for using a commercial servlet engine -- which it was.] -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Connector issues
Jeff Tulley wrote: There are some real problems with the Coyote Connectors right now. The main problem biting me (and a few others recently) is bugzilla bug # 10229 - form parameters not being preserved across a login redirection. The answer given on the user list (by me also) is typically, Use an non-Coyote connector. Unfortunately that is not a good answer. If they move back to the deprecated AJP13Connector, they will experience MBean exceptions that, among other things, make the Tomcat shutdown not function correctly. Beyond that they are stuck with not using a webserver plugin and instead going directly to an HTTP connector (non-Coyote). I would propose two things: 1) Fix the MBean exception in the Ajp13Connector. I can provide a patch for this, it is very simple. Even though this is deprecated, the reality is that people might need to use it due to bugs and/or unimplemented features in the Coyote connectors. It may be their only choice, and if we can make it work easily, why not? I would be interested in the patch to this. I have no issues with the Coyote connector at the moment -- but I would like to see the fallback (i.e. Ajp13Connector) in a more functional state. 2) Fix this form authentication problem in the Coyote connector. I will look into this and see if it is something that I can do and submit a patch for. I actually have similar issues with the native side connector story but that is for another day. I was under the impression that mod_jk2 was not production ready by most measures -- and that mod_jk was good enough for most purposes (and quite production ready)... -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [4.1.23] Tag soon
I'm not a commiter or any such, but: I'd much sooner see a stable release as soon as possible that rolls in all the improvements since 4.1.18, than wait to remove some extra baggage. Remy Maucherat wrote: Hi, I plan to tag 4.1.23 soon. The big question remaining is if we remove, or not, the commons-fileupload related functionality. Personally, I'm willing to ignore the issue. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [4.1.22] Tag later this week
Remy Maucherat wrote: I plan to tag 4.1.22 later this week. The idea is to allow getting some reports on the stability of 4.1.21, and port the last JSPC patch from TC 5 (for mangling). And then we'll have our next stable release for 4.1.x :) Remy Thanks for the info and all the effort! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Apache Tomcat 4.1.21 Beta released
I thought the overwhelming vote was for Stable -- or did I misread/miscount the tallies? [Desparately awaiting the next officially Stable version of 4.1.x...] -- Jess Holle Remy Maucherat wrote: The Tomcat Team announces the immediate availability of Apache Tomcat 4.1.21 Beta. Tomcat 4.1.21 includes many bugfixes and performance tweaks over Tomcat 4.1.18. Please see the release notes for a complete list of the changes. Downloads (source and binaries): http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.21-beta/ Release notes: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.21-beta/RELEASE-NOTES Important note: When upgrading from another Tomcat 4.x release, the Tomcat work directory must be cleared. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Apache Tomcat 4.1.21 Beta released
Remy Maucherat wrote: Jess M. Holle wrote: I thought the overwhelming vote was for Stable -- or did I misread/miscount the tallies? [Desparately awaiting the next officially Stable version of 4.1.x...] Unfortunately, there's a minor security issue in it (bug 17591). If you're not using the JDBC store, then you can consider that build release quality. Hmmm I'm not, but my customers might. Any chance of a quick follow on which fixes this and is officially Stable? [Customers tend to second guess use of anything not marked as Stable anyway -- regardless of the applicability of any of the bugs to their usage.] -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [4.1.21] New tag and upcoming vote
Remy Maucherat wrote: Hi, Since the needed fix to Jasper was integrated in the 4.1.x branch, I plan to tag and release a 4.1.21 version of Tomcat (and I hope it will then be voted as a beta :) ). Since the amount of changes between 4.1.20 and 4.1.21 is minimal, I plan to post the stability vote on the next day. Any hope for another stable release one of these weeks? -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JNDIRealm feature enhancements
After setting up a JNDIRealm for the Manager app, I noticed after a while the connection times out and returns NULL automatically. I was wondering, if instead of returning NULL, JNDIRealm to try to reconnect and then authenticate, and then return NULL, if a failure results from that attempt, otherwise return the JNDIRealm.User object. Also Ive notice there is no method for specifying an alternate connection URL in the event the URL specified in connectionURL is not available. So, I took the liberty of adding an attribute alternateURL to specify a secondary URL. When the JNDIRealm opens a connection it will attempt the primary, and, upon failure, then attempt to connect to the alternate URL. If this should fail, the JNDIRealm fails as it did before. In both features the first exception is logged before the second attempt to connect proceeds. I have attached the CVS diff between my copy of JNDIRealm and the current HEAD version of JNDIRealm. Brad Handy Programmer/Analyst Spring Arbor University JNDI.diff Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: hello
Dan Agarlita wrote: I want to know how can I modify the 404 Error page. I want to put another page. Is a param? Or I have to modify some classes ? :) 10x, dan I think you would be better off asking on the tomcat-users list... And no you don't have to modify a class. -- Regards, M Martin Sillence PR Newswire DL +44 (0)1865 78 5065 F +44 (0)1865 78 5100 W www.prnewswire.eu.com --- Any views or opinions are solely those of the author and do not necessarily represent those of PR Newswire Europe. The e-mail contents are intended only for addressee and may contain confidential and/or privileged material. If you are not the intended recipient, please do not read, copy, use or disclose this communication and notify the sender. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Tomcat 4.1.18 release
I'm not a commiter (so no real vote), but I was just on the verge of
patching in these very fixes into 4.1.17 as it is useless to me without
them.
I would *REALLY* appreciate a speedy 4.1.18 release.
--
Jess Holle
Remy Maucherat wrote:
A bug exists (unfortunately) in Tomcat 4.1.16 and Tomcat 4.1.17 which
causes the servlet Writer to stay in an invalid state after an
IOException occurs (99% of the time caused by an abrupt client
disconnection). After this happens, the processor will never be able
to output data using the Writer, causing blank pages. This is more
often seen with JSPs.
The bug affects Coyote HTTP/1.1, and may also affect Coyote JK 2,
although this is less likely.
It is proposed that Tomcat 4.1.18, based on the Tomcat 4.1.17 code,
with the addition of the patch committed by Bill fixing JK 2 SSL
support, as well as the following patch (which I committed one hour ago):
Index: CoyoteResponse.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteResponse.java,v
retrieving revision 1.30
diff -r1.30 CoyoteResponse.java
322a323,324
writer.recycle();
Index: CoyoteWriter.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteWriter.java,v
retrieving revision 1.2
diff -r1.2 CoyoteWriter.java
98a99,109
//
Package Methods
/**
* Recycle.
*/
void recycle() {
error = false;
}
Please review, and vote ASAP:
ballot
[ ] Yes
[ ] No
/ballot
Remy
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1.17] Tag soon ?
M wrote: Remy Maucherat wrote: I don't see any major issues with 4.1.16, so I plan to tag 4.1.17 (which hopefully would be the next stable build) tomorrow after a few more minor tweaks. There was a report made against JK 2 immediately after 4.1.16 Beta was announced. Can someone confirm there's no major issue with JK ? I made the report and I can confirm that it still isn't working. I'm using exacly the same configuration as for 4.1.12 and 4.1.14 both of which work. The workaround in Bug 15258 fixes our problem. We were indeed using the external ip address of the machine to connect and not the loopback address. (Multiple load balanced servers) Sorry I should have spotted the bind problem when I did a netstat... Many thanks. -- Regards, M Martin Sillence PR Newswire DL +44 (0)1865 78 5065 F +44 (0)1865 78 5100 W www.prnewswire.eu.com --- Any views or opinions are solely those of the author and do not necessarily represent those of PR Newswire Europe. The e-mail contents are intended only for addressee and may contain confidential and/or privileged material. If you are not the intended recipient, please do not read, copy, use or disclose this communication and notify the sender. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1.17] Tag soon ?
Remy Maucherat wrote: I don't see any major issues with 4.1.16, so I plan to tag 4.1.17 (which hopefully would be the next stable build) tomorrow after a few more minor tweaks. There was a report made against JK 2 immediately after 4.1.16 Beta was announced. Can someone confirm there's no major issue with JK ? I made the report and I can confirm that it still isn't working. I'm using exacly the same configuration as for 4.1.12 and 4.1.14 both of which work. There's some fixes we're looking for in the new release so I've been monitoring the list. Should I raise a bug instead of emailing the list? -- Regards, M Martin Sillence PR Newswire DL +44 (0)1865 78 5065 F +44 (0)1865 78 5100 W www.prnewswire.eu.com --- Any views or opinions are solely those of the author and do not necessarily represent those of PR Newswire Europe. The e-mail contents are intended only for addressee and may contain confidential and/or privileged material. If you are not the intended recipient, please do not read, copy, use or disclose this communication and notify the sender. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Apache Tomcat 4.1.16 AJP not working
Looking at the netstat on the machine I can see tomcat is bound to the port 8009 and can connect to it with telnet, apache works if I go back to tomcat 4.1.14. From the apache logs: [Tue Dec 03 16:04:22 2002] [jk_connect.c (143)]: jk_open_socket, connect() failed errno = 111 [Tue Dec 03 16:04:22 2002] [jk_ajp13_worker.c (196)]: In jk_endpoint_t::connect_to_tomcat, failed errno = 111 [Tue Dec 03 16:04:22 2002] [jk_ajp13_worker.c (635)]: Error connecting to the Tomcat process. [Tue Dec 03 16:04:22 2002] [jk_ajp13_worker.c (848)]: In jk_endpoint_t::service, send_request failed in send loop 0 As we're using apache 1.3 and can't use warp it's fairly critical to us... should I raise a bug report? -- Regards, M Martin Sillence PR Newswire DL +44 (0)1865 78 5065 F +44 (0)1865 78 5100 W www.prnewswire.eu.com --- Any views or opinions are solely those of the author and do not necessarily represent those of PR Newswire Europe. The e-mail contents are intended only for addressee and may contain confidential and/or privileged material. If you are not the intended recipient, please do not read, copy, use or disclose this communication and notify the sender. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Apache Tomcat 4.1.16 AJP not working
Henri Gomez wrote: M wrote: Looking at the netstat on the machine I can see tomcat is bound to the port 8009 and can connect to it with telnet, apache works if I go back to tomcat 4.1.14. From the apache logs: [Tue Dec 03 16:04:22 2002] [jk_connect.c (143)]: jk_open_socket, connect() failed errno = 111 [Tue Dec 03 16:04:22 2002] [jk_ajp13_worker.c (196)]: In jk_endpoint_t::connect_to_tomcat, failed errno = 111 [Tue Dec 03 16:04:22 2002] [jk_ajp13_worker.c (635)]: Error connecting to the Tomcat process. [Tue Dec 03 16:04:22 2002] [jk_ajp13_worker.c (848)]: In jk_endpoint_t::service, send_request failed in send loop 0 As we're using apache 1.3 and can't use warp it's fairly critical to us... should I raise a bug report? Which release of mod_jk ? Not sure, it's the debian default... It says its from tomcat (3.3a-4) in the changelog. You should try the 1.2.1 release Grabbed the one: http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.1/bin/linux/i386/mod_jk-1.3-eapi.so.asc Still the same problem. -- Regards, M Martin Sillence PR Newswire DL +44 (0)1865 78 5065 F +44 (0)1865 78 5100 W www.prnewswire.eu.com --- Any views or opinions are solely those of the author and do not necessarily represent those of PR Newswire Europe. The e-mail contents are intended only for addressee and may contain confidential and/or privileged material. If you are not the intended recipient, please do not read, copy, use or disclose this communication and notify the sender. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tomcat appache request parameters getting lost
M wrote: Hi, I'm using apache 1.3.26 with the mod_jk connector to tomcat 4.1.12 The below jsp includes a servet which is unable to access the parameters on the request url e.g. http://host.net/testInclude.jsp?test=test Removing a line from the test comment or changing the flush=true to flush=false can both make it work, but I don't understand why. It does seem to be very buffer related and very dependant on size of text before the include. This problem only occurs when using tomcat through apache and is not reproducible with tomcat alone. Should I have raised this as a bug? I'm not sure quite where to file it. I guess the ajp connector? Any comments gratefully received -- Regards, M Martin Sillence PR Newswire DL +44 (0)1865 78 5065 F +44 (0)1865 78 5100 W www.prnewswire.eu.com --- Any views or opinions are solely those of the author and do not necessarily represent those of PR Newswire Europe. The e-mail contents are intended only for addressee and may contain confidential and/or privileged material. If you are not the intended recipient, please do not read, copy, use or disclose this communication and notify the sender. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
tomcat appache request parameters getting lost
Hi, I'm using apache 1.3.26 with the mod_jk connector to tomcat 4.1.12 The below jsp includes a servet which is unable to access the parameters on the request url e.g. http://host.net/testInclude.jsp?test=test Removing a line from the test comment or changing the flush=true to flush=false can both make it work, but I don't understand why. It does seem to be very buffer related and very dependant on size of text before the include. This problem only occurs when using tomcat through apache and is not reproducible with tomcat alone. The below page id 778 bytes: %@ page language=java session=true % html head titleAccess Reports/title !-- test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test -- /head body jsp:include page=/servlet/testIncludeServlet flush=true jsp:param name=depth value=summary / /jsp:include /body /html -- Regards, M Martin Sillence PR Newswire DL +44 (0)1865 78 5065 F +44 (0)1865 78 5100 W www.prnewswire.eu.com --- Any views or opinions are solely those of the author and do not necessarily represent those of PR Newswire Europe. The e-mail contents are intended only for addressee and may contain confidential and/or privileged material. If you are not the intended recipient, please do not read, copy, use or disclose this communication and notify the sender. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
symlinks in test build 4.1.14 not working
Hi, I was testing the 4.1.14 build in the hope it will fix the follow symlinks outside the basedir problem we have. With a normal config I can not browse the directory structure or access files. With the added Resources tag and allowLinking attribute I can browse the directories but not retrieve any files. Below is the relevant extract of the config I'm useing as gleaned by searching the list: Context path= docBase=ROOT debug=0 privileged=false reloadable=true Logger className=org.apache.catalina.logger.FileLogger directory=logs prefix=prnj_log. suffix=.txt timestamp=true/ Resources className=org.apache.naming.resources.FileDirContext allowLinking=true docBase= / /Context -- Regards, M Martin Sillence PR Newswire DL +44 (0)1865 78 5065 F +44 (0)1865 78 5100 W www.prnewswire.eu.com --- Any views or opinions are solely those of the author and do not necessarily represent those of PR Newswire Europe. The e-mail contents are intended only for addressee and may contain confidential and/or privileged material. If you are not the intended recipient, please do not read, copy, use or disclose this communication and notify the sender. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: symlinks in test build 4.1.14 not working
Remy Maucherat wrote: M wrote: Hi, I was testing the 4.1.14 build in the hope it will fix the follow symlinks outside the basedir problem we have. With a normal config I can not browse the directory structure or access files. With the added Resources tag and allowLinking attribute I can browse the directories but not retrieve any files. I doubt the case sensitivity check (needed for Windows and OS X, so always enabled by default now) is compatible with symlinking. Try disabling it to see if it helps (caseSensitive=false). Spot on. That fixes it, many thanks. -- Regards, M Martin Sillence PR Newswire DL +44 (0)1865 78 5065 F +44 (0)1865 78 5100 W www.prnewswire.eu.com --- Any views or opinions are solely those of the author and do not necessarily represent those of PR Newswire Europe. The e-mail contents are intended only for addressee and may contain confidential and/or privileged material. If you are not the intended recipient, please do not read, copy, use or disclose this communication and notify the sender. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
New JSR on Java(TM) Compiler API
[I am resending this due the Mozilla's munging of the attachment on the previous try] Tomcat developers- I am starting up a new JSR on an API for invoking a Java Language compiler from within a Java program. A draft of the JSR proposal is enclosed. This API would be very useful anywhere a Java program will want to invoke the Java Compiler, for example ANT rebuilds, Java Server Pages, or anywhere an application wants to turn a small snippet of Java code into a Class efficiently. In addition, this API calls for the compiler to provide dependency information after compiling, which would help support incremental rebuilds. I am in the process of gathering support for this JSR to help it along the initial stages of the Java Community Process. Your comments are most welcome. Regards, Neal Gafter JSR Proposal Title: Java(TM) Compiler API Summary: A service provider API that allows a Java program to select and invoke a Java Language Compiler programmatically. Submitter: Sun Microsystems Contact Name: Neal Gafter Contact E-Mail: [EMAIL PROTECTED] Contact Phone: 408-276-7080 Contact Fax: 408-276-7700 Spec Lead Name: Neal Gafter Spec Lead E-Mail: [EMAIL PROTECTED] Spec Lead Phone: 408-276-7080 Spec Lead Fax: 408-276-7700 Initial Group Membership: TBD Supporting this JSR: Sun Microsystems Section 2.1: (Description of the proposed Specification) The Java Compiler API is a set of interfaces that describes the functions provided by a Java Language Compiler, and a service provider framework so vendors can provide implementations of these interfaces. The interfaces abstract the way a compiler interacts with its environment. While the existing command-line versions of compiler receive their inputs from the file systems and deposit their outputs there, reporting errors in a single output stream, the new compiler API will allow a compiler to interact with an abstraction of the file system. This abstraction will likely be provided by an extension of the NIO facilities in Tiger (1.5), and allow users to provide source and class files (and paths) to the compiler in the file system, in jar files, or in memory, and allowing the compiler to deposit its output similarly. Diagnostics will be returned from a compiler as structured data, with both pre- and post-localization messages available. In addition, the new API should provide a facility for a compiler to report dependency information among compilation units. Such information can assist an integrated development environment in reducing the scope of future recompilations. Future versions of this API might expose more of the structure of the program, for example the declaration structure of the program (ala the javadoc API), program annotations (JSR 175) or even the code itself (ASTs: Abstract Sytntax Trees). These are not goals of the initial version of this specifications. Section 2.2: (The target Java platform) J2SE Section 2.3: (What need of the Java community will be addressed by the spec) The main initial audiences are (1) JSP implementations, which must invoke a Java Language compiler on generated Java code (2) IDE (Integrated Development Environments) which must process user-written source code (3) Some internal Java facilities are simplified by the ability to generate class files efficiently through generation of source files. Section 2.4: (Why isn't this met by existing specifications?) There simply isn't anything like this in the platform. Section 2.5: (Description of the underlying technologies) The reference implementation will likely be built on Sun's javac. Section 2.6: (Proposed package name for the API spec) javax.compiler Section 2.7: (Are there any dependencies on OS/CPU/devices?) No Section 2.8: (Are there any new security issues?) No Section 2.9: (Are there internationalization of localization issues?) These will be explicitly addressed by the specification. Section 2.10: (Will any existring specs become obsolete?) No Section 2.11: (What is the anticipated schedule for this spec?) We hope to have the specification completed in time to be included in the next major revision of the Java platform (Tiger). Section 2.12: (What is the working model for the expert group?) Sun will lead the specification and implementation work, with experts contributing to the API specification. Section 3.1: (What existing documents, specs, or implementations describe the technology?) See
New JSR on Java(TM) Compiler API
Tomcat developers- I am starting up a new JSR on an API for invoking a Java Language compiler from within a Java program. A draft of the JSR proposal is enclosed. This API would be very useful anywhere a Java program will want to invoke the Java Compiler, for example ANT rebuilds, Java Server Pages, or anywhere an application wants to turn a small snippet of Java code into a Class efficiently. In addition, this API calls for the compiler to provide dependency information after compiling, which would help support incremental rebuilds. I am in the process of gathering support for this JSR to help it along the initial stages of the Java Community Process. Your comments are most welcome. Regards, Neal Gafter API Description: application/java-vm -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New JSR on Java(TM) Compiler API
Kin-Man Chung wrote: If these are not feasible, then at least include in the API a way to inform the client of the error locations programmatically. It's in there: Diagnostics will be returned from a compiler as structured data, with both pre- and post-localization messages available. The structued data includes the file in which the error occurred, line number, and column number. -Neal -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Wanted to forward this article on to the Tomcat folks but I can'tsubscribe in order to do it so...
This discussion started as a back-and-forth between Mike Cannon-Brooks and myself - on our weblogs. This culminated in two write-ups: Mike's Is Tomcat Crap http://radio.weblogs.com/0107789/stories/2002/05/28/isTomcatCrap.html And my Tomcat is not Crap http://radio.weblogs.com/0106533/stories/2002/05/28/tomcatIsNotCrap.html - Dave Andrew C. Oliver wrote: http://www.javalobby.org/thread.jsp?forum=61thread=3786 While the name of this article is just pure inflamatory, some of the points it makes are good and the numbers are interesting if unbacked (by WTF was it the application you benchmarked) I think constructive criticism is good. -Andy -- 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: Wanted to forward this article on to the Tomcat folks but I can'tsubscribe in order to do it so...
Yeah, that is especially fun when you have to telnet into 20 background servers and make the same changes to all 20 config files. It is also fun hitting the docs everytime you need to determine the legal values for a given config variable. That said, I agree with you both: a GUI admin tool should not preclude editing config files. - Dave Jun Inamori wrote: I agree with Andy. I have servers with no console attached. I simply ssh or telent in and do the configuration. If anyone ever writes a GUI admin for tomcat, I hope it does not conflict with the ability to use plain text and edit the conf files. +1000 Happy Java programming! --- Jun Inamori OOP-Reserch E-mail: [EMAIL PROTECTED] URL:http://www.oop-reserch.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]
Re: Wrong BUILDING.txt
That's it. Thanx. Jeff Turner wrote: On Sat, Mar 23, 2002 at 02:03:39PM +0100, Jose M. Palomar wrote: BUILDING.txt documentation file of CVS Tomcat 4 mentions the download of package commons-daemon. I've browsed builds directories searching for it and It was missing. What package replace this? It's in the jakarta-commons-sandbox CVS module. Doesn't look like it's being built nightly, so I think CVS is your only option. In theory, you can get any Gump-built jar from http://gump.covalent.net/jars/latest/, but it seems to be down ATM. --Jeff -- Jose M. Palomar www.talika.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Jose M. Palomar www.talika.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Wrong BUILDING.txt
BUILDING.txt documentation file of CVS Tomcat 4 mentions the download of package commons-daemon. I've browsed builds directories searching for it and It was missing. What package replace this? -- Jose M. Palomar www.talika.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] Tomcat 4 Servlets LocalStrings_es.properties
Tralation to spanish of the LocalStrings of the Tomcat 4 Servlets directory.
Well first something easy! Simply translating!
Hope it works it was the first time using diff -u too :).
Regards,
--
Jose M. Palomar
www.talika.org
--- LocalStrings_es.properties.orig Fri Mar 22 19:21:56 2002
+++ LocalStrings_es.properties Fri Mar 22 19:13:46 2002
@@ -0,0 +1,117 @@
+managerServlet.removed=OK - Elminada aplicaci\u00F3n del contexto {0}
+directory.size=Tama\u00F1o
+managerServlet.sessions=OK - Informaci\u00F3n de sesion para la aplicacion en el
+conexto {0}
+invokerServlet.invalidPath=No se especifico un nombre de servlet o clase en el camino
+{0}
+managerServlet.exception=FALLO - Encontrada la excepci\u00F3n {0}
+managerServlet.noPath=FALLO - Ning\u00FAn contexto fue especificado
+defaultservlet.files=Ficheros:
+managerServlet.startFailed=FALLO - La aplicaci\u00F3n del conexto {0} no pudo sert
+iniciada
+directory.version=Tomcat Catalina version 4.0
+managerServlet.unknownCommand=FALLO - Comando desconocido {0}
+defaultservlet.upto=Arriba a:
+directory.title=Listado del Directorio para {0}
+directory.lastModified=\u00DAltima modificaci\u00F3n
+invokerServlet.deallocate=No puedo desasignar una instancia de servlet para el camino
+{0}
+managerServlet.stopped=OK - Parada aplicaci\u00F3n en el contexto {0}
+managerServlet.sessiondefaultmax=Valor por defecto del m\u00E1ximo intervalo de
+actividad en la sesion {0} minutes
+managerServlet.cannotInvoke=No puedo invocar el manager servlet a trav\u00E9s de
+invoker
+directory.filename=Nombre del fichero
+invokerServlet.notNamed=No puedo llamar al invoker servlet con un dispatcher nombrado
+managerServlet.noContext=FALLO - No existe contexto para {0}
+defaultservlet.subdirectories=Subdirectorios:
+invokerServlet.allocate=No puedo asignar una instancia de servlet para el camino {0}
+managerServlet.started=OK - Iniciada aplicaci\u00F3n en el conexto {0}
+managerServlet.invalidPath=FALLO - El camino de contexto {0} no es valido
+managerServlet.reloaded=OK - Recargada aplicaci\u00F3n en el conexto {0}
+invokerServlet.cannotCreate=No puedo crear un servlet wrapper para el camino {0}
+managerServlet.invalidWar=FALLO - La URL de aplicaci\u00F3n {0} no es v\u00E1lida
+managerServlet.noCommand=FALLO - Ning\u00FAn comando fue especificado
+managerServlet.alreadyContext=FALLO - Ya existe una aplicaci\u00F3n en el camino {0}
+directory.parent=Arriba a {0}
+managerServlet.installed=OK - Aplicaci\u00F3n instalada en el camino del contexto {0}
+managerServlet.listitem={0}:{1}:{2}
+webdavservlet.jaxpfailed=Fallo en la inicializaci\u00F3n de JAXP
+invokerServlet.noWrapper=El contenedor no ha llamado a setWrapper() para este servlet
+managerServlet.noWrapper=El contenedor no ha llamado a setWrapper() para este servlet
+managerServlet.listed=OK - Listado de aplicaciones para el servidor virtual {0}
+defaultservlet.directorylistingfor=Listado del Directorio para:
+managerServlet.noRole=FALLO - El usuario no pertenece al rol {0}
+managerServlet.sessiontimeout={0} minutos:{1} sesiones
+managerServlet.removed=OK - Elminada aplicaci\u00F3n del contexto {0}
+directory.size=Tama\u00F1o
+managerServlet.sessions=OK - Informaci\u00F3n de sesion para la aplicacion en el
+conexto {0}
+invokerServlet.invalidPath=No se especifico un nombre de servlet o clase en el camino
+{0}
+managerServlet.exception=FALLO - Encontrada la excepci\u00F3n {0}
+managerServlet.noPath=FALLO - Ning\u00FAn contexto fue especificado
+defaultservlet.files=Ficheros:
+managerServlet.startFailed=FALLO - La aplicaci\u00F3n del conexto {0} no pudo sert
+iniciada
+directory.version=Tomcat Catalina version 4.0
+managerServlet.unknownCommand=FALLO - Comando desconocido {0}
+defaultservlet.upto=Arriba a:
+directory.title=Listado del Directorio para {0}
+directory.lastModified=\u00DAltima modificaci\u00F3n
+invokerServlet.deallocate=No puedo desasignar una instancia de servlet para el camino
+{0}
+managerServlet.stopped=OK - Parada aplicaci\u00F3n en el contexto {0}
+managerServlet.sessiondefaultmax=Valor por defecto del m\u00E1ximo intervalo de
+actividad en la sesion {0} minutes
+managerServlet.cannotInvoke=No puedo invocar el manager servlet a trav\u00E9s de
+invoker
+directory.filename=Nombre del fichero
+invokerServlet.notNamed=No puedo llamar al invoker servlet con un dispatcher nombrado
+managerServlet.noContext=FALLO - No existe contexto para {0}
+defaultservlet.subdirectories=Subdirectorios:
+invokerServlet.allocate=No puedo asignar una instancia de servlet para el camino {0}
+managerServlet.started=OK - Iniciada aplicaci\u00F3n en el conexto {0}
+managerServlet.invalidPath=FALLO - El camino de contexto {0} no es valido
+managerServlet.reloaded=OK - Recargada aplicaci\u00F3n en el conexto {0}
+invokerServlet.cannotCreate=No puedo crear un servlet wrapper para el camino {0}
+managerServlet.invalidWar=FALLO - La URL de aplicaci\u00F3n {0} no es v\u00E1lida
+managerServlet.noCommand=FALLO - Ning\u00FAn comando
Re: [VOTE] Final release of Tomcat 3.3.1
- Original Message - From: Larry Isaacs [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 20, 2002 10:20 PM Subject: [VOTE] Final release of Tomcat 3.3.1 I believe it is an appropriate time to release the HEAD of jakarta-tomcat as Tomcat 3.3.1. Also, as part of this release, I play to sync up the jakarta-tomcat-connectors/utils to ensure that there are no regressions in its tomcat-utils.jar with respect to the one in Tomcat 3.3.1. -- Vote to release jakarta-tomcat HEAD as Tomcat 3.3.1 [X] +1 I am in favor of the release, and will help support it [ ] +0 I am in favor of the release, but am unable to help support it. [ ] -0 I not in favor of the release [ ] -1 I am opposed to the release because: -- Cheers, Larry Isaacs -- 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: Tomcat source in IDE
I'm using Forte CE 3.0 with Tomcat sources without any problem. Did you tried to download the CVS source? You could import the sources using the CVS module of Forte and to build it use the ANT module too ;). For me works. - Jose M. Palomar www.talika.org - Original Message - From: bhai [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, March 18, 2002 10:06 PM Subject: Tomcat source in IDE Hello, I am trying to study tomcat source and i tried to import it in Eclipse and Forte but obvioulsy there are some directory heirachies that cause the IDE to throw an error. My question is that are there any articles out there for importing tomcat source into an IDE and then compiling/building the source from there (integrating ant with the IDE? ) Please guide me in the right direction. Thanks. -- 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]
Where to send code?
Hi all! I'll write a modification of the manager servlets that allows you to manage an entire Engine throught only one instance of the manager and I transtaled to spanish the localstrings. But I don't know where to send this changes for crontibuting them to the project. Meanwhile I'll posted them at my website www.talika.org if anyone want to see it. - Jose M. Palomar www.talika.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Status of BASIC authentication in Tomcat4.0-latest?
Craig == Craig R McClanahan [EMAIL PROTECTED] writes: Craig On 16 Jun 2001, David M. Karr wrote: What is the status of BASIC authentication in Tomcat4.0-latest? I noticed it seems to do nothing. A login dialog never appeared, but it gave access to the resource, and the return from request.getAuthType() in the resource was a null string. Craig As far as I know, it works according to the specs. Same for the other Craig container managed security methods. Craig Did you create a security-constraint to protect the resources that you Craig wanted to have protected? If you don't do this, authentication will never Craig be triggered (so request.getAuthType() will return null, of course). Following this is my web.xml for the BASIC test. This is almost verbatim from the Prof. JSP example. I tried a similar test with FORM-based authentication (also from the book), with similar but different results. It never went to the login page, but instead of just going to the protected resource (like the BASIC test), it failed with a permission error on the resource. ?xml version=1.0 ? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/j2ee/dtds/web-app_2_3.dtd; web-app security-constraint web-resource-collection web-resource-nameEntire Application/web-resource-name url-pattern/*/url-pattern /web-resource-collection /security-constraint login-config auth-methodBASIC/auth-method realm-nameProJSP Authentication Example/realm-name /login-config /web-app -- === David M. Karr ; Best Consulting [EMAIL PROTECTED] ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004)
Forcing generated JSP code to match package structure
A long time ago, I submitted a bug report pointing out that when JSP pages are generated to servlets, the directory structure in the work directory doesn't match the package structure of the generated class. When I checked the bug report later, I believe it was marked as Cosmetic. I believe this issue is more than cosmetic, although certainly not critical. The difficulty this creates (I think) is if you want to load Tomcat in a debugger as an application in order to debug generated JSP code, not using the fancy integrated web server and JSP debugger. The debugger doesn't seem to like it if the directory structure that a class lies in doesn't match the package structure, unless I'm misunderstanding what I'm seeing. When I try to do this in NetBeans (and Tomcat4.0latest), I'm able to set a breakpoint in the generated code, and the output window says that it hit the breakpoint, but it says Unavailable source file, even though I can display the source file in the integrated source editor. So am I understanding this situation correctly, or is there something basic that I'm overlooking? -- === David M. Karr ; Best Consulting [EMAIL PROTECTED] ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004)
Status of BASIC authentication in Tomcat4.0-latest?
What is the status of BASIC authentication in Tomcat4.0-latest? I noticed it seems to do nothing. A login dialog never appeared, but it gave access to the resource, and the return from request.getAuthType() in the resource was a null string. I'm not familiar with the architecture, but I tried setting breakpoints in AuthenticatorBase and BasicAuthentication (in NetBeans), but I never saw anything meaningful. It did hit some of the breakpoints, however. I did a search in the tomcat-dev mailing list, and I found lots of messages which talked about particular issues with BASIC and FORM authentication, but nothing specifically saying that BASIC authentication didn't work. I would have searched the bug database, but it was down at the time (Internal Server Error). This is mostly just a curiousity, as I doubt I'd ever use BASIC authentication for a real project, but as I'm just getting started absorbing the Tomcat architecture, I find it helpful to try to track problems, no matter how trivial. -- === David M. Karr ; Best Consulting [EMAIL PROTECTED] ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004)
Poor Tomcat 3.2.2 performance on Win32 with class reloading enabled
I just upgraded or application from Tomcat 3.1 to Tomcat 3.2.2 and noticed a dramatic slowdown and increased CPU utilization. This is on WinNT 4.0 SP5. To figure out what was happening, I fired up OptimizeIT and took a look. I found that 68% time was being spent in "org.apache.tomcat.core.ServletWrapper.handleReload" and of the time within this method, 51% of the time was being spent in "java.io.File.getCanonicalPath" and of the time spend within this method, all of it was spent within "java.io.Win32FileSystem.canonicalize". My question is is this normal and what in the hell is taking so long in "java.io.Win32FileSystem.canonacalize"? Once I disabled class reloading, by performance and CPU utilization went back to what was present with 3.1. Thanks for any input. Brett M. Bergquist Canoga Perkins Corp.
Tomcat Admin Web Interface
Hello All, In response to the recent postings regarding Tomcat documentation and administration (Re: ~rant~ Docs, user list, etc.), I am willing to contribute much effort in this area. In addition to documentation, I am particularly interested in helping to build an administrative web interface for Tomcat 4.0, something similar to JRun Management Console, for example. Naturally, I want to coordinate my efforts with the Tomcat community. Can anyone please point out where I should begin, or who I should contact? Is there a project for this? The Catalina TODO identifies John Shin as volunteer for producing an admin interface, but I thought I should email this list before contacting him directly. Thanks, Matt --- Craig R. McClanahan [EMAIL PROTECTED] wrote: ... Better docs would help. Better external resources (magazine articles and books) would help. Software that is easier to configure would help. But users will always be with us, and need their questions answered :-). Volunteers to do any or all of the above are welcome -- the committers will be eternally grateful! Craig McClanahan __ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/
Tomcat log limitations?
Ok, the scenario: Who m I? I've no idea about Tomcat, my first contact with it has been an hour ago. I've been LiNUX user for several years and I know how Java servlets serves works, so I think I'm an average system administrator. I've been application programmer for several years also, so I'm an average developer also. I've some contact with Enhydra that perhaps you know, but I've never installed or use it in a production environment. Hope this information helps. What's the matter? In a project, we need some collaborators each one with his own http server and operating system, give us they http logs in NCSA Combined format for generate stats for third parties. Well, one of those collaborators told us that they cannot generate NCSA Combined logs because they're using TomCat... As I CANNOT reproduce each collaborator system environment conditions, you will understand that's not reasonable that I must install a TomCat server just to see if this is true. I've seen that TomCat could be installed standalone or dependant of another web server like Apache or IIS. I think the situation of this collaborator is 'standalone' because another manner should provide they the logs of its apache or IIS web server without troubles. The trouble in a brief? Just two questions: Can TomCat as standalone server produce NCSA Combined logs? if yes... in a brief: How? Please note that by evident reasons I'm not suscribed to TomCat Users list, so if there's an answer, please, send it to my own mail box: fmmarzoa at e-samuelson.com THANKS A LOT everyone in advance, excuse my poor english and have a good one, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler Compiler.java
OK, I am thinking this is a pretty good idea now too, since seeing your and Marc's emails. My last two thoughts on the matter (just playing Devil's advocate): 1. Doesn't it seem a bit sloppy to leave a bunch of classes loaded that will never get dumped unless the server is shutdown? Just a matter of elegance, I suppose. 2. What unforseen problems might arise in a large application with interdependencies, such as included files that are overlooked -- if an included file is deleted but the includer is not, what happens? -- Scott Stirling West Newton, MA On 05 Jan 2001 15:58:07 -0800, Hans Bergsten wrote: Scott Stirling wrote: I agree with Craig. The ability to run JSP apps without any source JSPs must be maintained for app vendors who want to ship without source code. Not sure if this patch would interfere with that or not. It shouldn't; if you want to distribute JSP pages without source, you compile them to servlet classes and add mappings for the paths to the servlets in web.xml. The spec may be vague on this, but that's still what I believe is the recommendation stated in the section about precompilation. A separate issue: if a user removes the source JSP, it may be OK to remove the JSP class file, but what about the class loaded in memory (assuming the server was running when the JSP was deleted)? To be consistent you would have to unload that JSP class, Not necessarily unload, but remove all internal (automatic) mappings so that a request for the JSP always results in a 404. and possibly any associated objects (depending how JavaBeans and JSP are loaded in classloaders in Tomcat). For example, if an application scope bean were loaded by that JSP, would that bean be dumped with the classloader for that JSP or not? Hmmm... I think that's overkill. Hans - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler Compiler.java
On 05 Jan 2001 16:35:09 -0800, Hans Bergsten wrote: "Scott M. Stirling" wrote: 1. Doesn't it seem a bit sloppy to leave a bunch of classes loaded that will never get dumped unless the server is shutdown? Just a matter of elegance, I suppose. [Hans Bergsten] Yes, it does. But AFAIK there's no way you can just unload a class from the JVM; you would have to drop the class loader for the context and reload all classes that are still valid. That doesn't seem like the right thing to do in this situation IMHO. It depends how class loading in Tomcat works. I'm familiar with JRun 3.0, which works like this (I'm not giving away any family secrets, this stuff is documented in various places in Allaire docs): - servlets JavaBeans (even those called by JSPs) - loaded by a classloader with web-app scope. If a single servlet changes, the whole web-app's classloader is dumped so the servlet can be dynamically reloaded. No need to actively reload the other classes that got dumped with the classloader. They'll be reloaded as needed when requests come in for them. - JSPs are each loaded in their own classloader. So if a JSP is changed and reloaded, the old classloader is dumped and a new one created. JavaBeans are delegated to the web-app classloader, for whatever reason. All this may change in future versions, when JRun reloads tag handlers dynamically. I have no idea how Tomcat handles these classloader issues, but it would be interesting to hear about if anyone can distill it briefly. -- Scott Stirling West Newton, MA - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Mud (Was: [OT] Holiday Reading - Refactoring)
Hi, about mud, here is a pattern called "Big ball of mud" by Brian Foote and Joseph Yoder. Read it! http://www.laputan.org/mud/ Regards Stein M. Eliassen System Developer - KPNQwest Norway AS - Business communications @ the speed of light.
Re: Servlet - Jini - Tomcat3.1
- Original Message - Flavio, It is not clear from your description what you are trying to do. . does your server issue a query to obtain a Jini service reference from a lookup server ? Exactly, my servlet just make an unicast to receive from the lookup server the Registrar (LookupLocator.GETREGISTRAR) . The exception appears after that call. If it helps, I am trying to connect a servlet to a JavaSpace and TransactionManager (mahalo) services. . are you expecting that the Jini service will upload the WAR over the net to be incorporated ? This I didn't understand... (???) Arieh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Servlet - Jini - Tomcat3.1
Hi all, My servlet is getting the following exception when running on Tomcat3.1. This happens when I try to get the reference of a jini service (by a unicast call) : java.lang.ClassCastException: org.apache.tomcat.protocol.WARConnection A friend told me that it is a bug from Tomcat and that there would be a fix for that. I have no idea what this could be. Is there any special configuration to use in Tomcat3.1 to use with jini services ? What is this excepion about ? Thanks all, Flavio. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Linking mod_jk for apache 1.3, on HP-UX 11.00
Hey all. I've been struggling to get mod_jk for Apache 1.3 to link, using the 32-bit linker on HPUX 11.00. Problem is with the linker complaining about not being able to resolving external unknown symbols (that mod_jk uses, which are provided by apache during runtime). Here's the link command I'm using, and the associated error message(s); (more dialog at bottom): ld -B deferred -o mod_jk.sl jk_ajp12_worker.o \ jk_connect.o jk_msg_buff.o jk_util.o jk_ajp13.o jk_jni_worker.o \ jk_pool.o jk_worker.o jk_ajp13_worker.o jk_lb_worker.o \ jk_sockbuf.o jk_map.o jk_uri_worker_map.o mod_jk.o -lm -lc -ldld ld: Unsatisfied symbols: ap_update_mtime (code) ap_setup_client_block (code) ap_get_client_block (code) ap_get_server_version (code) ap_palloc (code) ap_overlay_tables (code) ap_bflush (code) ap_parseHTTPdate (code) ap_should_client_block (code) ap_table_get (code) ap_pstrdup (code) ap_get_remote_host (code) ap_table_add (code) ap_bsetflag (code) ap_reset_timeout (code) ap_bwrite (code) ap_table_set (code) ap_psprintf (code) ap_table_setn (code) ap_add_common_vars (code) ap_make_table (code) ap_pvsprintf (code) ap_set_last_modified (code) ap_content_type_tolower (code) ap_pcalloc (code) ap_log_error (code) ap_send_http_header (code) ld: Unsatisfied symbols: $global$ (data) I just need a way to tell the linker (either through gcc, or using native linker options) that these symbols will be provided by httpd during runtime. The native linker doc does not seem to have any useful information on this specific topic. I've tried several (unsuccessful) combinations of linker options. I'm currently using the natice C compiler and linker. Previously, I used gcc as both the C compiler and linker, with the same problem. Has anyone successfully compiled/linked mod_jk for apache, on HP-UX 11.00, using the 32-bit linker? What linker flags did you use? Any other issues running on this platform? Fwiw, I had to add some 32-bit shared library loader calls to common/jk_jni_worker.c (to replace the dl*() calls that my 32-bit libraries don't provide); If anyone is interested I can provide diffs. Brian -- Brian M. Kelley Vizdom Software, Inc. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
