commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 35602] New: - [id] ReadOnlyResourceStateImpl uses ClassLoader.getSystemResourceAsStream
Date Tue, 05 Jul 2005 04:13:51 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=35602>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35602

           Summary: [id] ReadOnlyResourceStateImpl uses
                    ClassLoader.getSystemResourceAsStream
           Product: Commons
           Version: 1.0 Alpha
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Sandbox
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: phil@steitz.com


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

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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


Mime
View raw message