felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: java.lang.NoClassDefFoundError: com/apple/eawt/ApplicationListener
Date Tue, 28 Dec 2010 21:54:04 GMT
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

View raw message