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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
