felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: java.lang.NoClassDefFoundError: com/apple/eawt/ApplicationListener
Date Wed, 29 Dec 2010 01:00:53 GMT
On 12/28/10 7:55 PM, Richard S. Hall wrote:
> On 12/28/10 6:14 PM, Bjorn Roche wrote:
>>>>>>
>>>>>> 3. The next step was to go through bit-by-bit and fix all the 
>>>>>> dynamic class loading and resource loading. Since I've actually 
>>>>>> not found good documentation explaining, from a user's 
>>>>>> standpoint, how to do this, I just centralized my code and found

>>>>>> something that gets it done. If I'm doing it wrong, at least it's

>>>>>> centralized so I can change it easily.
>>>>>>
>>>>>> - if a bundle is available (OSGi case) use the classloader from 
>>>>>> the bundle.
>>>>>> - if there is an object that likely used the same classloader I 
>>>>>> wanted, which is often the case, get that object's classloader.
>>>>>> - failing that, eg, if I'm in a static context -- I use something

>>>>>> like this: 
>>>>>> Thread.currentThread().getContextClassLoader().loadClass(path);
>>>>>
>>>>> Not sure about all this. I have to assume you are doing some 
>>>>> low-level stuff, since bundles typically shouldn't be doing this 
>>>>> sort of thing.
>>>>
>>>> I'm not doing anything special or low-level that I'm aware of. I 
>>>> did that stuff because I discovered that 
>>>> Thread.currentThread().getContextClassLoader().getResource() 
>>>> doesn't work in OSGi, nor does the System Classloader, but using 
>>>> the bundle did work.
>>>>
>>>> What /should/ I be doing to dynamically load classes and resources?
>>>
>>> Typically, bundles shouldn't have to dynamically load classes 
>>> manually, so it sounds like an advanced use case so far. If you are 
>>> integrating legacy third-party stuff, then you might not have a 
>>> choice, but if it is your own stuff it can quite possibly be avoided 
>>> through the use of services. Hard to say.
>>
>>
>> Okay. Theoretically, I could get rid of all the dynamic class 
>> loading, as it turns out to have been a bit overdesigned anyway, but 
>> leaving that asside, what about resources? If I just want a png or 
>> jpg from the classpath? That is pretty standard. For example, I load 
>> several thousand images from a resource directory, using code not 
>> unlike the code in the java tutorial 
>> (http://download.oracle.com/javase/tutorial/uiswing/components/icon.html):
>>
>> /** Returns an ImageIcon, or null if the path was invalid. */
>> protected ImageIcon createImageIcon(String path,
>>                                            String description) {
>>     java.net.URL imgURL = getClass().getResource(path);
>>     if (imgURL != null) {
>>         return new ImageIcon(imgURL, description);
>>     } else {
>>         System.err.println("Couldn't find file: " + path);
>>         return null;
>>     }
>> }
>> "Low level" or not, can you clarify about the right way to do this? 
>> Is there a better way to do this than using the bundle?
>
> 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.

-> richard

>
> -> richard
>
>>     bjorn
>>
>> -----------------------------
>> Bjorn Roche
>> http://www.xonami.com
>> Audio Collaboration
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message