Re: Wicket model problem
Very interesting discussion.
Yes I agree, IDetachListener should only be used as a checker in dev.
François
Le 20 févr. 2016 à 12:54, Martin Grigorov <mgrigo...@apache.org> a écrit :
> Hi,
>
> You might be interested in this discussion:
> http://markmail.org/message/qttwc5kunubl6ieo
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Fri, Feb 19, 2016 at 7:19 PM, Francois Meillet <
> francois.meil...@gmail.com> wrote:
>
>> You can also use a IDetachListener to check that no one LDM (field) is
>> attached after the page#detach() has been called.
>>
>> In the Application#init() you can add
>>
>> getFrameworkSettings().setDetachListener(
>>
>>new IDetachListener() {
>>
>>@Override
>>public void onDetach(Component component) {
>>
>>for (Field field :
>> component.getClass().getDeclaredFields()) {
>>field.setAccessible(true);
>>
>>Class theClass = field.getType();
>>if
>> (LoadableDetachableModel.class.isAssignableFrom(theClass)) {
>>
>>try {
>>if (((LoadableDetachableModel)
>> field.get(component)).isAttached()) {
>>System.err.println("warning:
>> component:" + component.getClass().getName() + " / " + field.getName() + "
>> is attached");
>>}
>>}
>>//
>>catch (IllegalAccessException e) {
>>e.printStackTrace();
>>}
>>}
>>}
>>}
>>
>>@Override
>>public void onDestroyListener() {
>>
>>}
>>}
>>);
>>
>>
>> François
>>
>>
>>
>>
>>
>>
>>
>>
>> Le 19 févr. 2016 à 16:47, Bas Gooren <b...@iswd.nl> a écrit :
>>
>>> Hi,
>>>
>>> I think the only way to track this is with custom code (or with aspects
>> for example).
>>>
>>> Since the contract of IModel only has detach() (and not isDetached()),
>> this cannot be tracked easily.
>>>
>>> What I would do in such a case is probably to add a requestcyclelistener
>> which walks a page after a request, iterates (/visits) over all the
>> components and checks their models.
>>> Of course this requires the models to expose a way to check their status
>> and origin.
>>>
>>> Also, what we do to prevent this: we have an abstract base model called
>> a AbstractConversionModel<S,T> which takes a parent model (S) and converts
>> to a target type (T), caching the conversion.
>>> This model takes a parent model as input (and subclasses of it require a
>> java 8 Function<S,T> or expose an abstract method for the conversion etc).
>>> This model also takes care of detaching the parent model.
>>>
>>> In the end it’s all about education I guess: programmer’s should be
>> careful when chaining models and ensure they detach the parent (/chained)
>> model.
>>>
>>> Met vriendelijke groet,
>>> Kind regards,
>>>
>>> Bas
>>>
>>> Op 19 februari 2016 bij 15:41:03, gmparker2000 (greg.par...@brovada.com)
>> schreef:
>>>
>>> Thanks for the reply. I suspect this is exactly the case we have created
>> for
>>> ourselves. Although we have a good grasp on the detach process I suspect
>>> that there are places where this rule of thumb is not being followed.
>>> Although the example I gave is somewhat fictitious, any of the LDMs we
>> have
>>> in our framework perform a detach on the parent. In the form there are
>>> numerous places where adhoc anonymous models are created and this is
>>> probably where the problems occur. Is there a recommended way to track
>>> these down? I ended up recompiling a version of Wicket with changes to
>>> LoadableDetachableModel that would essentially track every LDM within a
>>> RequestCycle. At the end of a request cycle I was left with a list of the
>>> models that never got detached. I also added a "whereAmI" member variable
>>> to LDM that would capture the stack trace in the constructor so I could
>>> figure out who instantiated the model in the first place.
>>>
>>> --
>>> View this message in context:
>> http://apache-wicket.1842946.n4.nabble.com/Wicket-model-problem-tp4673620p4673664.html
>>> Sent from the Users forum mailing list archive at Nabble.com.
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>
>>
Re: Wicket model problem
Hi,
You might be interested in this discussion:
http://markmail.org/message/qttwc5kunubl6ieo
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Fri, Feb 19, 2016 at 7:19 PM, Francois Meillet <
francois.meil...@gmail.com> wrote:
> You can also use a IDetachListener to check that no one LDM (field) is
> attached after the page#detach() has been called.
>
> In the Application#init() you can add
>
> getFrameworkSettings().setDetachListener(
>
> new IDetachListener() {
>
> @Override
> public void onDetach(Component component) {
>
> for (Field field :
> component.getClass().getDeclaredFields()) {
> field.setAccessible(true);
>
> Class theClass = field.getType();
> if
> (LoadableDetachableModel.class.isAssignableFrom(theClass)) {
>
> try {
> if (((LoadableDetachableModel)
> field.get(component)).isAttached()) {
> System.err.println("warning:
> component:" + component.getClass().getName() + " / " + field.getName() + "
> is attached");
> }
> }
> //
> catch (IllegalAccessException e) {
> e.printStackTrace();
> }
> }
> }
> }
>
> @Override
> public void onDestroyListener() {
>
> }
> }
> );
>
>
> François
>
>
>
>
>
>
>
>
> Le 19 févr. 2016 à 16:47, Bas Gooren <b...@iswd.nl> a écrit :
>
> > Hi,
> >
> > I think the only way to track this is with custom code (or with aspects
> for example).
> >
> > Since the contract of IModel only has detach() (and not isDetached()),
> this cannot be tracked easily.
> >
> > What I would do in such a case is probably to add a requestcyclelistener
> which walks a page after a request, iterates (/visits) over all the
> components and checks their models.
> > Of course this requires the models to expose a way to check their status
> and origin.
> >
> > Also, what we do to prevent this: we have an abstract base model called
> a AbstractConversionModel<S,T> which takes a parent model (S) and converts
> to a target type (T), caching the conversion.
> > This model takes a parent model as input (and subclasses of it require a
> java 8 Function<S,T> or expose an abstract method for the conversion etc).
> > This model also takes care of detaching the parent model.
> >
> > In the end it’s all about education I guess: programmer’s should be
> careful when chaining models and ensure they detach the parent (/chained)
> model.
> >
> > Met vriendelijke groet,
> > Kind regards,
> >
> > Bas
> >
> > Op 19 februari 2016 bij 15:41:03, gmparker2000 (greg.par...@brovada.com)
> schreef:
> >
> > Thanks for the reply. I suspect this is exactly the case we have created
> for
> > ourselves. Although we have a good grasp on the detach process I suspect
> > that there are places where this rule of thumb is not being followed.
> > Although the example I gave is somewhat fictitious, any of the LDMs we
> have
> > in our framework perform a detach on the parent. In the form there are
> > numerous places where adhoc anonymous models are created and this is
> > probably where the problems occur. Is there a recommended way to track
> > these down? I ended up recompiling a version of Wicket with changes to
> > LoadableDetachableModel that would essentially track every LDM within a
> > RequestCycle. At the end of a request cycle I was left with a list of the
> > models that never got detached. I also added a "whereAmI" member variable
> > to LDM that would capture the stack trace in the constructor so I could
> > figure out who instantiated the model in the first place.
> >
> > --
> > View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Wicket-model-problem-tp4673620p4673664.html
> > Sent from the Users forum mailing list archive at Nabble.com.
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
>
>
Re: Wicket model problem
You can also use a IDetachListener to check that no one LDM (field) is attached
after the page#detach() has been called.
In the Application#init() you can add
getFrameworkSettings().setDetachListener(
new IDetachListener() {
@Override
public void onDetach(Component component) {
for (Field field :
component.getClass().getDeclaredFields()) {
field.setAccessible(true);
Class theClass = field.getType();
if
(LoadableDetachableModel.class.isAssignableFrom(theClass)) {
try {
if (((LoadableDetachableModel)
field.get(component)).isAttached()) {
System.err.println("warning: component:" +
component.getClass().getName() + " / " + field.getName() + " is attached");
}
}
//
catch (IllegalAccessException e) {
e.printStackTrace();
}
}
}
}
@Override
public void onDestroyListener() {
}
}
);
François
Le 19 févr. 2016 à 16:47, Bas Gooren <b...@iswd.nl> a écrit :
> Hi,
>
> I think the only way to track this is with custom code (or with aspects for
> example).
>
> Since the contract of IModel only has detach() (and not isDetached()), this
> cannot be tracked easily.
>
> What I would do in such a case is probably to add a requestcyclelistener
> which walks a page after a request, iterates (/visits) over all the
> components and checks their models.
> Of course this requires the models to expose a way to check their status and
> origin.
>
> Also, what we do to prevent this: we have an abstract base model called a
> AbstractConversionModel<S,T> which takes a parent model (S) and converts to a
> target type (T), caching the conversion.
> This model takes a parent model as input (and subclasses of it require a java
> 8 Function<S,T> or expose an abstract method for the conversion etc).
> This model also takes care of detaching the parent model.
>
> In the end it’s all about education I guess: programmer’s should be careful
> when chaining models and ensure they detach the parent (/chained) model.
>
> Met vriendelijke groet,
> Kind regards,
>
> Bas
>
> Op 19 februari 2016 bij 15:41:03, gmparker2000 (greg.par...@brovada.com)
> schreef:
>
> Thanks for the reply. I suspect this is exactly the case we have created for
> ourselves. Although we have a good grasp on the detach process I suspect
> that there are places where this rule of thumb is not being followed.
> Although the example I gave is somewhat fictitious, any of the LDMs we have
> in our framework perform a detach on the parent. In the form there are
> numerous places where adhoc anonymous models are created and this is
> probably where the problems occur. Is there a recommended way to track
> these down? I ended up recompiling a version of Wicket with changes to
> LoadableDetachableModel that would essentially track every LDM within a
> RequestCycle. At the end of a request cycle I was left with a list of the
> models that never got detached. I also added a "whereAmI" member variable
> to LDM that would capture the stack trace in the constructor so I could
> figure out who instantiated the model in the first place.
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Wicket-model-problem-tp4673620p4673664.html
>
> Sent from the Users forum mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
Re: Wicket model problem
see the LoadableDetachableModel # isAttached() method which return the attached status of this model instance François Le 19 févr. 2016 à 16:47, Bas Gooren <b...@iswd.nl> a écrit : > Hi, > > I think the only way to track this is with custom code (or with aspects for > example). > > Since the contract of IModel only has detach() (and not isDetached()), this > cannot be tracked easily. > > What I would do in such a case is probably to add a requestcyclelistener > which walks a page after a request, iterates (/visits) over all the > components and checks their models. > Of course this requires the models to expose a way to check their status and > origin. > > Also, what we do to prevent this: we have an abstract base model called a > AbstractConversionModel<S,T> which takes a parent model (S) and converts to a > target type (T), caching the conversion. > This model takes a parent model as input (and subclasses of it require a java > 8 Function<S,T> or expose an abstract method for the conversion etc). > This model also takes care of detaching the parent model. > > In the end it’s all about education I guess: programmer’s should be careful > when chaining models and ensure they detach the parent (/chained) model. > > Met vriendelijke groet, > Kind regards, > > Bas > > Op 19 februari 2016 bij 15:41:03, gmparker2000 (greg.par...@brovada.com) > schreef: > > Thanks for the reply. I suspect this is exactly the case we have created for > ourselves. Although we have a good grasp on the detach process I suspect > that there are places where this rule of thumb is not being followed. > Although the example I gave is somewhat fictitious, any of the LDMs we have > in our framework perform a detach on the parent. In the form there are > numerous places where adhoc anonymous models are created and this is > probably where the problems occur. Is there a recommended way to track > these down? I ended up recompiling a version of Wicket with changes to > LoadableDetachableModel that would essentially track every LDM within a > RequestCycle. At the end of a request cycle I was left with a list of the > models that never got detached. I also added a "whereAmI" member variable > to LDM that would capture the stack trace in the constructor so I could > figure out who instantiated the model in the first place. > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Wicket-model-problem-tp4673620p4673664.html > > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org >
Re: Wicket model problem
Hi, I think the only way to track this is with custom code (or with aspects for example). Since the contract of IModel only has detach() (and not isDetached()), this cannot be tracked easily. What I would do in such a case is probably to add a requestcyclelistener which walks a page after a request, iterates (/visits) over all the components and checks their models. Of course this requires the models to expose a way to check their status and origin. Also, what we do to prevent this: we have an abstract base model called a AbstractConversionModel<S,T> which takes a parent model (S) and converts to a target type (T), caching the conversion. This model takes a parent model as input (and subclasses of it require a java 8 Function<S,T> or expose an abstract method for the conversion etc). This model also takes care of detaching the parent model. In the end it’s all about education I guess: programmer’s should be careful when chaining models and ensure they detach the parent (/chained) model. Met vriendelijke groet, Kind regards, Bas Op 19 februari 2016 bij 15:41:03, gmparker2000 (greg.par...@brovada.com) schreef: Thanks for the reply. I suspect this is exactly the case we have created for ourselves. Although we have a good grasp on the detach process I suspect that there are places where this rule of thumb is not being followed. Although the example I gave is somewhat fictitious, any of the LDMs we have in our framework perform a detach on the parent. In the form there are numerous places where adhoc anonymous models are created and this is probably where the problems occur. Is there a recommended way to track these down? I ended up recompiling a version of Wicket with changes to LoadableDetachableModel that would essentially track every LDM within a RequestCycle. At the end of a request cycle I was left with a list of the models that never got detached. I also added a "whereAmI" member variable to LDM that would capture the stack trace in the constructor so I could figure out who instantiated the model in the first place. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-model-problem-tp4673620p4673664.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket model problem
Thanks for the reply. I suspect this is exactly the case we have created for ourselves. Although we have a good grasp on the detach process I suspect that there are places where this rule of thumb is not being followed. Although the example I gave is somewhat fictitious, any of the LDMs we have in our framework perform a detach on the parent. In the form there are numerous places where adhoc anonymous models are created and this is probably where the problems occur. Is there a recommended way to track these down? I ended up recompiling a version of Wicket with changes to LoadableDetachableModel that would essentially track every LDM within a RequestCycle. At the end of a request cycle I was left with a list of the models that never got detached. I also added a "whereAmI" member variable to LDM that would capture the stack trace in the constructor so I could figure out who instantiated the model in the first place. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-model-problem-tp4673620p4673664.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket model problem
}
@Override
public void removeItem(GHI item, AjaxRequestTarget target) {
abc.getObject().deleteGHI(item);
}
}
this.add(listPanel);
}
}
After instrumenting LoadableDetachableModel and RequestCycle to track all
the LDMs, we can now see that after the detach process executes at the end
of the request cycle all of the models are detached and the problems appear
to go away.
Does this solution make sense? Is there something fundamentally wrong with
the pattern? Is it because we don't set a model on MyPanel thereby breaking
the detach process somehow? Is the use of the final "abc" model in the list
panel anonymous inner type causing inadvertent serialization problems?
We are using Wicket 6 and the problem doesn't become prevalent until the
form has been mildly stressed. Presumably this is because we have reached
some threshold that starts to trigger some Wicket serialization behaviour.
Any insights would be helpful to help us get to the root cause. Thanks
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Wicket-model-problem-tp4673620p4673662.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket model problem
{
abc.getObject().deleteGHI(item);
}
}
this.add(listPanel);
}
}
After instrumenting LoadableDetachableModel and RequestCycle to track all
the LDMs, we can now see that after the detach process executes at the end
of the request cycle all of the models are detached and the problems appear
to go away.
Does this solution make sense? Is there something fundamentally wrong with
the pattern? Is it because we don't set a model on MyPanel thereby breaking
the detach process somehow? Is the use of the final "abc" model in the list
panel anonymous inner type causing inadvertent serialization problems?
We are using Wicket 6 and the problem doesn't become prevalent until the
form has been mildly stressed. Presumably this is because we have reached
some threshold that starts to trigger some Wicket serialization behaviour.
Any insights would be helpful to help us get to the root cause. Thanks
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Wicket-model-problem-tp4673620p4673662.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket model problem
Hi, What kind of exceptions? Show us how the models are chained. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Thu, Feb 18, 2016 at 4:10 AM, gmparker2000 <greg.par...@brovada.com> wrote: > We are using LoadableDetachableModels heavily. The page we have created > has > a lot of repeating nested sections. The repeating panels have a model > chain > that leads back to the topmost LDM. The topmost LDM implements a load that > retrieves the model object from a document cache. As far as I can tell all > of the models are implemented properly (LDMs don't have member variables > referencing model objects, etc). Everything works great until you load the > page half a dozen times. After that we start to see exceptions and in some > cases, even worse, we don't see exceptions but see data lose. Can anyone > suggest a way to debug this situation? We have tried various things: > attaching a detach listener and looking for unattached models, the wicket > debug panel, etc. > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Wicket-model-problem-tp4673620.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Wicket model problem
We are using LoadableDetachableModels heavily. The page we have created has a lot of repeating nested sections. The repeating panels have a model chain that leads back to the topmost LDM. The topmost LDM implements a load that retrieves the model object from a document cache. As far as I can tell all of the models are implemented properly (LDMs don't have member variables referencing model objects, etc). Everything works great until you load the page half a dozen times. After that we start to see exceptions and in some cases, even worse, we don't see exceptions but see data lose. Can anyone suggest a way to debug this situation? We have tried various things: attaching a detach listener and looking for unattached models, the wicket debug panel, etc. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-model-problem-tp4673620.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
