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.
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.
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.
Thanks for all the help so far!
bjorn
-----------------------------
Bjorn Roche
http://www.xonami.com
Audio Collaboration
