cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <coc...@leverageweb.com>
Subject [PROPOSAL] Cocoon HttpSession implement javax HttpSession (Was Re: javax.servlet.http.HttpSession access from XSP?)
Date Tue, 03 Feb 2004 14:43:00 GMT
Would anyone be opposed to making 
org.apache.cocoon.environment.http.HttpSession implement 
javax.servlet.http.HttpSession?  It already does actually implement it's 
non-deprecated methods but does not declare it, so cannot be cast or 
used polymorphic-ly.  See below trail from users for what seems to be 
valid use-case.

For now, the deprecated methods could just be implemented to throw 
UnsupportedOperationException or something.

Geoff

Geoff Howard wrote:

> Joerg Heinicke wrote:
> 
>> On 02.02.2004 23:20, Phil Blake wrote:
>>
>>>>> How do I access the javax.servlet.http.HttpSession from within XSP?
>>>>> I know I have xsp-session but it is a 
>>>>> org.apache.cocoon.environment.Session
>>>>> And request.getSession() also returns a 
>>>>> org.apache.cocoon.environment.Session
>>>>> I've seen that the org.apache.cocoon.environment.http.HttpSession 
>>>>> is created from the javax.servlet.http.HttpSession but I can't see 
>>>>> how to access it from there.
>>>>
>>>>
>>>> I don't know exactly as I do not have written the code, but I think 
>>>> hiding the HttpSession was intended. You only shall access the 
>>>> Cocoon specific Session.
>>>>
>>>> What exactly do you want to do?
>>>
>>>
>>> I am using the database framework Cayenne. Like most web based 
>>> client/server frameworks, it requires that you pass it an HttpSession 
>>> to retrieve a context for that HttpSession.
>>>
>>> As there is no option here, I must supply the HttpSession, the 
>>> question is - does cocoon provide access to it?
>>>
>>> I guess I could re-create a standard HttpSession from the cocoon 
>>> HttpSession, but usually when I'm backed into such an ugly hack, it's 
>>> because I haven't found the "proper" way. I'm assuming that cocoon 
>>> would not completely obscure the standard HttpSession - even if it's 
>>> wrapped it. Does anyone know the real story?
>>
>>
>> Cocoon's HttpSession is just a wrapper around standard servlet 
>> HttpSession, but does not really give access to it. Have a look into 
>> the source code:
>> http://cvs.apache.org/viewcvs.cgi/*checkout*/cocoon-2.1/src/java/org/apache/cocoon/environment/http/HttpSession.java?content-type=text%2Fplain&rev=1.2

>>
>> As the wrappedSession field has only default access and the class is 
>> even final there remains only the way of adding an additional class in 
>> the same package to get the unwrapped HttpSession - that's obviously 
>> the "ugly hack".
>> I cc Carsten as he wrote the Cocoon HttpSession, maybe he knows of a 
>> more standard way to get the unwrapped HttpSession.
> 
> 
> By the way, it's important that people know the basic reason Cocoon 
> doesn't give you an HTTP session.  Cocoon abstracts the environment so 
> that it can be run from many different environments, not just 
> http/servlet.  Currently the command line interface is the only other 
> implemented environment but even there dependency on servlet jar and 
> HttpSession obviously makes no sense.  Examples of other potential 
> environments which have been discussed are email (via James) and JMS.
> 
> Now, that doesn't mean it should be impossible to get to the HttpSession 
> if you are in that environment and that's what we need to see.  I think 
> the method which is used in the other environment abstractions (Request 
> for example) won't work here, but I don't see a reason cocoon's session 
> couldn't implement HttpSession.  Right now, it seems the only methods 
> unimplemented from the javax interface are the deprecated methods. 
> Another alternative would be to use JDK 1.3 dynamic proxy which may work 
> if the code you pass the proxy to doesn't call the deprecated methods (I 
> can't remember for sure if this is true).
> 
> Geoff



Mime
View raw message