Return-Path: Delivered-To: apmail-incubator-openwebbeans-user-archive@minotaur.apache.org Received: (qmail 46706 invoked from network); 21 Feb 2009 16:04:20 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 21 Feb 2009 16:04:20 -0000 Received: (qmail 67778 invoked by uid 500); 21 Feb 2009 16:04:20 -0000 Delivered-To: apmail-incubator-openwebbeans-user-archive@incubator.apache.org Received: (qmail 67755 invoked by uid 500); 21 Feb 2009 16:04:20 -0000 Mailing-List: contact openwebbeans-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: openwebbeans-user@incubator.apache.org Delivered-To: mailing list openwebbeans-user@incubator.apache.org Received: (qmail 67746 invoked by uid 99); 21 Feb 2009 16:04:20 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 21 Feb 2009 08:04:20 -0800 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of mikewse@hotmail.com designates 65.54.246.108 as permitted sender) Received: from [65.54.246.108] (HELO bay0-omc1-s36.bay0.hotmail.com) (65.54.246.108) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 21 Feb 2009 16:04:11 +0000 Received: from hotmail.com ([64.4.38.78]) by bay0-omc1-s36.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 21 Feb 2009 08:03:51 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 21 Feb 2009 08:03:50 -0800 Message-ID: Received: from 83.227.224.93 by BAY116-DAV6.phx.gbl with DAV; Sat, 21 Feb 2009 16:03:46 +0000 X-Originating-IP: [83.227.224.93] X-Originating-Email: [mikewse@hotmail.com] X-Sender: mikewse@hotmail.com From: "Mike Wilson" To: Subject: RE: session creation Date: Sat, 21 Feb 2009 17:03:07 +0100 Message-ID: <033001c9943d$e2a26820$0a01a8c0@mikedeskxp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0331_01C99446.4466D020" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <906632.31967.qm@web38201.mail.mud.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcmUN0UW4997GAPrQlqBVM7TajXSvgAA3yDQ X-OriginalArrivalTime: 21 Feb 2009 16:03:50.0816 (UTC) FILETIME=[FC92BA00:01C9943D] X-Virus-Checked: Checked by ClamAV on apache.org This is a multi-part message in MIME format. ------=_NextPart_000_0331_01C99446.4466D020 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Gurkan, Thanks for quick and helpful responses. It sounds great that you will look into not forcing sessions - thanks! Hopefully it will not become too complicated to set up the session context on demand once it is needed. I pinged the JSR Expert Group about this as well, and it will be interesting to see what/if they respond. Regarding conversation context being tied to JSF; I had a quick look at the spec and the conversation mechanism described there doesn't seem to hard-wire against JSF. If I understand it correctly it goes roughly like this: 1. if the current incoming request isn't specifying a conversation id, a new temporary conversation context is created 2. this temporary conversation context "dies" with the request if not promoted to "long-running" (and thus in practive just acts like a parallel request context) 3. if Conversation.begin() is called the conversation is promoted to long-running, and it is registered with an id on the session (this would also be a place to forcibly create the session) 4. the conversation id is transferred to the browser by f ex redirecting to a url that contains it as a parameter so the browser will ask for the same conversation on subsequent requests Points (2) and (3) have no dependency to any specific web framework, and point (1) and (4) has specification text that says they will be taken care of automatically if using JSF, but should be possible to handle programatically if using another web framework. Ideally, this would mean that all bundled contexts could actually live in "openwebbeans-core" (talking in modularization terms again) and only the automagic stuff in point (1) and (4) would be implemented in "openwebbeans-jsf" (and the same goes for other web framework-specific modules). Best regards Mike _____ From: Gurkan Erdogdu [mailto:gurkanerdogdu@yahoo.com] Sent: den 21 februari 2009 16:15 To: openwebbeans-user@incubator.apache.org Subject: Re: session creation Hi Mike, Thanks for commenting. In the specification there are some parts that are hardly depend on the other specification, for example : Conversation Scope --> JSF, EntityManagers --> JPA, Session Beans --> EJB. As Mark stated, we have been thinking and working on the code base to divide it into the multi-modular structure, but it takes time. As coming to session question, actually I use the *initSessionContext* method in *initRequestContext* method to reconstruct the thread local ve session scope and application scope. I am going to refactor this not to use request.getSession(), instead use request.getSession(false); And we are always looking for the contributions :) Thanks again; /Gurkan _____ From: Mike Wilson To: openwebbeans-user@incubator.apache.org Sent: Saturday, February 21, 2009 11:49:26 AM Subject: RE: session creation Hi Gurkan, If I understand it correctly, WebBeans is supposed to be useful for other web frameworks than JSF. Or are you saying that the default WB context support is hard-wired to JSF, and other web frameworks should implement their own support for this through lower-level APIs in WB? It would certainly be useful if the ready-made contexts were built to allow for as much reuse as possible. Always forcing session creation makes it harder to reuse this code for stateless scenarios. Just discussing hypothetically; is there anything in the WB model that actually requires this "early" session creation, or could it in theory be deferred to when a request is referring to a bean on session or conversation scope? Best regards Mike _____ From: Gurkan Erdogdu [mailto:gurkanerdogdu@yahoo.com] Sent: den 20 februari 2009 16:03 To: openwebbeans-user@incubator.apache.org Subject: Re: session creation Hi; Actually this may not be a problem. Indeed, contexts is related with JSF semantics and session is created everytime in JSF. Thanks; /Gurkan _____ From: Mike Wilson To: openwebbeans-user@incubator.apache.org Sent: Thursday, February 19, 2009 7:21:56 PM Subject: session creation I got things running with Jetty 6.1.15rc4 and now I have a question about session creation: Will OpenWebBeans always force a session to be created? In the current codebase (see below) this seems to be the case. If possible, it would be nice if sessions only were created on-demand when a component needs session (or conversation) storage. Doing it this way would make it possible to have stateless requests that avoid the overhead of session creation when possible. ContextFactory.java: public static void initRequestContext(HttpServletRequest request) { requestContext.set(new RequestContext());// set thread local requestContext.get().setActive(true); if (request != null) { HttpSession session = request.getSession(); initSessionContext(session); initApplicationContext(request.getSession().getServletContext()); } } Best regards Mike Wilson ------=_NextPart_000_0331_01C99446.4466D020 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Gurkan,
 
