RE: newbie user...help
Check out orionsupport, there's a simple howto on this: http://www.orionsupport.com/articles/vhosts.html regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of g vasantha kumar Sent: Friday, May 11, 2001 9:42 PM To: Orion-Interest Subject: newbie user...help hi orion works fine and am able to run all demos.i don't understand the virtual directory mode.i want my webapp to run with a url , http://mycompany.com...instead of http://127.0.0.1/mycompany. help out.thanx in advance. __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
init params
Found something unexpected. I have attached an ear to illustrate. In the servlet TestServlet (config provided for expediency). servlet servlet-nametest/servlet-name display-nametest/display-name servlet-classcom.sequenet.mvc.TestServlet/servlet-class init-param param-nameconfig/param-name param-valuetest/param-value /init-param load-on-startup1/load-on-startup /servlet I try to get an init-param three ways. System.err.println(param=+getInitParameter(config)); System.err.println(param=+config.getInitParameter(config)); System.err.println(param=+getServletContext().getInitParameter(config)); the first two print test as they should. the last one print null. why? Just for kicks I performed this test in both the init() method and a service() method. Any thoughts? WR Russ White test.ear
RE: How to tell when a user first log's in?
Ad 1) %=request.getRemoteUser()% (obviously you'll have to reload the top frame) Ad 2) You will need to subclass DataSourceUerManager and add that functionality It would be possible to add that functionality on a page that the logged-in User is guaranteeed to go to, bad that would be bad design --peter -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeremy C Sent: Saturday, May 12, 2001 7:44 PM To: Orion-Interest Subject: How to tell when a user first log's in? Is it possible to attach a hook, or some means of detemining when a user first log's in? I use DataSourceUserManager... What I would like to do is two things, 1. In my top frame, indicate who you are logged in as 2. Check the last time you have changed your password, and prompt for a password change if it's past 3 months. Thanks! Jeremy - [EMAIL PROTECTED]
RE: init params
Russ: The first two methods... * getInitParameter(String):String * config.getInitParameter(String):String both reference the ServletConfig.getInitParameter(String):String method. This returns configuration information specified by an init-param element within a servlet definition. The other method... * getServletContext.getInitParameter(String):String references ServletContext.getInitParameter(String):String. which retrieves parameter values from the context-param element of a web-app definition. Check out the Servlet API JavaDocs or specification docs for more info. Jason Coward Technical Relationship Manager Mongoose Technology, Incorporated | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED]]On Behalf Of Russ White | Sent: Saturday, May 12, 2001 9:08 AM | To: Orion-Interest | Subject: init params | | | Found something unexpected. | | I have attached an ear to illustrate. | | In the servlet TestServlet (config provided for expediency). | servlet | servlet-nametest/servlet-name | display-nametest/display-name | servlet-classcom.sequenet.mvc.TestServlet/servlet-class | init-param | param-nameconfig/param-name | param-valuetest/param-value | /init-param | load-on-startup1/load-on-startup | /servlet | I try to get an init-param three ways. | | System.err.println(param=+getInitParameter(config)); | System.err.println(param=+config.getInitParameter(config)); | | System.err.println(param=+getServletContext().getInitParameter(config)); | | the first two print test as they should. | the last one print null. | | why? | | Just for kicks I performed this test in both the init() method and a service() | method. | | Any thoughts? | | WR | Russ White | |
Re: init params
You have given init parameter to the servlet thats the reason your first two statements given correct result. The thrird one looks for the context parameter which you haven't set. Refer the difference between the ServletInitParameter and the Context-Parameter. For contextparameter you have give context-param param-namecontextP/param-name param-valueContextValue/param-value /context-param - Original Message - From: Russ White [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Saturday, May 12, 2001 7:08 AM Subject: init params Found something unexpected. I have attached an ear to illustrate. In the servlet TestServlet (config provided for expediency). servlet servlet-nametest/servlet-name display-nametest/display-name servlet-classcom.sequenet.mvc.TestServlet/servlet-class init-param param-nameconfig/param-name param-valuetest/param-value /init-param load-on-startup1/load-on-startup /servlet I try to get an init-param three ways. System.err.println(param=+getInitParameter(config)); System.err.println(param=+config.getInitParameter(config)); System.err.println(param=+getServletContext().getInitParameter(config)); the first two print test as they should. the last one print null. why? Just for kicks I performed this test in both the init() method and a service() method. Any thoughts? WR Russ White
RE: Session Invalidate Exception
I don't think that excludes the desired behavior, which is that you should be able to invalidate a session and then create a new one. It appears that session invalidate() is setting a flag in the session object causing it to be cleaned up sometime later. Since the only way to logout a user is to call invalidate(), this causes some headaches. Ideally I would like my login submit page to a) discard existing credentials and b) try new credentials. This way if a user was already logged in, the net result of a new login attempt will be the unauthenticated state. Unfortunately I can't call getSession().invalidate(); session = getSession(); because what I get is the old session, which is going to disappear at the end of the method, the call to RoleManager.login() notwithstanding. Furthermore, a failed call to RoleManager.login() does *not* discard existing credentials. The only way to accomplish the original goal is to put the invalidate() on every page with a login form. Ok, this isn't super critical, but it's annoying nevertheless. Jeff -Original Message- From: Noah Nordrum [mailto:[EMAIL PROTECTED]] Sent: Friday, May 11, 2001 7:09 PM To: Orion-Interest Subject: Re: Session Invalidate Exception Session Invalidate ExceptionServlet Spec == 7.2 Creating a Session Because HTTP is a request-response based protocol, a session is considered to be new until a client joins it. A client joins a session when session tracking information has been successfully returned to the server indicating that a session has been established. Until the client joins a session, it cannot be assumed that the next request from the client will be recognized as part of the session. The session is considered to be new if either of the following is true: . The client does not yet know about the session . The client chooses not to join a session. This implies that the servlet container has no mechanism by which to associate a request with a previous request. A Servlet Developer must design their application to handle a situation where a client has not, can not, or will not join a session. == That last line is what specifically applies to your situation, only backwards. In this case you are invalidating the HttpSession, but the client doesn't yet know about the pending invalidation, hense the IllegalStateException. Noah - Original Message - From: Kesav Kumar To: Orion-Interest Sent: Friday, May 11, 2001 7:23 PM Subject: RE: Session Invalidate Exception If there is no valid session getSession(false) should return null is in't it? Kesav Kumar Software Engineer Voquette, Inc. 650 356 3740 mailto:[EMAIL PROTECTED] http://www.voquette.com Voquette...Delivering Sound Information -Original Message- From: Jason Coward [mailto:[EMAIL PROTECTED]] Sent: Friday, May 11, 2001 2:55 PM To: Orion-Interest Subject: RE: Session Invalidate Exception Kesav: I believe that when you call request.getSession(false), it will not create a new session if a valid one does not already exist. If you want to create a new one, right after invalidation of a previous session, call request.getSession() or request.getSession(true). Obviously, you will need to reset your attribute after the new session is created. Jason -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Kesav Kumar Sent: Friday, May 11, 2001 4:17 PM To: Orion-Interest Subject: Session Invalidate Exception When we call invalidate() method on the session what happens? I was doing the following and I am getting a strange error. This is just a testcondition I am giving to reproduce my error. The reality is much complex. session.setAttribute(kesav, I am nice); session.invalidate(); HttpSession sess = request.getSession(false); if(sess == null) System.out.println(Session is null); Object obj = sess.getAttribute(kesav); After the invalidate I was thinking that I won't get session object thats the reason I had a condition for null. What happening is I am getting a session object and when I try to access any attribute I am getting java.lang.IllegalStateException: Session was invalidated at com.evermind[Orion/1.4.8 (build 10374)].server.http.EvermindHttpSession.getAttribute(Unknown Source) at /Test.jsp._jspService(/Test.jsp.java:30) (JSP page line 7) at com.orionserver[Orion/1.4.8 (build 10374)].http.OrionHttpJspPage.service(Unknown Source) at com.evermind[Orion/1.4.8 (build 10374)]._aj._nxd(Unknown Source) at com.evermind[Orion/1.4.8 (build 10374)].server.http.JSPServlet.service(Unknown Source) at com.evermind[Orion/1.4.8 (build 10374)]._iib._vfd(Unknown Source) at com.evermind[Orion/1.4.8 (build
[Fwd: Orion 1.4.8 page reload stalls]
I am forwarding this on to the group per Mark's request... Additionally, Mark - yes! I have noticed too that the stall occurs *after* the contents have been sent to the browser - almost as hough the content length was set to be longer than the real content length. I've never seen this with any previous versions, and I agree that it is a serious problem - although since it worked before, I would guess that it wouldn't be a very difficult problem for the Orion team to fix, who have, in my opinion, done an incredible job with this product so far. -Dale Hello. I'm replying directly to you because I do not subscribe to the Orion list. Would you be so kind as to add this to the list? I have had the same problem with Orion. I've noticed a few more things: The stalls are always in regard to POST requests. The stalls occur after the request has been committed. I put in statements that print to the standard output once a JSP page has been finished. The stall is happening *after* the page contents have been sent to the browser. This is a very serious problem. -mark Mark Meuer Software Engineer Life Navigator, Inc. http://www.lifenavigator.com mailto:[EMAIL PROTECTED]
RE: init params
I used to have similar problems as Russ - IMHO the naming of ServletContext is wrong - the context is the web-application and not the servlet that's returned by getServletContext. Obviously the powers who created the API cut the naming of the function short - getContextServletIsIn - is what they meant. The grammatical construct SomethingContext usually is considered to name the Context - which to repeat myself is the web app. ServletConfig contains the parameters in the Context of the Servlet Wish Sun would reconsider the naming of some of these classes and methods ... --peter -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Coward Sent: Saturday, May 12, 2001 11:46 AM To: Orion-Interest Subject: RE: init params Russ: The first two methods... * getInitParameter(String):String * config.getInitParameter(String):String both reference the ServletConfig.getInitParameter(String):String method. This returns configuration information specified by an init-param element within a servlet definition. The other method... * getServletContext.getInitParameter(String):String references ServletContext.getInitParameter(String):String. which retrieves parameter values from the context-param element of a web-app definition. Check out the Servlet API JavaDocs or specification docs for more info. Jason Coward Technical Relationship Manager Mongoose Technology, Incorporated | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED]]On Behalf Of Russ White | Sent: Saturday, May 12, 2001 9:08 AM | To: Orion-Interest | Subject: init params | | | Found something unexpected. | | I have attached an ear to illustrate. | | In the servlet TestServlet (config provided for expediency). | servlet | servlet-nametest/servlet-name | display-nametest/display-name | servlet-classcom.sequenet.mvc.TestServlet/servlet-class | init-param | param-nameconfig/param-name | param-valuetest/param-value | /init-param | load-on-startup1/load-on-startup | /servlet | I try to get an init-param three ways. | | System.err.println(param=+getInitParameter(config)); | System.err.println(param=+config.getInitParameter(config)); | | System.err.println(param=+getServletContext().getInitParameter(config)); | | the first two print test as they should. | the last one print null. | | why? | | Just for kicks I performed this test in both the init() method and a service() | method. | | Any thoughts? | | WR | Russ White | |
RE: init params
Thanks for the quick posts. Stupid me, I thought getInitParameter would always be for init-params. I wonder why... getServletContext.getInitParameter(String):String is not getServletContext.getContextParameter(String):String ? Because getInitParameter() was invented before contexts ever existed. tim.
Re: Session Invalidate Exception
So have the page where the user enters their credentials wax their session,
then the validation of the credentials page will create a new session.
why do you have to invalidate the session? why can't you just do:
===
HttpSession session = request.getSession();
Enumeration attributes = session.getAttributeNames();
while (attributes.hasMoreElements()) {
session.removeAttribute((String)attributes.nextElement());
}
===
Then you'll basically have a fresh session (except for a few exceptions).
Noah
- Original Message -
From: Jeff Schnitzer [EMAIL PROTECTED]
To: Orion-Interest [EMAIL PROTECTED]
Sent: Saturday, May 12, 2001 1:31 PM
Subject: RE: Session Invalidate Exception
I don't think that excludes the desired behavior, which is that you
should be able to invalidate a session and then create a new one.
It appears that session invalidate() is setting a flag in the session
object causing it to be cleaned up sometime later. Since the only way
to logout a user is to call invalidate(), this causes some headaches.
Ideally I would like my login submit page to a) discard existing
credentials and b) try new credentials. This way if a user was already
logged in, the net result of a new login attempt will be the
unauthenticated state. Unfortunately I can't call
getSession().invalidate();
session = getSession();
because what I get is the old session, which is going to disappear at
the end of the method, the call to RoleManager.login() notwithstanding.
Furthermore, a failed call to RoleManager.login() does *not* discard
existing credentials. The only way to accomplish the original goal is
to put the invalidate() on every page with a login form.
Ok, this isn't super critical, but it's annoying nevertheless.
Jeff
-Original Message-
From: Noah Nordrum [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 11, 2001 7:09 PM
To: Orion-Interest
Subject: Re: Session Invalidate Exception
Session Invalidate ExceptionServlet Spec
==
7.2 Creating a Session
Because HTTP is a request-response based protocol, a session
is considered
to be new until a client joins it. A client joins a session
when session
tracking information has been successfully returned to the
server indicating
that a session has been established. Until the client joins a
session, it
cannot be assumed that the next request from the client will
be recognized
as part of the session.
The session is considered to be new if either of the
following is true:
. The client does not yet know about the session
. The client chooses not to join a session. This implies that
the servlet
container has no mechanism by which to associate a request
with a previous
request.
A Servlet Developer must design their application to handle a
situation
where a client has not, can not, or will not join a session.
==
That last line is what specifically applies to your situation, only
backwards. In this case you are invalidating the HttpSession,
but the client
doesn't yet know about the pending invalidation, hense the
IllegalStateException.
Noah
- Original Message -
From: Kesav Kumar
To: Orion-Interest
Sent: Friday, May 11, 2001 7:23 PM
Subject: RE: Session Invalidate Exception
If there is no valid session getSession(false) should return
null is in't
it?
Kesav Kumar
Software Engineer
Voquette, Inc.
650 356 3740
mailto:[EMAIL PROTECTED]
http://www.voquette.com
Voquette...Delivering Sound Information
-Original Message-
From: Jason Coward [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 11, 2001 2:55 PM
To: Orion-Interest
Subject: RE: Session Invalidate Exception
Kesav:
I believe that when you call request.getSession(false), it
will not create a
new session if a valid one does not already exist. If you
want to create a
new one, right after invalidation of a previous session, call
request.getSession() or request.getSession(true). Obviously,
you will need
to reset your attribute after the new session is created.
Jason
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Kesav Kumar
Sent: Friday, May 11, 2001 4:17 PM
To: Orion-Interest
Subject: Session Invalidate Exception
When we call invalidate() method on the session what happens?
I was doing the following and I am getting a strange error.
This is just a
testcondition I am giving to reproduce my error. The reality is much
complex.
session.setAttribute(kesav, I am nice);
session.invalidate();
HttpSession sess = request.getSession(false);
if(sess == null)
System.out.println(Session is null);
Object obj = sess.getAttribute(kesav);
After the invalidate I
RE: How to tell when a user first log's in?
Peter, Thanks, however I do have 1 more question for you. I do have the top frame saying request.getRemoteUser, but how do I automatically cause that frame to get refreshed when a user first log's in? On logout, I can do that because it accesses logout.jsp (just issue a JavaScript Refresh command.) Thanks! Jeremy - [EMAIL PROTECTED] At 10:23 AM 5/12/2001 -0600, you wrote: Ad 1) %=request.getRemoteUser()% (obviously you'll have to reload the top frame) Ad 2) You will need to subclass DataSourceUerManager and add that functionality It would be possible to add that functionality on a page that the logged-in User is guaranteeed to go to, bad that would be bad design --peter -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeremy C Sent: Saturday, May 12, 2001 7:44 PM To: Orion-Interest Subject: How to tell when a user first log's in? Is it possible to attach a hook, or some means of detemining when a user first log's in? I use DataSourceUserManager... What I would like to do is two things, 1. In my top frame, indicate who you are logged in as 2. Check the last time you have changed your password, and prompt for a password change if it's past 3 months. Thanks! Jeremy - [EMAIL PROTECTED]
DataSourceUserManager ... Restart App to get new group?
I have noticed that if I add a new group to the data source for a particular user that they will not have that group's rights until Orion is restarted. Is this normal? Is there a way to refresh the user's rights without restarting the server? I tried to invalidate their session with orionconsole, but that did not work. Thanks! Jeremy - [EMAIL PROTECTED]
RE: orionconsole and firewall - hangs !??
Thanks Andre, I will try this, Ed From: Andre Vanha [EMAIL PROTECTED] Reply-To: Orion-Interest [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Subject: RE: orionconsole and firewall - hangs !?? Date: Fri, 11 May 2001 14:46:34 -0600 Eddie, It looks like the orion console uses the ORMI protocol. The default port for ormi is 23791. You could edit rmi.xml to specify a different port. Andre -Original Message- From: Eddie [mailto:[EMAIL PROTECTED]] Sent: Friday, May 11, 2001 8:45 AM To: Orion-Interest Subject: orionconsole and firewall - hangs !?? Please tell me which ports I need to open such that orionconsole can monitor an orion server that is behind a firewall. I have some orion servers that I can monitor well, but one is behind a firewall and the orionconsole just hangs when I add the server and click on it (at least I was impatient to wait for the time-out to occur - waited for 10 minutest). Regards, Eddie _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Re: Session Invalidate Exception
By invalidating session we generally think that all the memory will be
released but if invalidate doesn't actually release memore and make the
session object null then we need to have our own measures for releasing the
memory. My concern is more for the memore rathar than the program error
handling.
- Original Message -
From: Noah Nordrum [EMAIL PROTECTED]
To: Orion-Interest [EMAIL PROTECTED]
Sent: Saturday, May 12, 2001 1:31 PM
Subject: Re: Session Invalidate Exception
So have the page where the user enters their credentials wax their
session,
then the validation of the credentials page will create a new session.
why do you have to invalidate the session? why can't you just do:
===
HttpSession session = request.getSession();
Enumeration attributes = session.getAttributeNames();
while (attributes.hasMoreElements()) {
session.removeAttribute((String)attributes.nextElement());
}
===
Then you'll basically have a fresh session (except for a few exceptions).
Noah
- Original Message -
From: Jeff Schnitzer [EMAIL PROTECTED]
To: Orion-Interest [EMAIL PROTECTED]
Sent: Saturday, May 12, 2001 1:31 PM
Subject: RE: Session Invalidate Exception
I don't think that excludes the desired behavior, which is that you
should be able to invalidate a session and then create a new one.
It appears that session invalidate() is setting a flag in the session
object causing it to be cleaned up sometime later. Since the only way
to logout a user is to call invalidate(), this causes some headaches.
Ideally I would like my login submit page to a) discard existing
credentials and b) try new credentials. This way if a user was already
logged in, the net result of a new login attempt will be the
unauthenticated state. Unfortunately I can't call
getSession().invalidate();
session = getSession();
because what I get is the old session, which is going to disappear at
the end of the method, the call to RoleManager.login() notwithstanding.
Furthermore, a failed call to RoleManager.login() does *not* discard
existing credentials. The only way to accomplish the original goal is
to put the invalidate() on every page with a login form.
Ok, this isn't super critical, but it's annoying nevertheless.
Jeff
-Original Message-
From: Noah Nordrum [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 11, 2001 7:09 PM
To: Orion-Interest
Subject: Re: Session Invalidate Exception
Session Invalidate ExceptionServlet Spec
==
7.2 Creating a Session
Because HTTP is a request-response based protocol, a session
is considered
to be new until a client joins it. A client joins a session
when session
tracking information has been successfully returned to the
server indicating
that a session has been established. Until the client joins a
session, it
cannot be assumed that the next request from the client will
be recognized
as part of the session.
The session is considered to be new if either of the
following is true:
. The client does not yet know about the session
. The client chooses not to join a session. This implies that
the servlet
container has no mechanism by which to associate a request
with a previous
request.
A Servlet Developer must design their application to handle a
situation
where a client has not, can not, or will not join a session.
==
That last line is what specifically applies to your situation, only
backwards. In this case you are invalidating the HttpSession,
but the client
doesn't yet know about the pending invalidation, hense the
IllegalStateException.
Noah
- Original Message -
From: Kesav Kumar
To: Orion-Interest
Sent: Friday, May 11, 2001 7:23 PM
Subject: RE: Session Invalidate Exception
If there is no valid session getSession(false) should return
null is in't
it?
Kesav Kumar
Software Engineer
Voquette, Inc.
650 356 3740
mailto:[EMAIL PROTECTED]
http://www.voquette.com
Voquette...Delivering Sound Information
-Original Message-
From: Jason Coward [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 11, 2001 2:55 PM
To: Orion-Interest
Subject: RE: Session Invalidate Exception
Kesav:
I believe that when you call request.getSession(false), it
will not create a
new session if a valid one does not already exist. If you
want to create a
new one, right after invalidation of a previous session, call
request.getSession() or request.getSession(true). Obviously,
you will need
to reset your attribute after the new session is created.
Jason
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Kesav Kumar
Sent:
RE: How to tell when a user first log's in?
OK, there's a couple of different ways of doing this, dependent on which
program flow you wish to implement. A fairly generic way is something like
this (DHTML of course, doesn't have anything to do with the server-side of
things):
!- index.htm FRAMESET--
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN
html
head
titleFrameNav/title
script type=text/javascript
var mFrame = main.htm;
var redirectFrame = location.search.substr(1).split(=);
if (redirectFrame[1]) {
mFrame = redirectFrame[1];
}
document.write('frameset rows=200, * frameborder=1 frame name=top
src=top.htm /frame name=main src=' + mFrame + ' //frameset');
/script
/head
body
/body
/html
!-end of index.htm --
!-foo.htm The file to be redirected--
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN
html
head
titlefoo.htm/title
/head
body
This is foo!br/br/
script type=text/javascript
if (top == self) {
window.location.replace(index.htm?url= + location.pathname);
}
/script
/body
/html
!-end of foo.htm --
I assume this does what you were looking for (by the way, this may require
IE5.5 and NS6.0; to make it more generic you need to implement the split()
function yourself)
--Peter
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jeremy C
Sent: Sunday, May 13, 2001 3:47 PM
To: Orion-Interest
Subject: RE: How to tell when a user first log's in?
Peter,
Thanks, however I do have 1 more question for you. I do have the top frame
saying request.getRemoteUser, but how do I automatically cause that frame
to get refreshed when a user first log's in? On logout, I can do that
because it accesses logout.jsp (just issue a JavaScript Refresh command.)
Thanks!
Jeremy - [EMAIL PROTECTED]
At 10:23 AM 5/12/2001 -0600, you wrote:
Ad 1) %=request.getRemoteUser()% (obviously you'll have to reload the
top
frame)
Ad 2) You will need to subclass DataSourceUerManager and add that
functionality
It would be possible to add that functionality on a page that the
logged-in
User is guaranteeed to go to, bad that would be bad design
--peter
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jeremy C
Sent: Saturday, May 12, 2001 7:44 PM
To: Orion-Interest
Subject: How to tell when a user first log's in?
Is it possible to attach a hook, or some means of detemining when a user
first log's in? I use DataSourceUserManager...
What I would like to do is two things,
1. In my top frame, indicate who you are logged in as
2. Check the last time you have changed your password, and prompt for a
password change if it's past 3 months.
Thanks!
Jeremy - [EMAIL PROTECTED]
RE: Session Invalidate Exception
Kesav,
In order to release memory, we need to make sure that we use enterprise
objects which are pooled by orion. As far as I know, these include
stateless session beans, entity beans and stateful session beans. Each of
these are recovered by the appserver as they fall out of context. Servlets
and jsp's are also pooled by the appserver. However, the servlet context may
include objects which stay in memory...but not real memory. These object
should be serialized as the servlet time's out, or looses its session.
One of the ideas behind application servers in general, and j2ee
specifically is that we register our objects with the appserver, and the
appserver should handle recovery of any objects (and therefore, memory) as
necessary.
If orion needs the memory, it will recover the objects which aren't being
used, because they are part of a pool of objects.
Don't worry so much about the memory stuff, because those guys in Sweden are
taking care of this for us.
Regards,
the elephantwalker
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Kesav Kumar
Sent: Saturday, May 12, 2001 4:58 PM
To: Orion-Interest
Subject: Re: Session Invalidate Exception
By invalidating session we generally think that all the memory will be
released but if invalidate doesn't actually release memore and make the
session object null then we need to have our own measures for releasing the
memory. My concern is more for the memore rathar than the program error
handling.
- Original Message -
From: Noah Nordrum [EMAIL PROTECTED]
To: Orion-Interest [EMAIL PROTECTED]
Sent: Saturday, May 12, 2001 1:31 PM
Subject: Re: Session Invalidate Exception
So have the page where the user enters their credentials wax their
session,
then the validation of the credentials page will create a new session.
why do you have to invalidate the session? why can't you just do:
===
HttpSession session = request.getSession();
Enumeration attributes = session.getAttributeNames();
while (attributes.hasMoreElements()) {
session.removeAttribute((String)attributes.nextElement());
}
===
Then you'll basically have a fresh session (except for a few exceptions).
Noah
- Original Message -
From: Jeff Schnitzer [EMAIL PROTECTED]
To: Orion-Interest [EMAIL PROTECTED]
Sent: Saturday, May 12, 2001 1:31 PM
Subject: RE: Session Invalidate Exception
I don't think that excludes the desired behavior, which is that you
should be able to invalidate a session and then create a new one.
It appears that session invalidate() is setting a flag in the session
object causing it to be cleaned up sometime later. Since the only way
to logout a user is to call invalidate(), this causes some headaches.
Ideally I would like my login submit page to a) discard existing
credentials and b) try new credentials. This way if a user was already
logged in, the net result of a new login attempt will be the
unauthenticated state. Unfortunately I can't call
getSession().invalidate();
session = getSession();
because what I get is the old session, which is going to disappear at
the end of the method, the call to RoleManager.login() notwithstanding.
Furthermore, a failed call to RoleManager.login() does *not* discard
existing credentials. The only way to accomplish the original goal is
to put the invalidate() on every page with a login form.
Ok, this isn't super critical, but it's annoying nevertheless.
Jeff
-Original Message-
From: Noah Nordrum [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 11, 2001 7:09 PM
To: Orion-Interest
Subject: Re: Session Invalidate Exception
Session Invalidate ExceptionServlet Spec
==
7.2 Creating a Session
Because HTTP is a request-response based protocol, a session
is considered
to be new until a client joins it. A client joins a session
when session
tracking information has been successfully returned to the
server indicating
that a session has been established. Until the client joins a
session, it
cannot be assumed that the next request from the client will
be recognized
as part of the session.
The session is considered to be new if either of the
following is true:
. The client does not yet know about the session
. The client chooses not to join a session. This implies that
the servlet
container has no mechanism by which to associate a request
with a previous
request.
A Servlet Developer must design their application to handle a
situation
where a client has not, can not, or will not join a session.
==
That last line is what specifically applies to your situation, only
backwards. In this case you are invalidating the HttpSession,
but the client
doesn't yet know about
