How do I get the line number in a JSP .....
Gurus, How do I get the line number in a JSP, when an exception occurs? Currently, the stack trace prints NullPointerException and says Unkown source. Any help would be highly appreciated. Thanks Sesha
Re: Doubt in Single Sign On !!!
I agree with Will completely . I have found a way to solve this issue and in that process have one more doubt. The invoke method of SingleSignOn is getting called when request for a resource is placed. The details of all the sessions that are currently associated is available inside the method. To solve my issue, what i have done is that i have retrieved all the Session objects and called the access() method so that the LastAccessed time gets updated for all the sessions when a request is placed for a particular context. This i have done it by extending the SingleSignOn and overriding the invoke method. Now if i specify my class in the server.xml i am getting an exception saying that Managed Bean not found with MyClasssName. How should i go about specifying my class in the server.xml instead of SingleSignOn. Thanks Shanmugam Will Hartung wrote: From: Craig R. McClanahan [EMAIL PROTECTED] Sent: Tuesday, January 28, 2003 2:01 PM Subject: Re: Doubt in Single Sign On !!! True ... there is no such thing as a cross-application session defined in the servlet spec. You're outside the bounds of the servlet spec when you talk about this, but nothing stops a container from providing something like it. Yes, for example, the Tomcat Servlet Container (tm reg. us. pat. off.) has a Single Sign On facility that's outside of the Servlet Spec, but it doesn't behave as a consistent time out across all the webapps its supporting. :-) Regards, Will Hartung ([EMAIL PROTECTED]) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Doubt in Single Sign On !!!
Will this be supported in the future releases of Tomcat Craig R. McClanahan wrote: On Tue, 28 Jan 2003, Will Hartung wrote: Date: Tue, 28 Jan 2003 13:32:46 -0800 From: Will Hartung [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: Doubt in Single Sign On !!! From: Craig R. McClanahan [EMAIL PROTECTED] Sent: Tuesday, January 28, 2003 1:04 PM Subject: Re: Doubt in Single Sign On !!! The reason for this design is security. Consider a portal-type application like My Yahoo, which implements their version of single sign on (you don't have to log in to mail, then to games, then to ...). I browse around between the apps, and decide to log out. Should the effect of this logout be global? I would suggest that it should -- you don't want to be in an Internet cafe and log out of one Yahoo app, but forget that you haven't logged out of all the rest. All well and good, but it seems to me that the problem that is being described here is that the sessions of each application have their own distinct timers, rather than a global timer for the single-sign-on session. True ... there is no such thing as a cross-application session defined in the servlet spec. Using Yahoo as an example, and, say, a 15 minute timeout, it would a fair expectation that if I log in to Yahoo, go read my mail, and then go and play Yahoo Cribbage for 30 minutes, then I would expect at the end of my last game to be able to pop back over to Yahoo Mail and still be authenticated. What is being described here sounds as if in this contrived example that the Yahoo Mail will time out in 15 minutes because it wasn't accessed, even though I was still logged in and active over on Yahoo Games. In the servlet world, session timeout logs you out (if you're using form based login). Therefore, it should be (and is) treated the same as an explicit logout by the user. Of course. The difficulty here is that the actual application sessions perhaps needs some kind of tie to the overall master single-sign on session, and not timeout until the SSO session times out. You're outside the bounds of the servlet spec when you talk about this, but nothing stops a container from providing something like it. Regards, Will Hartung ([EMAIL PROTECTED]) Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: SSL with Tomcat
Oh, thanks, but its all fixed now - I placed the .keystore file in the not default directory - and I only specified the directory and not the file itself in the parameter - keystoreFile ... all works now. Thanks to every body, trying to help ;) - Original Message - From: Turner, John [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Tuesday, January 28, 2003 9:57 PM Subject: RE: SSL with Tomcat What do the regular Tomcat logs say? John -Original Message- From: Yakov Belov [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 3:13 AM To: Tomcat Users List Subject: Re: SSL with Tomcat Thanks, but I don't use a command line to run Tomcat (everything is started via the web)- where exactly do I type this parameters in? - Original Message - From: list [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, January 28, 2003 7:08 PM Subject: Re: SSL with Tomcat hi! you may start tomcat with: -Djavax.net.debug=all or with: -Djavax.net.debug=ssl then you can 'see' whats going on during ssl handshake! Yakov Belov wrote: Dear All, I am trying to use Tomcat over SSL. I have followed the HOWTO: SSL in hte Tomcat Docs, i.e. downloaded the three needed jar files, created a ./keystore file and specified its location in the web.xml file. I have also uncommented the SSL Connector section in the web.xml file. Now when I run https://host name:8443/, the browser just keeps loading something and never seems to be able to finish the process. Can someone help? Best regards, Yakov Belov -- 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] --- Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.443 / Virus Database: 248 - Release Date: 1/10/2003 --- Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.443 / Virus Database: 248 - Release Date: 1/10/2003 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Possible CLOSE_WAIT bug
Hi, I'd like to verify what I'm seeing is a bug. If I set my maxProcessors sufficiently low (say 5), then run a script from another machine that floods Tomcat with requests for a given JSP, eventually Tomcat stops accepting requests at all. Ok, that's to be expected when every processor thread is busy. BUT, when the flood stops, all the threads let their socket connections remain in CLOSE_WAIT and they never close them. This causes Tomcat to NEVER accept new connections, until it's restarted. I'm seeing this problem happen on a site with 600 max processors. Eventually, it stops accepting connections and has to be restarted, every couple days. This is Tomcat 4.0.6 on Windows 2000, JDK 1.4.1_01. Any idears?? Regards, -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaBean problem
So, instead of WEB-INF/classes/MyBean, it would be something like WEB-INF/classes/com.mypackage.MyBean What works for me is: MyBean: (declaration at top of bean class file) package com.mypackage; Directory structure: WEB-INF = classes = com = mypackage = MyBean Note that the package declaration uses fullstops (periods in American) and the directory path has a separate directory for com and mypackage, the bean residing in the latter. Does WEB-INF = classes = com.mypackage = MyBean also work? Regards, Wilson (newbie) - Original Message - From: Jacob Kjome [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Wednesday, January 29, 2003 4:34 AM Subject: Re: JavaBean problem Is the bean in an actual defined package or the default package (no package). It *must* be in a package. So, instead of WEB-INF/classes/MyBean, it would be something like WEB-INF/classes/com.mypackage.MyBean Now import the com.mypackage.MyBean bean into your jsp. Things should work better now. Jake At 05:38 PM 1/28/2003 -0800, you wrote: I have just created and compiled my first JavaBean into tomcat-install\webapps\ROOT\WEB-INF\classes and am tying to access it from a jsp page in tomcat-install\webapps\ROOT directory. I am getting jsp compile errors because the jsp page cannot find the class defined in the JavaBean. Any help would be appreciated. My version of tomcat is 4.1.18. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com - 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: tomcat authtentication
On Tue, 28 Jan 2003, mike danese wrote: Date: Tue, 28 Jan 2003 13:56:31 -0800 From: mike danese [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: tomcat authtentication Trying to get a handle on how tomcat or tomcat-manager interact w/ InternetExplorer usr/passwd dialog box. I know that setting tomcat/catalina/server xml config files can invoke the IE usr/pswd dialog box, but how is the underlying code acomplishing it. Docs on apache/jakarta say fix-me' on this issue. Could anyone give an example of how to popup an IE/mozilla usr/pswd dialog from a jsp or a bean?? Presuming that you've used BASIC as your login-method, this will do the trick: response.sendError(HttpServletResponse.SC_UNAUTHORIZED); return; which is pretty much what Tomcat's authenticator does if you ask for a protected resource and have not logged in yet. For more information on how basic authentication works, see: http://www.rfc-editor.org/rfc/rfc2617.txt thanksk md Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory requirements
On Tue, 28 Jan 2003, Cees van de Griend wrote: On Tuesday 28 January 2003 21:23, Gulay Top wrote: I'm using Linux. As soon as I start tomcat, an application called java starts, This is correct. and there are 27 - 35 instances of it. This could be correct, does not sound unreasable. Those instances are *threads*, not *processes*. It takes up close to 1 GB of memory. No it doesn't. You'll note that the memory size for all the threads are the same? That is because it is the exact same memory space. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Doubt in Single Sign On !!!
On Tue, 28 Jan 2003, Will Hartung wrote: Date: Tue, 28 Jan 2003 16:49:09 -0800 From: Will Hartung [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: Doubt in Single Sign On !!! From: Craig R. McClanahan [EMAIL PROTECTED] Sent: Tuesday, January 28, 2003 2:01 PM Subject: Re: Doubt in Single Sign On !!! True ... there is no such thing as a cross-application session defined in the servlet spec. You're outside the bounds of the servlet spec when you talk about this, but nothing stops a container from providing something like it. Yes, for example, the Tomcat Servlet Container (tm reg. us. pat. off.) has a Single Sign On facility that's outside of the Servlet Spec, but it doesn't behave as a consistent time out across all the webapps its supporting. :-) Actually, SSO is *not* outside the bounds of the spec :-). See Section SRV.12.6 of the Servlet 2.3 Specification, and Tomcat's implementation complies with the requrements there. What is not defined is where the boundaries of a security policy domain are with respect to SSO -- Tomcat's choice to implement this at the virtual host level is entirely legitimate, as would an SSO implementation that was based on Project Liberty http://www.libertyalliance.org/ that covered multiple web apps on multiple servers (not even necessarily all Java based). However, Section 12.6 only talks about propogating security identities; it says nothing about updating the last access time of sessions in other web apps so that they don't time out. Technically, that would not be hard to accomplish (modify the existing SSO valve to call access() on the internal StandardSession object of each related session) -- but you wont' be able to claim that such behavior is required. Regards, Will Hartung ([EMAIL PROTECTED]) Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Doubt in Single Sign On !!!
On Wed, 29 Jan 2003, shanmugampl wrote: Date: Wed, 29 Jan 2003 10:53:41 +0530 From: shanmugampl [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: Doubt in Single Sign On !!! Will this be supported in the future releases of Tomcat The best way to make sure that happens is to submit an enhancement request, plus a patch that enables the feature you want, to: http://nagoya.apache.org/bugzilla/ That way, a Tomcat committer can at least evaluate what you think you want, and look at a solution (prepared by you) that actually works in the real world. A much less effective way is to just submit an enhancement request without a patch. Then, you are depending on the interest of some Tomcat committer in caring about this particular issue, then crafting and testing a solution that may or may not actually meet *your* requirements. Using open source software, and wanting enhancements, means that *you* need to take more responsibility if you really care about something. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
