Bas,
The code you showed is fine, foo will be garbage collected. You only
have to worry about situations where you reference a final object
inside an anonymous inner class. E.g. The below WebMarkupContainer
can has to keep a reference to foo, and so foo cannot be garbage
collected.
final Foo foo = getModelObject();
WebMarkupContainer bigBox = new WebMarkupContainer("me"){
if( foo.getX() )
add( new Label("x", new PropertyModel( getModel(), "x" ) );
else
add( new Label("x", new PropertyModel( getModel(), "y" ) );
};
add(bigBox);
Scott
Any time you make an object final it is potentially bound into the context of
On Wed, Aug 26, 2009 at 1:27 PM, Bas Gooren<[email protected]> wrote:
> Michael,
>
> This is something which is helpful in case you have models which are not
> "owned" by a component. This is not the case in my application.
> Also, the strategy they explain in the blog is something which is quite
> common with wicket, at least for me: a model referencing another model, and
> calling it's detach() method when its own onDetach() is called.
>
> Thanks anyway!
>
> Bas
>
> ----- Original Message ----- From: "Michael Mosmann" <[email protected]>
> To: <[email protected]>
> Sent: Wednesday, August 26, 2009 10:13 PM
> Subject: Re: How to detect model "leakage" into session
>
>
>> Am Mittwoch, den 26.08.2009, 21:29 +0200 schrieb Bas Gooren:
>>>
>>> Hi all,
>>>
>>> My problem is as follows: I use LoadableDetachableModels throughout my
>>> application, and have made sure I never use a model without it being
>>> attached to a component to prevent models which never get their detach()
>>> method called.
>>> Nonetheless, after hitting two fairly simple pages which list some
>>> database data in my application, I get a 100kb session which is filled with
>>> literal strings from model objects.
>>>
>>> I've fired up my (Eclipse) debugger and have stepped through all models
>>> on one of the pages after setting a breakpoint on the pages onDetach()
>>> method. I see all LoadableDetachableModels are detached, so I have no idea
>>> what's causing this.
>>>
>>> What would be a good strategy for finding the source of this problem?
>>
>> IMHO this could be a solution to your problem:
>>
>> http://www.wicket-praxis.de/blog/2009/01/03/modell-referenzen/
>>
>> CascadingLoadableDetachableModel will detach it's child so that for any
>> used model detach will be called.
>>
>> mm:)
>>
>>
>> ---------------------------------------------------------------------
>> 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]
