On Dec 30, 2010, at 9:26 AM, Richard S. Hall wrote:
On 12/30/10 7:50, Bjorn Roche wrote:
On Dec 29, 2010, at 8:51 AM, Richard S. Hall wrote:
On 12/29/10 0:20, Bjorn Roche wrote:
On Dec 28, 2010, at 8:00 PM, Richard S. Hall wrote:
Well, resources can be put into packages and shared like
classes via exports...or am I missing something?
In this particular example, it looks like the resource is
contained in the same bundle, so what you are doing is fine
since it delegates to the bundle's class loader (which is a
bundle class loader in this), which does the right thing.
From first reading your email, I thought you were talking about
shared resources...not resources contained in the bundle.
Regardless, resource loading isn't dynamic class loading and
doesn't involve the TCCL, etc. So, this isn't an advanced use
case if this is all you are talking about.
What I'm trying to do is convert an existing app to a single OSGi
bundle and get it to launch that way. Perhaps the length/
complexity/poor explanation of my original email gave you the
impression that I was trying to do something more complex, but
that's really all I want to do.
It was actually all the talk about class loaders and TCCL that
raised a red flag. If all your resources are in your bundle, then
you should only need to ask your class' class loader to find a
resource. No reason to probe around for other class loaders.
I am using the thread context class loader because in a static
context I have nothing else to go on. It looks something like this:
class A {
public static final ICON = new ImageIcon( fetch the resource
data using the TCCL );
...
}
What do you mean? If A is in a bundle, then just
A.class.getResource(), no?
IIRC, that did not work when I was using wrap and assembly, but it's
also possible that I read somewhere not to do that. I am now trying to
get your "exploded" bundle suggestion to work... if/when I get that
working I'll revisit.
bjorn
-----------------------------
Bjorn Roche
http://www.xonami.com
Audio Collaboration
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
