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 Fri, 31 Dec 2010 17:26:24 GMT
On 12/31/10 11:28, Bjorn Roche wrote:
> On Dec 30, 2010, at 2:51 PM, Richard S. Hall wrote:
>
>> On 12/30/10 14:41, Bjorn Roche wrote:
>>>
>>> On Dec 28, 2010, at 4:54 PM, Richard S. Hall wrote:
>>>
>>>> On 12/28/10 13:58, Bjorn Roche wrote:
>>>>>
>>>>> On Dec 28, 2010, at 12:24 PM, Richard S. Hall wrote:
>>>>>
>>>>>>> That's gotten me some distance. The app actually launches to
a 
>>>>>>> point. I'm still having two problems, though:
>>>>>>>
>>>>>>> A. My app won't load any JNI stuff no matter what I do.
>>>>>>> B. Putting that aside, I get this error:
>>>>>>>
>>>>>>> Caused by: java.lang.NoClassDefFoundError: 
>>>>>>> com/apple/eawt/ApplicationListener
>>>>>>
>>>>>> I don't know about this either. There are some issues with Java 
>>>>>> and the Mac Java GUI implementation, something about needing to 
>>>>>> use the right thread or something. Maybe it is related...
>>>>>
>>>>> Hmmm, well I'd love to know what that is exactly, otherwise I may 
>>>>> be SOL. In the meantime, I will try the "exploded bundle" thing 
>>>>> and see if that works any better.
>>>>
>>>> Yeah, maybe someone else knows more.
>>>>
>>>> -> richard
>>>
>>>
>>> Okay, so I tried your suggestion of building using the exploded 
>>> bundle. It works about as well as the "assembly:" and "wrap:" trick, 
>>> and both techniques seem to have their pros and cons. I got stuck at 
>>> the same point: java.lang.NoClassDefFoundError: 
>>> com/apple/eawt/ApplicationListener
>>>
>>> To belabor the point, here's the code that failed:
>>>
>>>        if (os == MAC_OS_X) {
>>>            try {
>>>                Class<?> osxAdapter = 
>>> ResourceUtil.getClass(app,"xowave.util.OSXAdapter");
>>>                Class<?>[] defArgs = { OSXApp.class };
>>>                Constructor<?> constructor = 
>>> osxAdapter.getConstructor(defArgs);
>>>                if (constructor != null) {
>>>                    Object[] args = { app };
>>>                    constructor.newInstance(args);
>>>                }
>>>            } catch (Exception e) {
>>>                ...
>>>            }
>>>
>>>
>>> Now xowave.util.OSXAdapter implements 
>>> com.apple.eawt.ApplicationListener, which is only available on mac 
>>> OS X, so if the class were loaded directly, it would cause 
>>> class-loading problems on non-OSX platforms, so I added the dynamic 
>>> loading code. (I don't recall if this is exactly the approach 
>>> recommended by apple, but something like it.)
>>
>> And your bundle imports the "xowave.util" package?
>
> xowave.util is part of the bundle.

Does the mentioned class have a direct dependency on 
com.apple.eawt.ApplicationListener? If so, is the bundle importing that 
package?

>
>>> I was able to get around this by following Richard's hunch: I simply 
>>> by putting the above code in the swing thread with a call to 
>>> SwingUtilities.invokeLater().
>>>
>>> This strikes me as a bug in OSGi because I should not need to be in 
>>> a particular thread to implement an interface no matter what the 
>>> interface is.
>>
>> I don't know if this is the issue, but if it is, the way I understood 
>> it, it is a limitation of the Mac implementation of AWT or something.
>
> It works fine outside of OSGi.

That's doesn't mean that it isn't a Mac implementation issue. I'm not 
saying it is or it isn't, though. Here is one example:

     http://www.eclipsezone.com/eclipse/forums/m92141277.html

>
>>> I am still stuck loading native code, though. I added this to my 
>>> MANIFEST.MF:
>>>
>>> Bundle-NativeCode: native/libXOengine-DOUBLE.jnilib ; 
>>> native/libXOengine-FLOAT.jnilib ; native/libquaqua.jnilib ;
>>>   processor=x86 ;
>>>   processor=ppc ;
>>>   osname=mac os x
>>>
>>> where the paths are relative to my bundle. I have some indication 
>>> that this is correct because if I deliberately type change something 
>>> I get
>>>
>>> Native library does not exist
>>> or
>>> No matching native libraries found.
>>>
>>> but when my code calls
>>>
>>> System.loadLibrary( "XOengine-FLOAT" );
>>>
>>> I get
>>>
>>> Caused by: java.lang.UnsatisfiedLinkError: no XOengine-FLOAT in 
>>> java.library.path
>>
>> Not sure. It should work. If you can create a simple bundle that 
>> fails, I can try it, since I work on a Mac. Send it to me privately.
>
> If I can reproduce on a small scale, I will, thank you. In the 
> meantime, I just noticed I am getting this, apparently from felix:
>
> ERROR: Unable to create library directory.
>
> What's more, System.load() works, where System.loadLibrary fails.
>
> Some googling suggested that the install name of the library might be 
> the issue, but I mucked with that without any luck.

Well, it should work. Let me know.

-> richard

>
> Thanks for all the help so far!
>
>     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


Mime
View raw message