2 Replies Latest reply on Apr 3, 2007 11:07 AM by Adrian Brock

    Internal AbstractController State

    Adrian Brock Master

      I can see having the abstract controller state protected is a bit dangerous
      given the recent changes for the Scoped Kernels.

      So I've changed all the state to private with documented protected methods
      for subclasses to use.

      The reason I say it is dangerous is because there is more to updating a context's
      state than allContexts. There are other "indexes" where the context could exist.

      Besides this new api looks wrong to me anyway, I documented it in a TODO

       // TODO This api looks broken and unsafe
       // 1) It should not be public
       // 2) There should be parameter checking for public methods
       // 3) There should be locking when updating state
       // 4) Error handling?
       public void addControllerContext(ControllerContext context)
      


      The way to make more dangerous operations available to subclasses
      would be through some helper class that is only protected accesible.

      e.g.
      
      private UnsafeInterface unsafe = new UnsafeImplementation();
      
      protected UnsafeInterface getUnsafe()
      {
       return unsafe;
      }
      
      protected interface UnsafeInterface
      {
       // Methods intended for subclasses that know what they are doing here
       // Properly documented to explain requirements, e.g. locking
      }
      
      private class UnsafeImplementation implements UnsafeInterface
      {
       // Implementation of potentially unsafe methods, but still does some checking
       // like null parameters or reasonable error handling so we don't end up
       // with a subclass breaking the whole system.
      }
      


      There is a similar trick that is the reverse where you define a wrapper interface
      that only exposes safe methods and make the real implementation
      unreachable (you always hand out the wrapper externally).

        • 1. Re: Internal AbstractController State
          Adrian Brock Master

           

          "adrian@jboss.org" wrote:

          The reason I say it is dangerous is because there is more to updating a context's
          state than allContexts. There are other "indexes" where the context could exist.


          I'm actually currently changing it so you can have a name->context
          in the allContexts which doesn't exist anywhere else.

          These will be aliases.

          So that will be even more work do in the scoped kernel,
          i.e. move the aliases as well as the main name/context.

          This says to me that we need a well defined api for these operations
          (register/unregisterControllerContext) where this, future enhancements
          and subclasses can plugin their new knowledge.

          • 2. Re: Internal AbstractController State
            Adrian Brock Master

            I've added a protected [un]registerControllerContext(ControllerContext)
            for the alias handling.

            This works when invoked from the [un]installed methods,
            but it does not handle maintinaing or clearing up the other internal state
            for the context (there is none for aliases).