Details

    • Type: Wish Wish
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.4-M1
    • Fix Version/s: 1.4.10
    • Component/s: wicket
    • Labels:
      None

      Description

      My copy of the inspector is completely broken. It's a shame that this useful tool is not really supported anymore. It gives people a sense of confidence when they can navigate their wicket session and see all the components with the inspector.

      To bring the inspector back, we could do the following things:

      1. fix the inspector

      • it needs to factor out the stack trace metadata so sizes of things are more accurate
      • my inspector causes every page viewed after using it to fail with a page expired exception

      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() with an explanation of what
      you must do to safely use the inspector in your application (add security to the pages via
      wicket-auth-roles or some other means and call setInspectorEnabled(true)).

      then we can all enjoy the return of the inspector!

        Issue Links

          Activity

          Hide
          Eelco Hillenius added a comment -

          > 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 .

          Show
          Eelco Hillenius added a comment - > 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 .
          Hide
          Jonathan Locke added a comment -

          yeah, we should make it clear on the page that it's a best estimate and what
          that best estimate is based on (serialization size in this case).

          there isn't really a working panel and a panel would require a bit more work
          because an inspector panel would affect the page it's on and also would need
          to be pretty ajaxy to let you drill down into the session and so forth. it's been
          a long time since i wrote that inspector though so maybe it's time to rethink it
          in terms of an ajax tree or something. we did not have that option back in those
          days. anyway, i agree a panel would be nice, but i'd be happy enough with
          just a safe, working page. certainly it would be a fun independent project
          for someone to do a rewrite or a major refactor of what we've got.

          Show
          Jonathan Locke added a comment - yeah, we should make it clear on the page that it's a best estimate and what that best estimate is based on (serialization size in this case). there isn't really a working panel and a panel would require a bit more work because an inspector panel would affect the page it's on and also would need to be pretty ajaxy to let you drill down into the session and so forth. it's been a long time since i wrote that inspector though so maybe it's time to rethink it in terms of an ajax tree or something. we did not have that option back in those days. anyway, i agree a panel would be nice, but i'd be happy enough with just a safe, working page. certainly it would be a fun independent project for someone to do a rewrite or a major refactor of what we've got.
          Hide
          Eelco Hillenius added a comment -

          Another alternative would be to put such a page in a separate project. If you include the project, you have the page.

          Show
          Eelco Hillenius added a comment - Another alternative would be to put such a page in a separate project. If you include the project, you have the page.
          Hide
          Johan Compagner added a comment -

          Inspector page seems to work fine i if go over the examples
          (at least i don't get a page expired)

          one problem i do see. Pages are not really listed there i guess that is because of the second level cache
          and the way it stores pages.

          Show
          Johan Compagner added a comment - Inspector page seems to work fine i if go over the examples (at least i don't get a page expired) one problem i do see. Pages are not really listed there i guess that is because of the second level cache and the way it stores pages.
          Hide
          Martijn Dashorst added a comment -

          see also wicket-599

          Show
          Martijn Dashorst added a comment - see also wicket-599
          Hide
          Jeremy Thomerson added a comment -

          I just tried using the inspector with a quickstart and it seemed to work okay (1.4-SNAPSHOT). Here's what I did to try it:

          1 - change wicket-examples pom.xml to temporarily build as jar (rather than war)
          2 - mvn clean install in wicket-examples, locally
          3 - add dependency in my quickstart pom on wicket-examples
          4 - add inspectorbug to page (i also mounted inspectorpage as bookmarkable - but that's beside the point)

          It seems to work.

          I would suggest, however, that we move it out of wicket-examples and into a "wicket-inspector" (or similar) subproject of its own. Thoughts?
          Could we do this with 1.4? Or since we're in RC already, should it wait to 1.5? I don't think that it would require any API changes - since it seems like you can't use it in your app now anyway without rebuilding wicket-examples on your own.

          Show
          Jeremy Thomerson added a comment - I just tried using the inspector with a quickstart and it seemed to work okay (1.4-SNAPSHOT). Here's what I did to try it: 1 - change wicket-examples pom.xml to temporarily build as jar (rather than war) 2 - mvn clean install in wicket-examples, locally 3 - add dependency in my quickstart pom on wicket-examples 4 - add inspectorbug to page (i also mounted inspectorpage as bookmarkable - but that's beside the point) It seems to work. I would suggest, however, that we move it out of wicket-examples and into a "wicket-inspector" (or similar) subproject of its own. Thoughts? Could we do this with 1.4? Or since we're in RC already, should it wait to 1.5? I don't think that it would require any API changes - since it seems like you can't use it in your app now anyway without rebuilding wicket-examples on your own.
          Hide
          Igor Vaynberg added a comment -

          i think we should have a wicket-dev or wicket-test or something of that nature where we can accumulate all these dev/test releated bits. for example the new @StatelessComponent annotation can go into that project insteadof being in core. just need to come up with a good name.

          Show
          Igor Vaynberg added a comment - i think we should have a wicket-dev or wicket-test or something of that nature where we can accumulate all these dev/test releated bits. for example the new @StatelessComponent annotation can go into that project insteadof being in core. just need to come up with a good name.
          Hide
          Jeremy Thomerson added a comment -

          @Igor - I think that's a good idea. Here's my suggestion:

          Create subpackage wicket-devutils
          In it, put the inspector (and related utilties) as well as the new @StatelessComponent
          Add to it a common place that all such dev utilities get their on/off switch (which will read from application's debug settings, perhaps)
          Enable it in dev by default, off in prod by default, but have a way that it can be enabled in production (by setting the value in debug settings)
          As Jon suggested - the pages will throw an exception if they are accessed and are disabled at the time.

          Thoughts?

          Show
          Jeremy Thomerson added a comment - @Igor - I think that's a good idea. Here's my suggestion: Create subpackage wicket-devutils In it, put the inspector (and related utilties) as well as the new @StatelessComponent Add to it a common place that all such dev utilities get their on/off switch (which will read from application's debug settings, perhaps) Enable it in dev by default, off in prod by default, but have a way that it can be enabled in production (by setting the value in debug settings) As Jon suggested - the pages will throw an exception if they are accessed and are disabled at the time. Thoughts?
          Hide
          Jeremy Thomerson added a comment -

          Oh, I forgot to add - try to improve the functionality of the inspector component to display additional details of sessions (would love to make it so that you can see everything held in session - and what's holding it).

          Show
          Jeremy Thomerson added a comment - Oh, I forgot to add - try to improve the functionality of the inspector component to display additional details of sessions (would love to make it so that you can see everything held in session - and what's holding it).
          Hide
          Igor Vaynberg added a comment -

          by subpackage you mean a project?

          im not that opposed to having wicket.dev package that contains all these runtime helpers. or wicket.devmode. or maybe even wicket.test.

          lets take this to the dev@ so we can get a wider audience.

          Show
          Igor Vaynberg added a comment - by subpackage you mean a project? im not that opposed to having wicket.dev package that contains all these runtime helpers. or wicket.devmode. or maybe even wicket.test. lets take this to the dev@ so we can get a wider audience.
          Hide
          Jeremy Thomerson added a comment -

          Took it to discussion on dev@ and everyone was favorable.
          I am starting development on this in my experimental branch.

          Here were the additional comments from the thread ():

              • Martin Grigorov:
                Additional candidate for this sub-project:
          • org.apache.wicket.markup.html.debug.PageView (wicket sub-project)
            (maybe you wont be able to move it for 1.4)
              • Igor Vaynberg:
                martijn and matej and i talked about having a floating console that
                can be enabled at runtime and that would host all these kinds of
                tools. so basically extending or encorporating our existing ajax
                console into something much more powerful. seems like if we move away
                from having these tools as pages and making them panels we can create
                a console.
              • Jeremy Thomerson:
                Yes - I agree. I think that would be the next step. I've been doing some work on a PHP site lately - which at first I thought I was going to hate. But everyone at that company only knew PHP - so I chose to go with Symfony [1] - and I've enjoyed it. Anyway, the point is - they have a great floating toolbar at the top right of the screen in development mode that gives you each query that was run, logging output for that request, timing for different cycles of the request, etc. It's great.

          I'd love to build something like it that would allow you to register various contributors to add different details to the debug bar.

          Show
          Jeremy Thomerson added a comment - Took it to discussion on dev@ and everyone was favorable. I am starting development on this in my experimental branch. Here were the additional comments from the thread (): Martin Grigorov: Additional candidate for this sub-project: org.apache.wicket.markup.html.debug.PageView (wicket sub-project) (maybe you wont be able to move it for 1.4) Igor Vaynberg: martijn and matej and i talked about having a floating console that can be enabled at runtime and that would host all these kinds of tools. so basically extending or encorporating our existing ajax console into something much more powerful. seems like if we move away from having these tools as pages and making them panels we can create a console. Jeremy Thomerson: Yes - I agree. I think that would be the next step. I've been doing some work on a PHP site lately - which at first I thought I was going to hate. But everyone at that company only knew PHP - so I chose to go with Symfony [1] - and I've enjoyed it. Anyway, the point is - they have a great floating toolbar at the top right of the screen in development mode that gives you each query that was run, logging output for that request, timing for different cycles of the request, etc. It's great. I'd love to build something like it that would allow you to register various contributors to add different details to the debug bar.
          Hide
          Max Bowsher added a comment -

          What is left to do in this issue? Just:

          • Maybe move org.apache.wicket.markup.html.debug package from wicket to wicket-devutils
          • Add some explanation about the estimation of sizes reported in the inspector

          ?

          Show
          Max Bowsher added a comment - What is left to do in this issue? Just: Maybe move org.apache.wicket.markup.html.debug package from wicket to wicket-devutils Add some explanation about the estimation of sizes reported in the inspector ?
          Hide
          Igor Vaynberg added a comment -

          aiirc this was fixed in earlier 1.4.x version.

          Show
          Igor Vaynberg added a comment - aiirc this was fixed in earlier 1.4.x version.

            People

            • Assignee:
              Jeremy Thomerson
              Reporter:
              Jonathan Locke
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0h
                0h
                Logged:
                Time Spent - 5.25h
                5.25h

                  Development