From: Greg W. <gr...@mo...> - 2003-10-16 08:24:55
|
Moving this to Jetty-discuss as a more appropriate forum... I was talking gibberish about the cookie domain. I meant the session cookie path. Currently that *IS* set to the context path of the context that creates the session. So if we let the target context set the cookie, it will not be sent to request for the original context. If we let the original context set the cookie path, then it will not be sent in any requests that go to the target context directly. Thus the context init param for the sesson path needs to be set to make sure that the path is set to something both contexts can see. I still think it is a reasonable thing to insist that the calling context also creates a session, so that we can force the IDs to be in sync. In summary to make cross context sessions I think we need to: 1) make all contexts have the useRequestedSessionId turned on 2) make all contexts set the session cookie path to / or some other common path. 3) The code will make sure that a session is created in the calling context before creating one in the target context. The ID will be reused. I can see we'll need an FAQ for this. cheers Greg Wilkins wrote: > > There are still a number of issues with cross context sessions that > I do not think are fixed by simply allows the target context to > create the session cookie. > > Firstly, there is the issue of cookie domains. These should really > be set to the context path. But whose context??? luckily jetty does > not set the domain unless it is set as a context init attribute, but > then whose context should we use?? > > The other problem is what if both contexts try to make a session at > the same time? They could both think up different session IDs. > > So I am now thinking that the solution is that before a target context > creates a session - it will force the calling context to create a session > (and thus manage the session ID). If no session previous existed in either > context, the target context will make sure it uses the id of the newly > created session from the calling context (by specializing > getRequestedSessionId). > > But I need to think about this a little bit more.... > Michael Stephenson wrote: > I hate to reply to myself, but I'll do it to let people know I don't > need an answer my original query and just in case someone else has the > same problem and finds this thread. > > From looking through the code the way to make jetty reuse the session > id's for the second context is to have a web-jetty.xml file like: > > <?xml version="1.0" encoding="ISO-8859-1"?> > <!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure > 1.2//EN" "http://jetty.mortbay.org/configure_1_2.dtd"> > > <Configure class="org.mortbay.jetty.servlet.WebApplicationContext"> > <Call name="getServletHandler"> > <Call name="getSessionManager"> > <Call name="setUseRequestedId"> > <Arg type="boolean">true</Arg> > </Call> > </Call> > </Call> > </Configure> > > This means you will get the same session each request, *providing the > visitor already has a suitable cookie* (requesting a session in the > first context is an easy way to ensure this). > > Unfortunately it's always marked as new, as access() doesn't seem to be > called on it. I believe this to be a bug, the following patch fixes this > problem: > > *** org/mortbay/jetty/servlet/Dispatcher.java.orig Fri Oct 10 > 16:19:02 2003--- org/mortbay/jetty/servlet/Dispatcher.java Fri Oct 10 > 16:21:33 2003 > *************** > *** 157,162 **** > --- 157,171 ---- > DispatcherResponse response = new > DispatcherResponse(httpServletResponse); > _request=request; > > + // If we are going to a different context, mark the session as > + // accessed > + if (_xContext) { > + HttpSession session=request.getSession(false); > + if (session!=null) > + ((SessionManager.Session)session).access(); > + Code.debug("session=",session); > + } > + > if (!_include) > servletResponse.resetBuffer(); > > I'm knew to jetty, so I don't know where I'm supposed to send this patch > for consideration, is it ok here? Or should I send it to jetty-discuss? > > As I said earlier this only solves the problem if there is already a > cookie in existance. When a new session is made in the context of a > Dispatcher no cookie is ever sent. > > At the moment the cookie setting behaviour only exists inside > ServletHttpRequest, the following patch shifts it into > AbstractSessionManager where it can be called whenever a new session is > created, this seems reasonable to me, but I've only been using jetty a > matter of days... > > *** org/mortbay/jetty/servlet/AbstractSessionManager.java.orig Fri > Oct 10 16:40:13 2003 > --- org/mortbay/jetty/servlet/AbstractSessionManager.java Fri Oct 10 > 17:06:12 2003 > *************** > *** 16,21 **** > --- 16,22 ---- > import java.util.Map; > import java.util.Random; > import javax.servlet.ServletContext; > + import javax.servlet.http.Cookie; > import javax.servlet.http.HttpServletRequest; > import javax.servlet.http.HttpSession; > import javax.servlet.http.HttpSessionAttributeListener; > *************** > *** 196,204 **** > for(int i=0;i<_sessionListeners.size();i++) > ((HttpSessionListener)_sessionListeners.get(i)) > .sessionCreated(event); > return session; > } > ! > > /* ------------------------------------------------------------ */ > protected abstract Session newSession(HttpServletRequest request); > --- 197,248 ---- > for(int i=0;i<_sessionListeners.size();i++) > ((HttpSessionListener)_sessionListeners.get(i)) > .sessionCreated(event); > + > + // Set the session cookie in the response > + if (_handler.isUsingCookies() && !cookieAlreadySet(request)) > + setSessionCookie(request, session); > + > return session; > } > ! > ! /* ------------------------------------------------------------ */ > ! private boolean cookieAlreadySet(HttpServletRequest request) { > ! return (request.getRequestedSessionId() != null > ! && request.isRequestedSessionIdFromCookie() > ! && _useRequestedId); > ! } > ! > ! > ! /* ------------------------------------------------------------ */ > ! private void setSessionCookie(HttpServletRequest request, > HttpSession session) > ! { > ! ServletHttpRequest httpRequest = > ServletHttpRequest.unwrap(request); > ! Cookie cookie = new Cookie(__SessionCookie,session.getId()); > ! String path= > ! _handler.getServletContext().getInitParameter(__SessionPath); > ! if (path==null) > ! path=httpRequest.getContextPath(); > ! if (path==null || path.length()==0) > ! path="/"; > ! > ! String domain= > ! > _handler.getServletContext().getInitParameter(__SessionDomain); > ! if (domain!=null) > ! cookie.setDomain(domain); > ! > ! String maxAge= > ! _handler.getServletContext().getInitParameter(__MaxAge); > ! if (maxAge!=null) > ! cookie.setMaxAge(Integer.parseInt(maxAge)); > ! else > ! cookie.setMaxAge(-1); > ! > ! cookie.setPath(path); > ! httpRequest > ! .getServletHttpResponse() > ! .getHttpResponse() > ! .addSetCookie(cookie,false); > ! } > > /* ------------------------------------------------------------ */ > protected abstract Session newSession(HttpServletRequest request); > *** org/mortbay/jetty/servlet/ServletHttpRequest.java.orig Fri Oct 10 > 16:54:51 2003 > --- org/mortbay/jetty/servlet/ServletHttpRequest.java Fri Oct 10 > 16:55:21 2003*************** > *** 499,536 **** > } > > if (_session == null && create) > - { > _session = _servletHandler.newHttpSession(this); > - if (_servletHandler.isUsingCookies()) > - { > - Cookie cookie = > - new > Cookie(SessionManager.__SessionCookie,_session.getId()); > - String path= > - _servletHandler.getServletContext() > - .getInitParameter(SessionManager.__SessionPath); > - if (path==null) > - path=getContextPath(); > - if (path==null || path.length()==0) > - path="/"; > - > - String domain= > - _servletHandler.getServletContext() > - .getInitParameter(SessionManager.__SessionDomain); > - if (domain!=null) > - cookie.setDomain(domain); > - > - String maxAge= > - _servletHandler.getServletContext() > - .getInitParameter(SessionManager.__MaxAge); > - if (maxAge!=null) > - cookie.setMaxAge(Integer.parseInt(maxAge)); > - else > - cookie.setMaxAge(-1); > - > - cookie.setPath(path); > - > _servletHttpResponse.getHttpResponse().addSetCookie(cookie,false); > - } > - } > > return _session; > } > --- 499,505 ---- > > If there's anything which can be improved in these patches, please let > me know and I'll happily fix them. > > Thanks, > > Michael > > Michael Stephenson wrote: > >> No, unfortunately it doesn't. :) >> >> That paragraph states that the second context's session should be >> different from the first, this is what I was expecting. I don't think >> that paragraph states that the callee servlet cannot expect it's >> session to be preserved between requests. :) >> >> The first paragraph of that section mentions that the same cookie can >> be used for both sessions, I believe this is what tomcat does, this is >> what I was alluding to when I mentioned that if a cookie was created >> in the first context, that the value of this wasn't used to find a >> session in the second context. >> >> I can see that without that clarification, that paragraph of my >> original email could be viewed as a strange digression into >> irrelevance. :) >> >> Michael >> >> Chris Haynes wrote: >> >>> Does reading the Servlet Spec (e.g. section SRV 7.3 in version 2.3 ) >>> help? >>> >>> See especially the last paragraph. >>> >>> Chris >>> >>> >>> "Michael Stephenson" asked >>> >>>> Hi, >>>> >>>> I have a problem with jetty 4.2.12. When I forward a request to a >>> >>> >>> different >>> >>>> context, and in the second context call getSession(), there is no >>> >>> >>> cookie set and >>> >>>> the session does not persist. >>>> >>>> That isn't a very good description of the problem so I'll elaborate >>> >>> >>> on it with a >>> >>>> simple example, I have two webapps - webapp1 and webapp2. >>>> >>>> webapp1 is defined as: >>>> >>>> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web >>> >>> >>> Application >>> >>>> 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd" > >>>> <web-app> >>>> <display-name>servlet1 context</display-name> >>>> >>>> <servlet> >>>> <servlet-name>Servlet1</servlet-name> >>>> <servlet-class>Servlet1</servlet-class> >>>> <load-on-startup>0</load-on-startup> >>>> </servlet> >>>> >>>> <servlet-mapping> >>>> <servlet-name>Servlet1</servlet-name> >>>> <url-pattern>/*</url-pattern> >>>> </servlet-mapping> >>>> >>>> </web-app> >>>> >>>> Servlet1.java is: >>>> >>>> import javax.servlet.http.*; >>>> import javax.servlet.*; >>>> import java.io.*; >>>> >>>> public class Servlet1 extends HttpServlet { >>>> >>>> public void service(HttpServletRequest request, >>>> HttpServletResponse response) >>>> throws ServletException, IOException { >>>> >>>> String uri = request.getRequestURI(); >>>> >>>> uri = removeContextPath(uri); >>>> >>>> ServletContext context = getServletConfig().getServletContext() >>>> .getContext(uri); >>>> >>>> if (context == null) { >>>> send404(request, response); >>>> return; >>>> } >>>> >>>> uri = removeContextPath(uri); >>>> >>>> RequestDispatcher rd = context.getRequestDispatcher(uri); >>>> >>>> if (rd != null) { >>>> rd.forward(request, response); >>>> } else { >>>> send404(request, response); >>>> } >>>> } >>>> >>>> private String removeContextPath(String uri) { >>>> if (uri.indexOf("/") == -1) { >>>> return uri; >>>> } >>>> return uri.substring(uri.indexOf("/", 1)); >>>> } >>>> >>>> private void send404(HttpServletRequest request, >>>> HttpServletResponse response) throws IOException { >>>> response.sendError(HttpServletResponse.SC_NOT_FOUND); >>>> } >>>> } >>>> >>>> webapp2 is defined as: >>>> >>>> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web >>> >>> >>> Application >>> >>>> 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd" > >>>> <web-app> >>>> <display-name>Servlet2 context</display-name> >>>> >>>> <servlet> >>>> <servlet-name>Servlet2</servlet-name> >>>> <servlet-class>Servlet2</servlet-class> >>>> <load-on-startup>0</load-on-startup> >>>> </servlet> >>>> >>>> <servlet-mapping> >>>> <servlet-name>Servlet2</servlet-name> >>>> <url-pattern>/*</url-pattern> >>>> </servlet-mapping> >>>> >>>> </web-app> >>>> >>>> Where Servlet2.java is: >>>> >>>> import javax.servlet.http.*; >>>> import javax.servlet.*; >>>> import java.io.*; >>>> >>>> public class Servlet2 extends HttpServlet { >>>> >>>> public void service(HttpServletRequest request, >>>> HttpServletResponse response) >>>> throws ServletException, IOException { >>>> HttpSession session = request.getSession(); >>>> >>>> Writer out = response.getWriter(); >>>> out.write(session.isNew() ? "created new session" >>>> : "using old session"); >>>> out.close(); >>>> } >>>> } >>>> >>>> When I send a request like: >>>> >>>> /webapp1/webapp2/jeff >>>> >>>> Servlet1 will find the context for /webapp2/jeff, and then forward >>> >>> >>> the request >>> >>>> to /jeff inside webapp2 - which is matched by Servlet2. >>>> >>>> I would expect this first request to Servlet2 to create a session in >>> >>> >>> the second >>> >>>> context, and return the text "created new session" to the user. When >>> >>> >>> the url is >>> >>>> reloaded I would expect to see the words "using old session" echoed >>> >>> >>> to the visitor. >>> >>>> >>>> This works as I would expect in a fresh tomcat installation but not >>> >>> >>> in a fresh >>> >>>> installation of jetty. In jetty a fresh session is created with each >>> >>> >>> request. >>> >>>> >>>> Tomcat sends the following response headers: >>>> >>>> HTTP/1.x 200 OK >>>> Date: Thu, 09 Oct 2003 11:14:17 GMT >>>> Server: Apache Tomcat/4.0 (HTTP/1.1 Connector) >>>> Transfer-Encoding: chunked >>>> Set-Cookie: >>> >>> >>> JSESSIONID=E7C1B28626F0E62220C5A3D013C80164;Path=/webapp1 >>> >>>> >>>> Where as jetty sends headers: >>>> >>>> HTTP/1.x 200 OK >>>> Jetty-Request: GET /webapp1/webapp2/jeff HTTP/1.1 >>>> Date: Thu, 09 Oct 2003 11:15:29 GMT >>>> Server: Jetty/4.2.12 (Linux/2.4.19 i386 java/1.4.2_01) >>>> Transfer-Encoding: chunked >>>> >>>> So you can see that jetty doesn't set a cookie with it's response, >>> >>> >>> so there's no >>> >>>> way that the session could persist. >>>> >>>> If I alter Servlet1 to call getSession() then jetty will set a >>> >>> >>> cookie, but that >>> >>>> cookie value doesn't seem to be used as an id for the second >>> >>> >>> context's session, >>> >>>> and each request still generates a fresh session. >>>> >>>> Is there a way of configuring jetty so this little example will >>> >>> >>> function the way >>> >>>> I've described? >>>> >>>> Thanks for reading this far, and for any help you can give me! >>>> >>>> Michael >>>> >>>> -- >>>> Web Applications Developer >>>> Open World Ltd, 11 Riverside Court, Riverside Road, Bath, BA2 3DZ. >>>> Tel: +44 1225 444950 Fax: +44 1225 336738 >>> >>> >>> http://www.openworld.co.uk/ >>> >>>> >>>> CONFIDENTIALITY NOTICE >>>> The information contained in this message is confidential, intended >>> >>> >>> only for >>> >>>> the use of the individual or the entity named as recipient. If the >>> >>> >>> reader of >>> >>>> this message is not that recipient, you are notified that any >>> >>> >>> dissemination, >>> >>>> distribution or copy of this message is strictly prohibited. If you >>> >>> >>> have >>> >>>> received this message in error, please immediately notify us by >>> >>> >>> telephone on >>> >>>> the number above. Your co-operation is appreciated. >>>> >>>> >>>> >>>> ------------------------------------------------------- >>>> This SF.net email is sponsored by: SF.net Giveback Program. >>>> SourceForge.net hosts over 70,000 Open Source Projects. >>>> See the people who have HELPED US provide better services: >>>> Click here: http://sourceforge.net/supporters.php >>>> _______________________________________________ >>>> Jetty-support mailing list >>>> Jet...@li... >>>> https://lists.sourceforge.net/lists/listinfo/jetty-support >>>> >>>> >>> >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.net email is sponsored by: SF.net Giveback Program. >>> SourceForge.net hosts over 70,000 Open Source Projects. >>> See the people who have HELPED US provide better services: >>> Click here: http://sourceforge.net/supporters.php >>> _______________________________________________ >>> Jetty-support mailing list >>> Jet...@li... >>> https://lists.sourceforge.net/lists/listinfo/jetty-support >>> >> >> > > -- Greg Wilkins<gr...@mo...> Phone/fax: +44 7092063462 Mort Bay Consulting Australia and UK. http://www.mortbay.com |
From: Greg W. <gr...@mo...> - 2003-10-16 12:59:45
|
I've done some more thinking on this, and I'm taking a step back. The whole setting of the servletHandler on the request is a throw back to the old way that Dispatchers were done - that of changing the original request. It also makes it very difficult to manipulate the session of the original request. It is not a good way to proceed. So I'm now working on a patch that never changes the servletHandler in the first place. It is only used for methods that are relative to the servlet context anyway, and these need to change after a dispatch between contexts. So this is good stuff - it has located a little bit of old kruft hanging about and the whole dispatcher will be better for it's removal. Stay tuned for a new patch soonish. regards Greg Wilkins wrote: > Moving this to Jetty-discuss as a more appropriate forum... > > I was talking gibberish about the cookie domain. > > I meant the session cookie path. Currently that *IS* set to the > context path of the context that creates the session. > > So if we let the target context set the cookie, it will not be sent > to request for the original context. > > If we let the original context set the cookie path, then it will > not be sent in any requests that go to the target context directly. > > Thus the context init param for the sesson path needs to be set to make > sure that the path is set to something both contexts can see. > > I still think it is a reasonable thing to insist that the calling > context also creates a session, so that we can force the IDs to be > in sync. > > In summary to make cross context sessions I think we need to: > > 1) make all contexts have the useRequestedSessionId turned on > 2) make all contexts set the session cookie path to / or some other > common path. > 3) The code will make sure that a session is created in the calling > context before creating one in the target context. The ID will be > reused. > > I can see we'll need an FAQ for this. > > cheers > > > Greg Wilkins wrote: > >> >> There are still a number of issues with cross context sessions that >> I do not think are fixed by simply allows the target context to >> create the session cookie. >> >> Firstly, there is the issue of cookie domains. These should really >> be set to the context path. But whose context??? luckily jetty does >> not set the domain unless it is set as a context init attribute, but >> then whose context should we use?? >> >> The other problem is what if both contexts try to make a session at >> the same time? They could both think up different session IDs. >> >> So I am now thinking that the solution is that before a target context >> creates a session - it will force the calling context to create a session >> (and thus manage the session ID). If no session previous existed in >> either >> context, the target context will make sure it uses the id of the newly >> created session from the calling context (by specializing >> getRequestedSessionId). >> >> But I need to think about this a little bit more.... >> > > > Michael Stephenson wrote: > >> I hate to reply to myself, but I'll do it to let people know I don't >> need an answer my original query and just in case someone else has the >> same problem and finds this thread. >> >> From looking through the code the way to make jetty reuse the session >> id's for the second context is to have a web-jetty.xml file like: >> >> <?xml version="1.0" encoding="ISO-8859-1"?> >> <!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure >> 1.2//EN" "http://jetty.mortbay.org/configure_1_2.dtd"> >> >> <Configure class="org.mortbay.jetty.servlet.WebApplicationContext"> >> <Call name="getServletHandler"> >> <Call name="getSessionManager"> >> <Call name="setUseRequestedId"> >> <Arg type="boolean">true</Arg> >> </Call> >> </Call> >> </Call> >> </Configure> >> >> This means you will get the same session each request, *providing the >> visitor already has a suitable cookie* (requesting a session in the >> first context is an easy way to ensure this). >> >> Unfortunately it's always marked as new, as access() doesn't seem to >> be called on it. I believe this to be a bug, the following patch fixes >> this problem: >> >> *** org/mortbay/jetty/servlet/Dispatcher.java.orig Fri Oct 10 >> 16:19:02 2003--- org/mortbay/jetty/servlet/Dispatcher.java Fri Oct >> 10 16:21:33 2003 >> *************** >> *** 157,162 **** >> --- 157,171 ---- >> DispatcherResponse response = new >> DispatcherResponse(httpServletResponse); >> _request=request; >> >> + // If we are going to a different context, mark the session as >> + // accessed >> + if (_xContext) { >> + HttpSession session=request.getSession(false); >> + if (session!=null) >> + ((SessionManager.Session)session).access(); >> + Code.debug("session=",session); >> + } >> + >> if (!_include) >> servletResponse.resetBuffer(); >> >> I'm knew to jetty, so I don't know where I'm supposed to send this >> patch for consideration, is it ok here? Or should I send it to >> jetty-discuss? >> >> As I said earlier this only solves the problem if there is already a >> cookie in existance. When a new session is made in the context of a >> Dispatcher no cookie is ever sent. >> >> At the moment the cookie setting behaviour only exists inside >> ServletHttpRequest, the following patch shifts it into >> AbstractSessionManager where it can be called whenever a new session >> is created, this seems reasonable to me, but I've only been using >> jetty a matter of days... >> >> *** org/mortbay/jetty/servlet/AbstractSessionManager.java.orig Fri >> Oct 10 16:40:13 2003 >> --- org/mortbay/jetty/servlet/AbstractSessionManager.java Fri Oct >> 10 17:06:12 2003 >> *************** >> *** 16,21 **** >> --- 16,22 ---- >> import java.util.Map; >> import java.util.Random; >> import javax.servlet.ServletContext; >> + import javax.servlet.http.Cookie; >> import javax.servlet.http.HttpServletRequest; >> import javax.servlet.http.HttpSession; >> import javax.servlet.http.HttpSessionAttributeListener; >> *************** >> *** 196,204 **** >> for(int i=0;i<_sessionListeners.size();i++) >> ((HttpSessionListener)_sessionListeners.get(i)) >> .sessionCreated(event); >> return session; >> } >> ! >> >> /* ------------------------------------------------------------ */ >> protected abstract Session newSession(HttpServletRequest request); >> --- 197,248 ---- >> for(int i=0;i<_sessionListeners.size();i++) >> ((HttpSessionListener)_sessionListeners.get(i)) >> .sessionCreated(event); >> + >> + // Set the session cookie in the response >> + if (_handler.isUsingCookies() && !cookieAlreadySet(request)) >> + setSessionCookie(request, session); >> + >> return session; >> } >> ! >> ! /* ------------------------------------------------------------ */ >> ! private boolean cookieAlreadySet(HttpServletRequest request) { >> ! return (request.getRequestedSessionId() != null >> ! && request.isRequestedSessionIdFromCookie() >> ! && _useRequestedId); >> ! } >> ! >> ! >> ! /* ------------------------------------------------------------ */ >> ! private void setSessionCookie(HttpServletRequest request, >> HttpSession session) >> ! { >> ! ServletHttpRequest httpRequest = >> ServletHttpRequest.unwrap(request); >> ! Cookie cookie = new Cookie(__SessionCookie,session.getId()); >> ! String path= >> ! >> _handler.getServletContext().getInitParameter(__SessionPath); >> ! if (path==null) >> ! path=httpRequest.getContextPath(); >> ! if (path==null || path.length()==0) >> ! path="/"; >> ! >> ! String domain= >> ! >> _handler.getServletContext().getInitParameter(__SessionDomain); >> ! if (domain!=null) >> ! cookie.setDomain(domain); >> ! >> ! String maxAge= >> ! _handler.getServletContext().getInitParameter(__MaxAge); >> ! if (maxAge!=null) >> ! cookie.setMaxAge(Integer.parseInt(maxAge)); >> ! else >> ! cookie.setMaxAge(-1); >> ! >> ! cookie.setPath(path); >> ! httpRequest >> ! .getServletHttpResponse() >> ! .getHttpResponse() >> ! .addSetCookie(cookie,false); >> ! } >> >> /* ------------------------------------------------------------ */ >> protected abstract Session newSession(HttpServletRequest request); >> *** org/mortbay/jetty/servlet/ServletHttpRequest.java.orig Fri Oct >> 10 16:54:51 2003 >> --- org/mortbay/jetty/servlet/ServletHttpRequest.java Fri Oct 10 >> 16:55:21 2003*************** >> *** 499,536 **** >> } >> >> if (_session == null && create) >> - { >> _session = _servletHandler.newHttpSession(this); >> - if (_servletHandler.isUsingCookies()) >> - { >> - Cookie cookie = >> - new >> Cookie(SessionManager.__SessionCookie,_session.getId()); >> - String path= >> - _servletHandler.getServletContext() >> - .getInitParameter(SessionManager.__SessionPath); >> - if (path==null) >> - path=getContextPath(); >> - if (path==null || path.length()==0) >> - path="/"; >> - >> - String domain= >> - _servletHandler.getServletContext() >> - .getInitParameter(SessionManager.__SessionDomain); >> - if (domain!=null) >> - cookie.setDomain(domain); >> - >> - String maxAge= >> - _servletHandler.getServletContext() >> - .getInitParameter(SessionManager.__MaxAge); >> - if (maxAge!=null) >> - cookie.setMaxAge(Integer.parseInt(maxAge)); >> - else >> - cookie.setMaxAge(-1); >> - >> - cookie.setPath(path); >> - >> _servletHttpResponse.getHttpResponse().addSetCookie(cookie,false); >> - } >> - } >> >> return _session; >> } >> --- 499,505 ---- >> >> If there's anything which can be improved in these patches, please let >> me know and I'll happily fix them. >> >> Thanks, >> >> Michael >> >> Michael Stephenson wrote: >> >>> No, unfortunately it doesn't. :) >>> >>> That paragraph states that the second context's session should be >>> different from the first, this is what I was expecting. I don't think >>> that paragraph states that the callee servlet cannot expect it's >>> session to be preserved between requests. :) >>> >>> The first paragraph of that section mentions that the same cookie can >>> be used for both sessions, I believe this is what tomcat does, this >>> is what I was alluding to when I mentioned that if a cookie was >>> created in the first context, that the value of this wasn't used to >>> find a session in the second context. >>> >>> I can see that without that clarification, that paragraph of my >>> original email could be viewed as a strange digression into >>> irrelevance. :) >>> >>> Michael >>> >>> Chris Haynes wrote: >>> >>>> Does reading the Servlet Spec (e.g. section SRV 7.3 in version 2.3 ) >>>> help? >>>> >>>> See especially the last paragraph. >>>> >>>> Chris >>>> >>>> >>>> "Michael Stephenson" asked >>>> >>>>> Hi, >>>>> >>>>> I have a problem with jetty 4.2.12. When I forward a request to a >>>> >>>> >>>> >>>> different >>>> >>>>> context, and in the second context call getSession(), there is no >>>> >>>> >>>> >>>> cookie set and >>>> >>>>> the session does not persist. >>>>> >>>>> That isn't a very good description of the problem so I'll elaborate >>>> >>>> >>>> >>>> on it with a >>>> >>>>> simple example, I have two webapps - webapp1 and webapp2. >>>>> >>>>> webapp1 is defined as: >>>>> >>>>> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web >>>> >>>> >>>> >>>> Application >>>> >>>>> 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd" > >>>>> <web-app> >>>>> <display-name>servlet1 context</display-name> >>>>> >>>>> <servlet> >>>>> <servlet-name>Servlet1</servlet-name> >>>>> <servlet-class>Servlet1</servlet-class> >>>>> <load-on-startup>0</load-on-startup> >>>>> </servlet> >>>>> >>>>> <servlet-mapping> >>>>> <servlet-name>Servlet1</servlet-name> >>>>> <url-pattern>/*</url-pattern> >>>>> </servlet-mapping> >>>>> >>>>> </web-app> >>>>> >>>>> Servlet1.java is: >>>>> >>>>> import javax.servlet.http.*; >>>>> import javax.servlet.*; >>>>> import java.io.*; >>>>> >>>>> public class Servlet1 extends HttpServlet { >>>>> >>>>> public void service(HttpServletRequest request, >>>>> HttpServletResponse response) >>>>> throws ServletException, IOException { >>>>> >>>>> String uri = request.getRequestURI(); >>>>> >>>>> uri = removeContextPath(uri); >>>>> >>>>> ServletContext context = getServletConfig().getServletContext() >>>>> .getContext(uri); >>>>> >>>>> if (context == null) { >>>>> send404(request, response); >>>>> return; >>>>> } >>>>> >>>>> uri = removeContextPath(uri); >>>>> >>>>> RequestDispatcher rd = context.getRequestDispatcher(uri); >>>>> >>>>> if (rd != null) { >>>>> rd.forward(request, response); >>>>> } else { >>>>> send404(request, response); >>>>> } >>>>> } >>>>> >>>>> private String removeContextPath(String uri) { >>>>> if (uri.indexOf("/") == -1) { >>>>> return uri; >>>>> } >>>>> return uri.substring(uri.indexOf("/", 1)); >>>>> } >>>>> >>>>> private void send404(HttpServletRequest request, >>>>> HttpServletResponse response) throws IOException { >>>>> response.sendError(HttpServletResponse.SC_NOT_FOUND); >>>>> } >>>>> } >>>>> >>>>> webapp2 is defined as: >>>>> >>>>> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web >>>> >>>> >>>> >>>> Application >>>> >>>>> 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd" > >>>>> <web-app> >>>>> <display-name>Servlet2 context</display-name> >>>>> >>>>> <servlet> >>>>> <servlet-name>Servlet2</servlet-name> >>>>> <servlet-class>Servlet2</servlet-class> >>>>> <load-on-startup>0</load-on-startup> >>>>> </servlet> >>>>> >>>>> <servlet-mapping> >>>>> <servlet-name>Servlet2</servlet-name> >>>>> <url-pattern>/*</url-pattern> >>>>> </servlet-mapping> >>>>> >>>>> </web-app> >>>>> >>>>> Where Servlet2.java is: >>>>> >>>>> import javax.servlet.http.*; >>>>> import javax.servlet.*; >>>>> import java.io.*; >>>>> >>>>> public class Servlet2 extends HttpServlet { >>>>> >>>>> public void service(HttpServletRequest request, >>>>> HttpServletResponse response) >>>>> throws ServletException, IOException { >>>>> HttpSession session = request.getSession(); >>>>> >>>>> Writer out = response.getWriter(); >>>>> out.write(session.isNew() ? "created new session" >>>>> : "using old session"); >>>>> out.close(); >>>>> } >>>>> } >>>>> >>>>> When I send a request like: >>>>> >>>>> /webapp1/webapp2/jeff >>>>> >>>>> Servlet1 will find the context for /webapp2/jeff, and then forward >>>> >>>> >>>> >>>> the request >>>> >>>>> to /jeff inside webapp2 - which is matched by Servlet2. >>>>> >>>>> I would expect this first request to Servlet2 to create a session in >>>> >>>> >>>> >>>> the second >>>> >>>>> context, and return the text "created new session" to the user. When >>>> >>>> >>>> >>>> the url is >>>> >>>>> reloaded I would expect to see the words "using old session" echoed >>>> >>>> >>>> >>>> to the visitor. >>>> >>>>> >>>>> This works as I would expect in a fresh tomcat installation but not >>>> >>>> >>>> >>>> in a fresh >>>> >>>>> installation of jetty. In jetty a fresh session is created with each >>>> >>>> >>>> >>>> request. >>>> >>>>> >>>>> Tomcat sends the following response headers: >>>>> >>>>> HTTP/1.x 200 OK >>>>> Date: Thu, 09 Oct 2003 11:14:17 GMT >>>>> Server: Apache Tomcat/4.0 (HTTP/1.1 Connector) >>>>> Transfer-Encoding: chunked >>>>> Set-Cookie: >>>> >>>> >>>> >>>> JSESSIONID=E7C1B28626F0E62220C5A3D013C80164;Path=/webapp1 >>>> >>>>> >>>>> Where as jetty sends headers: >>>>> >>>>> HTTP/1.x 200 OK >>>>> Jetty-Request: GET /webapp1/webapp2/jeff HTTP/1.1 >>>>> Date: Thu, 09 Oct 2003 11:15:29 GMT >>>>> Server: Jetty/4.2.12 (Linux/2.4.19 i386 java/1.4.2_01) >>>>> Transfer-Encoding: chunked >>>>> >>>>> So you can see that jetty doesn't set a cookie with it's response, >>>> >>>> >>>> >>>> so there's no >>>> >>>>> way that the session could persist. >>>>> >>>>> If I alter Servlet1 to call getSession() then jetty will set a >>>> >>>> >>>> >>>> cookie, but that >>>> >>>>> cookie value doesn't seem to be used as an id for the second >>>> >>>> >>>> >>>> context's session, >>>> >>>>> and each request still generates a fresh session. >>>>> >>>>> Is there a way of configuring jetty so this little example will >>>> >>>> >>>> >>>> function the way >>>> >>>>> I've described? >>>>> >>>>> Thanks for reading this far, and for any help you can give me! >>>>> >>>>> Michael >>>>> >>>>> -- >>>>> Web Applications Developer >>>>> Open World Ltd, 11 Riverside Court, Riverside Road, Bath, BA2 3DZ. >>>>> Tel: +44 1225 444950 Fax: +44 1225 336738 >>>> >>>> >>>> >>>> http://www.openworld.co.uk/ >>>> >>>>> >>>>> CONFIDENTIALITY NOTICE >>>>> The information contained in this message is confidential, intended >>>> >>>> >>>> >>>> only for >>>> >>>>> the use of the individual or the entity named as recipient. If the >>>> >>>> >>>> >>>> reader of >>>> >>>>> this message is not that recipient, you are notified that any >>>> >>>> >>>> >>>> dissemination, >>>> >>>>> distribution or copy of this message is strictly prohibited. If you >>>> >>>> >>>> >>>> have >>>> >>>>> received this message in error, please immediately notify us by >>>> >>>> >>>> >>>> telephone on >>>> >>>>> the number above. Your co-operation is appreciated. >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------- >>>>> This SF.net email is sponsored by: SF.net Giveback Program. >>>>> SourceForge.net hosts over 70,000 Open Source Projects. >>>>> See the people who have HELPED US provide better services: >>>>> Click here: http://sourceforge.net/supporters.php >>>>> _______________________________________________ >>>>> Jetty-support mailing list >>>>> Jet...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/jetty-support >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------- >>>> This SF.net email is sponsored by: SF.net Giveback Program. >>>> SourceForge.net hosts over 70,000 Open Source Projects. >>>> See the people who have HELPED US provide better services: >>>> Click here: http://sourceforge.net/supporters.php >>>> _______________________________________________ >>>> Jetty-support mailing list >>>> Jet...@li... >>>> https://lists.sourceforge.net/lists/listinfo/jetty-support >>>> >>> >>> >> >> > > > > |
From: Paul D. <pda...@ig...> - 2003-10-17 12:01:46
|
I have an application which makes an HTTP connection to Jetty on the = localhost to acquire the output of a JSP. The application always resides = on the same host as the Jetty server itself. I've known for sometime = that it's therefore somewhat unnecessary to make a network connection = each time to a localhost. Is there anyway to modify Jetty so that I = might acquire a Reader or Inputstream?=20 |
From: Greg W. <gr...@mo...> - 2003-10-22 10:57:38
|
There are ways to do this, but they are a bit of hassle and probably not worth the effort. Local loop back networks are often very efficient. Is there a specific need you have for this? If you REALLY REALLY want this, the approach would be to write an in-JVM listener that would provide the HttpConnection that connects directly to the stream that you are using. This is probably a day or twos effort. Paul Daniell wrote: > I have an application which makes an HTTP connection to Jetty on the > localhost to acquire the output of a JSP. The application always resides > on the same host as the Jetty server itself. I've known for sometime > that it's therefore somewhat unnecessary to make a network connection > each time to a localhost. Is there anyway to modify Jetty so that I > might acquire a Reader or Inputstream? > |
From: Paul D. <pda...@ig...> - 2003-10-22 11:27:57
|
Hi Greg, I'm working on an open-source project called TTemplating. We've just recently opened a sourceforge account. For a lot of high volume websites, like newspapers, magazines, gov sites, etc., it's either unfeasible or too expensive to deliver a large portion of the available content through servlets. Often it's just easier to deliver the content through static HTML pages --especially when the skin of the pages won't change very often. However, JSP offers a lot of rewards -- especially with JSTL and introspection on already available bean classes. Moreover, most J2EE engineers are already trained in the syntax. The aim of TTemplating is to allow J2EE developers to use JSP as a transformation engine. That is, create JSP documents that will ultimately produce sets of static HTML pages (rather than a dynamic app). For VERY large sites, transforming their whole dataset into HTML pages can take weeks. Right now, TT hits a deployed Jetty server and captures the output to a file. Introducing a dependency on HTTPConnections might, I *suspect*, be the cause of a little delay. I'm trying to eliminate it -- at least for the aim of elegance. Anyway, that's the story about this request. I could help you code the necessary changes if I can get some guidance about where to go next. Thanks, Paul ----- Original Message ----- From: "Greg Wilkins" <gr...@mo...> To: <jet...@li...>; <pda...@ig...> Sent: Tuesday, October 21, 2003 11:56 PM Subject: Re: [jetty-discuss] Grabbing a reader from Jetty > > There are ways to do this, but they are a bit of hassle and > probably not worth the effort. > > Local loop back networks are often very efficient. > > Is there a specific need you have for this? If you REALLY REALLY > want this, the approach would be to write an in-JVM listener that > would provide the HttpConnection that connects directly to the > stream that you are using. > > This is probably a day or twos effort. > > > Paul Daniell wrote: > > I have an application which makes an HTTP connection to Jetty on the > > localhost to acquire the output of a JSP. The application always resides > > on the same host as the Jetty server itself. I've known for sometime > > that it's therefore somewhat unnecessary to make a network connection > > each time to a localhost. Is there anyway to modify Jetty so that I > > might acquire a Reader or Inputstream? > > > |
From: Greg W. <gr...@mo...> - 2003-10-28 07:46:37
|
Paul, sounds like a reasonable thing to do. I suggest you have a look at test/src/org/mortbay/http/TestRFC2616.java I think it does what you want (more or less). cheers Paul Daniell wrote: > Hi Greg, > > I'm working on an open-source project called TTemplating. We've just > recently opened a sourceforge account. > > For a lot of high volume websites, like newspapers, magazines, gov sites, > etc., it's either unfeasible or too expensive to deliver a large portion of > the available content through servlets. Often it's just easier to deliver > the content through static HTML pages --especially when the skin of the > pages won't change very often. > > However, JSP offers a lot of rewards -- especially with JSTL and > introspection on already available bean classes. Moreover, most J2EE > engineers are already trained in the syntax. > > The aim of TTemplating is to allow J2EE developers to use JSP as a > transformation engine. That is, create JSP documents that will ultimately > produce sets of static HTML pages (rather than a dynamic app). > > For VERY large sites, transforming their whole dataset into HTML pages can > take weeks. Right now, TT hits a deployed Jetty server and captures the > output to a file. Introducing a dependency on HTTPConnections might, I > *suspect*, be the cause of a little delay. I'm trying to eliminate it -- at > least for the aim of elegance. > > Anyway, that's the story about this request. I could help you code the > necessary changes if I can get some guidance about where to go next. > > Thanks, > Paul > > ----- Original Message ----- > From: "Greg Wilkins" <gr...@mo...> > To: <jet...@li...>; <pda...@ig...> > Sent: Tuesday, October 21, 2003 11:56 PM > Subject: Re: [jetty-discuss] Grabbing a reader from Jetty > > > >>There are ways to do this, but they are a bit of hassle and >>probably not worth the effort. >> >>Local loop back networks are often very efficient. >> >>Is there a specific need you have for this? If you REALLY REALLY >>want this, the approach would be to write an in-JVM listener that >>would provide the HttpConnection that connects directly to the >>stream that you are using. >> >>This is probably a day or twos effort. >> >> >>Paul Daniell wrote: >> >>>I have an application which makes an HTTP connection to Jetty on the >>>localhost to acquire the output of a JSP. The application always resides >>>on the same host as the Jetty server itself. I've known for sometime >>>that it's therefore somewhat unnecessary to make a network connection >>>each time to a localhost. Is there anyway to modify Jetty so that I >>>might acquire a Reader or Inputstream? >>> >> > > > > ------------------------------------------------------- > This SF.net email is sponsored by OSDN developer relations > Here's your chance to show off your extensive product knowledge > We want to know what you know. Tell us and you have a chance to win $100 > http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 > _______________________________________________ > jetty-discuss mailing list > jet...@li... > https://lists.sourceforge.net/lists/listinfo/jetty-discuss > |
From: Chaitanya(Hotmail) <cha...@ho...> - 2003-10-22 12:25:44
|
Dear All, I have a small problem in managing sessions between WAS and JBOSS. My application is such that first login screen comes from JBOSS and when login information is provided I am keeping total information in session and passing that session to WAS. Till here I am able to maintain the values in the session but when at a certain point I am redirecting the session back to JBOSS, the session is null. Could any one pls tell solution for this? While I was searching for this I found some interesting document in following IP, but doesnt know where to implement this as I dont have source of JBOSS (Dispatcher.java) but only have class files. https://sourceforge.net/mailarchive/forum.php?thread_id=3293537&forum_id=565 7 Please explain me. Thanks Chaitanya. |
From: Greg W. <gr...@mo...> - 2003-10-28 07:49:13
|
Can you describe what you are doing a bit more??? Is this 2 WWW sites trying to share a session? If so it can't be done. It can share a session ID, but you have to set the domain and or path or the session cookie appropriately. Eitherway, I need more detail about what you are trying to do? regards Chaitanya(Hotmail) wrote: > Dear All, > > I have a small problem in managing sessions between > WAS and JBOSS. > > My application is such that first login screen comes > from JBOSS and when login information is provided > I am keeping total information in session and passing that > session to WAS. Till here I am able to maintain the values > in the session but when at a certain point I am redirecting the > session back to JBOSS, the session is null. > > Could any one pls tell solution for this? > > While I was searching for this I found some interesting > document in following IP, but doesnt know where to > implement this as I dont have source of JBOSS (Dispatcher.java) > but only have class files. > https://sourceforge.net/mailarchive/forum.php?thread_id=3293537&forum_id=565 > 7 > > Please explain me. > > > Thanks > Chaitanya. > > > ------------------------------------------------------- > This SF.net email is sponsored by OSDN developer relations > Here's your chance to show off your extensive product knowledge > We want to know what you know. Tell us and you have a chance to win $100 > http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 > _______________________________________________ > jetty-discuss mailing list > jet...@li... > https://lists.sourceforge.net/lists/listinfo/jetty-discuss > |
From: Chaitanya(Hotmail) <cha...@ho...> - 2003-10-29 06:16:48
|
Thanks for your response. Let me explain you in detail. I have two applications one in JBOSS and other in WAS. First User accesses the JBOSS's login page and enters required data for user authentication, if user is valid, then iam setting some required values to the session and passing the session to WAS and user gets a second screen from WAS as loggedin successful and till here I have got the session but as per fucntionality at a point I will redirect the same session to JBOSS but here I am getting session as null. Yes! I have my both application servers in same domain. These are not WWW sites and these are in LAN. Could you please explain me regarding setting the domain or path or the session cookie. I found in the following URL that there is a problem of session contexts but to fix that it says to change the code in Dispatcher class file but , can I convert that class file to java file & add this code and copy the file in jar file of org.mortbay.jetty.jar to make it work. https://sourceforge.net/mailarchive/forum.php?thread_id=3293537&forum_id=565 7 Please refer to URL and explain me. Thanks Chaitanya. ----- Original Message ----- From: Greg Wilkins <gr...@mo...> To: <jet...@li...>; <cha...@ho...> Sent: Tuesday, October 28, 2003 1:17 PM Subject: Re: [jetty-discuss] Problem with two web apps session. > > Can you describe what you are doing a bit more??? > > Is this 2 WWW sites trying to share a session? If so > it can't be done. It can share a session ID, but you > have to set the domain and or path or the session cookie > appropriately. > > Eitherway, I need more detail about what you are trying to do? > > regards > > Chaitanya(Hotmail) wrote: > > Dear All, > > > > I have a small problem in managing sessions between > > WAS and JBOSS. > > > > My application is such that first login screen comes > > from JBOSS and when login information is provided > > I am keeping total information in session and passing that > > session to WAS. Till here I am able to maintain the values > > in the session but when at a certain point I am redirecting the > > session back to JBOSS, the session is null. > > > > Could any one pls tell solution for this? > > > > While I was searching for this I found some interesting > > document in following IP, but doesnt know where to > > implement this as I dont have source of JBOSS (Dispatcher.java) > > but only have class files. > > https://sourceforge.net/mailarchive/forum.php?thread_id=3293537&forum_id=565 > > 7 > > > > Please explain me. > > > > > > Thanks > > Chaitanya. > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by OSDN developer relations > > Here's your chance to show off your extensive product knowledge > > We want to know what you know. Tell us and you have a chance to win $100 > > http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 > > _______________________________________________ > > jetty-discuss mailing list > > jet...@li... > > https://lists.sourceforge.net/lists/listinfo/jetty-discuss > > > > > |
From: Greg W. <gr...@mo...> - 2003-10-30 06:53:20
|
Chaitanya, When you say "passing the session to WAS", what do you mean? Do you mean redirect the next request to the WAS server? Sessions cannot be shared, passed or redirected. Sessions are private to an application server. However you can arrange for application servers to share a session ID, so requests can be redirect between servers and both will maintain their sessions. If you are using URL rewriting for session tracking, then this should work without and special configuration (except note a end of this email). If you are using cookies, then if webapplication at jboss.acme.com/myapp will normaly set a session cookie with a header like: Set-Cookie: JSESSION_ID=a4j39s9jd3; path=/myapp Because cookies default to only be sent to the same host that created them, this means that the JSESSION_ID cookie will only be included in requests to jboss.acme.com/myapp/* If you send a request to was.acme.com/anything or jboss.acme.com/somethingElse then the cookie will not be included and a new session will probably be created. But if a request is redirected back to the jboss server, the orginal cookie will be sent again and the session will be seen. However, with Jetty you can set the domain and path of the session cookies. So you could have a set cookie generated like: Set-Cooke: JSESSION_ID=a4j39s9jd3; path=/; domain=acme.com This says send the session id to any request in the acme.com domain. Thus the app servers can share the session ID. BUT NOT THE SESSION CONTENTS. One other complication is that some servers will not reuse a session ID. So if a session ID is presented for a session that does not exist, it is discarded and a new ID created. Jetty can be configured to either accept or ignore such invalid session IDs. If was does not reuse invalid session IDs, then any attempt to use cookies or URL rewriting will result in the session ID being ignored and a new ID being set - this will mean you loose your session when going back to JBoss. I hope this helps a little bit??? Chaitanya(Hotmail) wrote: > Thanks for your response. > > Let me explain you in detail. > > I have two applications one in JBOSS and other in WAS. > First User accesses the JBOSS's login page and enters required > data for user authentication, if user is valid, then iam setting some > required values to the session and passing the session to WAS and > user gets a second screen from WAS as loggedin successful and till > here I have got the session but as per fucntionality at a point I will > redirect the > same session to JBOSS but here I am getting session as null. > > Yes! I have my both application servers in same domain. > These are not WWW sites and these are in LAN. > > Could you please explain me regarding setting the domain or path > or the session cookie. > > I found in the following URL that there is a problem of session contexts > but to fix that it says to change the code in Dispatcher class file but , > can I > convert that class file to java file & add this code and copy the file in > jar file of org.mortbay.jetty.jar > to make it work. > https://sourceforge.net/mailarchive/forum.php?thread_id=3293537&forum_id=565 > 7 > > Please refer to URL and explain me. > > Thanks > Chaitanya. > > > > > ----- Original Message ----- > From: Greg Wilkins <gr...@mo...> > To: <jet...@li...>; <cha...@ho...> > Sent: Tuesday, October 28, 2003 1:17 PM > Subject: Re: [jetty-discuss] Problem with two web apps session. > > > >>Can you describe what you are doing a bit more??? >> >>Is this 2 WWW sites trying to share a session? If so >>it can't be done. It can share a session ID, but you >>have to set the domain and or path or the session cookie >>appropriately. >> >>Eitherway, I need more detail about what you are trying to do? >> >>regards >> >>Chaitanya(Hotmail) wrote: >> >>>Dear All, >>> >>>I have a small problem in managing sessions between >>>WAS and JBOSS. >>> >>>My application is such that first login screen comes >>>from JBOSS and when login information is provided >>>I am keeping total information in session and passing that >>>session to WAS. Till here I am able to maintain the values >>>in the session but when at a certain point I am redirecting the >>>session back to JBOSS, the session is null. >>> >>>Could any one pls tell solution for this? >>> >>>While I was searching for this I found some interesting >>>document in following IP, but doesnt know where to >>>implement this as I dont have source of JBOSS (Dispatcher.java) >>>but only have class files. >>> > > https://sourceforge.net/mailarchive/forum.php?thread_id=3293537&forum_id=565 > >>>7 >>> >>>Please explain me. >>> >>> >>>Thanks >>>Chaitanya. >>> >>> >>>------------------------------------------------------- >>>This SF.net email is sponsored by OSDN developer relations >>>Here's your chance to show off your extensive product knowledge >>>We want to know what you know. Tell us and you have a chance to win $100 >>>http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 >>>_______________________________________________ >>>jetty-discuss mailing list >>>jet...@li... >>>https://lists.sourceforge.net/lists/listinfo/jetty-discuss >>> >> >> >> > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > jetty-discuss mailing list > jet...@li... > https://lists.sourceforge.net/lists/listinfo/jetty-discuss > |
From: Chaitanya(Hotmail) <cha...@ho...> - 2003-11-03 10:28:18
|
Greg, Thanks for your solutions. Though I confused you bit with my sentences, you got the point and now your answers solve the problem in my application. Thanks Chaitanya. ----- Original Message ----- From: Greg Wilkins <gr...@mo...> To: <jet...@li...> Cc: <cha...@ho...> Sent: Thursday, October 30, 2003 12:22 PM Subject: Re: [jetty-discuss] Problem with two web apps session. > Chaitanya, > > When you say "passing the session to WAS", what do you mean? > Do you mean redirect the next request to the WAS server? > > Sessions cannot be shared, passed or redirected. Sessions are > private to an application server. However you can arrange for > application servers to share a session ID, so requests can be > redirect between servers and both will maintain their sessions. > > If you are using URL rewriting for session tracking, then this > should work without and special configuration (except note a end > of this email). > > If you are using cookies, then if webapplication at jboss.acme.com/myapp > will normaly set a session cookie with a header like: > > Set-Cookie: JSESSION_ID=a4j39s9jd3; path=/myapp > > Because cookies default to only be sent to the same host that created > them, this means that the JSESSION_ID cookie will only be > included in requests to jboss.acme.com/myapp/* > > If you send a request to was.acme.com/anything or jboss.acme.com/somethingElse > then the cookie will not be included and a new session will probably > be created. But if a request is redirected back to the jboss server, the > orginal cookie will be sent again and the session will be seen. > > However, with Jetty you can set the domain and path of the session > cookies. So you could have a set cookie generated like: > > Set-Cooke: JSESSION_ID=a4j39s9jd3; path=/; domain=acme.com > > This says send the session id to any request in the acme.com domain. > > Thus the app servers can share the session ID. BUT NOT THE SESSION CONTENTS. > > > One other complication is that some servers will not reuse a session ID. > So if a session ID is presented for a session that does not exist, it is > discarded and a new ID created. Jetty can be configured to either accept > or ignore such invalid session IDs. > > If was does not reuse invalid session IDs, then any attempt to use cookies > or URL rewriting will result in the session ID being ignored and a new ID > being set - this will mean you loose your session when going back to JBoss. > > I hope this helps a little bit??? > > > > > > > > > > > Chaitanya(Hotmail) wrote: > > Thanks for your response. > > > > Let me explain you in detail. > > > > I have two applications one in JBOSS and other in WAS. > > First User accesses the JBOSS's login page and enters required > > data for user authentication, if user is valid, then iam setting some > > required values to the session and passing the session to WAS and > > user gets a second screen from WAS as loggedin successful and till > > here I have got the session but as per fucntionality at a point I will > > redirect the > > same session to JBOSS but here I am getting session as null. > > > > Yes! I have my both application servers in same domain. > > These are not WWW sites and these are in LAN. > > > > Could you please explain me regarding setting the domain or path > > or the session cookie. > > > > I found in the following URL that there is a problem of session contexts > > but to fix that it says to change the code in Dispatcher class file but , > > can I > > convert that class file to java file & add this code and copy the file in > > jar file of org.mortbay.jetty.jar > > to make it work. > > https://sourceforge.net/mailarchive/forum.php?thread_id=3293537&forum_id=565 > > 7 > > > > Please refer to URL and explain me. > > > > Thanks > > Chaitanya. > > > > > > > > > > ----- Original Message ----- > > From: Greg Wilkins <gr...@mo...> > > To: <jet...@li...>; <cha...@ho...> > > Sent: Tuesday, October 28, 2003 1:17 PM > > Subject: Re: [jetty-discuss] Problem with two web apps session. > > > > > > > >>Can you describe what you are doing a bit more??? > >> > >>Is this 2 WWW sites trying to share a session? If so > >>it can't be done. It can share a session ID, but you > >>have to set the domain and or path or the session cookie > >>appropriately. > >> > >>Eitherway, I need more detail about what you are trying to do? > >> > >>regards > >> > >>Chaitanya(Hotmail) wrote: > >> > >>>Dear All, > >>> > >>>I have a small problem in managing sessions between > >>>WAS and JBOSS. > >>> > >>>My application is such that first login screen comes > >>>from JBOSS and when login information is provided > >>>I am keeping total information in session and passing that > >>>session to WAS. Till here I am able to maintain the values > >>>in the session but when at a certain point I am redirecting the > >>>session back to JBOSS, the session is null. > >>> > >>>Could any one pls tell solution for this? > >>> > >>>While I was searching for this I found some interesting > >>>document in following IP, but doesnt know where to > >>>implement this as I dont have source of JBOSS (Dispatcher.java) > >>>but only have class files. > >>> > > > > https://sourceforge.net/mailarchive/forum.php?thread_id=3293537&forum_id=565 > > > >>>7 > >>> > >>>Please explain me. > >>> > >>> > >>>Thanks > >>>Chaitanya. > >>> > >>> > >>>------------------------------------------------------- > >>>This SF.net email is sponsored by OSDN developer relations > >>>Here's your chance to show off your extensive product knowledge > >>>We want to know what you know. Tell us and you have a chance to win $100 > >>>http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 > >>>_______________________________________________ > >>>jetty-discuss mailing list > >>>jet...@li... > >>>https://lists.sourceforge.net/lists/listinfo/jetty-discuss > >>> > >> > >> > >> > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: SF.net Giveback Program. > > Does SourceForge.net help you be more productive? Does it > > help you create better code? SHARE THE LOVE, and help us help > > YOU! Click Here: http://sourceforge.net/donate/ > > _______________________________________________ > > jetty-discuss mailing list > > jet...@li... > > https://lists.sourceforge.net/lists/listinfo/jetty-discuss > > > > > |