Gary,
I'm not really an Eclipse or OSGi expert, I just play one on mailing
lists.... I've ramped up on using them as my company bases all our
technology on them.
In my experience, I'd always thought it was GeoTools that was
thoughtfully hiding the exceptions. With Eclipse, I generally don't have
any problems with figuring out that a class didn't load. Maybe I just know
where to look. When I first started with Eclipse and OSGi, I thought they
were a serious pain in the ass. Once I finally figured out it how to work
with it became incredibly useful. OSGi IMHO is the only sane approach
towards solving large scale deployments of Java that integrate lots of
disparate components. Deserialization is the one thing I've found that's
just a huge pain that I've had to hack in. <Steps off Soap box>.
If you are writing a full GUI Eclipse application, add a Help -> About
menu. Use that to click on Configuration Detail -> View Error Log (those
should be there by default in the stock Eclipse About menu). A lot of
internal exceptions that get swallowed end up in there. That's really just
a file somewhere on the filesystem. In the .metadata/.plugins directory of
either the workspace directory you ran it out of, or out of the runtime
directory it constructed for you to run out of.
The other way is in "Run...", pick what you want to run, and click on
the Tracing tab. You can pick a lot of different things, but classloading
is all in the org.eclipse.osgi section. If you configure it correctly,
it'll show you absolutely every classloader it attempts to load every class
from. Including all of the failures.
In terms of making JAI export easier, you might consider doing something
like what is described in this e-mail:
http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg01865.html
Essentially, adding a fragment to the system.bundle that exports the JAI
classes from the JRE. I believe that's part of your problem.
I have a requirement that I my stuff has to run on a virgin JRE, so I just
bundle the JAI jar in a plug-in and export absolutely every package in it.
It's worked for me with respect to WFS and WMS when I use those. I added
the mlibwrapper_jai.jar, jai_ocde.jar and the jai_core.jar to the plug-in
classpath, and make sure those are exported. I added a directory path of
"os/win/x86" and I dumped the DLL's in there. I believe that's "the old
deprecated way" of getting platform specific libraries found, but it worked
and I didn't have time to track down the right way when I learned it wasn't
the suggested way to do this. In reality, you should make fragments for
each platform, but since I only run on Windows, this was acceptable for my
needs. Look at SWT for examples of how to package things that need native
libraries on multiple platforms if you need that sort of functionality.
I've got a Mac at home, so I'm intrigued by the thread about getting
everything to build on a Mac. If that's too much effort, I might just take
the Jar's and write a tool to "OSGi'ify" the jar files, along with a sample
factory that works within the OSGi framework. 90% of the work is reading in
the Manifest file and translating it to have a small bit of OSGi goop in it.
Setting up the services/extension points is harder, but making it work as
a plain jane Eclipse plug-in/OSGi bundle is no big deal.
I don't have time to fight the Mac and Maven issues. I don't know how to
use Maven, and the last time I tried to learn it was a huge time sink. It
was right as 2.0 was coming out, where everything said, to understand 2.0
read the source, and all the lists said this features is hard in 1.0 use
2.0... *Sigh* Too much cool technology not enough hours in the day.
Hopefully if I can get that tool bootstrapped enough, I can contribute that
to someone who can help integrate it into the GeoTools environment. I'd
really like to see GeoTools ship a set of jar files that are usable as OSGi
bundles, Eclipse Plug-ins, and as Plain-Old-Jar files. It'd make life much
easier for me, and probably the uDig folks. Plus, the GeoTools has saved me
so much development effort I really should contribute back.
Anybody who is attempting to integrate GeoTools into Eclipse, I'd be happy
to discuss off-line with if it's inappropriate on this list. I've spent a
lot of time in the bowels of Eclipse learning how to make 3rd Party
libraries work and the in's and out's of an OSGi segment classloader so I
could diagnose what was going on when things went wrong.
Thanks,
Kirby
>From: "Gary W. Lucas" <[EMAIL PROTECTED]>
>To: [email protected]
>Subject: Re: [Geotools-gt2-users] ClassLoader problems with GeoTools/RCP
>Date: Wed, 21 Mar 2007 16:40:33 -0400
>
>
>I've been out of town and am just getting back to this. My thanks again to
>the folks who have sent me suggestions on this problem.
>
>I'm afraid that I still belong to the camp that views OSGi class
>loaders as EVIL :-)
>but perhaps I'll come along in time as I learn more about this environment.
>Right now, I'm still stuck. So I will apologize in advance for
>treating this mailing list
>a bit like "Remedial Eclipse 101", but also offer the excuse that I
>think that this is an
>issue that others will encounter and so go ahead and ask my question anyway
>with the hope that I am not just asking for myself, but for the user
>community
>as a whole... now there's a rationalization if ever I've seen one :-)
>
>Following the suggestions from earlier postings, I created a big
>plug-in to hold all
>the GeoTools jar files and configured my run dialog appropriately.
>Things looked
>good for awhile, but now I realize that Eclipse can't find one of the
>JAI classes when
>I try to create a StreamingRenderer. (specifically:
>javax.media.jai.util.Range).
>
>So this naturally leads to two questions. The first is how do I
>include the JAI classes in my
>plug-in?
>
>The second is a little more troubling to me. For whatever reason,
>when Eclipse detects
>that it can't load the class, it throws a ClassNotFound exception...
>but it also handles the
>exception internally and never gives me any indication of what's
>going on. I imagine that
>there is some kind of configuration option you can set to tell it to
>report the problem,
>but I haven't found it. This seems like a silly design choice (it's
>hard to fix fatal errors
>when your development environment does its level best to hide them from
>you),
>so I'm sure there's a way to disable it.
>
>Thanks in advance for your help.
>
>Gary
>
>
>
>Gary W. Lucas
>Sonalysts, Inc.
>215 Parkway North
>Waterford CT 06320, USA
>(860) 326-3682
>
>
>
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share
>your
>opinions on IT & business topics through brief surveys-and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>Geotools-gt2-users mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
_________________________________________________________________
Exercise your brain! Try Flexicon.
http://games.msn.com/en/flexicon/default.htm?icid=flexicon_hmemailtaglinemarch07
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-gt2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
