You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Felix Meschberger <fm...@gmail.com> on 2007/09/28 22:50:44 UTC

Re: Jira 379

Hi Rob,

(taking this discussion to the list if you don't mind)

I ran your test bundle and found and issue with resource access
(FELIX-382). Other than that, it seems, that your test bundle runs just
fine.

But another error occurred to me: Should servlets registered with
different OSGi HttpContext instances share HttpSessions or not ? I
assume, they should not. And this is where my solution will probably
break - didn't test it given that the JSESSIONID cookie is located at
the root path, all servlets would probably share the session - unless we
would add some session multiplexing in a HttpServletRequestWrapper which
takes the OSGi HttpContext into account ?

This would just have the minor (?) drawback, that different sessions
with actually the same session ID are used for the servlets of the
different OSGi HttpContext instances.

Regards
Felix

Am Freitag, den 28.09.2007, 15:57 +0100 schrieb Rob Walker:
> You're welcome. Happy hunting.
> 
> This was a bug in the original Oscar code that someone pointed out to
> me, and took some brain scratching to solve. I also seem to recall
> this was the reason for the rather ungainly use of multiple
> registrations under '/' - but my memory could be wrong there..
> 
> I create an "http-test" bundle that had some very simple (and far from
> exhaustive) test cases to check variables got maintained between
> calls.
> 
> I think this is the HTTP Test bundle that's still in the OBR if you
> want it for reference:
> 
> http://oscar-osgi.sourceforge.net/
> 
> Regards
> 
> -- Rob
> 
> Felix Meschberger wrote: 
> > Hi Rob,
> > 
> > Yes, I just posted my response. Thanks for pointing me in that
> > direction. I will look into that issue and if there is something wrong,
> > I will just open a new JIRA for me to solve :-)
> > 
> > Regards
> > Felix
> > 
> > Am Freitag, den 28.09.2007, 15:37 +0100 schrieb Rob Walker:
> >   
> > > Felix
> > > 
> > > Not sure if you saw it, just added a comment on verifying http session 
> > > context / cookie etc. handlinga across multiple requests and browser 
> > > sessions with your new mods.
> > > 
> > > Regards
> > > 
> > > -- Rob
> > > 
> > > 
> > > Ascert - Taking systems to the Edge
> > > robw@ascert.com
> > > +44 (0)20 7488 3470
> > > www.ascert.com
> > > 
> > >     
> > 
> >   
> 
> -- 
> 
> 
> Ascert - Taking systems to the Edge
> robw@ascert.com
> +44 (0)20 7488 3470
> www.ascert.com


Re: Jira 379

Posted by Rob Walker <ro...@ascert.com>.
Felix

No probs taking to list for discussion - it's an area that I'm sure will 
benefit from input.

My view would be that HTTP sessions etc. should only be shared across 
servlets that share a common HttpContext - so whilst it may not affect 
too many people if this isn't followed, I suspect it's more rigorous if 
we can achieve it. It's always seemed to me, although I don't recall of 
the OSGi spec states this, that the purpose of allowing a HttpContext to 
be shared is to explicitly allow sharing of session items etc. across 
servlets. And hence the converse is, that where you don't use a common 
context such items shouldn't be shared.

Aiming to achieve that is pretty much why the Http service ended up 
coded the way it was - so that all servlets with a common HttpContext 
saw the saw view of attributes, sessions, cookies etc.

Happy to defer to greater wisdom on Http handling and/or the strict OSGi 
Http Service if others have a better take on this.

Regards

-- Rob

Felix Meschberger wrote:
> Hi Rob,
>
> (taking this discussion to the list if you don't mind)
>
> I ran your test bundle and found and issue with resource access
> (FELIX-382). Other than that, it seems, that your test bundle runs just
> fine.
>
> But another error occurred to me: Should servlets registered with
> different OSGi HttpContext instances share HttpSessions or not ? I
> assume, they should not. And this is where my solution will probably
> break - didn't test it given that the JSESSIONID cookie is located at
> the root path, all servlets would probably share the session - unless we
> would add some session multiplexing in a HttpServletRequestWrapper which
> takes the OSGi HttpContext into account ?
>
> This would just have the minor (?) drawback, that different sessions
> with actually the same session ID are used for the servlets of the
> different OSGi HttpContext instances.
>
> Regards
> Felix
>
> Am Freitag, den 28.09.2007, 15:57 +0100 schrieb Rob Walker:
>   
>> You're welcome. Happy hunting.
>>
>> This was a bug in the original Oscar code that someone pointed out to
>> me, and took some brain scratching to solve. I also seem to recall
>> this was the reason for the rather ungainly use of multiple
>> registrations under '/' - but my memory could be wrong there..
>>
>> I create an "http-test" bundle that had some very simple (and far from
>> exhaustive) test cases to check variables got maintained between
>> calls.
>>
>> I think this is the HTTP Test bundle that's still in the OBR if you
>> want it for reference:
>>
>> http://oscar-osgi.sourceforge.net/
>>
>> Regards
>>
>> -- Rob
>>
>> Felix Meschberger wrote: 
>>     
>>> Hi Rob,
>>>
>>> Yes, I just posted my response. Thanks for pointing me in that
>>> direction. I will look into that issue and if there is something wrong,
>>> I will just open a new JIRA for me to solve :-)
>>>
>>> Regards
>>> Felix
>>>
>>> Am Freitag, den 28.09.2007, 15:37 +0100 schrieb Rob Walker:
>>>   
>>>       
>>>> Felix
>>>>
>>>> Not sure if you saw it, just added a comment on verifying http session 
>>>> context / cookie etc. handlinga across multiple requests and browser 
>>>> sessions with your new mods.
>>>>
>>>> Regards
>>>>
>>>> -- Rob
>>>>
>>>>
>>>> Ascert - Taking systems to the Edge
>>>> robw@ascert.com
>>>> +44 (0)20 7488 3470
>>>> www.ascert.com
>>>>
>>>>     
>>>>         
>>>   
>>>       
>> -- 
>>
>>
>> Ascert - Taking systems to the Edge
>> robw@ascert.com
>> +44 (0)20 7488 3470
>> www.ascert.com
>>     
>
>   

-- 


Ascert - Taking systems to the Edge
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com