Re: Update Tomcat 5 - 6 .. JDBC driver problem
The Modified directory structure section of
http://tomcat.apache.org/migration.html describes what you need to do. I
created my own ${catalina.home}/lib/shared subdirectory to keep the
out-of-the-box jars separate from my jars.
- Original Message
From: David Smith [EMAIL PROTECTED]
To: Tomcat Users List users@tomcat.apache.org
Sent: Thursday, June 28, 2007 5:29:11 AM
Subject: Re: Update Tomcat 5 - 6 .. JDBC driver problem
In tomcat 6, the new common/lib is simply lib as I understand it. Could
you post your config? The error you originally posted typically
indicates a misconfiguration as opposed to not being able to find the
driver class.
--David
Rene Guenther wrote:
Alas, still the same error.
So you think, that I get this error because tomcat isnt able to find
the .jar file with the MySQL driver? Maybe something changed between
Tomcat 5 and 6 related to context?
Regards
René
On Thu, 28 Jun 2007 18:37:21 +0800
Allen 孙 [EMAIL PROTECTED] wrote:
Put your jars into: *apache-tomcat-6.x.x/lib* will be just fine.
2007/6/28, Rene Guenther [EMAIL PROTECTED]:
Thanks for your reply. Unfortunately I am still getting
the same error with tomcat 6.0.13
Regards
René
On Thu, 28 Jun 2007 02:34:10 -0700 (PDT)
gregory hans [EMAIL PROTECTED] wrote:
try to put your jdbc in your web application
(WEB-INF/LIB/). stop the service first, put the jdbc then
start again...
Rene Guenther [EMAIL PROTECTED] wrote:
Hello,
I am getting the following exception with tomcat 6.0.13:
Cannot create JDBC driver of class '' for connect URL
'null'
This exception I dont get with tomcat 5.5.23
I put the mysql jdbc driver (version 5.x) into
apache-tomcat-x.x.x/common/lib
Anyone knows what the problem could be?
(OS: Linux Debian, Java Version 1.5)
Regards
René
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Sincerely yours 孙
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dynamic form-login-page?
I have run this through the Struts mailing lists and am hoping for a change/solution. Without digging through the servlet spec myself can I ask if the Tomcat implementation is the expected behavior (i.e. no processing of filters on container managed authentication redirects)? Or is it just not specified and left up to the container implementation? Is it worth while opening a bugzilla entry for a configurable Tomcat implementation that wouldn't require a servlet? - Original Message From: Christopher Schultz [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, June 27, 2007 6:03:26 AM Subject: Re: Dynamic form-login-page? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon, Jon Wilmoth wrote: Unfortunately it looks like the Struts 2 architectural change is the culprit after all. That's an interesting side-effect of switching from a servlet to a filter. This is a major bummer to say the least. I'm not sure if the tomcat implementation of the servlet spec is flawed, if there's a gap in the servlet spec or what. I am surprised I'm the first S2 user to run into this. I'd GREATLY appreciate if one of the Tomcat developers monitoring this list could comment on the current implementation of ApplicationDispatcher.invoke and possibly suggest a workaround. I might take this question (back?) to the struts-users list and ask if anyone has successfully done this on servers other than Tomcat. You're kind of in a Tomcat ghetto, here. For example would it be feasible to plug-in a subclass of org.apache.catalina.core.ApplicationDispatcher that had an invoke method that always executed the filter chain even if the servlet was null? I think a better idea might be to see if you can re-create the ActionServlet in struts and use that for selected URL patterns -- essentially going back to old behavior. I wouldn't be surprised if the ActionServlet still exists in some form in struts. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGgmAe9CaO5/Lv0PARAsOAAJ9EGvAb3EhUXLiiI1oVSzAfGU6ZtACfVWKC 0YdaMCIzaavtDOJuyxkECrY= =YqJq -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dynamic form-login-page?
Unfortunately it looks like the Struts 2 architectural change is the culprit after all. After digging through the tomcat 5.5.23 (also present in the most recent 6.0.13 release) code I've come to the conclusion Struts2 actions CAN NOT be used for any of the common web.xml descriptor elements (form-login-page, form-error-page, welcome-file?, other?). Here's a snippet of the javadoc from org.apache.catalina.core.ApplicationDispatcher's invoke method: * strongIMPLEMENTATION NOTE/strong: This implementation assumes that no filters are applied to a forwarded or included resource, because they were already done for the original request. Since S2 is based on a Filter (org.apache.struts2.dispatcher.FilterDispatcher) the container doesn't attempt to invoke the MVC framework. This is a major bummer to say the least. I'm not sure if the tomcat implementation of the servlet spec is flawed, if there's a gap in the servlet spec or what. I am surprised I'm the first S2 user to run into this. I'd GREATLY appreciate if one of the Tomcat developers monitoring this list could comment on the current implementation of ApplicationDispatcher.invoke and possibly suggest a workaround. For example would it be feasible to plug-in a subclass of org.apache.catalina.core.ApplicationDispatcher that had an invoke method that always executed the filter chain even if the servlet was null? Thanks, Jon - Original Message From: Jon Wilmoth [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Monday, June 25, 2007 7:27:29 PM Subject: Re: Dynamic form-login-page? To add some more context to this, I was able to successfully use a Struts 1.x action in my web.xml. Struts 1 was based on a servlet vs the ServletFilter that Struts 2.x is based on. Is there anything about this architectural change that would require a different Tomcat configuration? The default extension for struts also changed from .do to .action. Is there anything about this that requires a special Tomcat configuration for form-login-pages that are handled by Struts2? Any help or working examples of a S2 app deployed on Tomcat 5.5.x or 6.x is greatly appreciated! - Original Message From: Jon Wilmoth [EMAIL PROTECTED] To: users@tomcat.apache.org Sent: Monday, June 25, 2007 2:43:45 PM Subject: Dynamic form-login-page? I'm having problems using FORM authentication and a dynamic login page via Struts 2. I've tried the following web.xml/struts.xml entries with S2.0.8 Tomcat 5.5.23, but get a 404 The requested resource (/mywebapp/login.action) is not available message. login-config auth-methodFORM/auth-method form-login-config form-login-page/login.action/form-login-page form-error-page/loginFailure.action/form-error-page /form-login-config /login-config action name=login result/login.jsp/result /action The login action loads the login.jsp just fine when called directly, but doesn't work when invoked by the servlet container. Instead I see the following in the Tomcat log: Jun-25-2007 10:31:30:865 AM, PDT [DEBUG] (org.apache.catalina.authenticator.FormAuthenticator) - Save request in session '930B154E1AD9BFB1283165CD888441EF' Jun-25-2007 10:31:33:053 AM, PDT [DEBUG] (org.apache.catalina.core.ApplicationDispatcher) - servletPath=/login.action, pathInfo=null, queryString=null, name=null Jun-25-2007 10:31:33:053 AM, PDT [DEBUG] (org.apache.catalina.core.ApplicationDispatcher) - Path Based Forward Jun-25-2007 10:31:33:053 AM, PDT [DEBUG] (org.apache.catalina.core.ApplicationDispatcher) - Disabling the response for futher output I've asked on the Struts2 list if this should be possible to do and the response I got was it definitely should work. I'm wondering if there's a special Tomcat configuration (beyond my webapp's web.xml struts2 filter mapping) I need to add to enable a .action extension being used for form-authentication. Thanks, Jon - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Dynamic form-login-page?
I'm having problems using FORM authentication and a dynamic login page via Struts 2. I've tried the following web.xml/struts.xml entries with S2.0.8 Tomcat 5.5.23, but get a 404 The requested resource (/mywebapp/login.action) is not available message. login-config auth-methodFORM/auth-method form-login-config form-login-page/login.action/form-login-page form-error-page/loginFailure.action/form-error-page /form-login-config /login-config action name=login result/login.jsp/result /action The login action loads the login.jsp just fine when called directly, but doesn't work when invoked by the servlet container. Instead I see the following in the Tomcat log: Jun-25-2007 10:31:30:865 AM, PDT [DEBUG] (org.apache.catalina.authenticator.FormAuthenticator) - Save request in session '930B154E1AD9BFB1283165CD888441EF' Jun-25-2007 10:31:33:053 AM, PDT [DEBUG] (org.apache.catalina.core.ApplicationDispatcher) - servletPath=/login.action, pathInfo=null, queryString=null, name=null Jun-25-2007 10:31:33:053 AM, PDT [DEBUG] (org.apache.catalina.core.ApplicationDispatcher) - Path Based Forward Jun-25-2007 10:31:33:053 AM, PDT [DEBUG] (org.apache.catalina.core.ApplicationDispatcher) - Disabling the response for futher output I've asked on the Struts2 list if this should be possible to do and the response I got was it definitely should work. I'm wondering if there's a special Tomcat configuration (beyond my webapp's web.xml struts2 filter mapping) I need to add to enable a .action extension being used for form-authentication. Thanks, Jon - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dynamic form-login-page?
To add some more context to this, I was able to successfully use a Struts 1.x action in my web.xml. Struts 1 was based on a servlet vs the ServletFilter that Struts 2.x is based on. Is there anything about this architectural change that would require a different Tomcat configuration? The default extension for struts also changed from .do to .action. Is there anything about this that requires a special Tomcat configuration for form-login-pages that are handled by Struts2? Any help or working examples of a S2 app deployed on Tomcat 5.5.x or 6.x is greatly appreciated! - Original Message From: Jon Wilmoth [EMAIL PROTECTED] To: users@tomcat.apache.org Sent: Monday, June 25, 2007 2:43:45 PM Subject: Dynamic form-login-page? I'm having problems using FORM authentication and a dynamic login page via Struts 2. I've tried the following web.xml/struts.xml entries with S2.0.8 Tomcat 5.5.23, but get a 404 The requested resource (/mywebapp/login.action) is not available message. login-config auth-methodFORM/auth-method form-login-config form-login-page/login.action/form-login-page form-error-page/loginFailure.action/form-error-page /form-login-config /login-config action name=login result/login.jsp/result /action The login action loads the login.jsp just fine when called directly, but doesn't work when invoked by the servlet container. Instead I see the following in the Tomcat log: Jun-25-2007 10:31:30:865 AM, PDT [DEBUG] (org.apache.catalina.authenticator.FormAuthenticator) - Save request in session '930B154E1AD9BFB1283165CD888441EF' Jun-25-2007 10:31:33:053 AM, PDT [DEBUG] (org.apache.catalina.core.ApplicationDispatcher) - servletPath=/login.action, pathInfo=null, queryString=null, name=null Jun-25-2007 10:31:33:053 AM, PDT [DEBUG] (org.apache.catalina.core.ApplicationDispatcher) - Path Based Forward Jun-25-2007 10:31:33:053 AM, PDT [DEBUG] (org.apache.catalina.core.ApplicationDispatcher) - Disabling the response for futher output I've asked on the Struts2 list if this should be possible to do and the response I got was it definitely should work. I'm wondering if there's a special Tomcat configuration (beyond my webapp's web.xml struts2 filter mapping) I need to add to enable a .action extension being used for form-authentication. Thanks, Jon - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
v5.5.x default context support outside of server.xml
I've tried unsuccessfully to deploy my webapp as the default context for my host using a context defined outside of the server.xml (individual files (with a .xml extension) in the $CATALINA_HOME/conf/[enginename]/[hostname]/ directory) as strongly recommended in http://tomcat.apache.org/tomcat-5.5-doc/config/context.html*. I searched the mailing list archives and found a thread on this subject that ended without any resolution. There seems to be some conflict between different sections of the context config documentation** that leads me to believe it's not possible to specify a default virtual host's context with an empty string path attribute for a context. Is this true? If not, please let me know what I'm missing. Thanks, Jon * Please note that for tomcat 5, unlike tomcat 4.x, it is NOT recommended to place Context elements directly in the server.xml file. Instead, put them in the META-INF/context.xml directory of your WAR file or the conf directory as described above. ** a Context that has an empty PATH attribute will become the default web application for the virtual host. and The value of this field [path] must not be set except when statically defining a Context in server.xml, as it will be infered from the filenames used for either the .xml context file or the docBase. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: v5.5.x default context support outside of server.xml
Thanks. I renamed my stand-alone context definition conf/[engine]/[host]/ROOT.xml and it worked. FYI...I've asked the developer list about the possibility of respecting the empty string path attribute value regardless of where the context is defined and/or update the documentation to capture this specific naming requirement for specifying the defining the host's default context (aka webapp). - Original Message From: Caldarale, Charles R [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Thursday, October 12, 2006 9:06:00 AM Subject: RE: v5.5.x default context support outside of server.xml From: Jon Wilmoth [mailto:[EMAIL PROTECTED] Subject: v5.5.x default context support outside of server.xml There seems to be some conflict between different sections of the context config documentation that leads me to believe it's not possible to specify a default virtual host's context with an empty string path attribute for a context. The doc is a bit obtuse in this area, since it wasn't fully revised from previous levels. To specify the default app, you must first delete the existing webapps/ROOT directory, then install your app in webapps/ROOT (or webapps/ROOT.war) or put your Context element in conf/[engine]/[host]/ROOT.xml. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
