commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Reilly <>
Subject Re: commons-id Using ClassLoader.getSystemResourceAsStream()
Date Mon, 25 Oct 2004 02:01:10 GMT
On Thu, 21 Oct 2004 11:58:51 -0500, Gregg, John E. wrote:
> Hi all,
> 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?

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. Do you find this
implementation useful?...let me know, I was going to remove it

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

yes. I think there's a way in Maven to say that a resource is a "test
resource" only, but I don't know how. I've actually got a comment in
the project.xml for [id] that says something like "I want this to be a
test only resource, but don't know how"

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

I was reading "When Singleton's aren't Singleton's", and so having the
System classloader load the uuid stuff was what I was going for I
think, although that's from memory.

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

After knowing the rationale I had followed, let me know if you think
there is a better way. I'm still learning, so maybe I've missed on
this. I know the package and class organization is gross. I'm open to
suggestions there as well.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message