Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Message-ID: <40201B6A.1050101@leverageweb.com>
Date: Tue, 03 Feb 2004 17:06:34 -0500
From: Geoff Howard <cocoon@leverageweb.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.5) Gecko/20031007
MIME-Version: 1.0
To: users@cocoon.apache.org
Subject: Re: javax.servlet.http.HttpSession access from XSP?
References: <3F93B638.5080008@ish.de>
 <67C442DD-5511-11D8-A4D0-003065A85E10@sparkbc.com.au>
 <401E9A4A.3080106@gmx.de>
 <03DCA0FC-55CE-11D8-BDE0-003065A85E10@sparkbc.com.au>
 <401EDE47.3020900@gmx.de> <401F16AC.7050301@leverageweb.com>
 <FBF21C70-560B-11D8-BDE0-003065A85E10@sparkbc.com.au>
 <401FB2DA.3000005@leverageweb.com>
In-Reply-To: <401FB2DA.3000005@leverageweb.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Geoff Howard wrote:

> Phil Blake wrote:
> 
>>> 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).
>>
>>
>>
>> Good point Geoff.
>>
>> This is a specialised case. I think you'd only want access to the 
>> HttpSession for this kind of integration. Perhaps a _wrappedSession() 
>> method on org.apache.cocoon.environment.Session is too easy to abuse. 
>> A little opinionated documentation could help with that. :)
>>
>> Any comments?
> 
> 
> I was thinking more of just declaring that the cocoon HttpSession 
> implements the javax interface as I mention above.  It would be easiest 
> to implement the deprecated methods to just throw an exception.  Does 
> Cayenne need them?  If we do this, you could just pass the cocoon 
> session along with a possible cast depending on how you got it.
> 
> I've started a proposal on the dev list about this if you want to pipe 
> in or follow along there.

Ok, I think the proposal to do this is not going to go anywhere, but 
there is a solution.  You'll probably need to give more info (or remind 
us of it) of what code you are calling this from (action, flow, 
generator, transformer, etc.).

While you are at it, can you give more info about what part of the 
Cayenne API relies on this?  It is odd that they need an http session 
object - what if you wanted to use this code outside of a webapp?

Geoff


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org