[jira] Updated: (SANDBOX-53) [id] ReadOnlyResourceStateImpl uses ClassLoader.getSystemResourceAsStream

["Henri Yandell (JIRA)" <ji...@apache.org>]

     [ http://issues.apache.org/jira/browse/SANDBOX-53?page=all ]

Henri Yandell updated SANDBOX-53:
---------------------------------

    Component: Id

> [id] ReadOnlyResourceStateImpl uses ClassLoader.getSystemResourceAsStream
> -------------------------------------------------------------------------
>
>          Key: SANDBOX-53
>          URL: http://issues.apache.org/jira/browse/SANDBOX-53
>      Project: Commons Sandbox
>         Type: Bug

>   Components: Id
>     Versions: 1.0 Alpha
>  Environment: Operating System: other
> Platform: Other
>     Reporter: Phil Steitz

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

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org