cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardContext.java
remm2003/07/31 23:14:40
Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
Log:
- Remove (for now) dead reload code.
Revision ChangesPath
1.78 +1 -148
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java
Index: StandardContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
retrieving revision 1.77
retrieving revision 1.78
diff -u -r1.77 -r1.78
--- StandardContext.java 31 Jul 2003 20:56:25 - 1.77
+++ StandardContext.java 1 Aug 2003 06:14:40 - 1.78
@@ -2744,153 +2744,6 @@
setPaused(false);
-if (true)
-return;
-
-// Binding thread
-ClassLoader oldCCL = bindThread();
-
-// Shut down our session manager
-if ((manager != null) (manager instanceof Lifecycle)) {
-try {
-((Lifecycle) manager).stop();
-} catch (LifecycleException e) {
-log.error(sm.getString(standardContext.stoppingManager), e);
-}
-}
-
-// Shut down the current version of all active servlets
-Container children[] = findChildren();
-for (int i = 0; i children.length; i++) {
-Wrapper wrapper = (Wrapper) children[i];
-if (wrapper instanceof Lifecycle) {
-try {
-((Lifecycle) wrapper).stop();
-} catch (LifecycleException e) {
-log.error(sm.getString(standardContext.stoppingWrapper,
- wrapper.getName()),
-e);
-}
-}
-}
-
-// Shut down application event listeners
-listenerStop();
-
-// Clear all application-originated servlet context attributes
-if (context != null)
-context.clearAttributes();
-
-// Shut down filters
-filterStop();
-
-if (isUseNaming()) {
-// Start
-namingContextListener.lifecycleEvent
-(new LifecycleEvent(this, Lifecycle.STOP_EVENT));
-}
-
-// Binding thread
-unbindThread(oldCCL);
-
-// Shut down our application class loader
-if ((loader != null) (loader instanceof Lifecycle)) {
-try {
-((Lifecycle) loader).stop();
-} catch (LifecycleException e) {
-log.error(sm.getString(standardContext.stoppingLoader), e);
-}
-}
-
-// Binding thread
-oldCCL = bindThread();
-
-// Restart our application class loader
-if ((loader != null) (loader instanceof Lifecycle)) {
-try {
-((Lifecycle) loader).start();
-} catch (LifecycleException e) {
-log.error(sm.getString(standardContext.startingLoader), e);
-}
-}
-
-// Binding thread
-unbindThread(oldCCL);
-
-// Create and register the associated naming context, if internal
-// naming is used
-boolean ok = true;
-if (isUseNaming()) {
-// Start
-namingContextListener.lifecycleEvent
-(new LifecycleEvent(this, Lifecycle.START_EVENT));
-}
-
-// Binding thread
-oldCCL = bindThread();
-
-// Restart our application event listeners and filters
-if (ok) {
-if (!listenerStart()) {
-log.error(sm.getString(standardContext.listenerStartFailed));
-ok = false;
-}
-}
-if (ok) {
-if (!filterStart()) {
-log.error(sm.getString(standardContext.filterStartFailed));
-ok = false;
-}
-}
-
-// Restore the Welcome Files and Resources context attributes
-postResources();
-postWelcomeFiles();
-
-// Restart our currently defined servlets
-for (int i = 0; i children.length; i++) {
-if (!ok)
-break;
-Wrapper wrapper = (Wrapper) children[i];
-if (wrapper instanceof Lifecycle) {
-try {
-((Lifecycle) wrapper).start();
-} catch (LifecycleException e) {
-log.error(sm.getString(standardContext.startingWrapper,
- wrapper.getName()),
-e);
-ok = false;
-}
-}
-}
-
-// Reinitialize
cvs commit: jakarta-tomcat-5 build.properties.default
remm2003/07/31 23:54:10
Modified:.build.properties.default
Log:
- Update to Xerces 2.5.0 (will revert to 2.4.0 if there are problems ;-) ).
Revision ChangesPath
1.99 +3 -3 jakarta-tomcat-5/build.properties.default
Index: build.properties.default
===
RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.98
retrieving revision 1.99
diff -u -r1.98 -r1.99
--- build.properties.default 18 Jul 2003 14:29:29 - 1.98
+++ build.properties.default 1 Aug 2003 06:54:10 - 1.99
@@ -127,11 +127,11 @@
# - Xerces XML Parser, version 2.4.0 -
-xerces.home=${base.path}/xerces-2_4_0
+xerces.home=${base.path}/xerces-2_5_0
xerces.lib=${xerces.home}
xercesImpl.jar=${xerces.lib}/xercesImpl.jar
xmlParserAPIs.jar=${xerces.lib}/xmlParserAPIs.jar
-xerces.loc=http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.4.0.tar.gz
+xerces.loc=http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.5.0.tar.gz
# --
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22041] New: - Loading DynamicProxys from session
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=22041. 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=22041 Loading DynamicProxys from session Summary: Loading DynamicProxys from session Product: Tomcat 4 Version: 4.1.18 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If you got a DynamicProxy inside the session, catalina fails to load this object. Suggested fix: (tested just a little bit, not realy) in: org.apache.catalina.util.CustomObjectInputStream overwrite the method protected Class resolveProxyClass(String[] interfaces) with the implementation of java.io.ObjectInputStream except the first line ClassLoader latestLoader = classLoader; // instead of ClassLoader latestLoader = latestUserDefinedLoader(); this seams to work.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Validation of the server.xml
hi there, may be, this isn't really important but why is there no DTD or scheme to validate the server.xml ? in combination with the defined DTD for validating the mbeans descriptor file this should be a 'nice' feature. so if You are interested in developing / using such a scheme I would start to define one. Interest ??? sabine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters
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=21795. 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=21795 j_security_check isn't fed through filters --- Additional Comments From [EMAIL PROTECTED] 2003-08-01 08:16 --- After lack of comment and/or action from developers on this issue, and the discovery of over 680 open bugs in Tomcat 4, confidence in Tomcats stability and standards complaince is now very low. With this in mind we have made the decision to replace Tomcat with an alternative servlet engine. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22013] - RequestDispatcher.forward doesn't work with a relative path on a forwarded request
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=22013. 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=22013 RequestDispatcher.forward doesn't work with a relative path on a forwarded request [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2003-08-01 09:26 --- forgot to reopen bug with my last comment :-( - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/managerHTMLManagerServlet.java LocalStrings.properties ManagerServlet.java
[EMAIL PROTECTED] wrote:
remm2003/06/15 11:31:45
Modified:webapps/manager/WEB-INF/classes/org/apache/catalina/manager
HTMLManagerServlet.java LocalStrings.properties
ManagerServlet.java
Log:
- Update the manager to implement the new functionality as described in the docs.
- Pausing won't be implemented, due to difficulties, and the likelihood of bringing
the whole server to its knees (thanks to Glenn for poiting that out).
- Versioning is not tested yet.
- Known issue: locking occurs on an uploaded WAR, for reasons which
elude me right now.
- Known issue 2: to deploy local WARs, a jar:file: URL must be used.
1.2 +257 -55 jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/ManagerServlet.java
Index: ManagerServlet.java
===
RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/ManagerServlet.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ManagerServlet.java 26 Mar 2003 09:49:19 - 1.1
+++ ManagerServlet.java 15 Jun 2003 18:31:45 - 1.2
@@ -331,6 +349,12 @@
String path = request.getParameter(path);
String type = request.getParameter(type);
String war = request.getParameter(war);
+String tag = request.getParameter(tag);
+boolean update = false;
+if ((request.getParameter(update) != null)
+ (request.getParameter(update).equals(true))) {
+update = false;
+}
// Prepare our output writer to generate the response message
Locale locale = Locale.getDefault();
Remy,
here you set update to false or to false ;-). Would it be better touse
something like this?
boolean update = true.equals(request.getParameter(update));
@@ -399,6 +431,12 @@
if (command == null)
command = request.getServletPath();
String path = request.getParameter(path);
+String tag = request.getParameter(tag);
+boolean update = false;
+if ((request.getParameter(update) != null)
+ (request.getParameter(update).equals(true))) {
+update = false;
+}
// Prepare our output writer to generate the response message
response.setContentType(text/plain);
The same here.
Radim
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters
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=21795. 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=21795 j_security_check isn't fed through filters --- Additional Comments From [EMAIL PROTECTED] 2003-08-01 09:53 --- j_security_check is handled internaly by tomcat authenticator valves, and so never reachs your filter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: build-hpux.sh
Mertz, Wendy (Director Corporate Systems, IT) a écrit : To whom it may concern: We are trying to install and link Apache with Tomcat and am unable to locate the build-hpux.sh script for Apache 1.3.14 to Tomcat 3.2.3 (HP Unix 11.0). Can you assist me by providing me the script? Thank you in advance, You should use the configure way : ./buildconf.sh ./configure --with-apxs=/your/path/to/apxs make - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22045] New: - Virtual host mappings in mod_jk2 (related to bug 18472)
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=22045. 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=22045 Virtual host mappings in mod_jk2 (related to bug 18472) Summary: Virtual host mappings in mod_jk2 (related to bug 18472) Product: Tomcat 4 Version: 4.1.24 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In httpd.conf I have something like: --- NameVirtualHost * VirtualHost * ServerName www.example.com ServerAlias www ServerAlias localhost DocumentRoot /var/www/html Location /examples/* JkUriSet worker ajp13:localhost:8009 /Location /VirtualHost VirtualHost * ServerName someapp.example.com DocumentRoot /projects/someapp Location /*.html JkUriSet worker ajp13:localhost:8009 /Location /VirtualHost So I'm trying to get jk2 to forward all *.html for someapp.example.com to Tomcat, but *not* in www.example.com. If you look at the status worker however, I notice in the uri runtime info: id | name | host | uri | group | context 0 | /examples/* | * | /examples/* | ajp13:localhost:8009 | / 0 | /*.html * | /*.html | ajp13:localhost:8009 | / Obviously, I would expect the host to be set properly, not * as it happens now. I build my mod_jk2 from the jakarta-tomcat-connectors-4.1.24-src (which was a real pain), which should include the fix for bug 18472. (Apache 2.0.47) Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release mod_jk 1.2.5
No problems have been reported since the last test source distribution of mod_jk 1.2.5 was made available for testing July 26. ballot Please vote on a release of mod_jk 1.2.5: [ ] +1 release, and I will help build binaries for _ os/web server [ ] +0 ok to release [ ] -0 release, but I still have a problem with _ [ ] -1 don't release, there is a problem with _ /ballot The votes will be counted Monday August 4 and the source dist release made if the vote passes. Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validation of the server.xml
I'm not interested, here's why: http://jakarta.apache.org/tomcat/faq/misc.html#dtd -Tim Sabine Winkler wrote: hi there, may be, this isn't really important but why is there no DTD or scheme to validate the server.xml ? in combination with the defined DTD for validating the mbeans descriptor file this should be a 'nice' feature. so if You are interested in developing / using such a scheme I would start to define one. Interest ??? sabine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters
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=21795. 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=21795 j_security_check isn't fed through filters --- Additional Comments From [EMAIL PROTECTED] 2003-08-01 10:43 --- But under the Sun specifications it SHOULD reach the filter because the filter is defined as handling all request going to that webapp. Authentication is suppose to be a transparent layer on top of the webapp, not something that overrides the behaviour specified in web.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters
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=21795. 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=21795 j_security_check isn't fed through filters --- Additional Comments From [EMAIL PROTECTED] 2003-08-01 11:03 --- copied text from servlet-spec-2.4-pfd3 for container managed security with forms - j_security_check SRV.12.5.3 Form Based Authentication The look and feel of the login screen cannot be varied using the web browser s built-in authentication mechanisms. This specification introduces a required form based authentication mechanism which allows a Developer to control the look and feel of the login screens. The web application deployment descriptor contains entries for a login form and error page. The login form must contain fields for entering a username and a password. These fields must be named j_username and j_password , respectively. When a user attempts to access a protected web resource, the container checks the user s authentication. If the user is authenticated and possesses authority to access the resource, the requested web resource is activated and a reference to it is returned. If the user is not authenticated, all of the following steps occur: 1. The login form associated with the security constraint is sent to the client and the URL path triggering the authentication is stored by the container. 2. The user is asked to fill out the form, including the username and password fields. 3. The client posts the form back to the server. 4. The container attempts to authenticate the user using the information from the form. 5. If authentication fails, the error page is returned using either a forward or a re-direct, and the status code of the response is set to 401. 6. If authentication succeeds, the authenticated user s principal is checked to see if it is in an authorized role for accessing the resource. 7. If the user is authorized, the client is redirected to the resource using the stored URL path. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters
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=21795. 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=21795 j_security_check isn't fed through filters [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-08-01 11:11 --- The spec implies that authentication is part of the container, not part of the webapp so the j_security_check occurs outside the role of filters. SRV.12.2 Declarative Security Declarative security refers to the means of expressing an applications security structure, including roles, access control, and authentication requirements in a form external to the application. The deployment descriptor is the primary vehicle for declarative security in web applications. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters
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=21795. 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=21795 j_security_check isn't fed through filters --- Additional Comments From [EMAIL PROTECTED] 2003-08-01 11:12 --- Please see Section SRV6.2.4 in the Sun Servlet spec 2.3, which details the procedure a contain must follow when dealing with requests. In short it says that if an incoming URI matches a filter pattern the user specified filter should be invoked. It appears neither section says that the use of j_security_check should stop a filter being triggered, yet the filter section indicates that the filter should be. Other containers do trigger filters on j_security_check, evidence of this can be found at http://publib7b.boulder.ibm.com/wasinfo1/en/info/aes/ae/tsec_servlet.html (4th paragraph), http://mainframeforum.com/archive/1047/2003/4/545167 (comment from Scott Sobotka), and http://www.caucho.com/quercus/faq/question.xtp? question_id=1239 Snippet: - Identifies the target web resource according to the rules of SRV.11.2. - If there are filters matched by servlet name and the web resource has a servlet-name, the container builds the chain of filters matching in the order declared in the deployment descriptor. The last filter in this chain corresponds to the last servlet-name matching filter and is the filter that invokes the target web resource. - If there are filters using url-pattern matching and the url-pattern matches the request URI according to the rules of SRV.11.2, the container builds the chain of url-pattern matched filters in the same order as declared in the deployment descriptor. The last filter in this chain is the last url-pattern matching filter in the deployment descriptor for this request URI. The last filter in this chain is the filter that invokes the first filter in the servlet-name macthing chain, or invokes the target web resource if there are none. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters
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=21795. 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=21795 j_security_check isn't fed through filters [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2003-08-01 11:18 --- The bug isn't resolved. There is still a dispute over the spec. Closing a bug without checking with the bug reporter's agreement maybe a way to thin down the bug count, but is NOT a way to professionally handle bug reports. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters
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=21795. 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=21795 j_security_check isn't fed through filters [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-08-01 12:06 --- Please get a response from the spec team from Sun to confirm tomcat's behavior is invalid. I contend the tomcat's behavior is correct with respect to the spec. If you strongly disagree, please attach a patch that fixes the behavior and if another committer agrees with your patch, it will be committed. Here's a note from Craig about filters and j_security_check: http://marc.theaimsgroup.com/?l=tomcat-userm=101078110723448w=2 If another container allows this behavior, that is ok. But it appears there is no requirement that tomcat must do this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release mod_jk 1.2.5
Glenn Nielsen a écrit : No problems have been reported since the last test source distribution of mod_jk 1.2.5 was made available for testing July 26. ballot Please vote on a release of mod_jk 1.2.5: [X] +1 release, and I will help build binaries for _ os/web server [ ] +0 ok to release [ ] -0 release, but I still have a problem with _ [ ] -1 don't release, there is a problem with _ /ballot BTW, I'll be on holidays for 3 weeks starting tomorrow, so you should some helps for Linux binaries ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release mod_jk 1.2.5
Henri Gomez a écrit : Glenn Nielsen a écrit : No problems have been reported since the last test source distribution of mod_jk 1.2.5 was made available for testing July 26. ballot Please vote on a release of mod_jk 1.2.5: [X] +1 release, and I will help build binaries for _ os/web server [ ] +0 ok to release [ ] -0 release, but I still have a problem with _ [ ] -1 don't release, there is a problem with _ /ballot BTW, I'll be on holidays for 3 weeks starting tomorrow, so you should some helps for Linux binaries ;) For help on Linux binaries, you should contact my friend at www.jpackage.org which allready produce jk binaries for many Linux distribution, take a look at : http://dl.sf.net/jpackage/direct_download/1.5/ Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [4.1.27] Builds uploaded
Howdy, Thanks and enjoy the trip Remy ;) Yoav Shapira (Also another -LE build user) Millennium ChemInformatics -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2003 3:53 PM To: Tomcat Developers List Subject: [4.1.27] Builds uploaded Hi, I have uploaded the binaries (http://www.apache.org/dist/jakarta/tomcat-4/), and committed the sites updates. I'll only update the live website tomorrow morning (unless someone does it before; I'm trying to leave enough time for the mirrors to sync up before an official announcement), and will send email announcements at the same time. (Note: I decided to skip the LE builds, because I am lazy and people have been confused by them; I'll add them this WE if there's some demand) Note: I'm off to a short trip starting tomorrow morning, and will likely not have access to email. I'll be back saturday evening. If something is really wrong, don't wait for me: just pull the build ;-) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release mod_jk 1.2.5
From: Glenn Nielsen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, August 01, 2003 6:39 AM Subject: [VOTE] Release mod_jk 1.2.5 No problems have been reported since the last test source distribution of mod_jk 1.2.5 was made available for testing July 26. I've found one problem on the OpenBSD/sparc64 platform in jk_resolve. The recent change of the datatype of laddr from in_addr_t to u_long has broken this function. Could this be reverted back before release? Below is a copy of the commit that caused the problem: hgomez 2003/07/25 07:58:22 Modified:jk/native/common jk_connect.c Log: Use u_long instead of in_addr_t which make unhappy some platforms like iSeries Revision ChangesPath 1.10 +2 -3 jakarta-tomcat-connectors/jk/native/common/jk_connect.c Index: jk_connect.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- jk_connect.c 24 Jul 2003 08:17:10 - 1.9 +++ jk_connect.c 25 Jul 2003 14:58:22 - 1.10 @@ -110,8 +110,7 @@ int x; /* TODO: Should be updated for IPV6 support. */ -/* for now use the correct type, in_addr_t */ -in_addr_t laddr; +u_long laddr; rc-sin_port = htons((short)port); rc-sin_family = AF_INET; -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters
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=21795. 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=21795 j_security_check isn't fed through filters --- Additional Comments From [EMAIL PROTECTED] 2003-08-01 13:07 --- Thankyou for youe comments. Tomcat will now be removed from our list of approved software. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release mod_jk 1.2.5
Kurt Miller a écrit : From: Glenn Nielsen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, August 01, 2003 6:39 AM Subject: [VOTE] Release mod_jk 1.2.5 No problems have been reported since the last test source distribution of mod_jk 1.2.5 was made available for testing July 26. I've found one problem on the OpenBSD/sparc64 platform in jk_resolve. The recent change of the datatype of laddr from in_addr_t to u_long has broken this function. Could this be reverted back before release? Below is a copy of the commit that caused the problem: hgomez 2003/07/25 07:58:22 Modified:jk/native/common jk_connect.c Log: Use u_long instead of in_addr_t which make unhappy some platforms like iSeries Revision ChangesPath 1.10 +2 -3 jakarta-tomcat-connectors/jk/native/common/jk_connect.c Index: jk_connect.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- jk_connect.c 24 Jul 2003 08:17:10 - 1.9 +++ jk_connect.c 25 Jul 2003 14:58:22 - 1.10 @@ -110,8 +110,7 @@ int x; /* TODO: Should be updated for IPV6 support. */ -/* for now use the correct type, in_addr_t */ -in_addr_t laddr; +u_long laddr; rc-sin_port = htons((short)port); rc-sin_family = AF_INET; -Kurt It was u_long before I change it in in_addr_t and then change it back to u_long. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 21795] - j_security_check isn't fed throughfilters
[EMAIL PROTECTED] a écrit : 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=21795. 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=21795 j_security_check isn't fed through filters --- Additional Comments From [EMAIL PROTECTED] 2003-08-01 13:07 --- Thankyou for youe comments. Tomcat will now be removed from our list of approved software. Are you sure it's the correct way to handle the problem ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters
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=21795. 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=21795 j_security_check isn't fed through filters --- Additional Comments From [EMAIL PROTECTED] 2003-08-01 13:38 --- You may wish to remove weblogic too: http://groups.google.com/groups?hl=enlr=ie=UTF-8oe=UTF-8selm=3e9b0241%40newsgroups.bea.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 21795] - j_security_check isn't fed throughfilters
[EMAIL PROTECTED] a écrit : 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=21795. 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=21795 j_security_check isn't fed through filters --- Additional Comments From [EMAIL PROTECTED] 2003-08-01 13:38 --- You may wish to remove weblogic too: http://groups.google.com/groups?hl=enlr=ie=UTF-8oe=UTF-8selm=3e9b0241%40newsgroups.bea.com LOL ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release mod_jk 1.2.5
I can confirm what Henri said, laddr had always been a ulong and was only type in_addr_t for a short period of time. Does mod_jk 1.2.4 build and work correctly? It used a ulong for laddr. What web server are you building this for? If you are building for Apache 2 it may be a problem with the APR code. Regards, Glenn Kurt Miller wrote: From: Glenn Nielsen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, August 01, 2003 6:39 AM Subject: [VOTE] Release mod_jk 1.2.5 No problems have been reported since the last test source distribution of mod_jk 1.2.5 was made available for testing July 26. I've found one problem on the OpenBSD/sparc64 platform in jk_resolve. The recent change of the datatype of laddr from in_addr_t to u_long has broken this function. Could this be reverted back before release? Below is a copy of the commit that caused the problem: hgomez 2003/07/25 07:58:22 Modified:jk/native/common jk_connect.c Log: Use u_long instead of in_addr_t which make unhappy some platforms like iSeries Revision ChangesPath 1.10 +2 -3 jakarta-tomcat-connectors/jk/native/common/jk_connect.c Index: jk_connect.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- jk_connect.c 24 Jul 2003 08:17:10 - 1.9 +++ jk_connect.c 25 Jul 2003 14:58:22 - 1.10 @@ -110,8 +110,7 @@ int x; /* TODO: Should be updated for IPV6 support. */ -/* for now use the correct type, in_addr_t */ -in_addr_t laddr; +u_long laddr; rc-sin_port = htons((short)port); rc-sin_family = AF_INET; -Kurt - 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: [VOTE] Release mod_jk 1.2.5
From: Henri Gomez [EMAIL PROTECTED] It was u_long before I change it in in_addr_t and then change it back to u_long. Oh. I guess I should have done a bit more research.;-) I just started attempting to get mod_jk going on sparc64 a few days ago. However, using a u_long for laddr is the cause of jk_resolve failing on OpenBSD/sparc64. The memcpy at the end copies all zeros into rc-sin_addr when u_long is used. There are some other issues going on with mod_jk OpenBSD/sparc64, so its not yet working even with this corrected. Given that, it may not make sense to hold up the release for this. I will need to put in more time to investigate the next issue. OpenBSD-3.3/sparc64 uses Apache 1.3.27 so this is not an issue with the new APR code. I tested releases 1.2.1 - 1.2.5 on OpenBSD/sparc64 and they all don't work. It wasn't until recently that I had time to start investigating it. I'll post patches here as I make progress. -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters
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=21795. 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=21795 j_security_check isn't fed through filters --- Additional Comments From [EMAIL PROTECTED] 2003-08-01 13:57 --- The removal of Tomcat is as much about how this bug has been handled as it is about this specific issue. The overall problems are; 1) There are a HUGE number of bugs with Tomcat 4 that either haven't been looked at or been fixed after 25 minor revisions. 2) The bugs that are closed may be closed because the reporter has been referred to another group rather than being closed because the issue was resolved in a manner that satisfies both parties. 3) To get any movement on the bug I had to indicate an intention to move to another servlet engine. In short, if we recommend Tomcat and someone comes accross one of the 680+ outstanding issues, we're pretty much on our own. As we do not claim to be experts in Tomcat or it's underlying code, this isn't a responsibility we can afford to take on. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release mod_jk 1.2.5
Kurt Miller a écrit : From: Henri Gomez [EMAIL PROTECTED] It was u_long before I change it in in_addr_t and then change it back to u_long. Oh. I guess I should have done a bit more research.;-) I just started attempting to get mod_jk going on sparc64 a few days ago. However, using a u_long for laddr is the cause of jk_resolve failing on OpenBSD/sparc64. The memcpy at the end copies all zeros into rc-sin_addr when u_long is used. There are some other issues going on with mod_jk OpenBSD/sparc64, so its not yet working even with this corrected. Given that, it may not make sense to hold up the release for this. I will need to put in more time to investigate the next issue. OpenBSD-3.3/sparc64 uses Apache 1.3.27 so this is not an issue with the new APR code. I tested releases 1.2.1 - 1.2.5 on OpenBSD/sparc64 and they all don't work. It wasn't until recently that I had time to start investigating it. I'll post patches here as I make progress. The correct behaviour will be to use in_addr_t, but it don't works on iSeries (even if it's defined, I couldn't find the correct include). To fix the problem we could use a #define BSD64 ? to make use of in_addr_t until we make more works ? Just provide the correct defined var for BSD/SPARC64 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release mod_jk 1.2.5
Kurt Miller wrote: From: Henri Gomez [EMAIL PROTECTED] It was u_long before I change it in in_addr_t and then change it back to u_long. Oh. I guess I should have done a bit more research.;-) I just started attempting to get mod_jk going on sparc64 a few days ago. However, using a u_long for laddr is the cause of jk_resolve failing on OpenBSD/sparc64. The memcpy at the end copies all zeros into rc-sin_addr when u_long is used. There are some other issues going on with mod_jk OpenBSD/sparc64, so its not yet working even with this corrected. Given that, it may not make sense to hold up the release for this. I will need to put in more time to investigate the next issue. OpenBSD-3.3/sparc64 uses Apache 1.3.27 so this is not an issue with the new APR code. I tested releases 1.2.1 - 1.2.5 on OpenBSD/sparc64 and they all don't work. It wasn't until recently that I had time to start investigating it. I'll post patches here as I make progress. Yes, please send us the patches when they are available. The more OS/web servers, the better. :-) Thanks Kurt Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release mod_jk 1.2.5
Kurt Miller a écrit : From: Henri Gomez [EMAIL PROTECTED] Kurt Miller a écrit : From: Henri Gomez [EMAIL PROTECTED] It was u_long before I change it in in_addr_t and then change it back to u_long. Oh. I guess I should have done a bit more research.;-) I just started attempting to get mod_jk going on sparc64 a few days ago. However, using a u_long for laddr is the cause of jk_resolve failing on OpenBSD/sparc64. The memcpy at the end copies all zeros into rc-sin_addr when u_long is used. There are some other issues going on with mod_jk OpenBSD/sparc64, so its not yet working even with this corrected. Given that, it may not make sense to hold up the release for this. I will need to put in more time to investigate the next issue. OpenBSD-3.3/sparc64 uses Apache 1.3.27 so this is not an issue with the new APR code. I tested releases 1.2.1 - 1.2.5 on OpenBSD/sparc64 and they all don't work. It wasn't until recently that I had time to start investigating it. I'll post patches here as I make progress. The correct behaviour will be to use in_addr_t, but it don't works on iSeries (even if it's defined, I couldn't find the correct include). To fix the problem we could use a #define BSD64 ? to make use of in_addr_t until we make more works ? Just provide the correct defined var for BSD/SPARC64 I'm thinking a define may not be needed. I mischaracterized the problem slightly... u_long on OpenBSD/sparc64 is 8 bytes long, so the memcpy copies 8 bytes into rc-sin_addr. The first four bytes are zeros the next four overwrite some of the rest of the struct. Would it fix the problem if laddr was defined as a datatype that is 4 bytes long on all arches? Maybe u_int32_t or struct in_addr (same as rc-sin_addr)? Hum trying to play with bytes is not a good idea, we should stay with socket API and types. BTW, the current code is not compatible with IPv6, and we may have to use APR supports API, which could break the consensus that JK should works without requiring APR (or Apache 2.0). The future will be mod_jk2, and I think we should focus on it after the 1.2.5 release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22032] - missing security-policy in default-configuration
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=22032. 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=22032 missing security-policy in default-configuration --- Additional Comments From [EMAIL PROTECTED] 2003-08-01 15:07 --- OK, but the problem occured not only with precompiled JSPs. For me, even the standard tomcat webapps/index.jsp and all of the jsp-examples threw this exception. I think this shouldn't be the default behaviour with a fresh installed tomcat using the security manager. Thanks for the workaround with removing the jasper-package from the catalina.properties file. I hope this doesn't open any security holes... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22058] New: - incorrect JSP compilation
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=22058.
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=22058
incorrect JSP compilation
Summary: incorrect JSP compilation
Product: Tomcat 5
Version: 5.0.5
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Jasper2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I have a simple JSP that use a custom tag (file) writen by extending
SimpleTagSupport.
Here is the JSP :
%@ taglib uri=c-rt.tld prefix=b %
%@ taglib uri=templater.tld prefix=t %
b:forEach begin=0 end=10
t:file name=t
b:if test=true
/b:if
/t:file
/b:forEach
The generated code doesn't compile. The error is:
_jspx_push_body_count_b_forEach_0 cannot be resolved (in the function invoke_0)
Here is an extract of the generated code:
private class test_jspHelper
extends org.apache.jasper.runtime.JspFragmentHelper
{
private javax.servlet.jsp.tagext.JspTag parentTag;
public test_jspHelper( int discriminator, JspContext jspContext,
javax.servlet.jsp.tagext.JspTag parentTag ) {
super( discriminator, jspContext, parentTag );
this.parentTag = parentTag;
}
public boolean invoke0( java.io.Writer out )
throws Throwable
{
javax.servlet.jsp.tagext.JspTag _jspx_th_t_file_0 = parentTag;
out.write(\r\n\t\t);
if (_jspx_meth_b_if_0(_jspx_th_t_file_0, pageContext,
_jspx_push_body_count_b_forEach_0))
return true;
out.write(\r\n\t);
return false;
}
public void invoke( java.io.Writer writer )
throws javax.servlet.jsp.JspException
{
java.io.Writer out = null;
if( writer != null ) {
out = this.jspContext.pushBody(writer);
} else {
out = this.jspContext.getOut();
}
try {
switch( this.discriminator ) {
case 0:
invoke0( out );
break;
}
}
catch( Throwable e ) {
if (e instanceof javax.servlet.jsp.SkipPageException)
throw (javax.servlet.jsp.SkipPageException) e;
throw new javax.servlet.jsp.JspException( e );
}
finally {
if( writer != null ) {
this.jspContext.popBody();
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validation of the server.xml
On Fri, 1 Aug 2003, Sabine Winkler wrote: Date: Fri, 1 Aug 2003 10:15:46 +0200 From: Sabine Winkler [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Validation of the server.xml hi there, may be, this isn't really important but why is there no DTD or scheme to validate the server.xml ? in combination with the defined DTD for validating the mbeans descriptor file this should be a 'nice' feature. so if You are interested in developing / using such a scheme I would start to define one. Interest ??? A complete DTD (and I'm pretty sure even a schema) for server.xml, which would support the current level of functionality, is not technically feasible. The reason for this shows up when you think about what Tomcat does when it reads one of the XML elements like Host or Context. In particular, it maps all of the attribute names to corresponding property setter methods, and calls them -- using the attribute values to configure the behavior of that Tomcat component. In order to represent this capability in a DTD or schema, you'd need to include all possible attributes for all possible implementation classes (even your own custom Valve that provides some local feature you've installed in the request processing pipeline). At best, you could limit yourself to the standard implementation classes that come with Tomcat, but even then your definition of something like Valve would have to include all possible attributes on all the standard Valve implementations, even though some of those attributes will be irrelevant to some Valve classes. sabine Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters
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=21795. 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=21795 j_security_check isn't fed through filters --- Additional Comments From [EMAIL PROTECTED] 2003-08-01 16:26 --- Al, your interpretation that the Servlet Specification requires j_security_check to be handled through filters does *not* conform to my understanding of the Servlet Specification, and AFAIK it does not conform to the understanding of any other member of the JSR-154 expert group (responsible for creating the Servlet 2.4 specification) either. The best way to get the issue cleared up, however, would be to submit feedback to the expert group (send mail to [EMAIL PROTECTED]) and ask for it to be clarified. Complaining about Tomcat isn't going to have any influence on what the spec actually says or means. Encouraging the expert group to clarify things is the only way to accomplish that. Craig McClanahan Member, JSR-154 Expert Group J2EE Web Tier Architect - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21279] - Proc Runner: No Listener Notification on Shutdown
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=21279. 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=21279 Proc Runner: No Listener Notification on Shutdown [EMAIL PROTECTED] changed: What|Removed |Added Version|5.0.3 |5.0.5 --- Additional Comments From [EMAIL PROTECTED] 2003-08-01 16:50 --- I have added some logging to org.apache.catalina.startup.Bootstrap: main() is never reached on shutdown via procrun. Looks like procrun just kills the JVM. What strikes me here is that no shutdown hook gets activated. If I shutdown TC via telnet (port 8005) SessionListener and ContextListener are properly notified. I have no tools available to actually look what procrun does on shutdown. Any help is much appreciated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Collector.java PageInfo.java
luehe 2003/08/01 10:10:11
Modified:jasper2/src/share/org/apache/jasper/compiler Collector.java
PageInfo.java
Log:
Removed unused methods and instance vars
Revision ChangesPath
1.13 +2 -9
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Collector.java
Index: Collector.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Collector.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- Collector.java15 May 2003 18:45:40 - 1.12
+++ Collector.java1 Aug 2003 17:10:10 - 1.13
@@ -88,7 +88,6 @@
private boolean paramActionSeen = false;
private boolean setPropertySeen = false;
private boolean hasScriptingVars = false;
- private boolean tagFileSeen = false;
public void visit(Node.ParamAction n) throws JasperException {
if (n.getValue().isExpression()) {
@@ -139,11 +138,6 @@
public void visit(Node.CustomTag n) throws JasperException {
- // Remember if the tag handler is a tag file
- if (n.getTagFileInfo() != null) {
- tagFileSeen = true;
- }
-
curTagNesting++;
if (curTagNesting maxTagNesting) {
maxTagNesting = curTagNesting;
@@ -250,7 +244,6 @@
public void updatePageInfo(PageInfo pageInfo) {
pageInfo.setMaxTagNesting(maxTagNesting);
pageInfo.setScriptless(! scriptingElementSeen);
- pageInfo.setHasTagFile(tagFileSeen);
}
}
1.35 +3 -14
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageInfo.java
Index: PageInfo.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageInfo.java,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- PageInfo.java 28 Jul 2003 18:47:30 - 1.34
+++ PageInfo.java 1 Aug 2003 17:10:10 - 1.35
@@ -107,9 +107,6 @@
private boolean elIgnoredSpecified = false;
private String omitXmlDecl = null;
-// A custom tag is a tag file
-private boolean hasTagFile = false;
-
private boolean isJspPrefixHijacked;
// Set of all element and attribute prefixes used in this translation unit
@@ -221,14 +218,6 @@
public void setIncludeCoda(Vector coda) {
includeCoda = coda;
-}
-
-public void setHasTagFile(boolean hasTag) {
- hasTagFile = hasTag;
-}
-
-public boolean hasTagFile() {
- return hasTagFile;
}
public void setHasJspRoot(boolean s) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release mod_jk 1.2.5
[EMAIL PROTECTED] 8/1/2003 4:39:27 AM No problems have been reported since the last test source distribution of mod_jk 1.2.5 was made available for testing July 26. ballot Please vote on a release of mod_jk 1.2.5: [ X] +1 release, and I will help build binaries for NetWare Apache 1.3/NetWare Apache 2.0/NetWare Enterprise_ os/web server [ ] +0 ok to release [ ] -0 release, but I still have a problem with _ [ ] -1 don't release, there is a problem with _ /ballot The votes will be counted Monday August 4 and the source dist release made if the vote passes. Regards, Glenn Mike Anderson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release mod_jk 1.2.5
Henri Gomez said: The correct behaviour will be to use in_addr_t, but it don't works on iSeries (even if it's defined, I couldn't find the correct include). To fix the problem we could use a #define BSD64 ? to make use of in_addr_t until we make more works ? Just provide the correct defined var for BSD/SPARC64 If that's the case, wouldn't it be better to provide a #define for iSeries since in_addr_t works for most platforms? -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: Re: Tomcat and LDAP Issues
Something from the user list of note for development. The current method does something like this when handling a communication exception at authenticate time: / If not a Socket closed. error then rethrow. if (e.getMessage().indexOf(Socket closed) 0) throw(e); This seems to have two problems 1) e.getMessage() is sometimes null with some LDAP providers. 2) some LDAP providers set the exception to actually be connection closed (retrieved by e.toString()) Just forwarding this on for the user, since this code currently has some problems that ought to be fixed. (I have a vested interest being a heavy user of JNDIRealm). For a stopgap measure, one could do the following I guess: if (e.toString().indexOf(closed) 0) throw(e); Though as the bug report points out there may be yet other error messages given by other LDAP providers, and I don't know if closed is too general to check on or not. Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com [EMAIL PROTECTED] 8/1/03 2:00:46 PM Well, I understand this is now a bug: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19864 Was this fixed in the 4.1.27 version? Can't seem to determine if it was based on the README in the download. Jon On Friday, August 1, 2003, at 12:07 PM, Jon Wynacht wrote: Hi, I have Tomcat 4.1.24 installed on a server that hosts a web application. I have set up the container to do authentication via LDAP and it works for a bit then just stops working. The only way to get things working again is to restart Tomcat. I've included the error message below and am wondering if anybody on this list has had a similar experience? If so, how did you solve it? Thanks in advance, Jon 2003-08-01 10:37:29 JNDIRealm[Standalone]: lookupUser(jwynacht) 2003-08-01 10:37:29 JNDIRealm[Standalone]: dn=uid=jwynacht, ou=active, ou=employees, ou=people, o=cisco.com 2003-08-01 10:37:29 JNDIRealm[Standalone]: validating credentials by binding as the user 2003-08-01 10:37:29 JNDIRealm[Standalone]: binding as uid=jwynacht, ou=active, ou=employees, ou=people, o=cisco.com 2003-08-01 10:37:29 CoyoteAdapter An exception or error occurred in the container during the request processing java.lang.NullPointerException at org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:793) at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(Basic Authenticator.java:161) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authenticato rBase.java:526) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java: 480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:24 15) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.jav a:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherV alve.java:171) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.jav a:172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java: 480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve .java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java: 480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:5 94) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process Connection(Http11Protocol.java:392) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:5 65) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPoo l.java:619) at java.lang.Thread.run(Thread.java:536) - To unsubscribe, e-mail: [EMAIL PROTECTED] For
FW: JDK 1.4.2 and class loading
I wonder if any tomcat guys have any insight they could share with us... -Original Message- From: Noel J. Bergman [mailto:[EMAIL PROTECTED] Sent: 01 August 2003 20:02 To: James-Dev Mailing List Cc: Ted Neward; Jeroen Frijters Subject: JDK 1.4.2 and class loading Apparently, there has been a subtle change in JDK 1.4.2. Either intentional or accidental, but the URL: file://path/jarfile.jar does not appear to work under JDK 1.4.2, at least on Windows (the platform where this was noticed and tested today). Instead, the following URL does work: jar:file:path/jarfile.jar!/ Which means that the code in o.a.j.transport.Loader would change: - jarlist.add(new URL(file:// + baseDirectory + /SAR-INF/lib/ + flist[i] )); + jarlist.add(new URL(jar:file: + baseDirectory + /SAR-INF/lib/ + flist[i] + !/)); This behavior is noted at http://forum.java.sun.com/thread.jsp?forum=26thread=408858tstart =0trange= 15. Does anyone have any additional information on this issue? I'm not spotting anything in the docs, release notes or javadocs. Two related questions. Does anyone have any thoughts on the use of new URLClassLoader(URL[])vs URLClassLoader.newInstance(URL[]) Most examples use the latter form. There are is a code difference related to package security and exported packages. The current Java v1.4.2 documentation (http://java.sun.com/j2se/1.4.2/docs/guide/extensions/spec.html) don't go into it, but there is some information on exported packages in a cached copy of some docs from an older beta (http://kavosh.irost.net/books/jdk1.2beta3/docs/guide/extensions/s pec.html). This probably doesn't effect our use AT THE MOMENT, but I'm surprised to see the the operations aren't synonyms. Also, we've ran into some cases where: classLoader.loadClass(className); fails, whereas: Class.forName(className, true, classLoader) works. The best analysis I have found on the subject so far is Ted Neward's paper at http://www.javageeks.com/Papers/ClassForName/index.html, but he doesn't really go too far into the details of WHY the latter behaves differently, other than acknowledging that it does. --- Noel - 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: Validation of the server.xml
From: Craig R. McClanahan [EMAIL PROTECTED] Subject: Re: Validation of the server.xml Date: Fri, 1 Aug 2003 09:15:22 -0700 (PDT) On Fri, 1 Aug 2003, Sabine Winkler wrote: may be, this isn't really important but why is there no DTD or scheme to validate the server.xml ? in combination with the defined DTD for validating the mbeans descriptor file this should be a 'nice' feature. so if You are interested in developing / using such a scheme I would start to define one. Interest ??? A complete DTD (and I'm pretty sure even a schema) for server.xml, which would support the current level of functionality, is not technically feasible. How about RELAX NG (http://relaxng.org/) ? RELAX NG is a schema language for XML. RELAX NG has a include feature, so RELAX NG allows merging plural schemas. And the schema compiler for RELAX NG such as JAXB and Relaxer(http://www.relaxer.org/) maps the schema to Java classes. If tomcat provides some rules for schemas to include, it is easy to get Java objects from XML documents. The server.xml will be a plugable and valid document. --- HARADA, Yoko - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fw: [Apache Newsletter Draft] News on Jakarta in July, 2003
Dear Jakarta Tomcat Development Team, (http://jakarta.apache.org/tomcat/) Hello, I am now in the process of preparing the first all-Apache-wide newsletter. http://www.apache.org/newsletter/ Please feel free to write statement/comment etc. to the Apache Newsletter (Issue 1) using ApacheWiki or in this mailing list. Hope to hear from you. http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheNewsletterDrafts/Issue1 Sincerely, -- Tetsuya Kitahata ([EMAIL PROTECTED]) P.S. Jakarta Tomcat Project's Wikipage is here: http://nagoya.apache.org/wiki/apachewiki.cgi?Tomcat Forwarded by Tetsuya Kitahata [EMAIL PROTECTED] --- Original Message --- From:Tetsuya Kitahata [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date:Fri, 01 Aug 2003 15:54:21 +0900 Subject: [Apache Newsletter Draft] News on Jakarta in July, 2003 Hello, All (Jakarta-General Mailing List Subscribers) I am now preparing the 'The Apache Newsletter Issue 1', the first ASF-wide-newsletter of July 2003, which will be published in the middle of August 2003. -- http://www.apache.org/newsletter/ -- This The Apache Newsletter will be published as a result of the outgrowth of the previous Jakarta Newsletter and The Apache Newsletter can now cover all the projects under apache.org including infrastructure, incubator, xml, webservice, et cetra. 'The Apache Newsletter Issue 1' will be appeared at http://www.apache.org/newsletter/200307.html and the editorial deadline will be 00:00 GMT, 9th August. ApacheWiki (http://nagoya.apache.org/wiki/apachewiki.cgi) had been already set up. If you have anything to be added to the ApacheWiki, please go to http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheNewsletterDrafts/Issue1 and fill up what you want to append in. If there's nothing news-worthy on your sub/projects, then please write something you *hope* (e.g. XX project will release FINAL version of XX product in the middle of August, etc etc). If you have been voted in warmly as a new committer in ASF the last month (July) please add your name to the list on ApacheWiki. If your project really want some ADVERTISEMENT (to recruit new comers, etc etc), please write nice and catchy blurb at the advertisement section so that it will attract the readers' attentions. Probably, the former newsletter final draft and newsletter itself (Jakarta Newsletter Issue 9) will give you some hints in writing the articles. cf. http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaNewsletterDrafts/Issue9 http://jakarta.apache.org/site/news/200305.html If you have any questions about this, please send your messages to [EMAIL PROTECTED] This Newsletter will be published as webpage and be announced at [EMAIL PROTECTED] (the ASF-wide announcement list) To subscribe to [EMAIL PROTECTED], please follow this instruction: http://www.apache.org/foundation/mailinglists.html#foundation-announce Hope to hear from many jakarta subprojects!! (If you feel hesitation in writing articles on ApacheWiki, please write your memo in this Jakarta General mailing list or give me a note). http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheNewsletterDrafts/Issue1 Sincerely, -- Tetsuya Kitahata ([EMAIL PROTECTED]) P.S. Also, your voice at Readers' Voice section will be highly appreciated. Contributions from readers are cordially invited !! - Tetsuya Kitahata -- Terra-International, Inc. E-mail: [EMAIL PROTECTED] http://www.terra-intl.com/ (Apache Jakarta Translation, Japanese) http://jakarta.terra-intl.com/ - Original Message Ends - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
