RE: isapi_redirector2 build using static APR
IMO it would be better to build the non Apache connectors using static APR builds. That way we don't need to ship the extra dll's with the connector. The dll builds are ok for mod_jk2 since Apache is already there. +1 (speaking more as a user than a developer these days ...) It would be quite easy to do that adding /D APR_DECLARE_STATIC /D APU_DECLARE_STATIC, linking with apr.lib and aprutil.lib instead of libapr and libaprutil -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10356] New: - deploy task from catalina-ant fails
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=10356. 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=10356 deploy task from catalina-ant fails Summary: deploy task from catalina-ant fails Product: Tomcat 4 Version: 4.0.4 Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Webapps:Administration AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hello, Please suggest with a following behave: when running tomcat deploy task from ant (catalina-ant.jar) - it fails to install/deploy war file, when I cutpaste the war file URL and run it from browser - it works. here is an URL example: property name=warfile value=jar:file://d:/development/song/dev/song/tngappserver.war!/ Please suggest. thanks D:\development\song\dev\songant -f deploy.xml install Buildfile: deploy.xml install: FAIL - Encountered exception java.net.MalformedURLException: java.lang.NumberFor matException: file: BUILD FAILED D:\development\song\dev\song\deploy.xml:48: FAIL - Encountered exception java.ne t.MalformedURLException: java.lang.NumberFormatException: file: Total time: 0 seconds -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/jni jk_jni_aprImpl.c
mturk 2002/06/30 02:57:38 Modified:jk/native2/jni jk_jni_aprImpl.c Log: Removed the jkStatus native call. Use the jkSetAttribute for TC startup signaling. Revision ChangesPath 1.39 +15 -13jakarta-tomcat-connectors/jk/native2/jni/jk_jni_aprImpl.c Index: jk_jni_aprImpl.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/jni/jk_jni_aprImpl.c,v retrieving revision 1.38 retrieving revision 1.39 diff -u -r1.38 -r1.39 --- jk_jni_aprImpl.c 29 Jun 2002 07:44:04 - 1.38 +++ jk_jni_aprImpl.c 30 Jun 2002 09:57:38 - 1.39 @@ -98,6 +98,8 @@ #define JK_GET_REGION 1 #define JK_GET_BYTE_ARRAY_ELEMENTS 2 #define JK_DIRECT_BUFFER_NIO 3 +#define JNI_TOMCAT_STARTING 1 +#define JNI_TOMCAT_STARTED 2 static int arrayAccessMethod=JK_GET_REGION; void JK_METHOD jk2_env_setAprPool( jk_env_t *env, void *aprPool ); @@ -301,6 +303,19 @@ char *value=(char *)(*jniEnv)-GetStringUTFChars(jniEnv, valueJ, 0); int rc=JK_OK; +/* XXX need to find a way how to set this to channel:jni component + * instead of global variable. + */ +if(env == NULL || component == NULL) { +if (strcmp(name, channel:jni) == 0) { +if (strcmp(value, starting) == 0) +jk_jni_status_code = JNI_TOMCAT_STARTING; +else if (strcmp(value, done) == 0) + jk_jni_status_code = JNI_TOMCAT_STARTED; +} +return JK_OK; +} + if( component-setAttribute ==NULL ) return JK_OK; @@ -505,15 +520,6 @@ return rc; } -/* -*/ -JNIEXPORT void JNICALL -Java_org_apache_jk_apr_AprImpl_jkStatus - (JNIEnv *jniEnv, jobject o, jint statusCode ) -{ -jk_jni_status_code = statusCode; -} - static JNINativeMethod org_apache_jk_apr_AprImpl_native_methods[] = { { initialize, ()I, @@ -562,10 +568,6 @@ { jkRecycle, (JJ)V, Java_org_apache_jk_apr_AprImpl_jkRecycle -}, -{ -jkStatus, (I)V, -Java_org_apache_jk_apr_AprImpl_jkStatus }, }; -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/apr AprImpl.java
mturk 2002/06/30 02:59:02 Modified:jk/java/org/apache/jk/apr AprImpl.java Log: Removed the jkStatus native call. Use the jkSetAttribute for TC startup signaling. Revision ChangesPath 1.23 +1 -11 jakarta-tomcat-connectors/jk/java/org/apache/jk/apr/AprImpl.java Index: AprImpl.java === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/apr/AprImpl.java,v retrieving revision 1.22 retrieving revision 1.23 diff -u -r1.22 -r1.23 --- AprImpl.java 29 Jun 2002 07:43:24 - 1.22 +++ AprImpl.java 30 Jun 2002 09:59:02 - 1.23 @@ -119,9 +119,6 @@ */ public native void jkRecycle(long xEnv, long endpointP); -/* Send a TC status code to the server */ -public static native void jkStatus(int code); - // Called from C // XXX Check security, add guard or other protection // It's better to do it the other way - on init 'push' AprImpl into @@ -166,6 +163,7 @@ loadNative(); initialize(); +jkSetAttribute(0, 0, channel:jni, starting); } catch( Throwable t ) { throw new IOException( t.getMessage() ); } @@ -183,14 +181,6 @@ jniMode=true; } -public static void jniStatus(int code) throws IOException { -try { -jkStatus( code); -} catch( Throwable t) { -throw new IOException( t.getMessage() ); -} -} - /** This method of loading the libs doesn't require setting * LD_LIBRARY_PATH. Assuming a 'right' binary distribution, * or a correct build all files will be in their right place. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/apr TomcatStarter.java
mturk 2002/06/30 02:59:11 Modified:jk/java/org/apache/jk/apr TomcatStarter.java Log: Removed the jkStatus native call. Use the jkSetAttribute for TC startup signaling. Revision ChangesPath 1.10 +3 -4 jakarta-tomcat-connectors/jk/java/org/apache/jk/apr/TomcatStarter.java Index: TomcatStarter.java === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/apr/TomcatStarter.java,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- TomcatStarter.java29 Jun 2002 07:43:38 - 1.9 +++ TomcatStarter.java30 Jun 2002 09:59:11 - 1.10 @@ -15,13 +15,12 @@ public class TomcatStarter implements Runnable { Class c; String args[]; +AprImpl apr = new AprImpl(); public static String mainClasses[]={ org.apache.tomcat.startup.Main, org.apache.catalina.startup.BootstrapService, org.apache.catalina.startup.Bootstrap}; -public static final int TC_STARTING=1; -public static final int TC_STARTED=2; // If someone has time - we can also guess the classpath and do other // fancy guessings. @@ -71,12 +70,12 @@ public void run() { System.err.println(Starting + c.getName()); try { -AprImpl.jniStatus(TC_STARTING); Class argClass=args.getClass(); Method m=c.getMethod( main, new Class[] {argClass} ); m.invoke( c, new Object[] { args } ); -AprImpl.jniStatus(TC_STARTED); System.out.println(TomcatStarter: Done); +if (apr.isLoaded()) +apr.jkSetAttribute(0, 0, channel:jni, done); } catch( Throwable t ) { t.printStackTrace(System.err); } -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi isapi_redirector2.reg
mturk 2002/06/30 03:11:11 Modified:jk/native2/server/isapi isapi_redirector2.reg Log: Fix the workerFile key to workersFile Revision ChangesPath 1.3 +1 -1 jakarta-tomcat-connectors/jk/native2/server/isapi/isapi_redirector2.reg Index: isapi_redirector2.reg === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/isapi/isapi_redirector2.reg,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- isapi_redirector2.reg 19 May 2002 21:17:10 - 1.2 +++ isapi_redirector2.reg 30 Jun 2002 10:11:11 - 1.3 @@ -3,5 +3,5 @@ [HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Jakarta Isapi Redirector\2.0] serverRoot=E:\\tomcat\\jakarta-tomcat\\build\\tomcat extensionUri=/jakarta/isapi_redirector2.dll -workerFile=E:\\tomcat\\jakarta-tomcat\\build\\tomcat\\conf\\workers2.properties +workersFile=E:\\tomcat\\jakarta-tomcat\\build\\tomcat\\conf\\workers2.properties -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10357] New: - java.lang.IllegalArgumentException: Short Read
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=10357. 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=10357 java.lang.IllegalArgumentException: Short Read Summary: java.lang.IllegalArgumentException: Short Read Product: Tomcat 3 Version: 3.2.3 Final Platform: PC OS/Version: Windows NT/2K Status: UNCONFIRMED Severity: Blocker Priority: Other Component: Servlet AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This happens when i try to use the request dispatcher from my servlet to a jsp java.lang.IllegalArgumentException: Short Read at javax.servlet.http.HttpUtils.parsePostData(HttpUtils.java:238) at org.apache.tomcat.util.RequestUtil.readFormData(RequestUtil.java:101) at org.apache.tomcat.core.RequestImpl.handleParameters (RequestImpl.java:719) at org.apache.tomcat.core.RequestImpl.getParameterNames (RequestImpl.java:264) at org.apache.tomcat.facade.RequestDispatcherImpl.doInclude (RequestDispatcherImpl.java:375) at org.apache.tomcat.facade.RequestDispatcherImpl.include (RequestDispatcherImpl.java:270) at com.project.athena.navigation.Athena_PortletDisplay.renderBody (Athena_PortletDisplay.java:109) at com.project.athena.navigation.Athena_PortletDisplay.render (Athena_PortletDisplay.java:74) at com.project.athena.navigation.Athena_PortletDisplayProxy.render (Athena_PortletDisplayProxy.java:68) at oracle.portal.provider.v1.http.ServletProviderResponse.showPortlet (ServletProviderResponse.java:524) at oracle.portal.provider.v1.http.HttpProvider.dispatchProviderAction (HttpProvider.java:660) at oracle.portal.provider.v1.http.HttpProvider.service (HttpProvider.java:390) at com.project.athena.navigation.Athena_PortalManager.service (Athena_PortalManager.java:42) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService (ServletWrapper.java:405) at org.apache.tomcat.core.Handler.service(Handler.java:287) at org.apache.tomcat.core.ServletWrapper.service (ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService (ContextManager.java:812) at org.apache.tomcat.core.ContextManager.service (ContextManager.java:758) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection (HttpConnectionHandler.java:213) at org.apache.tomcat.service.TcpWorkerThread.runIt (PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run (ThreadPool.java:501) at java.lang.Thread.run(Thread.java:484) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: isapi_redirector2 build using static APR
De: Mladen Turk [mailto:[EMAIL PROTECTED]] Enviado el: 30 de junio de 2002 7:28 hmmm, this will force us to make a binary everytime Apache2 has a release too? in this case -1, if not +1 Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: isapi_redirector2 build using static APR
-Original Message- From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] Sent: 30. lipanj 2002 18:45 To: '[EMAIL PROTECTED]' Subject: RE: isapi_redirector2 build using static APR De: Mladen Turk [mailto:[EMAIL PROTECTED]] Enviado el: 30 de junio de 2002 7:28 hmmm, this will force us to make a binary everytime Apache2 has a release too? in this case -1, if not +1 Only if the APR changes itself (in the API way), but then we have to rebuild it in any case. All the Apache utils itself use the static APR if they don't need to go to the httpd directly. Since we are using apr in the IIS connector only as a common library for things like pools, tables, network io, etc. The only rebuild needed would be in the case of some sort of discovered bug. The apr itself is quite stable, and since we are not building apache module, versioning is not an issue here. Actually we'll be less dependent. Other benefit will be simply the elimination of things like various libapr.dll's flying around. MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Valves, requests and getting the session
Hello. I'm am trying to write a Valve, very much like SingleSignOn but for our authetnication system that uses more than just a username and password. I want my Valve to pass login information from one Session to another when a user uses different webapps (Contexts). I am nearly there codewise, but have a small problem. I do not seem to be able to get the session from the request! I've tried calling request.getSession() and request.getSession(true) yet both return null. It's hardly worth pasting, but: public void invoke(Request request, Response response, ValveContext context) throws IOException, ServletException { System.out.println( ((HttpRequest)request).getSession(true) ); Will always print null. I assume I can get at the session from this level and I'm obviously doing something dumb. Are there any obvious things I should check? Thanks John Baker -- John Baker, BSc CS. Java Developer, TEAM Slb. (http://www.teamenergy.com/) The views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
configure tomcat (web-inf)
I want to know how I have to configure tomcat to run a jsp file with imports jar files, by example, xalan, jdom, xindice,... I don't know if I have to put this jar files in the CLASSPATH, copy them into the web-inf/lib... etc thanks _ MSN. Más Útil cada Día. http://www.msn.es/intmap/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: configure tomcat (web-inf)
On Sunday 30 June 2002 7:09 pm, Juan Antonio Herraiz wrote: I want to know how I have to configure tomcat to run a jsp file with imports jar files, by example, xalan, jdom, xindice,... I don't know if I have to put this jar files in the CLASSPATH, copy them into the web-inf/lib... etc Sounds like you want to read up on the structure of webapps. webapps/myapp/someJspPage.jsp webapps/myapp/WEB-INF/classes classes go here webapps/myapp/WEB-INF/lib jars go here John -- John Baker, BSc CS. Java Developer, TEAM Slb. (http://www.teamenergy.com/) The views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Valves, requests and getting the session
--- John Baker [EMAIL PROTECTED] wrote: Hello. I'm am trying to write a Valve, very much like SingleSignOn but for our authetnication system that uses more than just a username and password. I want my Valve to pass login information from one Session to another when a user uses different webapps (Contexts). I am nearly there codewise, but have a small problem. I do not seem to be able to get the session from the request! I've tried calling request.getSession() and request.getSession(true) yet both return null. It's hardly worth pasting, but: public void invoke(Request request, Response response, ValveContext context) throws IOException, ServletException { System.out.println( ((HttpRequest)request).getSession(true) ); Will always print null. Shouldn't you be using this instead? (HttpServletRequest request, HttpServletResponse response, ValveContext context) Also, why are you casting HttpSession to HttpRequest? That should cause an exception since HttpServletRequest extends ServletRequest and HttpSession doesn't extend either interface. peter lin __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Valves, requests and getting the session
On Sunday 30 June 2002 7:32 pm, Peter Lin wrote: --- John Baker [EMAIL PROTECTED] wrote: Hello. I'm am trying to write a Valve, very much like SingleSignOn but for our authetnication system that uses more than just a username and password. I want my Valve to pass login information from one Session to another when a user uses different webapps (Contexts). I am nearly there codewise, but have a small problem. I do not seem to be able to get the session from the request! I've tried calling request.getSession() and request.getSession(true) yet both return null. It's hardly worth pasting, but: public void invoke(Request request, Response response, ValveContext context) throws IOException, ServletException { System.out.println( ((HttpRequest)request).getSession(true) ); Will always print null. Shouldn't you be using this instead? (HttpServletRequest request, HttpServletResponse response, ValveContext context) Err, the inteface Valve clearly defines: public void invoke(Request request, Response response, ValveContext context) throws IOException, ServletException; Also, why are you casting HttpSession to HttpRequest? I'm not, I'm casting request to HttpRequest so I can call getSession. I did cut some of my code but I do check to make sure request can be casted. See org.apache.catalina.authenticator.AuthenticationBase and the method getSession(HttpRequest request, boolean create); as this gives a clear example of what I'm trying to do. yet it doesnt work for me! John -- John Baker, BSc CS. Java Developer, TEAM Slb. (http://www.teamenergy.com/) The views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: isapi_redirector2 build using static APR
OK, +1.. i'll do the changes to the isapi build Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10361] New: - JDBCRealm requires restart if JDBC connection fails.
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=10361. 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=10361 JDBCRealm requires restart if JDBC connection fails. Summary: JDBCRealm requires restart if JDBC connection fails. Product: Tomcat 4 Version: 4.0.3 Final Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If the JDBC connection obtained by JDBCRealm fails in ways other than throwing an SQLException (such as would be the case if the database forced the connection closed because of an idle timeout, or the database was bounced), JDBCRealm doesn't appear to handle any thing other than SQLException and remains non-operational until tomcat is restarted. The current behavior would frustrate users by making their first attempt to log into a server with a failed JDBC connection even if they typed their password in correctly. It is also frustrating for the server administrator if the JDBC driver does not always wrap other failures and rethrow them as SQLExceptions. It would be better if JDBCRealm attempted to reconnect within the first call to authenticate and made this attempt upon any failure of the cached connection (i.e. catch Throwable). Changes could be as follows (unless someone thinks of a better way): public Principal authenticate(String username, String credentials) { return authenticate(username, credentials, true); } private final Principal authenticate(String username, String credentials, boolean firstTry) { Connection dbConnection = null; try { // Ensure that we have an open database connection dbConnection = open(); // Acquire a Principal object for this user Principal principal = authenticate(dbConnection, username, credentials); // Release the database connection we just used release(dbConnection); // Return the Principal (if any) return (principal); } catch (Throwable t) { if (firstTry) { // recurse and try one more time while we're here return authenticate(username, password, false); } else { // give up and hope something changes before next login // Log the problem for posterity log(sm.getString(jdbcRealm.exception), t); // Close the connection so that it gets reopened next time if (dbConnection != null) close(dbConnection); // Return not authenticated for this request return (null); } } -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Valves, requests and getting the session
On Sun, 30 Jun 2002, John Baker wrote: Date: Sun, 30 Jun 2002 19:00:18 +0100 From: John Baker [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Valves, requests and getting the session Hello. I'm am trying to write a Valve, very much like SingleSignOn but for our authetnication system that uses more than just a username and password. I want my Valve to pass login information from one Session to another when a user uses different webapps (Contexts). I am nearly there codewise, but have a small problem. I do not seem to be able to get the session from the request! I've tried calling request.getSession() and request.getSession(true) yet both return null. It's hardly worth pasting, but: public void invoke(Request request, Response response, ValveContext context) throws IOException, ServletException { System.out.println( ((HttpRequest)request).getSession(true) ); Will always print null. I assume I can get at the session from this level and I'm obviously doing something dumb. Are there any obvious things I should check? Try this slight variation (based on what Catalina does in the getSession() method of AuthenticatorBase): HttpServletRequest hrequest = (HttpServletRequest) request.getRequest(); HttpSession session = hrequest.getSession(true); The code you quoted above shouldn't actually compile, because you're calling getSession() on the internal HttpRequest interface, but there is no getSession() method on that interface. You need the extra getRequest() call to get to the HttpServletRequest object that would be handed to a servlet -- that's the one with the getSession() method that operates as you need it to. Thanks John Baker Craig -- John Baker, BSc CS. Java Developer, TEAM Slb. (http://www.teamenergy.com/) The views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Valves, requests and getting the session
On Sunday 30 June 2002 9:25 pm, Craig R. McClanahan wrote: Will always print null. I assume I can get at the session from this level and I'm obviously doing something dumb. Are there any obvious things I should check? Try this slight variation (based on what Catalina does in the getSession() method of AuthenticatorBase): HttpServletRequest hrequest = (HttpServletRequest) request.getRequest(); HttpSession session = hrequest.getSession(true); Already tried that, and sadly it didnt work :( The code you quoted above shouldn't actually compile, because you're calling getSession() on the internal HttpRequest interface, but there is no getSession() method on that interface. You need the extra getRequest() call to get to the HttpServletRequest object that would be handed to a servlet -- that's the one with the getSession() method that operates as you need it to. Yea I know, I copied rather than pasting and mistyped the casting. The mystery goes on. John -- John Baker, BSc CS. Java Developer, TEAM Slb. (http://www.teamenergy.com/) The views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Valves, requests and getting the session
On Sun, 30 Jun 2002, John Baker wrote: Date: Sun, 30 Jun 2002 21:27:36 +0100 From: John Baker [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: Valves, requests and getting the session On Sunday 30 June 2002 9:25 pm, Craig R. McClanahan wrote: Will always print null. I assume I can get at the session from this level and I'm obviously doing something dumb. Are there any obvious things I should check? Try this slight variation (based on what Catalina does in the getSession() method of AuthenticatorBase): HttpServletRequest hrequest = (HttpServletRequest) request.getRequest(); HttpSession session = hrequest.getSession(true); Already tried that, and sadly it didnt work :( The code you quoted above shouldn't actually compile, because you're calling getSession() on the internal HttpRequest interface, but there is no getSession() method on that interface. You need the extra getRequest() call to get to the HttpServletRequest object that would be handed to a servlet -- that's the one with the getSession() method that operates as you need it to. Yea I know, I copied rather than pasting and mistyped the casting. The mystery goes on. Hmm ... this is baslically how the standard form-based login implementation creates a session, except that it goes on and gets the internal Session object ... I presume you're trying to create the session *before* calling context.invokeNext(), right? If you don't the response will have already been committed so creating a new session would be ineffective. John Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Valves, requests and getting the session
On Sunday 30 June 2002 9:35 pm, Craig R. McClanahan wrote: Hmm ... this is baslically how the standard form-based login implementation creates a session, except that it goes on and gets the internal Session object ... That's what I thought. I presume you're trying to create the session *before* calling context.invokeNext(), right? If you don't the response will have already been committed so creating a new session would be ineffective. Yes, I am. I need to check to see if certain objects are in the session and if not, see if they are in another session that is pointed to by the Cookie id. It's like SingleSignOn, but slightly different. However I'm a bit confused to why I can't get a session, even when the rest of the app (the jsp pages etc) are making good use of it., The headers also show the session id, but oddly enough calling HttpServletRequest.SessionIdFromCookie() returns true, but HttpServletRequest.isRequestSessionIdvalid() returns false! John -- John Baker, BSc CS. Java Developer, TEAM Slb. (http://www.teamenergy.com/) The views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: isapi_redirector2 build using static APR
I'm close to -1 on this, but if everyone else is +1 I'll change it to -0. Apr is a library, just like glib or libc, and I hope soon more modules and programs will use it - including in IIS or other environments. I see no problem with having apr.dll - it is actually easier to get it from an Apache installation ( or pre-built whenever they have a release ) Maybe having the dll around will encourage other uses as well :-) Costin On Sun, 30 Jun 2002, Mladen Turk wrote: -Original Message- From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] Sent: 30. lipanj 2002 18:45 To: '[EMAIL PROTECTED]' Subject: RE: isapi_redirector2 build using static APR De: Mladen Turk [mailto:[EMAIL PROTECTED]] Enviado el: 30 de junio de 2002 7:28 hmmm, this will force us to make a binary everytime Apache2 has a release too? in this case -1, if not +1 Only if the APR changes itself (in the API way), but then we have to rebuild it in any case. All the Apache utils itself use the static APR if they don't need to go to the httpd directly. Since we are using apr in the IIS connector only as a common library for things like pools, tables, network io, etc. The only rebuild needed would be in the case of some sort of discovered bug. The apr itself is quite stable, and since we are not building apache module, versioning is not an issue here. Actually we'll be less dependent. Other benefit will be simply the elimination of things like various libapr.dll's flying around. MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10361] - JDBCRealm requires restart if JDBC connection fails.
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=10361. 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=10361 JDBCRealm requires restart if JDBC connection fails. --- Additional Comments From [EMAIL PROTECTED] 2002-07-01 00:39 --- I did a bit of additional testing on this and found that the problem I was seeing was reporting a Communications link failure: java.io.IOException but must have actually been wrapped and thrown in an SQLException. The modification to recurse and try at least twice would still be helpful to avoid the login failure for the first arrival to a failed JDBC connection. The private signature of authenticate that has the firstTry boolean argument still applies, but the suggested modification to the catch would acutally be something like the following: } catch (SQLException e) { if (firstTry dbConnection != null) { close(dbConnection); // close the connection return authenticate(username, password, false); // try a 2nd time } else { // give up and hope something changes before next login // bla bla bla, etc. etc. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: isapi_redirector2 build using static APR
Yes, It might be a problem if we think (and should) that someone else will use apr to build some other filter or isapi extension using apr that will coexist in the same process (IIS) with our redirector. In that case we could have serious initialization problems. The same problem lies with the assumption that we are the only user of java vm, cause we cannont start two vm's in the same process, so currently we cannot have two jvm modules in Apache. I'll withdraw my proposal, and the only thing that's left is to use the MD instead of MT build, cause the apr is build using dynamic run-time, and we are using static, and mixing that can cause problems. MT. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 30. lipanj 2002 23:15 To: Tomcat Developers List Subject: RE: isapi_redirector2 build using static APR I'm close to -1 on this, but if everyone else is +1 I'll change it to -0. Apr is a library, just like glib or libc, and I hope soon more modules and programs will use it - including in IIS or other environments. I see no problem with having apr.dll - it is actually easier to get it from an Apache installation ( or pre-built whenever they have a release ) Maybe having the dll around will encourage other uses as well :-) Costin On Sun, 30 Jun 2002, Mladen Turk wrote: -Original Message- From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] Sent: 30. lipanj 2002 18:45 To: '[EMAIL PROTECTED]' Subject: RE: isapi_redirector2 build using static APR De: Mladen Turk [mailto:[EMAIL PROTECTED]] Enviado el: 30 de junio de 2002 7:28 hmmm, this will force us to make a binary everytime Apache2 has a release too? in this case -1, if not +1 Only if the APR changes itself (in the API way), but then we have to rebuild it in any case. All the Apache utils itself use the static APR if they don't need to go to the httpd directly. Since we are using apr in the IIS connector only as a common library for things like pools, tables, network io, etc. The only rebuild needed would be in the case of some sort of discovered bug. The apr itself is quite stable, and since we are not building apache module, versioning is not an issue here. Actually we'll be less dependent. Other benefit will be simply the elimination of things like various libapr.dll's flying around. MT. -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]