DO NOT REPLY [Bug 38329] New: - isapi_redirect.dll returns application not available when application stopped in Manager
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38329. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38329 Summary: isapi_redirect.dll returns application not available when application stopped in Manager Product: Tomcat 5 Version: 5.5.7 Platform: PC OS/Version: Windows Server 2003 Status: NEW Severity: normal Priority: P2 Component: Connector:AJP AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] When using the load balancer worker and on one of the clustered host the application is stopped (via Manager or the like) isapi_redirect.dll (version 1.2.15) will return application unavailable. I would like to suggest an enhancement that isapi_redirect.dll check other host in the worker.list before returning this message. Kevin -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
an example of Users element
Furthermore, the original Realm element could be moved into Users element. The Users element should be able to include several Realm elements, such as one for Database, another one for LDAP, even one more in tomcat-usrs.xml format. Examples: Users keystoreFile=xx\.keystore scope=web-app Realm memory realm user username=owner password=jack roles=owner/ user username=xxx password=jack roles=aaa/ user username=yyy password=jack roles=bbb/ /Realm Realm memory realm src=users.xml / Realm jdbc config/ Realm jndi config/ Realm ldap config/ /Users The certificate of this web-app will be included in the context if it has one. When the web-app is running, it might have to access its own certificate, too. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
The original Realm
Terry Zhou [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Tomcat does have a realm in different level(Engine,Host,Webapp) for security. Check http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html Personally, I believe that the original Realm mixed up the authentication authorization. It should be seperated into Authorizer UserRealm. The reason why I suggest to add user package is that the source code of the original implementation is not easy to be integrated into the source code of web-app. Principal is web-app dependant HttpServletRequest.getRemoreUser() returns the name of the user of the request. When we use certificates, the return object is not well defined since there is no name here. HttpServletRequest.getUserPrincipal() doesn't have a good definition, either. It just says the principal name of the current authenticated user. So, what is in the returned Principal object is up to the container, too. However, the reason to have such a method is to let the web-app can access it. And so, the returned Principal should be web-app dependent. We had better to ask the web-app to implement the Principal if the web-app care who the user is. In such a case, we had better leave the authentication to the web-app (in UserContext), too. If the web-app doesn't care at all, then we can use GenericPrincipal as the current implementation. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
UserManager managing UserContexts
Terry Zhou [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Tomcat does have a realm in different level(Engine,Host,Webapp) for security. Check http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html The document really says that, but as I tried, the result is disappointing. It just doesn't work. I guess the document might just give the direction to go. If it works for you please let me know. I added this into context.xml: Realm className=org.apache.catalina.realm.MemoryRealm pathname=conf/Catalina/localhost/dusers.xml /Realm Furthermore, I want to have a UserContext component. The users' information might be store in several places. Any classes just have to deal with UserContext, all details will be encapsulated inside the UserContext such as access keystore, truststore, or database, ldap. And single signon will become more logic, easier to controle. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Response not flushed before RD.forward() returns
Jan Luehe wrote:
Bill Barker wrote On 01/19/06 18:11,:
-Original Message-
From: Jan Luehe [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 19, 2006 5:57 PM
To: tomcat-dev@jakarta.apache.org
Subject: Response not flushed before RD.forward() returns
Consider the following code snippet of a servlet's service() method:
public class DispatcherServlet extends HttpServlet {
public void service(HttpServletRequest req,
HttpServletResponse res)
throws IOException, ServletException {
request.getRequestDispatcher(/target).forward(request, response);
try {
Thread.currentThread().sleep(6);
} catch (Exception ex) { }
}
where target prints some output to the response.
The code currently returns the output printed by target only after
DispatcherServlet's service() method has finished, instead of right
before RD.forward() returns.
This seems to be in violation of the Servlet Spec, which has this:
SRV.8.4 (The Forward Method):
Before the forward() method of the RequestDispatcher interface
returns, the response content must be sent and committed, and closed
by the servlet container.
The code at the end of o.a.c.core.ApplicationDispatcher.doForward()
looks like this:
// This is not a real close in order to support error
processing
if ( log.isDebugEnabled() )
log.debug( Disabling the response for futher output);
if (response instanceof ResponseFacade) {
((ResponseFacade) response).finish();
} else {
// Servlet SRV.6.2.2. The Resquest/Response may have been
wrapped
// and may no longer be instance of RequestFacade
if (log.isDebugEnabled()){
log.debug( The Response is vehiculed using
a wrapper:
+ response.getClass().getName() );
}
// Close anyway
try {
PrintWriter writer = response.getWriter();
writer.close();
} catch (IllegalStateException e) {
try {
ServletOutputStream stream =
response.getOutputStream();
stream.close();
} catch (IllegalStateException f) {
;
} catch (IOException f) {
;
}
} catch (IOException e) {
;
}
}
In the above code sample, response will be an instance of
ResponseFacade, meaning it will be suspended instead of being flushed
and closed right away.
Does anyone remember why the response instanceof ResponseFacade
check is there? I would have expected the else case to always be
executed.
Without ever actually having looked at ResponseFacade, I'd always assumed
that ResponseFacade.finish called Response.finishResponse. And I would have
been wrong ;-). This would have done the commit/send/close properly.
I don't have time right now to dig through the SVN logs to see why it's this
way, but suspended doesn't really look good enough to satisfy the spec.
Yes. I'm afraid it's been like this forever.
And it has to stay like this forever too: this needs to get some post
processing done (like error pages, etc). If this person wants to flush,
let him call flush.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35853] - Make JkMount compatible with servlet-mapping/url-pattern in web.xml
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35853. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35853 --- Additional Comments From [EMAIL PROTECTED] 2006-01-20 12:32 --- Right. The problem is that mod_jk needs to follow the common denominator of the web server, not servlet-api. Many OS-es does not allow case sensitivity, so the lowrecase is that common denomitator. It is something that you'll have to live with :) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Response not flushed before RD.forward() returns
Bill Barker wrote: Without ever actually having looked at ResponseFacade, I'd always assumed that ResponseFacade.finish called Response.finishResponse. And I would have been wrong ;-). This would have done the commit/send/close properly. It has always been like this: processing for error pages and status report pages has to occur later. It's the same for other similarly worded mechanisms, such as sendError, sendRedirect, etc. I don't have time right now to dig through the SVN logs to see why it's this way, but suspended doesn't really look good enough to satisfy the spec. It is the best and only acceptable behavior from a usability standpoint, however. There are other areas where I think implementing the letter of the specification turned out completely wrong, such as the charset handling that Jan implemented some time before (aka, forcing the addition of a charset even if none was specified whenever a writer is being used). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38332] New: - Documented AJP Connector configuration for pending request queue size in error
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38332. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38332 Summary: Documented AJP Connector configuration for pending request queue size in error Product: Tomcat 5 Version: 5.5.9 Platform: Other URL: http://tomcat.apache.org/tomcat-5.5-doc/config/ajp.html OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Connector:AJP AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] In configuring my AJP13 connector between Tomcat 5.5.9 and Apache2 (on Red Hat Enterprise 3 with Java 1.5) I am finding that the attribute named backlog seems to have no affect, while the attribute named acceptCount does. In my original load/configuration testing for deployment I had copied existing Connector configuration in the server.xml file from other defined Connectors. These use the acceptCount attribute name to manipulate the size of the pending request queue size. However, the documentation for this same configuation specifies the use of backlog, which does not appear to have an effect on performance. I have inquired the users group about this topic, but have had no reply. Since I am seeing a performance change using acceptCount, I can only assume at this time that the documentation is in error. See http://tomcat.apache.org/tomcat-5.5-doc/config/ajp.html -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 37859] - add a reliable real_remote_socket and real_remote_port attribute to requets
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37859. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37859 [EMAIL PROTECTED] changed: What|Removed |Added Severity|major |enhancement Status|RESOLVED|REOPENED Resolution|INVALID | Summary|getServerPort() not reliable|add a reliable ||real_remote_socket and ||real_remote_port attribute ||to requets Version|5.5.9 |Unknown --- Additional Comments From [EMAIL PROTECTED] 2006-01-20 19:00 --- ok, understood - especially if there is a proxy in-between you don't want the proxy address but the address and port of the original requestor. However, wouldn't it be useful, to add e.g. in org.apache.coyote.http11.Http11Processor a request.setAttribute(javax.servlet.request.real_remote_host, socket. getRemoteSocketAddress()); //or socket.getInetAddress() ? and a request.setAttribute(javax.servlet.request.real_remote_port, socket.getPort()) ? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Security Manager
I tried running 5.5.14 with -security specified and got this error:
Using Security Manager
Listening for transport dt_socket at address: 7100
Could not load Logmanager org.apache.juli.ClassLoaderLogManager
java.security.AccessControlException: access denied
(java.lang.RuntimePermission
shutdownHooks)
at
java.security.AccessControlContext.checkPermission(AccessControlConte
xt.java:264)
at
java.security.AccessController.checkPermission(AccessController.java:
427)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
My solution was to add:
grant codeBase file:${catalina.home}/bin/tomcat-juli.jar {
permission java.security.AllPermission;
};
To the catalina.policy file. Is this correct?
George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 37859] - add a reliable real_remote_socket and real_remote_port attribute to requets
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37859. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37859 --- Additional Comments From [EMAIL PROTECTED] 2006-01-20 19:21 --- In the case of proxies - that is what proxyName and proxyPort are for: http://tomcat.apache.org/tomcat-5.5-doc/config/http.html -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Security Manager
It also seems to me the policy file should have:
grant codeBase file:${catalina.base}/shared/- {
permission java.security.AllPermission;
};
George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
-Original Message-
From: George Sexton [mailto:[EMAIL PROTECTED]
Sent: Friday, January 20, 2006 11:14 AM
To: 'Tomcat Developers List'
Subject: Security Manager
I tried running 5.5.14 with -security specified and got this error:
Using Security Manager
Listening for transport dt_socket at address: 7100
Could not load Logmanager org.apache.juli.ClassLoaderLogManager
java.security.AccessControlException: access denied
(java.lang.RuntimePermission
shutdownHooks)
at
java.security.AccessControlContext.checkPermission(AccessControlConte
xt.java:264)
at
java.security.AccessController.checkPermission(AccessController.java:
427)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
My solution was to add:
grant codeBase file:${catalina.home}/bin/tomcat-juli.jar {
permission java.security.AllPermission;
};
To the catalina.policy file. Is this correct?
George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
-
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: Security Manager
Yet more. It seems by specification (SRV.3.7.1)
grant {
permission java.io.FilePermission ${catalina.base}/temp/-, read,
write,delete;
permission java.util.PropertyPermission javax.servlet.context.tempdir,
read;
};
Really should be set so.
George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
-Original Message-
From: George Sexton [mailto:[EMAIL PROTECTED]
Sent: Friday, January 20, 2006 11:14 AM
To: 'Tomcat Developers List'
Subject: Security Manager
I tried running 5.5.14 with -security specified and got this error:
Using Security Manager
Listening for transport dt_socket at address: 7100
Could not load Logmanager org.apache.juli.ClassLoaderLogManager
java.security.AccessControlException: access denied
(java.lang.RuntimePermission
shutdownHooks)
at
java.security.AccessControlContext.checkPermission(AccessControlConte
xt.java:264)
at
java.security.AccessController.checkPermission(AccessController.java:
427)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
My solution was to add:
grant codeBase file:${catalina.home}/bin/tomcat-juli.jar {
permission java.security.AllPermission;
};
To the catalina.policy file. Is this correct?
George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
-
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]
DO NOT REPLY [Bug 38335] New: - Tomcat fails to shut down in response to shutdown.sh script
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38335. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38335 Summary: Tomcat fails to shut down in response to shutdown.sh script Product: Tomcat 5 Version: 5.5.12 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Connector:Coyote AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Tomcat fails to shut down in response to shutdown.sh script. Hangs, eventually throws exception with dreaded Protocol handler pause failed message. I have tried both values for LD_ASSUME_KERNEL as per release notes. It changes the behavior slightly, but the problem remains (more below). Environment: - A freshly built updated fedora RC4 install: 2.6.14-1.1656_FC4 - A completely unmodified Tomcat Version 5.5.12 - I untarred it and ran it. - Sun's jdk1.5.0_06 Repro: 1) run startup.sh 2) hit localhost:8080 in browser, works 3) run shutdown.sh 4) log shows: Jan 19, 2006 11:08:27 PM org.apache.coyote.http11.Http11BaseProtocol pause INFO: Pausing Coyote HTTP/1.1 on http-8080 It hangs for a minute or so, then throws: Jan 19, 2006 11:03:48 PM org.apache.catalina.connector.Connector pause SEVERE: Protocol handler pause failed java.net.ConnectException: Connection timed out at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) at java.net.Socket.connect(Socket.java:507) at java.net.Socket.connect(Socket.java:457) at java.net.Socket.init(Socket.java:365) at java.net.Socket.init(Socket.java:207) at org.apache.jk.common.ChannelSocket.unLockSocket(ChannelSocket.java:463) at org.apache.jk.common.ChannelSocket.pause(ChannelSocket.java:270) at org.apache.jk.server.JkMain.pause(JkMain.java:679) at org.apache.jk.server.JkCoyoteHandler.pause(JkCoyoteHandler.java:162) at org.apache.catalina.connector.Connector.pause(Connector.java:1031) at org.apache.catalina.core.StandardService.stop(StandardService.java:491) at org.apache.catalina.core.StandardServer.stop(StandardServer.java:714) at org.apache.catalina.startup.Catalina.stop(Catalina.java:586) at org.apache.catalina.startup.Catalina.start(Catalina.java:561) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:275) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) Interestingly enough, lsof shows different behaviors depending on the value of the LD_ASSSUME_KERNEL variable. With no variable set, # lsof -P | grep java | grep 8080 java 6555 chris 10u IPv6 329120 TCP *:8080 (LISTEN) setting LD_ASSUME_KERNEL=2.2.5 results in about 40 threads listening on the port (in the hung state): # lsof -P | grep java | grep 8080 java 6652 chris 12u IPv6 331547 TCP *:8080 (LISTEN) java 6653 chris 12u IPv6 331547 TCP *:8080 (LISTEN) ...etc setting it to 2.4.1 yields the more entertaining: # lsof -P | grep java | grep 8080 java 6779 chris mem REG 253,0 14656364980808 /lib/obsolete/linuxthreads/i686/libc-2.3.5.so java 6779 chris 12u IPv6 334251 TCP *:8080 (LISTEN) java 6780 chris mem REG 253,0 14656364980808 /lib/obsolete/linuxthreads/i686/libc-2.3.5.so java 6780 chris 12u IPv6 334251 TCP *:8080 (LISTEN) ... but the behavior is the same. Surely tomcat on Fedora can't be this broken out of the box, can it? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 37859] - add a reliable real_remote_socket and real_remote_port attribute to requets
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37859. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37859 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2006-01-20 23:02 --- (In reply to comment #2) ok, understood - especially if there is a proxy in-between you don't want the proxy address but the address and port of the original requestor. However, wouldn't it be useful, to add e.g. in org.apache.coyote.http11.Http11Processor a request.setAttribute(javax.servlet.request.real_remote_host, socket. getRemoteSocketAddress()); //or socket.getInetAddress() ? and a request.setAttribute(javax.servlet.request.real_remote_port, socket.getPort()) ? Seems pretty useless, since it simply duplicates what is already available via request.getRemoteAddr() and request.getRemotePort(). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38337] New: - GlobalNamingResource will not allow commercial DataSource drivers
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38337. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38337 Summary: GlobalNamingResource will not allow commercial DataSource drivers Product: Tomcat 5 Version: Unknown Platform: All OS/Version: Windows Server 2003 Status: NEW Severity: critical Priority: P2 Component: Unknown AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] We have the same datasource configurations for three webapps that we host on the same server. We want to merge those configurations into one place with GlobalNamingResource. The exact same configuration in the Context element will not work with the GlobalNamingResource element. Here is an example Resource config: !-- NOTE: there are more configuration settings but this is the part that is important -- Resource name=jdbc/cableds auth=Container type=com.jnetdirect.jsql.JSQLPoolingDataSource factory=org.apache.naming.factory.BeanFactory serverName=ntncdsql3s portNumber=1433/ When that configuration lives inside a Context element everything works as expected. When it lives inside a GlobalNamingResource Tomcat tries to use the DBCP driver with the exception thrown: org.apache.tomcat.dbcp.dbcp.SQLNestedException: Canot create JDBC driver of class '' for connect URL 'null' stack trace omitted We do not want to use DBCP, we want to use the JNetDirect pooling drivers we paid for. Why is this happening? We are using Tomcat 5.5.12 (sorry there was no entry for it here) on Windows. This seriously affects our deployment model as we will need to use the same connections for server authentication in the very near future. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 7831] - [PATCH] JNDIRealm does not work with CLIENT-CERT auth method
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=7831. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=7831 --- Additional Comments From [EMAIL PROTECTED] 2006-01-20 21:37 --- I'm happy to look at adding CLIENT-CERT support to the JNDI realm based on your proposal. If I put together a patch are you willing to test it? If yes, I can use 5.5.x or 4.1.x. Which would you prefer? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38335] - Tomcat fails to shut down in response to shutdown.sh script
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38335. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38335 --- Additional Comments From [EMAIL PROTECTED] 2006-01-20 21:52 --- NOT reproducible using same JDK and tomcat versions on Fedora 3 install. same java: java version 1.5.0_06 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) same tomcat: Apache Tomcat/5.5.12 different kernel: Linux 2.6.12-1.1381_FC3 different glibc. this box works: $ rpm -qa | grep -i libc libcap-1.10-20 glibc-2.3.5-0.fc3.1 glibc-devel-2.3.5-0.fc3.1 libcap-devel-1.10-20 glibc-kernheaders-2.4-9.1.87 glibc-common-2.3.5-0.fc3.1 glibc-headers-2.3.5-0.fc3.1 this box doesn't work: $ rpm -qa | grep -i libc glibc-common-2.3.5-10.3 libcroco-0.6.0-5 libcap-devel-1.10-22 libcroco-devel-0.6.0-5 glibc-2.3.5-10.3 glibc-devel-2.3.5-10.3 glibc-kernheaders-2.4-9.1.94 glibc-2.3.5-10 libcap-1.10-22 glibc-headers-2.3.5-10.3 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Please give me some responses!!
Hi, guys, please give me some responses! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r370985 - in /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator: BasicAuthenticator.java DigestAuthenticator.java
Author: billbarker
Date: Fri Jan 20 21:21:15 2006
New Revision: 370985
URL: http://svn.apache.org/viewcvs?rev=370985view=rev
Log:
Use sendError instead of setStatus to send the 401 code.
This is per section 9.9.2 of the spec. It doesn't seem to cause any problems
in my testing, and it also allows (the mostly useless) custom 401 page.
Modified:
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator/BasicAuthenticator.java
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator/DigestAuthenticator.java
Modified:
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator/BasicAuthenticator.java
URL:
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator/BasicAuthenticator.java?rev=370985r1=370984r2=370985view=diff
==
---
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator/BasicAuthenticator.java
(original)
+++
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator/BasicAuthenticator.java
Fri Jan 20 21:21:15 2006
@@ -201,7 +201,7 @@
}
authenticateCC.append('\');
authenticate.toChars();
-response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
+response.sendError(HttpServletResponse.SC_UNAUTHORIZED);
//response.flushBuffer();
return (false);
Modified:
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator/DigestAuthenticator.java
URL:
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator/DigestAuthenticator.java?rev=370985r1=370984r2=370985view=diff
==
---
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator/DigestAuthenticator.java
(original)
+++
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator/DigestAuthenticator.java
Fri Jan 20 21:21:15 2006
@@ -189,7 +189,7 @@
String nOnce = generateNOnce(request);
setAuthenticateHeader(request, response, config, nOnce);
-response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
+response.sendError(HttpServletResponse.SC_UNAUTHORIZED);
// hres.flushBuffer();
return (false);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: Help :: Running Servlet Prog. in Apache HTTP Server -reg
Hi Everybody, Plz Help me How to use Servlets with Apache I found there is an additional module named mod_jk for Apache to do the interaction between the Apache HTTP Webserver and the Tomcat's Catalina Container. I can't find info about the usage of mod_jk and conf details Plz help me as soon as possible. I'm inneed of it very urgently to continue with my academic project Thank u Everybody for considering this mail Regret my mistake if any Awaiting for the reply eagerly Thank u Urs.. GhaneshMV
DO NOT REPLY [Bug 7831] - [PATCH] JNDIRealm does not work with CLIENT-CERT auth method
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=7831. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=7831 --- Additional Comments From [EMAIL PROTECTED] 2006-01-21 07:50 --- Cool, Thanks! For sure I will test it. I prefer 5.5.x -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Re: Response not flushed before RD.forward() returns]
Jan Luehe wrote: Right, but flush does nothing once the response has been suspended. In addition, consider the case where a request has been forward-dispatched into a foreign context. If the target servlet in the foreign context has set a status code on the response, and the response is being suspended before returning from the RD.forward(), the status code will be mapped to an error page using the mappings of the *origin* context as the response travels through the origin context's pipeline (and error valve) on the way out. The origin and target contexts may map the same status code to different error pages, or the origin context may not even contain any mapping for the given status code. In any case, I would find it confusing for the origin context's mappings to be used, since a RD.forward() is supposed to transfer control to the target. I think it is cleaner for the response to be committed before returning from RD.forward(), at the cost of not being mapped to any error page. This is better than mapping the response to a wrong error page. Or we could suspend the response when the origin and target servlets share the same context, and commit it when they reside in different contexts? Clearly, this would require a spec clarification. -1 Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