Thanks for quick and helpful responses. It = sounds great=20 that you will look into not forcing sessions - thanks! Hopefully it = will=20 not become too complicated to set up the session context on demand once = it is=20 needed. I pinged the JSR Expert Group about this as well, and it will be = interesting to see what/if they respond.
 
Regarding conversation context being tied to = JSF; I had a=20 quick look at the spec and the conversation mechanism described there = doesn't=20 seem to hard-wire against JSF. If I understand it correctly it goes = roughly like=20 this:
  1. if the current incoming request isn't = specifying a=20 conversation id, a new temporary conversation context is created
  2. this temporary conversation context "dies" = with the=20 request if not promoted to "long-running" (and thus in practive just = acts=20 like a parallel request context)
  3. if Conversation.begin() is called the = conversation is=20 promoted to long-running, and it is registered with an id on the = session (this=20 would also be a place to forcibly create the = session)
  4. the conversation id is transferred to the = browser by f ex=20 redirecting to a url that contains it as a parameter so the browser = will ask=20 for the same conversation on subsequent = requests
Points (2) and (3) have no dependency to any = specific=20 web framework, and point (1) and (4) has specification text that=20 says they will be taken care of automatically = if using JSF,=20 but should be possible to handle programatically if using another web=20 framework.

Ideally, this would mean that all bundled contexts could = actually live in=20 "openwebbeans-core" (talking in modularization terms again) and only the = automagic stuff in point (1) and (4) would be implemented in = "openwebbeans-jsf"=20 (and the same goes for other web framework-specific modules).=20
 
Best=20 regards
Mike
From: Gurkan Erdogdu=20 [mailto:gurkanerdogdu@yahoo.com]
Sent: den 21 februari 2009 = 16:15
To: = openwebbeans-user@incubator.apache.org
Subject:=20 Re: session creation

Hi Mike,

Thanks for commenting. In the specification there = are=20 some parts that are hardly depend on the other specification, for = example :=20 Conversation Scope --> JSF, EntityManagers --> JPA, Session = Beans -->=20 EJB. As Mark stated, we have been thinking and  working on the = code base=20 to divide it into the multi-modular structure, but  it takes=20 time.

As coming to session question, actually I use the=20 *initSessionContext* method in *initRequestContext* method to = reconstruct the=20 thread local ve session scope and application scope. I am going to = refactor=20 this not to use request.getSession(), instead use=20 request.getSession(false);

And we are always looking for the=20 contributions :)

Thanks again;

/Gurkan

From: Mike Wilson=20 <mikewse@hotmail.com>
To:=20 openwebbeans-user@incubator.apache.org
Sent: Saturday, February 21, = 2009=20 11:49:26 AM
Subject: RE:=20 session creation

Hi Gurkan,
 
If I understand it correctly, WebBeans is = supposed to be=20 useful for other web frameworks than JSF. Or are you saying that the = default=20 WB context support is hard-wired to JSF, and other web frameworks = should=20 implement their own support for this through lower-level APIs in=20 WB?
It would certainly be useful if the = ready-made contexts=20 were built to allow for as much reuse as possible. Always forcing = session=20 creation makes it harder to reuse this code for stateless=20 scenarios.
 
Just discussing hypothetically; is there = anything in the=20 WB model that actually requires this "early" session creation, or = could it in=20 theory be deferred to when a request is referring to a bean on session = or=20 conversation scope?
 
Best=20 regards
Mike

From: Gurkan Erdogdu=20 [mailto:gurkanerdogdu@yahoo.com]
Sent: den 20 februari = 2009=20 16:03
To:=20 openwebbeans-user@incubator.apache.org
Subject: Re: = session=20 creation

Hi;

Actually this may not be a problem. Indeed, contexts = is=20 related with JSF semantics and session is created everytime in=20 JSF.

Thanks;

/Gurkan

From: Mike Wilson=20 <mikewse@hotmail.com>
To:=20 openwebbeans-user@incubator.apache.org
Sent: Thursday, February 19, = 2009=20 7:21:56 PM
Subject: session=20 creation

I got things running with Jetty 6.1.15rc4 and = now I=20 have a question
about session creation:

Will OpenWebBeans = always=20 force a session to be created? In the
current codebase (see = below) this=20 seems to be the case. If
possible, it would be nice if sessions = only=20 were created on-demand
when a component needs session (or = conversation)=20 storage.
Doing it this way would make it possible to have = stateless=20 requests
that avoid the overhead of session creation when=20 possible.

ContextFactory.java:

    public = static=20 void initRequestContext(HttpServletRequest request)
    = {
        requestContext.set(new = RequestContext());//=20 set thread local
       =20 requestContext.get().setActive(true);

      =   if=20 (request !=3D null)
        {
  =    =20       HttpSession session =3D = request.getSession();
 =20           = initSessionContext(session);
 =20          =20 =

initApplicationContext(request.getSession().getServletContext());=
 =20       }
    }

Best = regards
Mike=20 = Wilson



------=_NextPart_000_0331_01C99446.4466D020--