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 >