Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 69243 invoked from network); 7 Mar 2004 14:19:09 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 7 Mar 2004 14:19:09 -0000 Received: (qmail 79964 invoked by uid 500); 7 Mar 2004 14:19:02 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 79910 invoked by uid 500); 7 Mar 2004 14:19:01 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 79893 invoked from network); 7 Mar 2004 14:19:01 -0000 Received: from unknown (HELO rwcrmhc11.comcast.net) (204.127.198.35) by daedalus.apache.org with SMTP; 7 Mar 2004 14:19:01 -0000 Received: from almightybeast (h0010b50ed00a.ne.client2.attbi.com[24.128.112.68]) by comcast.net (rwcrmhc11) with SMTP id <20040307141902013002fh3pe>; Sun, 7 Mar 2004 14:19:02 +0000 From: "Howard M. Lewis Ship" To: "'Jakarta Commons Developers List'" Subject: RE: [Hivemind] build hivemind in eclipse? Date: Sun, 7 Mar 2004 09:18:52 -0500 Message-ID: <03a801c4044f$1e849770$6401a8c0@ALMIGHTYBEAST> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <0dd101c403fc$5f0324e0$2400a8c0@turbonium> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N This is why we're going to get away from Maven. The exact version of Maven you have seems very significant. All I can say is that I'm using 1.0-rc2-SNAPSHOT. Does that help? Maybe not. -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Tapestry: Java Web Components http://howardlewisship.com > -----Original Message----- > From: Geoff Longman [mailto:glongman@intelligentworks.com] > Sent: Saturday, March 06, 2004 11:27 PM > To: commons-dev@jakarta.apache.org > Subject: [Hivemind] build hivemind in eclipse? > > > I got the missing MAVEN_REPO classpath variable errors so I > installed maven > and ran > > >maven full-site > > and added the MAVEN_REPO classpath variable. > > All the errors are gone except this one: > > Error Missing required library: 'C:Documents and > Settings/Administrator/.maven/repository/jboss/jars/jboss-jmx- > 3.0.6.jar'. > > Although, the maven build did tank after a while with this: > > +---------------------------------------- > | Generating site for HiveMind Framework > | Memory: 12M/13M > +---------------------------------------- > > BUILD FAILED > File...... file:/C:/Documents and > Settings/Administrator/.maven/plugins/maven-multiproject-plugin-1.1/ > Element... maven:reactor > Line...... 69 > Column.... 7 > Unable to obtain goal [site] -- file:/C:/Documents and > Settings/Administrator/.maven/plugins/maven-site-plugin-1.3/:22:42: > al> Goal [xdoc:register-reports] has no action definition. > Total time: 46 seconds > Finished at: Sat Mar 06 22:47:33 EST 2004 > > What am I doing wrong? BTW I just pulled the latest code out > of CVS and got > the same error. > > Geoff > > ----- Original Message ----- > From: "Geoff Longman" > To: "Tapestry development" ; > > Sent: Saturday, March 06, 2004 10:27 PM > 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" > > To: "Tapestry development" ; > > > > 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" > > > >To: "Tapestry development" ; > > > > > > > >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" > > > >>>To: "Jakarta Commons Developers List" > > > > >>>Cc: "Tapestry development" > > > >>>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