jdic
  1. jdic
  2. JDIC-240

Design tasks - Pluggable Service Providers with Mustang

    Details

    • Type: Task Task
    • Status: Open
    • Priority: Blocker Blocker
    • Resolution: Unresolved
    • Affects Version/s: current
    • Fix Version/s: None
    • Component/s: JDIC API general
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      240

      Description

      The api/spi pluggable providers as implemented in Issue_74-78 envision a single
      provider instance and static api methods. Issue 220 requests instance methods
      on each service.

      Will each service.getInstance() method return a singleton, or will multiple
      service instances be created?

      If/when the spi plug point is added, is there going to be a single provider
      instance or a provider instance per service instance?

      An additional factor affecting these decisions is the desire to run in a
      classloader container environment such as JPF. (Look at issue 235)

        Issue Links

          Activity

          Hide
          paul_huang added a comment -

          Good questions, Chas. I am now working on the code to merge the branch
          Issue_74-78 into the trunk, plus to apply the API changes introduced in Issue 220.

          Actually, I am now just considering these questions. What would be your suggestion?

          Show
          paul_huang added a comment - Good questions, Chas. I am now working on the code to merge the branch Issue_74-78 into the trunk, plus to apply the API changes introduced in Issue 220. Actually, I am now just considering these questions. What would be your suggestion?
          Hide
          paul_huang added a comment -

          I looked at the refactoring code from branch Issue_74-78 again and realized that
          in this implementation, we actually obtained a singleton provider instance and
          use this instance to invoke each method. If I am right, this should help to
          avoide the limitation that "Static methods limit the potential of extension in
          the future.". We can still "manage appcontext-sensitive configuration settintgs,
          enforce security, etc. "

          If this is the case, we can still keep using the static method invocation.

          What's your idea, Chas?

          Correct me if I am wrong.

          Show
          paul_huang added a comment - I looked at the refactoring code from branch Issue_74-78 again and realized that in this implementation, we actually obtained a singleton provider instance and use this instance to invoke each method. If I am right, this should help to avoide the limitation that "Static methods limit the potential of extension in the future.". We can still "manage appcontext-sensitive configuration settintgs, enforce security, etc. " If this is the case, we can still keep using the static method invocation. What's your idea, Chas? Correct me if I am wrong.
          Hide
          chas added a comment -

          I believe this will work for simple containers such as webstart or applet. We
          would have problems in a EJB or servlet container, particularly with hot-deploy
          applications. On the other hand, I doubt that EJBs or servlets are going to
          need desktop services.

          Can you imagine any scenario where a single application instance is going to
          need multiple behaviors (either security or configuration)?

          We'll want to minimize the number of expensive security checks. I think this
          can be done once in each provider factory. I doubt security policies would
          change based upon the thread.

          The related issue 235 is that the delayed provider class loading occurs in the
          AWT thread which does not have the same thread context classloader as the main
          application thread and therefore cannot find the provider. The JPF framework
          has a similar problem with Swing Look&Feel resources, so I am not sure we need
          to change the SPI pattern to solve this issue. Additionally, this problem will
          also go away if the jdic classes are loaded by the system classloader.

          Show
          chas added a comment - I believe this will work for simple containers such as webstart or applet. We would have problems in a EJB or servlet container, particularly with hot-deploy applications. On the other hand, I doubt that EJBs or servlets are going to need desktop services. Can you imagine any scenario where a single application instance is going to need multiple behaviors (either security or configuration)? We'll want to minimize the number of expensive security checks. I think this can be done once in each provider factory. I doubt security policies would change based upon the thread. The related issue 235 is that the delayed provider class loading occurs in the AWT thread which does not have the same thread context classloader as the main application thread and therefore cannot find the provider. The JPF framework has a similar problem with Swing Look&Feel resources, so I am not sure we need to change the SPI pattern to solve this issue. Additionally, this problem will also go away if the jdic classes are loaded by the system classloader.
          Hide
          paul_huang added a comment -

          This is the feedback from the AWT team.

          "I think you need to just make another small step from the hidden, private
          factory to a public factory, which Desktop.getDesktop is actually.

          I am not saying you need to do this for JDIC Desktop package, but J2SE API
          should have such a design."

          Show
          paul_huang added a comment - This is the feedback from the AWT team. "I think you need to just make another small step from the hidden, private factory to a public factory, which Desktop.getDesktop is actually. I am not saying you need to do this for JDIC Desktop package, but J2SE API should have such a design."

            People

            • Assignee:
              paul_huang
              Reporter:
              chas
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated: