commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geoff Longman" <glong...@intelligentworks.com>
Subject [Hivemind] build hivemind in eclipse?
Date Sun, 07 Mar 2004 04:26:33 GMT
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:
<attainGo
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" <glongman@intelligentworks.com>
To: "Tapestry development" <tapestry-dev@jakarta.apache.org>;
<commons-dev@jakarta.apache.org>
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" <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


Mime
View raw message