Hi Kirby,
You obviously have a great grasp of the issues. It would be a big +1
from me if you wanted to help geotools become more OSGi friendly.
Jody, would it make sense to perhaps provide some module space for Kirby
( if he is interested of course ) to create geotools osgi bundles?
-Justin
Kirby Bohling wrote:
> All,
>
> Sorry to be slow on responding.
>
> Technically speaking, BuddyLoaders don't all have the same class loader,
> it's just that you delegate to your buddy class loaders (in very weird
> corner cases the difference is important as I learned the hard way). If
> you really need them to be in the same class loader you use fragments.
>
> I have one plug-in that includes the "core" GeoTools plug-ins:
> geoapi-2.0.jar
> jsr108-0.01.jar
> gt2-api-2.2.1.jar
> gt2-main-2.2.1.jar
> gt2-referencing-2.2.1.jar
>
> That plug-in depends upon two other plug-ins that include vecmath and JAI.
>
> Inside of the core plugin's MANIFEST.MF include a line like this:
> Eclipse-BuddyPolicy: registered
>
> Then inside of an extension of that plug-in use:
> Eclipse-RegisterBuddy: ${CORE_PLUGIN_ID}
>
> At that point, everything has just worked for me. I have managed to put
> all of the dependencies of GeoTools into an RCP plug-ins (including JAI)
> and can run off a freshly installed JRE. BuddyLoading breaks certain
> assumptions in the ClassLoader, which can lead to deadlock. I've never
> had it happen with GeoTools, but have in other code bases. Using
> Fragments would solve that problem.
>
> The other alternative is to have a core plug-in and fragments. The
> Fragments would cause them to all be in the same class loader.
>
> Is there any interest in writing "OSGi" compliant or friendly bundles?
> You wouldn't have to change the factory at interfaces at all. I've
> written Factory classes that move between Eclipse plug-ins and straight
> JRE classloaders without issue. While, OSGi while might be EVIL if your
> methodology doesn't account for them, are a godsend in large scale
> applications with numerous dependencies that have conflicting versions.
> Just dumping everything onto a single classpath can be far more
> problematic when integrating numerous disparate libraries.
>
> I don't think that it'd be a huge deal to write a translator that
> tranformed configuration from one format into the other, so you only
> have to maintain one copy of the config and run a tool at build time.
> I've made GeoTools work in Eclipse RCP bundles (using extension points,
> I haven't done it on raw OSGi Bundles w/ Services) with everything being
> packaged in a way that you can pull just the pieces you need.
>
> I have made a factory pattern that works inside and out of an Eclipse
> RCP classloader environment. I just have an extension point that is the
> interface name, and then register all implementations with the concrete
> class name as the key. When doing constructing one, pull the extensions
> one of the attributes will be the plug-in name. The plug-in name is a
> key you can use to pull the classloader that will allow you to do Class
> clazz = ClassLoader.resolveClass(...); I don't believe it matters if
> you export that class at that point, because you are using the
> classloader that knows about it.
>
> Proceed with normal reflection at this point. If there is interest, I'd
> be absolutely thrilled to help get GeoTools to be Eclipse Plug-in
> friendly or OSGi bundle complaint. It'd save me a great deal of
> parallel effort.
>
> Kirby
>
>
>
>
>
>> From: Jody Garnett <[EMAIL PROTECTED]>
>> To: Justin Deoliveira <[EMAIL PROTECTED]>
>> CC: Martin Desruisseaux <[EMAIL PROTECTED]>,Gary Lucas
>> <[EMAIL PROTECTED]>,[email protected]
>> Subject: Re: [Geotools-gt2-users] ClassLoader problems with GeoTools/RCP
>> Date: Fri, 16 Mar 2007 10:24:31 -0700
>>
>> Justin is correct - the GeoTools "lookup and intergration" code is
>> broken.
>>
>> Indeed I am talking with Martin right now about a couple proposed
>> fixes :-(
>>
>> For now you are stuck dumping eveything into a single plugin (or many
>> buddy plugins) so they
>> all get in the same class loader.
>>
>> At a technical level our "Factory Lookup" is done in the same manner as
>> ImageIO ... it goes into
>> each jar looking for a directory "META-INF/services/" where have a file
>> named after the interface
>> being discovered. The file lists all the instances that the jar provides.
>>
>> The OSGi classloader is EVIL and locks down the packages that can be
>> loaded by dependent
>> plugins (they chain class loaders so a dependent plugin is loaded using
>> a child classloader). However
>> you have to list manually the packages that are visible - and they don't
>> let you list "META-INF/services/"
>> (as it is not a valid package name). So the that file is not available
>> as a resource :-(
>>
>> The proposed solution is to register a FactoryIterator with GeoTools;
>> and then implement one
>> that plugin extension point (so yes we will need to duplicate all the
>> information contained in META-INF/services).
>>
>> Cheers,
>> Jody
>>
>> Justin Deoliveira wrote:
>> > Hi Gary,
>> >
>> > Yes the breakdown geotools modules wont map cleanly to eclipse rcp
>> > plugins due to class loading issues. I believe there is some magic you
>> > can pull off with "buddy classloading" but I have never tried it out.
>> > The udig guys can comment on that.
>> >
>> > The udig approach is to have a single "libs" plugin which essentially
>> > contains the entire geotools library in one plugin. What is your
>> plugin
>> > structure?
>> >
>> > -Justin
>> >
>> > Gary Lucas wrote:
>> >
>> >> I am attempting to use GeoTools to create and eclipse plug-in that
>> draws
>> >> maps. I've had some luck writing conventional Java applications and
>> >> decided to move forward a Rich Client Platform (RCP) implementation to
>> >> take advantage of the better GUI support. Anyway, I've hit a
>> roadblock.
>> >>
>> >> At the point in the program execution when I try to create my first
>> map,
>> >> the program fails when calling a constructor for a class. The class
>> >> loads a shape file and creates a map context. A key point here is
>> that
>> >> the constructor itself is empty (it's just a stub for now) and the
>> >> method that creates the map context is NEVER called. Even so, if the
>> >> statement
>> >>
>> >> MapContext mapContext = DefaultMapContext();
>> >>
>> >> is called, the program fails. If the line is commented out, it
>> continues
>> >> on... though of course there's little point in doing so since it will
>> >> never be able to render a map. A similar thing happens if I use
>> >> DefaultMapLayer. Interestingly enough, the program is able to include
>> >> code open a shape file and create a ShapeFileDatastore.
>> >>
>> >> Clearly the problem has to do with the ClassLoader and Eclipse's
>> notion
>> >> of installing custom class loaders. I am new to the RCP and plug-ins,
>> >> so I don't really know how to proceed from here.
>> >>
>> >> I was wondering whether anyone had a solution for this problem. I know
>> >> that the uDig folks must have worked it out, but I haven't found any
>> >> relevant discussion in the archives for this mailing list.
>> >>
>> >> As I have said so many times before on this discussion group:
>> thanks in
>> >> advance for your help.
>> >>
>> >> Gary
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> ---
>> >> Gary W. Lucas, Senior Software Engineer
>> >> Sonalysts, Inc
>> >> 215 Parkway North
>> >> Waterford, CT 06320
>> >> (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
>> >>
>> >> !DSPAM:4007,45fa8ed8230332051017194!
>> >>
>> >>
>> >>
>> ------------------------------------------------------------------------
>> >>
>> >> _______________________________________________
>> >> Geotools-gt2-users mailing list
>> >> [email protected]
>> >> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
>> >>
>> >>
>> >> !DSPAM:4007,45fa8ed8230332051017194!
>> >>
>> >
>> >
>> >
>>
>>
>> -------------------------------------------------------------------------
>> 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
>
> _________________________________________________________________
> It’s tax season, make sure to follow these few simple tips
> http://articles.moneycentral.msn.com/Taxes/PreparationTips/PreparationTips.aspx?icid=HMMartagline
>
>
>
>
> !DSPAM:4007,4600127c4061116498154!
>
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
-------------------------------------------------------------------------
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
