[ 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]