You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Bjorn Roche <bj...@xowave.com> on 2010/12/28 14:58:01 UTC
java.lang.NoClassDefFoundError: com/apple/eawt/ApplicationListener
First off, sorry if I am missing something obvious -- I've been
chugging away trying to "OSGi-ify" 250,000 lines of code and it's
wrecking havoc on my basic ability to think, so I probably am missing
something obvious...
Here's how I've been progressing:
1. First, I built a small infrastructure that lets me run my code
without JAR'ing it up, since JAR'ing my code after every small change
is going to be prohibitively slow. This is primarily dependent on the
"assembly" and "wrap" URL protocols from the pax runner folks -- so
they've done the hard work for me. I created a project to help others
with this as well, and once I get this working I plan to put more
instructions up:
http://code.google.com/p/piecemeal/
2. Replace sym links with actual files where necessary. The pax runner
code doesn't seem to like sym links.
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);
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
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:676)
at org.apache.felix.framework.ModuleImpl
$ModuleClassLoader.findClass(ModuleImpl.java:1907)
at
org
.apache
.felix
.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:
727)
at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71)
at org.apache.felix.framework.ModuleImpl
$ModuleClassLoader.loadClass(ModuleImpl.java:1768)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at
org
.apache
.felix.framework.ModuleImpl.getClassByDelegation(ModuleImpl.java:645)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1599)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:904)
at com.xowave.sjwidget.ResourceUtil.getClass(ResourceUtil.java:132)
.....
I have seen that kind of error in reference to knopflerfish, which
apparently has (had?) a bug causing apple's ApplicationListener class
not to load, but I am not seeing any answers relating to Felix. I've
been through my build and, on the mac, I don't seem to be doing
anything special to load add that class to the classpath when I'm not
using OSGi -- do I need to do something special to add it when I am
using OSGi?
Any other suggestions?
TIA,
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
Re: java.lang.NoClassDefFoundError: com/apple/eawt/ApplicationListener
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 12/28/10 14:45, Bjorn Roche wrote:
>
> On Dec 28, 2010, at 1:58 PM, Bjorn Roche wrote:
>
>>
>> On Dec 28, 2010, at 12:24 PM, Richard S. Hall wrote:
>>
>>> On 12/28/10 8:58, Bjorn Roche wrote:
>>>> First off, sorry if I am missing something obvious -- I've been
>>>> chugging away trying to "OSGi-ify" 250,000 lines of code and it's
>>>> wrecking havoc on my basic ability to think, so I probably am
>>>> missing something obvious...
>>>>
>>>>
>>>> Here's how I've been progressing:
>>>>
>>>> 1. First, I built a small infrastructure that lets me run my code
>>>> without JAR'ing it up, since JAR'ing my code after every small
>>>> change is going to be prohibitively slow. This is primarily
>>>> dependent on the "assembly" and "wrap" URL protocols from the pax
>>>> runner folks -- so they've done the hard work for me. I created a
>>>> project to help others with this as well, and once I get this
>>>> working I plan to put more instructions up:
>>>>
>>>> http://code.google.com/p/piecemeal/
>>>
>>> Did you know you can install an "exploded" bundle as a directory in
>>> both Equinox and Felix just by appending "reference:" to the URL
>>> pointing to the directory? This shouldn't be used in place of
>>> ultimately creating a JAR file, but it can help during development.
>>
>> I did not. Sounds like the same concept as the assembly URL. When I
>> google this, all I get is ml postings and a few Eclipse articles. Is
>> there somewhere this is properly documented? Perhaps it will work
>> better than what I'm doing now.
>>
>
> Well I can't figure out how to include the .jar files my app depends
> on, which is something I can do with the "assembly:" protocol
> (actually, the "assemblyref"), plus I get missing parts of core java:
>
> java.lang.NoClassDefFoundError:
> javax/sound/sampled/UnsupportedAudioFileException
>
> So I think this is a no go, unless someone has some hints for me.
Yeah, the "reference:" protocol won't assemble a bundle for you, it
assumes you've created a directory that looks like a bundle already.
This directory can then contain your needed JAR files which would be
mentioned on the Bundle-ClassPath like normal.
-> 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
Re: java.lang.NoClassDefFoundError: com/apple/eawt/ApplicationListener
Posted by Bjorn Roche <bj...@xowave.com>.
On Dec 28, 2010, at 1:58 PM, Bjorn Roche wrote:
>
> On Dec 28, 2010, at 12:24 PM, Richard S. Hall wrote:
>
>> On 12/28/10 8:58, Bjorn Roche wrote:
>>> First off, sorry if I am missing something obvious -- I've been
>>> chugging away trying to "OSGi-ify" 250,000 lines of code and it's
>>> wrecking havoc on my basic ability to think, so I probably am
>>> missing something obvious...
>>>
>>>
>>> Here's how I've been progressing:
>>>
>>> 1. First, I built a small infrastructure that lets me run my code
>>> without JAR'ing it up, since JAR'ing my code after every small
>>> change is going to be prohibitively slow. This is primarily
>>> dependent on the "assembly" and "wrap" URL protocols from the pax
>>> runner folks -- so they've done the hard work for me. I created a
>>> project to help others with this as well, and once I get this
>>> working I plan to put more instructions up:
>>>
>>> http://code.google.com/p/piecemeal/
>>
>> Did you know you can install an "exploded" bundle as a directory in
>> both Equinox and Felix just by appending "reference:" to the URL
>> pointing to the directory? This shouldn't be used in place of
>> ultimately creating a JAR file, but it can help during development.
>
> I did not. Sounds like the same concept as the assembly URL. When I
> google this, all I get is ml postings and a few Eclipse articles. Is
> there somewhere this is properly documented? Perhaps it will work
> better than what I'm doing now.
>
Well I can't figure out how to include the .jar files my app depends
on, which is something I can do with the "assembly:" protocol
(actually, the "assemblyref"), plus I get missing parts of core java:
java.lang.NoClassDefFoundError: javax/sound/sampled/
UnsupportedAudioFileException
So I think this is a no go, unless someone has some hints for me.
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
Re: java.lang.NoClassDefFoundError: com/apple/eawt/ApplicationListener
Posted by Bjorn Roche <bj...@xowave.com>.
On Jan 3, 2011, at 11:51 AM, Richard S. Hall wrote:
> On 1/3/11 9:51, Bjorn Roche wrote:
>>
>> On Jan 2, 2011, at 10:58 PM, Richard S. Hall wrote:
>>
>>> On 1/2/11 20:03, Bjorn Roche wrote:
>>>>
>>>> On Dec 31, 2010, at 12:26 PM, Richard S. Hall wrote:
>>>>
>>>>> 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.
>>>>
>>>>
>>>> It's my understanding that java.library.path is not used -- at
>>>> least directly -- during normal Felix/OSGi operation, but I
>>>> thought I'd see what its value was right before calling
>>>> System.loadLibrary to get a hint. When I run my code outside of
>>>> OSGi I get:
>>>>
>>>> .:/Users/bjorn/Library/Java/Extensions:/Library/Java/Extensions:/
>>>> System/Library/Java/Extensions:/usr/lib/java
>>>>
>>>> which seams reasonable. I use -Djava.library.path to set it to
>>>> just the path I care about with my native libs so that they will
>>>> load, and that's always worked.
>>>>
>>>> Inside felix/OSGi, the same line of code gives:
>>>>
>>>> :/usr/local/ImageMagick-6.3.9//lib:.:/Users/bjorn/Library/Java/
>>>> Extensions:/Library/Java/Extensions:/System/Library/Java/
>>>> Extensions:/usr/lib/java
>>>>
>>>> which seemed whack, at least the part before the what I get out
>>>> of OSGi. It turned out my .profile was setting that ImageMagick
>>>> line, and, moreover, it was totally bogus:
>>>>
>>>> .profile:MAGICK_HOME="/usr/local/ImageMagick-6.3.9/" ; export
>>>> MAGICK_HOME
>>>> arigato:~ bjorn$ grep MAGICK_HOME .*
>>>> .profile:MAGICK_HOME="/usr/local/ImageMagick-6.3.9/" ; export
>>>> MAGICK_HOME
>>>> .profile:#MAGICK_HOME="/usr/local/" ; export MAGICK_HOME
>>>> .profile:PATH="$PATH:$MAGICK_HOME/bin:":~/bin: ; export PATH
>>>> .profile:DYLD_LIBRARY_PATH="$DYLD_LIBRARY_PATH:$MAGICK_HOME/
>>>> lib" ; export DYLD_LIBRARY_PATH
>>>>
>>>> arigato:~ bjorn$ ls /usr/local/ImageMagick-6.3.9/
>>>> ls: /usr/local/ImageMagick-6.3.9/: No such file or directory
>>>>
>>>> Once I removed that (I think this was from a failed gallery
>>>> remote install) and restarted my shell I got something reasonable
>>>> out of java.library.path, even inside OSGi:
>>>>
>>>> .:/Users/bjorn/Library/Java/Extensions:/Library/Java/Extensions:/
>>>> System/Library/Java/Extensions:/usr/lib/java
>>>>
>>>> Once that's fixed, I get a slightly different error when I run my
>>>> app:
>>>>
>>>> ERROR: Extracting native library.
>>>> (java.io.FileNotFoundException: ./felix-cache/bundle3/version0.0/
>>>> xowave-lib/0/native/libXOengine-FLOAT.jnilib (No such file or
>>>> directory))
>>>> java.io.FileNotFoundException: ./felix-cache/bundle3/version0.0/
>>>> xowave-lib/0/native/libXOengine-FLOAT.jnilib (No such file or
>>>> directory)
>>>> java.io.FileNotFoundException: ./felix-cache/bundle3/version0.0/
>>>> xowave-lib/0/native/libXOengine-FLOAT.jnilib (No such file or
>>>> directory)
>>>> at java.io.FileOutputStream.open(Native Method)
>>>> at java.io.FileOutputStream.<init>(FileOutputStream.java:179)
>>>> at java.io.FileOutputStream.<init>(FileOutputStream.java:131)
>>>> at
>>>> org
>>>> .apache
>>>> .felix
>>>> .framework
>>>> .util.SecureAction.getFileOutputStream(SecureAction.java:461)
>>>> at
>>>> org
>>>> .apache
>>>> .felix
>>>> .framework.cache.BundleCache.copyStreamToFile(BundleCache.java:310)
>>>> at
>>>> org
>>>> .apache
>>>> .felix
>>>> .framework
>>>> .cache
>>>> .DirectoryContent.getEntryAsNativeLibrary(DirectoryContent.java:
>>>> 266)
>>>> at org.apache.felix.framework.ModuleImpl
>>>> $ModuleClassLoader.findLibrary(ModuleImpl.java:2081)
>>>>
>>>> After I did a little digging I found the directory tree it
>>>> claimed to be looking for (felix-cache/bundle3/version0.0/xowave-
>>>> lib/0/native/), but it wasn't in the current directory; it was in
>>>> my home directory. By deleting the caches directory and
>>>> rerunning, I realized that felix is building two caches every
>>>> time I run it, one in my home dir and one in the current dir.
>>>> There seems to be some bug relating to this. Setting the
>>>> temporary dir explicitly to my home dir:
>>>>
>>>> org.osgi.framework.storage=/Users/bjorn/felix-cache
>>>>
>>>> works! Also works when I set the storage dir from the command
>>>> line rather than the conf file:
>>>>
>>>> -Dorg.osgi.framework.storage=/tmp/$USER/felix-cache
>>>>
>>>>
>>>> Great, so I have a solution. Still, it seems there is a problem
>>>> with locating the cache dir (is it in the home dir or current
>>>> dir?). Also, it seems to me that even if a bogus path is added to
>>>> DYLD_LIBRARY_PATH, that shouldn't change anything.
>>>
>>> If no cache directory is specified, the Felix framework will
>>> create a "felix-cache" directory in the current directory (i.e.,
>>> the directory you are in when you launch the framework). So, if
>>> you are starting the framework from different directories, you'll
>>> see it get created in different places. I don't think there is any
>>> way a single execution of the framework will create multiple
>>> copies of the cache.
>>
>> when I ran felix, it would create cache directories in both my home
>> and current directories. I verified this by deleting "felix-cache"
>> in both the current and home dir, running felix once, and locating
>> these directories again. It built the felix-cache/bundle3/
>> version0.0/xowave-lib/0/native/ tree in my home directory, but then
>> complained that it couldn't find it. It put everything else in the
>> current directory. The solution to this issue seemed to be to
>> specify the org.osgi.framework.storage variable from the command
>> line rather than the configuration file, but I'm not really sure.
>
> Maybe this is a bug in the code to support "exploded bundles". Can
> you create a test case (framework configuration and/or bundle) that
> demonstrates this? If so, open a bug an submit it.
That seems like the most likely explanation to me. I am working on a
minimal test case.
>>
>>> Regarding the java.library.path, the framework doesn't look at
>>> this at all. This should only impact the JVM. The only thing the
>>> framework does is create a custom class loader that overrides
>>> findLibrary() and waits for the JVM to call it when a class loaded
>>> by the class loader needs a native library.
>>
>> I'm not really sure what the issue here was -- I only used
>> java.library.path to discover what was going on and it may only
>> have been related incidentally. Perhaps the issue has to do with
>> the $DYLD_LIBRARY_PATH variable -- it must at least indirectly
>> since that's what I changed to get it working.
>
> Maybe, but I'm not sure how it would impact the framework, since it
> never consults it.
>
Hmmm. That's odd. Maybe it has some indirect impact. I will see if I
can reproduce that on some small sample code as well. It's possible I
have a configuration issue on my system.
bjorn
-----------------------------
Bjorn Roche
http://www.xonami.com
Audio Collaboration
Re: java.lang.NoClassDefFoundError: com/apple/eawt/ApplicationListener
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 1/3/11 9:51, Bjorn Roche wrote:
>
> On Jan 2, 2011, at 10:58 PM, Richard S. Hall wrote:
>
>> On 1/2/11 20:03, Bjorn Roche wrote:
>>>
>>> On Dec 31, 2010, at 12:26 PM, Richard S. Hall wrote:
>>>
>>>> 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.
>>>
>>>
>>> It's my understanding that java.library.path is not used -- at least
>>> directly -- during normal Felix/OSGi operation, but I thought I'd
>>> see what its value was right before calling System.loadLibrary to
>>> get a hint. When I run my code outside of OSGi I get:
>>>
>>> .:/Users/bjorn/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java
>>>
>>>
>>> which seams reasonable. I use -Djava.library.path to set it to just
>>> the path I care about with my native libs so that they will load,
>>> and that's always worked.
>>>
>>> Inside felix/OSGi, the same line of code gives:
>>>
>>> :/usr/local/ImageMagick-6.3.9//lib:.:/Users/bjorn/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java
>>>
>>>
>>> which seemed whack, at least the part before the what I get out of
>>> OSGi. It turned out my .profile was setting that ImageMagick line,
>>> and, moreover, it was totally bogus:
>>>
>>> .profile:MAGICK_HOME="/usr/local/ImageMagick-6.3.9/" ; export
>>> MAGICK_HOME
>>> arigato:~ bjorn$ grep MAGICK_HOME .*
>>> .profile:MAGICK_HOME="/usr/local/ImageMagick-6.3.9/" ; export
>>> MAGICK_HOME
>>> .profile:#MAGICK_HOME="/usr/local/" ; export MAGICK_HOME
>>> .profile:PATH="$PATH:$MAGICK_HOME/bin:":~/bin: ; export PATH
>>> .profile:DYLD_LIBRARY_PATH="$DYLD_LIBRARY_PATH:$MAGICK_HOME/lib" ;
>>> export DYLD_LIBRARY_PATH
>>>
>>> arigato:~ bjorn$ ls /usr/local/ImageMagick-6.3.9/
>>> ls: /usr/local/ImageMagick-6.3.9/: No such file or directory
>>>
>>> Once I removed that (I think this was from a failed gallery remote
>>> install) and restarted my shell I got something reasonable out of
>>> java.library.path, even inside OSGi:
>>>
>>> .:/Users/bjorn/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java
>>>
>>>
>>> Once that's fixed, I get a slightly different error when I run my app:
>>>
>>> ERROR: Extracting native library. (java.io.FileNotFoundException:
>>> ./felix-cache/bundle3/version0.0/xowave-lib/0/native/libXOengine-FLOAT.jnilib
>>> (No such file or directory))
>>> java.io.FileNotFoundException:
>>> ./felix-cache/bundle3/version0.0/xowave-lib/0/native/libXOengine-FLOAT.jnilib
>>> (No such file or directory)
>>> java.io.FileNotFoundException:
>>> ./felix-cache/bundle3/version0.0/xowave-lib/0/native/libXOengine-FLOAT.jnilib
>>> (No such file or directory)
>>> at java.io.FileOutputStream.open(Native Method)
>>> at java.io.FileOutputStream.<init>(FileOutputStream.java:179)
>>> at java.io.FileOutputStream.<init>(FileOutputStream.java:131)
>>> at
>>> org.apache.felix.framework.util.SecureAction.getFileOutputStream(SecureAction.java:461)
>>> at
>>> org.apache.felix.framework.cache.BundleCache.copyStreamToFile(BundleCache.java:310)
>>> at
>>> org.apache.felix.framework.cache.DirectoryContent.getEntryAsNativeLibrary(DirectoryContent.java:266)
>>> at
>>> org.apache.felix.framework.ModuleImpl$ModuleClassLoader.findLibrary(ModuleImpl.java:2081)
>>>
>>> After I did a little digging I found the directory tree it claimed
>>> to be looking for
>>> (felix-cache/bundle3/version0.0/xowave-lib/0/native/), but it wasn't
>>> in the current directory; it was in my home directory. By deleting
>>> the caches directory and rerunning, I realized that felix is
>>> building two caches every time I run it, one in my home dir and one
>>> in the current dir. There seems to be some bug relating to this.
>>> Setting the temporary dir explicitly to my home dir:
>>>
>>> org.osgi.framework.storage=/Users/bjorn/felix-cache
>>>
>>> works! Also works when I set the storage dir from the command line
>>> rather than the conf file:
>>>
>>> -Dorg.osgi.framework.storage=/tmp/$USER/felix-cache
>>>
>>>
>>> Great, so I have a solution. Still, it seems there is a problem with
>>> locating the cache dir (is it in the home dir or current dir?).
>>> Also, it seems to me that even if a bogus path is added to
>>> DYLD_LIBRARY_PATH, that shouldn't change anything.
>>
>> If no cache directory is specified, the Felix framework will create a
>> "felix-cache" directory in the current directory (i.e., the directory
>> you are in when you launch the framework). So, if you are starting
>> the framework from different directories, you'll see it get created
>> in different places. I don't think there is any way a single
>> execution of the framework will create multiple copies of the cache.
>
> when I ran felix, it would create cache directories in both my home
> and current directories. I verified this by deleting "felix-cache" in
> both the current and home dir, running felix once, and locating these
> directories again. It built the
> felix-cache/bundle3/version0.0/xowave-lib/0/native/ tree in my home
> directory, but then complained that it couldn't find it. It put
> everything else in the current directory. The solution to this issue
> seemed to be to specify the org.osgi.framework.storage variable from
> the command line rather than the configuration file, but I'm not
> really sure.
Maybe this is a bug in the code to support "exploded bundles". Can you
create a test case (framework configuration and/or bundle) that
demonstrates this? If so, open a bug an submit it.
>
>> Regarding the java.library.path, the framework doesn't look at this
>> at all. This should only impact the JVM. The only thing the framework
>> does is create a custom class loader that overrides findLibrary() and
>> waits for the JVM to call it when a class loaded by the class loader
>> needs a native library.
>
> I'm not really sure what the issue here was -- I only used
> java.library.path to discover what was going on and it may only have
> been related incidentally. Perhaps the issue has to do with the
> $DYLD_LIBRARY_PATH variable -- it must at least indirectly since
> that's what I changed to get it working.
Maybe, but I'm not sure how it would impact the framework, since it
never consults it.
>
>> Other than that, I'm not sure what to tell you. Again, if you can get
>> me an example bundle and a set of steps to reproduce any issues you
>> are seeing, I'd gladly look into it.
>
> I will see what I can do.
Thanks!
-> 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
Re: java.lang.NoClassDefFoundError: com/apple/eawt/ApplicationListener
Posted by Bjorn Roche <bj...@xowave.com>.
On Jan 2, 2011, at 10:58 PM, Richard S. Hall wrote:
> On 1/2/11 20:03, Bjorn Roche wrote:
>>
>> On Dec 31, 2010, at 12:26 PM, Richard S. Hall wrote:
>>
>>> 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.
>>
>>
>> It's my understanding that java.library.path is not used -- at
>> least directly -- during normal Felix/OSGi operation, but I thought
>> I'd see what its value was right before calling System.loadLibrary
>> to get a hint. When I run my code outside of OSGi I get:
>>
>> .:/Users/bjorn/Library/Java/Extensions:/Library/Java/Extensions:/
>> System/Library/Java/Extensions:/usr/lib/java
>>
>> which seams reasonable. I use -Djava.library.path to set it to just
>> the path I care about with my native libs so that they will load,
>> and that's always worked.
>>
>> Inside felix/OSGi, the same line of code gives:
>>
>> :/usr/local/ImageMagick-6.3.9//lib:.:/Users/bjorn/Library/Java/
>> Extensions:/Library/Java/Extensions:/System/Library/Java/
>> Extensions:/usr/lib/java
>>
>> which seemed whack, at least the part before the what I get out of
>> OSGi. It turned out my .profile was setting that ImageMagick line,
>> and, moreover, it was totally bogus:
>>
>> .profile:MAGICK_HOME="/usr/local/ImageMagick-6.3.9/" ; export
>> MAGICK_HOME
>> arigato:~ bjorn$ grep MAGICK_HOME .*
>> .profile:MAGICK_HOME="/usr/local/ImageMagick-6.3.9/" ; export
>> MAGICK_HOME
>> .profile:#MAGICK_HOME="/usr/local/" ; export MAGICK_HOME
>> .profile:PATH="$PATH:$MAGICK_HOME/bin:":~/bin: ; export PATH
>> .profile:DYLD_LIBRARY_PATH="$DYLD_LIBRARY_PATH:$MAGICK_HOME/lib" ;
>> export DYLD_LIBRARY_PATH
>>
>> arigato:~ bjorn$ ls /usr/local/ImageMagick-6.3.9/
>> ls: /usr/local/ImageMagick-6.3.9/: No such file or directory
>>
>> Once I removed that (I think this was from a failed gallery remote
>> install) and restarted my shell I got something reasonable out of
>> java.library.path, even inside OSGi:
>>
>> .:/Users/bjorn/Library/Java/Extensions:/Library/Java/Extensions:/
>> System/Library/Java/Extensions:/usr/lib/java
>>
>> Once that's fixed, I get a slightly different error when I run my
>> app:
>>
>> ERROR: Extracting native library. (java.io.FileNotFoundException: ./
>> felix-cache/bundle3/version0.0/xowave-lib/0/native/libXOengine-
>> FLOAT.jnilib (No such file or directory))
>> java.io.FileNotFoundException: ./felix-cache/bundle3/version0.0/
>> xowave-lib/0/native/libXOengine-FLOAT.jnilib (No such file or
>> directory)
>> java.io.FileNotFoundException: ./felix-cache/bundle3/version0.0/
>> xowave-lib/0/native/libXOengine-FLOAT.jnilib (No such file or
>> directory)
>> at java.io.FileOutputStream.open(Native Method)
>> at java.io.FileOutputStream.<init>(FileOutputStream.java:179)
>> at java.io.FileOutputStream.<init>(FileOutputStream.java:131)
>> at
>> org
>> .apache
>> .felix
>> .framework.util.SecureAction.getFileOutputStream(SecureAction.java:
>> 461)
>> at
>> org
>> .apache
>> .felix
>> .framework.cache.BundleCache.copyStreamToFile(BundleCache.java:310)
>> at
>> org
>> .apache
>> .felix
>> .framework
>> .cache
>> .DirectoryContent.getEntryAsNativeLibrary(DirectoryContent.java:266)
>> at org.apache.felix.framework.ModuleImpl
>> $ModuleClassLoader.findLibrary(ModuleImpl.java:2081)
>>
>> After I did a little digging I found the directory tree it claimed
>> to be looking for (felix-cache/bundle3/version0.0/xowave-lib/0/
>> native/), but it wasn't in the current directory; it was in my home
>> directory. By deleting the caches directory and rerunning, I
>> realized that felix is building two caches every time I run it, one
>> in my home dir and one in the current dir. There seems to be some
>> bug relating to this. Setting the temporary dir explicitly to my
>> home dir:
>>
>> org.osgi.framework.storage=/Users/bjorn/felix-cache
>>
>> works! Also works when I set the storage dir from the command line
>> rather than the conf file:
>>
>> -Dorg.osgi.framework.storage=/tmp/$USER/felix-cache
>>
>>
>> Great, so I have a solution. Still, it seems there is a problem
>> with locating the cache dir (is it in the home dir or current
>> dir?). Also, it seems to me that even if a bogus path is added to
>> DYLD_LIBRARY_PATH, that shouldn't change anything.
>
> If no cache directory is specified, the Felix framework will create
> a "felix-cache" directory in the current directory (i.e., the
> directory you are in when you launch the framework). So, if you are
> starting the framework from different directories, you'll see it get
> created in different places. I don't think there is any way a single
> execution of the framework will create multiple copies of the cache.
when I ran felix, it would create cache directories in both my home
and current directories. I verified this by deleting "felix-cache" in
both the current and home dir, running felix once, and locating these
directories again. It built the felix-cache/bundle3/version0.0/xowave-
lib/0/native/ tree in my home directory, but then complained that it
couldn't find it. It put everything else in the current directory. The
solution to this issue seemed to be to specify the
org.osgi.framework.storage variable from the command line rather than
the configuration file, but I'm not really sure.
> Regarding the java.library.path, the framework doesn't look at this
> at all. This should only impact the JVM. The only thing the
> framework does is create a custom class loader that overrides
> findLibrary() and waits for the JVM to call it when a class loaded
> by the class loader needs a native library.
I'm not really sure what the issue here was -- I only used
java.library.path to discover what was going on and it may only have
been related incidentally. Perhaps the issue has to do with the
$DYLD_LIBRARY_PATH variable -- it must at least indirectly since
that's what I changed to get it working.
> Other than that, I'm not sure what to tell you. Again, if you can
> get me an example bundle and a set of steps to reproduce any issues
> you are seeing, I'd gladly look into it.
I will see what I can do.
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
Re: java.lang.NoClassDefFoundError: com/apple/eawt/ApplicationListener
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 1/2/11 20:03, Bjorn Roche wrote:
>
> On Dec 31, 2010, at 12:26 PM, Richard S. Hall wrote:
>
>> 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.
>
>
> It's my understanding that java.library.path is not used -- at least
> directly -- during normal Felix/OSGi operation, but I thought I'd see
> what its value was right before calling System.loadLibrary to get a
> hint. When I run my code outside of OSGi I get:
>
> .:/Users/bjorn/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java
>
>
> which seams reasonable. I use -Djava.library.path to set it to just
> the path I care about with my native libs so that they will load, and
> that's always worked.
>
> Inside felix/OSGi, the same line of code gives:
>
> :/usr/local/ImageMagick-6.3.9//lib:.:/Users/bjorn/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java
>
>
> which seemed whack, at least the part before the what I get out of
> OSGi. It turned out my .profile was setting that ImageMagick line,
> and, moreover, it was totally bogus:
>
> .profile:MAGICK_HOME="/usr/local/ImageMagick-6.3.9/" ; export MAGICK_HOME
> arigato:~ bjorn$ grep MAGICK_HOME .*
> .profile:MAGICK_HOME="/usr/local/ImageMagick-6.3.9/" ; export MAGICK_HOME
> .profile:#MAGICK_HOME="/usr/local/" ; export MAGICK_HOME
> .profile:PATH="$PATH:$MAGICK_HOME/bin:":~/bin: ; export PATH
> .profile:DYLD_LIBRARY_PATH="$DYLD_LIBRARY_PATH:$MAGICK_HOME/lib" ;
> export DYLD_LIBRARY_PATH
>
> arigato:~ bjorn$ ls /usr/local/ImageMagick-6.3.9/
> ls: /usr/local/ImageMagick-6.3.9/: No such file or directory
>
> Once I removed that (I think this was from a failed gallery remote
> install) and restarted my shell I got something reasonable out of
> java.library.path, even inside OSGi:
>
> .:/Users/bjorn/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java
>
>
> Once that's fixed, I get a slightly different error when I run my app:
>
> ERROR: Extracting native library. (java.io.FileNotFoundException:
> ./felix-cache/bundle3/version0.0/xowave-lib/0/native/libXOengine-FLOAT.jnilib
> (No such file or directory))
> java.io.FileNotFoundException:
> ./felix-cache/bundle3/version0.0/xowave-lib/0/native/libXOengine-FLOAT.jnilib
> (No such file or directory)
> java.io.FileNotFoundException:
> ./felix-cache/bundle3/version0.0/xowave-lib/0/native/libXOengine-FLOAT.jnilib
> (No such file or directory)
> at java.io.FileOutputStream.open(Native Method)
> at java.io.FileOutputStream.<init>(FileOutputStream.java:179)
> at java.io.FileOutputStream.<init>(FileOutputStream.java:131)
> at
> org.apache.felix.framework.util.SecureAction.getFileOutputStream(SecureAction.java:461)
> at
> org.apache.felix.framework.cache.BundleCache.copyStreamToFile(BundleCache.java:310)
> at
> org.apache.felix.framework.cache.DirectoryContent.getEntryAsNativeLibrary(DirectoryContent.java:266)
> at
> org.apache.felix.framework.ModuleImpl$ModuleClassLoader.findLibrary(ModuleImpl.java:2081)
>
> After I did a little digging I found the directory tree it claimed to
> be looking for (felix-cache/bundle3/version0.0/xowave-lib/0/native/),
> but it wasn't in the current directory; it was in my home directory.
> By deleting the caches directory and rerunning, I realized that felix
> is building two caches every time I run it, one in my home dir and one
> in the current dir. There seems to be some bug relating to this.
> Setting the temporary dir explicitly to my home dir:
>
> org.osgi.framework.storage=/Users/bjorn/felix-cache
>
> works! Also works when I set the storage dir from the command line
> rather than the conf file:
>
> -Dorg.osgi.framework.storage=/tmp/$USER/felix-cache
>
>
> Great, so I have a solution. Still, it seems there is a problem with
> locating the cache dir (is it in the home dir or current dir?). Also,
> it seems to me that even if a bogus path is added to
> DYLD_LIBRARY_PATH, that shouldn't change anything.
If no cache directory is specified, the Felix framework will create a
"felix-cache" directory in the current directory (i.e., the directory
you are in when you launch the framework). So, if you are starting the
framework from different directories, you'll see it get created in
different places. I don't think there is any way a single execution of
the framework will create multiple copies of the cache.
Regarding the java.library.path, the framework doesn't look at this at
all. This should only impact the JVM. The only thing the framework does
is create a custom class loader that overrides findLibrary() and waits
for the JVM to call it when a class loaded by the class loader needs a
native library.
Other than that, I'm not sure what to tell you. Again, if you can get me
an example bundle and a set of steps to reproduce any issues you are
seeing, I'd gladly look into it.
-> 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
Re: java.lang.NoClassDefFoundError: com/apple/eawt/ApplicationListener
Posted by Bjorn Roche <bj...@xowave.com>.
On Dec 31, 2010, at 12:26 PM, Richard S. Hall wrote:
> 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.
It's my understanding that java.library.path is not used -- at least
directly -- during normal Felix/OSGi operation, but I thought I'd see
what its value was right before calling System.loadLibrary to get a
hint. When I run my code outside of OSGi I get:
.:/Users/bjorn/Library/Java/Extensions:/Library/Java/Extensions:/
System/Library/Java/Extensions:/usr/lib/java
which seams reasonable. I use -Djava.library.path to set it to just
the path I care about with my native libs so that they will load, and
that's always worked.
Inside felix/OSGi, the same line of code gives:
:/usr/local/ImageMagick-6.3.9//lib:.:/Users/bjorn/Library/Java/
Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/
usr/lib/java
which seemed whack, at least the part before the what I get out of
OSGi. It turned out my .profile was setting that ImageMagick line,
and, moreover, it was totally bogus:
.profile:MAGICK_HOME="/usr/local/ImageMagick-6.3.9/" ; export
MAGICK_HOME
arigato:~ bjorn$ grep MAGICK_HOME .*
.profile:MAGICK_HOME="/usr/local/ImageMagick-6.3.9/" ; export
MAGICK_HOME
.profile:#MAGICK_HOME="/usr/local/" ; export MAGICK_HOME
.profile:PATH="$PATH:$MAGICK_HOME/bin:":~/bin: ; export PATH
.profile:DYLD_LIBRARY_PATH="$DYLD_LIBRARY_PATH:$MAGICK_HOME/lib" ;
export DYLD_LIBRARY_PATH
arigato:~ bjorn$ ls /usr/local/ImageMagick-6.3.9/
ls: /usr/local/ImageMagick-6.3.9/: No such file or directory
Once I removed that (I think this was from a failed gallery remote
install) and restarted my shell I got something reasonable out of
java.library.path, even inside OSGi:
.:/Users/bjorn/Library/Java/Extensions:/Library/Java/Extensions:/
System/Library/Java/Extensions:/usr/lib/java
Once that's fixed, I get a slightly different error when I run my app:
ERROR: Extracting native library. (java.io.FileNotFoundException: ./
felix-cache/bundle3/version0.0/xowave-lib/0/native/libXOengine-
FLOAT.jnilib (No such file or directory))
java.io.FileNotFoundException: ./felix-cache/bundle3/version0.0/xowave-
lib/0/native/libXOengine-FLOAT.jnilib (No such file or directory)
java.io.FileNotFoundException: ./felix-cache/bundle3/version0.0/xowave-
lib/0/native/libXOengine-FLOAT.jnilib (No such file or directory)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.<init>(FileOutputStream.java:179)
at java.io.FileOutputStream.<init>(FileOutputStream.java:131)
at
org
.apache
.felix
.framework.util.SecureAction.getFileOutputStream(SecureAction.java:461)
at
org
.apache
.felix.framework.cache.BundleCache.copyStreamToFile(BundleCache.java:
310)
at
org
.apache
.felix
.framework
.cache.DirectoryContent.getEntryAsNativeLibrary(DirectoryContent.java:
266)
at org.apache.felix.framework.ModuleImpl
$ModuleClassLoader.findLibrary(ModuleImpl.java:2081)
After I did a little digging I found the directory tree it claimed to
be looking for (felix-cache/bundle3/version0.0/xowave-lib/0/native/),
but it wasn't in the current directory; it was in my home directory.
By deleting the caches directory and rerunning, I realized that felix
is building two caches every time I run it, one in my home dir and one
in the current dir. There seems to be some bug relating to this.
Setting the temporary dir explicitly to my home dir:
org.osgi.framework.storage=/Users/bjorn/felix-cache
works! Also works when I set the storage dir from the command line
rather than the conf file:
-Dorg.osgi.framework.storage=/tmp/$USER/felix-cache
Great, so I have a solution. Still, it seems there is a problem with
locating the cache dir (is it in the home dir or current dir?). Also,
it seems to me that even if a bogus path is added to
DYLD_LIBRARY_PATH, that shouldn't change anything.
bjorn
-----------------------------
Bjorn Roche
http://www.xonami.com
Audio Collaboration
Re: java.lang.NoClassDefFoundError: com/apple/eawt/ApplicationListener
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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
Re: java.lang.NoClassDefFoundError: com/apple/eawt/ApplicationListener
Posted by Bjorn Roche <bj...@xowave.com>.
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
Re: java.lang.NoClassDefFoundError: com/apple/eawt/ApplicationListener
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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?
You could always try to com.apple.eawt to the
org.osgi.framework.bootdelegation property, but this still isn't a very
good solution.
>
> 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.
>
>
>
> 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.
-> 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
Re: java.lang.NoClassDefFoundError: com/apple/eawt/ApplicationListener
Posted by Bjorn Roche <bj...@xowave.com>.
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.)
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 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
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
Re: java.lang.NoClassDefFoundError: com/apple/eawt/ApplicationListener
Posted by Bjorn Roche <bj...@xowave.com>.
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: java.lang.NoClassDefFoundError: com/apple/eawt/ApplicationListener
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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?
-> 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
Re: java.lang.NoClassDefFoundError: com/apple/eawt/ApplicationListener
Posted by Bjorn Roche <bj...@xowave.com>.
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 );
...
}
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
Re: java.lang.NoClassDefFoundError: com/apple/eawt/ApplicationListener
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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.
-> 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
Re: java.lang.NoClassDefFoundError: com/apple/eawt/ApplicationListener
Posted by Bjorn Roche <bj...@xowave.com>.
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.
bjorn
-----------------------------
Bjorn Roche
http://www.xonami.com
Audio Collaboration
Re: java.lang.NoClassDefFoundError: com/apple/eawt/ApplicationListener
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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
Re: java.lang.NoClassDefFoundError: com/apple/eawt/ApplicationListener
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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?
-> 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
Re: java.lang.NoClassDefFoundError: com/apple/eawt/ApplicationListener
Posted by Bjorn Roche <bj...@xowave.com>.
>>>>
>>>> 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?
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
Re: java.lang.NoClassDefFoundError: com/apple/eawt/ApplicationListener
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 12/28/10 13:58, Bjorn Roche wrote:
>
> On Dec 28, 2010, at 12:24 PM, Richard S. Hall wrote:
>
>> On 12/28/10 8:58, Bjorn Roche wrote:
>>> First off, sorry if I am missing something obvious -- I've been
>>> chugging away trying to "OSGi-ify" 250,000 lines of code and it's
>>> wrecking havoc on my basic ability to think, so I probably am
>>> missing something obvious...
>>>
>>>
>>> Here's how I've been progressing:
>>>
>>> 1. First, I built a small infrastructure that lets me run my code
>>> without JAR'ing it up, since JAR'ing my code after every small
>>> change is going to be prohibitively slow. This is primarily
>>> dependent on the "assembly" and "wrap" URL protocols from the pax
>>> runner folks -- so they've done the hard work for me. I created a
>>> project to help others with this as well, and once I get this
>>> working I plan to put more instructions up:
>>>
>>> http://code.google.com/p/piecemeal/
>>
>> Did you know you can install an "exploded" bundle as a directory in
>> both Equinox and Felix just by appending "reference:" to the URL
>> pointing to the directory? This shouldn't be used in place of
>> ultimately creating a JAR file, but it can help during development.
>
> I did not. Sounds like the same concept as the assembly URL. When I
> google this, all I get is ml postings and a few Eclipse articles. Is
> there somewhere this is properly documented?
Probably not. It is sort of an undocumented non-spec feature.
> Perhaps it will work better than what I'm doing now.
>
>>> 2. Replace sym links with actual files where necessary. The pax
>>> runner code doesn't seem to like sym links.
>>>
>>> 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.
>
>>> 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
>
> thanks for your 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: java.lang.NoClassDefFoundError: com/apple/eawt/ApplicationListener
Posted by Bjorn Roche <bj...@xowave.com>.
On Dec 28, 2010, at 12:24 PM, Richard S. Hall wrote:
> On 12/28/10 8:58, Bjorn Roche wrote:
>> First off, sorry if I am missing something obvious -- I've been
>> chugging away trying to "OSGi-ify" 250,000 lines of code and it's
>> wrecking havoc on my basic ability to think, so I probably am
>> missing something obvious...
>>
>>
>> Here's how I've been progressing:
>>
>> 1. First, I built a small infrastructure that lets me run my code
>> without JAR'ing it up, since JAR'ing my code after every small
>> change is going to be prohibitively slow. This is primarily
>> dependent on the "assembly" and "wrap" URL protocols from the pax
>> runner folks -- so they've done the hard work for me. I created a
>> project to help others with this as well, and once I get this
>> working I plan to put more instructions up:
>>
>> http://code.google.com/p/piecemeal/
>
> Did you know you can install an "exploded" bundle as a directory in
> both Equinox and Felix just by appending "reference:" to the URL
> pointing to the directory? This shouldn't be used in place of
> ultimately creating a JAR file, but it can help during development.
I did not. Sounds like the same concept as the assembly URL. When I
google this, all I get is ml postings and a few Eclipse articles. Is
there somewhere this is properly documented? Perhaps it will work
better than what I'm doing now.
>> 2. Replace sym links with actual files where necessary. The pax
>> runner code doesn't seem to like sym links.
>>
>> 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?
>> 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.
thanks for your 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
Re: java.lang.NoClassDefFoundError: com/apple/eawt/ApplicationListener
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 12/28/10 8:58, Bjorn Roche wrote:
> First off, sorry if I am missing something obvious -- I've been
> chugging away trying to "OSGi-ify" 250,000 lines of code and it's
> wrecking havoc on my basic ability to think, so I probably am missing
> something obvious...
>
>
> Here's how I've been progressing:
>
> 1. First, I built a small infrastructure that lets me run my code
> without JAR'ing it up, since JAR'ing my code after every small change
> is going to be prohibitively slow. This is primarily dependent on the
> "assembly" and "wrap" URL protocols from the pax runner folks -- so
> they've done the hard work for me. I created a project to help others
> with this as well, and once I get this working I plan to put more
> instructions up:
>
> http://code.google.com/p/piecemeal/
Did you know you can install an "exploded" bundle as a directory in both
Equinox and Felix just by appending "reference:" to the URL pointing to
the directory? This shouldn't be used in place of ultimately creating a
JAR file, but it can help during development.
>
> 2. Replace sym links with actual files where necessary. The pax runner
> code doesn't seem to like sym links.
>
> 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.
>
> 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...
-> richard
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:676)
> at
> org.apache.felix.framework.ModuleImpl$ModuleClassLoader.findClass(ModuleImpl.java:1907)
> at
> org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:727)
> at
> org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71)
> at
> org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1768)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
> at
> org.apache.felix.framework.ModuleImpl.getClassByDelegation(ModuleImpl.java:645)
> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1599)
> at
> org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:904)
> at com.xowave.sjwidget.ResourceUtil.getClass(ResourceUtil.java:132)
> .....
>
> I have seen that kind of error in reference to knopflerfish, which
> apparently has (had?) a bug causing apple's ApplicationListener class
> not to load, but I am not seeing any answers relating to Felix. I've
> been through my build and, on the mac, I don't seem to be doing
> anything special to load add that class to the classpath when I'm not
> using OSGi -- do I need to do something special to add it when I am
> using OSGi?
>
> Any other suggestions?
>
> TIA,
>
> 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