Uploaded image for project: 'Commons Sandbox'
  1. Commons Sandbox
  2. SANDBOX-53

[id] ReadOnlyResourceStateImpl uses ClassLoader.getSystemResourceAsStream



    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Id
    • Labels:
    • Environment:

      Operating System: other
      Platform: Other

    • Bugzilla Id:


      From post to commons-dev from John Gregg:

      I'm having a little trouble with the fact that commons-id's
      ReadOnlyResourceStateImpl uses ClassLoader.getSystemResourceAsStream to load
      the config file containing MAC addresses. Is that intentional? When I'm
      testing my app with Maven, the only thing in the system class loader's path
      is Maven's forehead jar. Perhaps I can/should change that, but it causes my
      test to fail because my config file isn't found. If I use
      this.getClass().getResourceAsStream(), things are fine. I can understand
      why the system class loader is used, however, for that particular file--
      because it's based on where the app is deployed and therefore is not
      portable, like the rest of the app is. If you think it should change to use
      the app's class loader, I'll submit a patch. If you think it should stay
      the way it is, I might consider refactoring the load() method to use
      inversion of control so I can better test with mock objects and not worry
      about environmental concerns. If I do that I'll submit a patch.

      Response from Tim Reilly:

      It was intentional since I was thinking the commons-id.jar and the
      configuration xml should be deployed to the jre/lib/ext directory -
      Thought process was: this way all classloaders/contexts use the same
      file/MAC addresses regardless of application isolation. This is much
      less important for the ReadOnlyResourceStateImpl, but important for
      the ReadWriteStateImpl. Seperate applications or even jre instances
      (as in vertical clusters) should all use the same configuration. The
      real issue is that there's no good way I can think to get a device
      wide mutex/or lock. I'm thinking of using the locking mechanism from
      sandbox-transaction (a file based locking mechanism)

      ReadOnlyResourceStateImpl was a mistake on my part. I thought EJB
      containers would be alright with non-explicit i/o, such as
      ClassLoader.getSystemResourceAsStream but then I was reminded that
      accessing classloaders is also a no-no.




            • Assignee:
              phil@steitz.com Phil Steitz
            • Votes:
              0 Vote for this issue
              0 Start watching this issue


              • Created: