You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Daniel Radünz <ih...@gmx.de> on 2021/04/12 09:13:44 UTC

Problem with MetaData when detaching Component

Hello,

I am facing a problem with our Wicket 8.10.0 application and I wonder if it's a
bug or if I am using the MetaData feature in an unsupported or wrong way.

I have a Behavior, which adds a MetaData entry to a component in the Behavior's
"onConfigure(Component component)" method and later removes the same MetaData again
from the component in the Behaviour's "detach(Component component)" method.
(I'll skip explaining what it is used for, but if it's important to understand my
use case I'll gladly explain it)

Now upon detaching the component with said Behaviour, Wickets NotDetachedModelChecker
encountered a not detached model in the component. After debugging the problem for
a few hours I discovered the cause:

Right before the detach phase starts, the components internal "data" field is an
array with the following 4 entries:
- [0] the component's Model
- [1] the MetaDataEntry belonging to the described Behavior
- [2] the Behavior itself
- [3] an AttributeModifier with a StringResourceModel

When the component's "detach()" method is called by Wicket, it internally calls
the static "Behaviors.detach(Component component)" method. This method then iterates
through all the entries in the aforementioned "data" array and detaches them, if
they are Behaviours.
Now when it detaches the Behavior (index 2), the MetaDataEntry (index 1) gets removed
as well by our Behavior, shifting every entry in the data array by 1. The next loop
iteration for index 3 then doesn't find anything anymore, since the AttributeModifier,
which still needed to get detached, is now at index 2 and not 3 anymore, ultimately
resulting in the observed error from the NotDetachedModelChecker.

To fix the problem for now I set the MetaDataEntry to a known non-null "undefined"
value in the Behavior's "detach(Component component)" method and then compare that
value again in the Behavior's "onConfigure(Component component)" to treat it as null.

Now I wonder, if you would consider this being a bug, if I'm just using it the wrong
way or if I should rather save the information in a different way, like for example
in a map (Component mapped to value) in the RequestCycle object.

Thanks for your help

Daniel


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Problem with MetaData when detaching Component

Posted by Daniel Radünz <ih...@gmx.de>.
Thanks for the response!

I switched to using the RequestCycle to store the component related
data, which solved the specific problem for me. :)

Nevertheless I have created a bug reported with a quickstart attached as
requested. (WICKET-6877)

Regards,
Daniel


Am 12.04.2021 um 12:24 schrieb Martin Grigorov:
> Hi,
>
> On Mon, Apr 12, 2021 at 12:13 PM Daniel Radünz <ih...@gmx.de> wrote:
>
>
> It sounds like a bug to me!
> Please create an issue in JIRA. With a failing test case would be perfect!
>
> To work it around you can probably use RequestCycle's MetaData instead.
>
> Regards,
> Martin
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Problem with MetaData when detaching Component

Posted by Martin Grigorov <mg...@apache.org>.
Hi,

On Mon, Apr 12, 2021 at 12:13 PM Daniel Radünz <ih...@gmx.de> wrote:

> Hello,
>
> I am facing a problem with our Wicket 8.10.0 application and I wonder if
> it's a
> bug or if I am using the MetaData feature in an unsupported or wrong way.
>
> I have a Behavior, which adds a MetaData entry to a component in the
> Behavior's
> "onConfigure(Component component)" method and later removes the same
> MetaData again
> from the component in the Behaviour's "detach(Component component)" method.
> (I'll skip explaining what it is used for, but if it's important to
> understand my
> use case I'll gladly explain it)
>
> Now upon detaching the component with said Behaviour, Wickets
> NotDetachedModelChecker
> encountered a not detached model in the component. After debugging the
> problem for
> a few hours I discovered the cause:
>
> Right before the detach phase starts, the components internal "data" field
> is an
> array with the following 4 entries:
> - [0] the component's Model
> - [1] the MetaDataEntry belonging to the described Behavior
> - [2] the Behavior itself
> - [3] an AttributeModifier with a StringResourceModel
>
> When the component's "detach()" method is called by Wicket, it internally
> calls
> the static "Behaviors.detach(Component component)" method. This method
> then iterates
> through all the entries in the aforementioned "data" array and detaches
> them, if
> they are Behaviours.
> Now when it detaches the Behavior (index 2), the MetaDataEntry (index 1)
> gets removed
> as well by our Behavior, shifting every entry in the data array by 1. The
> next loop
> iteration for index 3 then doesn't find anything anymore, since the
> AttributeModifier,
> which still needed to get detached, is now at index 2 and not 3 anymore,
> ultimately
> resulting in the observed error from the NotDetachedModelChecker.
>
> To fix the problem for now I set the MetaDataEntry to a known non-null
> "undefined"
> value in the Behavior's "detach(Component component)" method and then
> compare that
> value again in the Behavior's "onConfigure(Component component)" to treat
> it as null.
>
> Now I wonder, if you would consider this being a bug, if I'm just using it
> the wrong
> way or if I should rather save the information in a different way, like
> for example
> in a map (Component mapped to value) in the RequestCycle object.
>

It sounds like a bug to me!
Please create an issue in JIRA. With a failing test case would be perfect!

To work it around you can probably use RequestCycle's MetaData instead.

Regards,
Martin


>
> Thanks for your help
>
> Daniel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>