> It gives people a sense of confidence when they can navigate their wicket session and see all the components with the inspector.
I'm still not completely sure how acurate the picture is we are displaying there. When I did testing I found there was a big difference between how many users I could support with a certain ammount of MBs based on what the inspector says and how much memory I actually consumed when I tested with that number of sessions. Gladly, always in favor of the real situation. This is even true when you include the wicket-objectsizeof-agent project for your measurings, which should give a much better estimate anyway.
Anyway... I agree it is a nice toy and it would be nice to have this available for people as long as they understand that it's best estimates rather than a hard numbers they are seeing.
> 1. fix the inspector
> - it needs to factor out the stack trace metadata so sizes of things are more accurate
Stack trace meta data is removed at the end of requests, so the only polluted number you are seeing might be of the inspector page itself.
> 2. add a security setting setInspectorEnabled() which defaults to false (disabled) and unless
> the inspector is explicitly enabled, the constructor of every publicly accessible bookmarkable
> page in the inspector package throws an IllegalStateException() ...
I think it is a better idea to ship just the inspector panel, not the page. That way people can decide for themselves how to include and protect it, and we don't have to litter our settings any more .