What I ended up doing is a hack... 

The problem is that when the sub-class is being created (via Javassist), the
InjectObjectWorker injects the object through the constructor and adds a 
simple getter method to access this. This is probably a bug.. for example if
you inject the request object (or a spring bean) it gets passed through the 
constructor. Since the the pages are pooled, the next user will get the page
with a reference to some previous Request (or Spring object).

I hacked the InjectObjectWorker to look for spring beans, HttpRequest, & 
httpResponse by not modifying the constructor but by adding a getter method 
that calls the deprecated method calls using
getRequestCycle().getRequestContext() and
loading up the spring bean factory using the servlet context.
This way the objects are not cached.

So the hack works but I would prefer a cleaner solution.

My final question: is this the intended behavior for object injection or is
this really a bug?

--- James Carman <[EMAIL PROTECTED]> wrote:

> You can achieve this using a MethodAnnotationEnhancementWorker the same way
> Tapestry does to inject everything else.  It shouldn't be difficult.  Here's
> a good example of how to do it.  If you're not an expert with Javassist, I
> might be able to "assist" you (couldn't resist, sorry).
> 
> 
> http://jakarta.apache.org/tapestry/tapestry-annotations/apidocs/src-html/org
> /apache/tapestry/annotations/InjectObjectAnnotationWorker.html#line.35
> 
> 
> 
> -----Original Message-----
> From: Todd Orr [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, March 01, 2006 3:33 PM
> To: Tapestry users
> Subject: Re: Tapestry + Spring question
> 
> He's currently looking for approval at my company to see if he can
> contribute the code to the community. Keep ya posted.
> 
> On 2/21/06, Cliff Zhao <[EMAIL PROTECTED]> wrote:
> > Also like to  know some detail about the InjectSpringBean annotation. Is
> it
> > used in pages? Where is the place that your annotation get recognized. I
> > created some annotation in my own EngineService. Did he modify the Page
> > service?
> >
> > On 2/21/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> > wrote:
> > >
> > > Hi Todd,
> > >
> > > So are you completely bypassing Hivemind at this point? I
> > > wonder if this is a bug or intended behavior of Hivemind.
> > >
> > > I am not too familiar with annotations, if you can describe it in
> > > a little more detail (or some code snippet) it would be *greatly*
> > > appreciated.
> > >
> > > Thanks,
> > > Amir
> > >
> > > ----- Original Message ----
> > > From: Todd Orr <[EMAIL PROTECTED]>
> > > To: Tapestry users <[email protected]>
> > > Sent: Monday, February 20, 2006 11:05:59 PM
> > > Subject: Re: Tapestry + Spring question
> > >
> > > A coworker had the same problem. It seems that hivemind is also
> > > caching or making singletons out of the beans returned from spring. My
> > > coworker created a new annotation @InjectSpringBean that replaces the
> > > @InjectObject("spring:linkSearch") type syntax. It pulls beans
> > > directly out of the spring app context so that hivemind cannot get its
> > > hands on teh resulting beans. This has worked very well so far.
> > >
> > > On 2/20/06, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]>
> > > wrote:
> > > > I did mark the bean as a prototype (singleton=false) and I still get
> the
> > > same behavior.
> > > >
> > > >  When I run this outside Tapestry (in a JUnit) then it worls fine...
> > > when the singleton is marked true you get the same object back, when set
> to
> > > false you get a new object back each time.
> > > >
> > > > So the question remains, why am I getting the same object back
> everytime
> > > I call getLinkSearchCommand() even though it has singleton=false in
> spring
> > > configuration.
> > > >
> > > >
> > > > ----- Original Message ----
> > > > From: James Carman <[EMAIL PROTECTED]>
> > > > To: Tapestry users <[email protected]>
> > > > Sent: Monday, February 20, 2006 4:36:18 PM
> > > > Subject: RE: Tapestry + Spring question
> > > >
> > > > You can make the bean a "prototype"
> > > >
> > > >
> > >
> http://www.springframework.org/docs/reference/beans.html#beans-factory-modes
> > > >
> > > > I believe Tapestry actually looks up the bean every time when you call
> > > > getLinkSearchCommand().  Try that.
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Amir Sheibani [mailto:[EMAIL PROTECTED]
> > > > Sent: Monday, February 20, 2006 5:49 PM
> > > > To: [email protected]
> > > > Subject: Tapestry + Spring question
> > > >
> > > > Hi all,
> > > >
> > > > I have a question on using Spring beans from tapestry pages. I am
> using
> > > > http://wiki.apache.org/jakarta-tapestry/Tapestry4Spring to integrate,
> > > and on
> > > > my Tapestry page I have:
> > > >
> > > >     @InjectObject("spring:linkSearch")
> > > >     public abstract ILinkSearch getLinkSearchCommand();
> > > >
> > > > In my Spring configuration file I have the bean set as a singleton:
> > > >
> > > >     <bean id="linkSearch"
> > > >         class="LinkSearch"
> > > >         singleton="false">
> > > >         <constructor-arg>
> > > >             <ref bean="accountSummaryDao" />
> > > >         </constructor-arg>
> > > >     </bean>
> > > >
> > > > The problem is that I need a new instance of this bean every time the
> > > page
> > > > gets loaded; however it seems that once a new instance is created, the
> > > same
> > > > one is returned every time the page is reloaded. I am not too familiar
> > > with
> > > > how Hivemind works... is this being cached by Hivemind?
> > > >
> > > > Thanks in advance,
> > > > Amir
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to