Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <0e6d01c40509$4588bc10$2400a8c0@turbonium>
From: "Geoff Longman" <glongman@intelligentworks.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
References: 
 <1570986627-1078641732-cardhu_blackberry.rim.net-14394-@engine07.bwc.produk.on.blackberry>
Subject: Re: Re: [Hivemind] Tapestry/HttpSession service
Date: Mon, 8 Mar 2004 07:31:24 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I like this idea. Won't be able to get back to this before the weekend
though. The day job calls..

Geoff
----- Original Message -----
From: "christian essl" <christianessl@yahoo.de>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Sunday, March 07, 2004 1:44 AM
Subject: AW: Re: [Hivemind] Tapestry/HttpSession service


> another try without a sessin-model actually quite simular to yours.
>
> A ServiceFactory which is thread-local and delegates to another
SerciceFact. the servicefact checks if the implementation is already in the
session if not creates it and returns. it also keeps a list off all handed
out implementations and right befor the request is over it stores them back
in the session - therefor it is thread-local or pooled. this factory is than
used from thread-local models.
>
> what do you think?
>
> thanks,
> chris
> -----Original Message-----
> From: "Geoff Longman" <glongman@intelligentworks.com>
> Date: Sat, 6 Mar 2004 22:27:50
> To:"Tapestry development" <tapestry-dev@jakarta.apache.org>,
<commons-dev@jakarta.apache.org>
> Subject: Re: [Hivemind] Tapestry/HttpSession service
>
> Ahh, but we're trying to reduce our dependency on the Visit. We have many
> groups of pages, and each group needs to store a distinct set of data. Our
> visit class was becoming a mess.
>
> Plus, a session local service could also be useful outside of Tapestry
where
> there is no Visit! No reason why a JSP couldn't use a session local
service.
>
> Geoff
>
> ----- Original Message -----
> From: "Harish Krishnaswamy" <hkrishnaswamy@comcast.net>
> To: "Tapestry development" <tapestry-dev@jakarta.apache.org>;
> <commons-dev@jakarta.apache.org>
> Sent: Saturday, March 06, 2004 10:14 PM
> Subject: Re: [Hivemind] Tapestry/HttpSession service
>
>
> > The way I see it, you simply need a regular service with
> > ThreadLocalStorage. The servlet filter would set the visit in the
> > ThreadLocalStorage for every request and the service would simply get
> > and set the data on the visit in the ThreadLocal. Would that work?
> >
> > -Harish
> >
> > Geoff Longman wrote:
> >
> > >Perhaps, I wish I had more time to read the Hivemind source.
> > >
> > >I might be getting this wrong but how about a Factory that makes a
> session
> > >local instance of a service? Wait that can't be right. A
> SessionLocalService
> > >that pulls a service from a pool and hooks it up to the session. The
> > >existing servlet filter could be a model for a filter that sets up the
> > >SessionLocalService with the thread local session.
> > >
> > >The above ignores the need to restore/save a service's session local
> state
> > >though.
> > >
> > >hmm, still thinking..
> > >
> > >Geoff
> > >----- Original Message -----
> > >From: "Harish Krishnaswamy" <hkrishnaswamy@comcast.net>
> > >To: "Tapestry development" <tapestry-dev@jakarta.apache.org>;
> > ><commons-dev@jakarta.apache.org>
> > >Sent: Saturday, March 06, 2004 9:54 PM
> > >Subject: Re: [Hivemind] Tapestry/HttpSession service
> > >
> > >
> > >
> > >
> > >>Ah, yes I did miss that part. Seems like you want a wrapper service to
> > >>the HttpSession like the Visit?
> > >>
> > >>Geoff Longman wrote:
> > >>
> > >>
> > >>
> > >>>I don't think ThreadLocalStorage is sufficient. Perhaps this is too
> > >>>
> > >>>
> > >specific
> > >
> > >
> > >>>to Tapestry and is a topic for Tapestry 3.1 discussion.
> > >>>
> > >>>It all boils down to a service that not only is thread local, but is
> also
> > >>>session local.
> > >>>
> > >>>Geoff
> > >>>----- Original Message -----
> > >>>From: "Harish Krishnaswamy" <hkrishnaswamy@comcast.net>
> > >>>To: "Jakarta Commons Developers List"
<commons-dev@jakarta.apache.org>
> > >>>Cc: "Tapestry development" <tapestry-dev@jakarta.apache.org>
> > >>>Sent: Saturday, March 06, 2004 9:28 PM
> > >>>Subject: Re: [Hivemind] Tapestry/HttpSession service
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>Have you looked into the ThreadLocalStorage?
> > >>>>
> > >>>>-Harish
> > >>>>
> > >>>>Geoff Longman wrote:
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>The content of this message crosses boundaries so I'm cc'ing
Tapestry
> > >>>>>
> > >>>>>
> > >dev
> > >
> > >
> > >>>>>too.
> > >>>>>
> > >>>>>I have a real problem in a Tapestry application and I'm wondering
if
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>another
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>>'flavour' of Hivemind service approach would be applicable.
> > >>>>>
> > >>>>>We have a Tapestry app that has many hundreds of pages. Different
> > >>>>>
> > >>>>>
> > >groups
> > >
> > >
> > >>>>>
> > >>>>>
> > >>>of
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>>pages need to share different sets of information. We have tried
> using
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>the
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>>Visit  to share data and have also tried explicity passing things
> > >>>>>
> > >>>>>
> > >between
> > >
> > >
> > >>>>>pages but both methods are less than ideal..
> > >>>>>
> > >>>>>The visit approach ends up being like a big hashtable. Explicity
> > >>>>>
> > >>>>>
> > >passing
> > >
> > >
> > >>>>>data via method calls leads to coupling between pages.
> > >>>>>
> > >>>>>What would be nice is a service that is not only pooled, but is
> > >>>>>
> > >>>>>
> > >peristent
> > >
> > >
> > >>>>>
> > >>>>>
> > >>>in
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>>the Tapestry way, i.e. the value of certain fields in the service
are
> > >>>>>private to one user session.
> > >>>>>
> > >>>>>An example implementation could be a Wizard that uses 5 pages to
> build
> > >>>>>
> > >>>>>
> > >a
> > >
> > >
> > >>>>>
> > >>>>>
> > >>>new
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>>customer record in a database.
> > >>>>>
> > >>>>>If the service I described was doable, each page could access a
> > >>>>>NewCustomerWizard service, read data from it and set data in it.
The
> > >>>>>NewCustomerWizardService could minimally reply to questions like:
> > >>>>>
> > >>>>>- Can the wizard finish?
> > >>>>>- What's the next page to show?
> > >>>>>- What's the previous page to show?
> > >>>>>
> > >>>>>Thus, the pages could interact individually with the service and
not
> be
> > >>>>>coupled to one another.
> > >>>>>
> > >>>>>In fact, a menu component could interrogate the
> > >>>>>
> > >>>>>
> > >NewCustomerWizardService
> > >
> > >
> > >>>>>also to get the first page to show in order to start the Wizard.
> Plus,
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>the
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>>service could keep track of all the pages used so far and if the
user
> > >>>>>clicked 'Finish' or 'Cancel', the service could respond with the
list
> > >>>>>
> > >>>>>
> > >of
> > >
> > >
> > >>>>>seen pages for cleanup purposes (forgetPage()).
> > >>>>>
> > >>>>>Is this wishful thinking?
> > >>>>>Cheers,
> > >>>>>
> > >>>>>Geoff
> > >>>>>
> > >>>>>Geoffrey Longman
> > >>>>>Intelligent Works Inc.
> > >>>>>
> > >>>>>
> >
>>>>>---------------------------------------------------------------------
> > >>>>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > >>>>>For additional commands, e-mail:
commons-dev-help@jakarta.apache.org
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> >
>>>>---------------------------------------------------------------------
> > >>>>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > >>>>For additional commands, e-mail:
tapestry-dev-help@jakarta.apache.org
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>---------------------------------------------------------------------
> > >>>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > >>>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>---------------------------------------------------------------------
> > >>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > >>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> > >>
> > >>
> > >>
> > >
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > >For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> > >
> > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org