Parameterized service injection

[Andrus Adamchik]

From what I gather Tapestry 5.4 still does not support parameterized service 
injection? E.g. in the following example both s1 and s2 will map to the same DI 
key of the bare class:

  @Inject
  private MyService s1;

  @Inject
  private MyService s2;

I am running Tapestry on a Bootique.io stack with underlying injection bridged 
to Google Guice, that supports the above style. So I am a bit crippled by this 
limitation. I may (or may not :)) have time to develop and contribute this 
functionality to Tapestry, but before I start digging any deeper, wanted to 
check whether this is already in the works (or perhaps I overlooked something 
obvious, and I simply need to revise my Guice to tapestry bridge)?

Thanks for any insight.

Andrus
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Clear PersistentFieldConduit cached value

[David Diaz]

Figured it out. You can invoke the conduit_set_[fieldname] method using
reflection (declared, not regular) and this will reflect the value in the
PerthreadMap. This function takes a singular argument with the type of the
field.

Cheers

On Mon, Dec 12, 2016 at 5:45 PM, David Diaz  wrote:

> Hi all,
>
> I am trying to set a persistent value of a field in my application on a
> XHR request. I am using tynamo's tapestry-conversation and I want to copy
> the old conversation's values to the new conversation. I am iterating
> through each field in the old conversation and setting the value for the
> new conversation like so:
>
>> Session session = request.getSession(false);
>> for (String name : session.getAttributeNames(oldConversationPrefix))
>>session.setAttribute(name.replace(oldConversationPrefix,
> newConversationPrefix), session.getAttribute(name)
>
> However once the XHR request completes the changes aren't shown in the
> render. If I update the XHR again after this has been done with another
> request (i.e click on something on the page) then the values are actually
> updated and I see what I expect.
>
> I looked into why this is happening and it seems like whenever a field is
> accessed it goes into the PerthreadMap for the specific field and grabs the
> value that was generated when the page was first rendered. Since it only
> does it at the start of the render any changes to the field don't seem to
> be reflected until the next render.
>
> I've tried:
>   * Setting the field using reflection
>   * Using InternalComponentResourcesImpl.persistFieldChange
>   * Trying to find a way to run the conduit_get_[fieldname] method to
> modify the PersistentFieldConduit value, but I couldn't figure this out
>
> Any help would be appreciated... this has stumped me! I'm sure I'm just
> doing something wrong and I've been missing something that's obvious.
>
> Thanks,
> David
>