Jody,
Were you referring to posting on the GeoTools wiki at http://docs.codehaus.org/display/GEOTDOC/Home ? At 01:54 PM 4/12/2007, Jody Garnett wrote: > [snip] ... do you mind posting [your email] to the GeoTools site as a news item? I can see where there might be a place for an article on "how to bundle GeoTools in an Eclipse plug-in", but I'm not sure I'm really qualified to do so. At this time I am still learning to use Eclipse plug-ins/bundles and I would be a bit afraid that I might put out the wrong information. On the other hand, once something gets out on a wiki, it is easy for somebody else to add corrections (usually, the tough part is getting the article out there in the first place). So, if that's what you're looking for, I will volunteer to do so. And, if anyone on this mailing list has recommendations on content, please let me know. Gary At 01:54 PM 4/12/2007, Jody Garnett wrote: >A message from the Isle of death then ... >>Other the other hand, Eclipse plug-ins present their own problem. >>This happens because the Eclipse framework depends on its own, >>custom classloaders (actually, the OSGi classloader). Unless you >>make special provision when building an eclipse plug-in project >>(which are essentially the same things as OSGi bundles), the >>classloader can't find the resources defined in the JAI extensions jar files. >Darn I was sure this was one of the first things to try ... your >email messages is *spot on* ... do you mind posting it to the >GeoTools site as a news item? >>In my earlier posts I mentioned two kinds of exceptions. First, >>there were "NoClassDefFoundError" exceptions. These were thrown in >>the case where the classloader could not find the JAI classes it needed. >Okay that makes sense - unless you tell OSGi "please look in the >java extensions for more classes" it won't see the jars defined >there. By default OSGi gives you Java and just Java (not CLASSPATH, >no extensions, no nothing). >>I attempted to solve this problem by including the JAI jar files in >>my plug-in... (Yes, it felt wrong at the time, but it was all I >>could think of) . This approach got rid of the not-found exception, >>but led to another, the "ClassCastException". >This would also make sense - the *exact* same class from different >class loaders will produce a ClassCastException. These problems are >kind of like nested russian dolls. > >We want to see: > >Platform (the glue code) >| JAI INTERFACE >| NATIVE IMPLEMENTATION >|| GEOTOOLS IMPLEMENTATION >|| YOUR CODE > >(as long as the implementation and interface are using the *same* >interface - their classloader is a "child" of the classloader that >has the interface we are good) > >This is what you tried first: >| JAI INTERFACES >| NATIVE IMPLEMENTATIONS >|| JAI INTERFACES >|| GEOTOOLS IMPLEMENTATION >||| YOUR CODE > >>It turns out that the solution that was suggested to me was to >>include the following line >> >>Eclipse-BuddyPolicy: ext >> >>In the manifest.mf file associated with the plug-in I built to hold >>the GeoTools jars. This seems to have solved the problem. I know >>that there is more to it than I've described here, but I have not >>yet sorted out all the details. Perhaps somebody else can add the >>missing information. >Bah - I really wish we had gotten you to try that earlier. I am very >glad you are up and running now. >>Over the last couple of weeks, I've done a lot of looking into the >>OSGi classloaders trying to understand this issue. And I have >>concluded that the whole situation related to understanding how to >>use OSGi/Eclipse bundles was best described by a line in a certain >>well-known pirate movie: "it is an isle of the dead which cannot be >>reached, except by those who already know where it is." >Classloaders are always Evil; it is almost like they do not trust us >or something. > >Java has a different idea for how to seperate things "comming real >soon now", basically makes little mini virtiual machines. They are >hoping to use that to segreagate their modules in the future; for >now the rest of the world uses OSGi -and is very thankful that OSGi >takes most of the pain of class loaders away from us. > >The Java Extensions thing that JAI uses can be viewed as Sun's first >attempt to solve the problem. >OSGi can be viewed as the popular way to solve the problem. >And sun is working on a JVN level change to sandbox modules. > >Needless to say none of these solutions place nice with others. >Jody >> Web articles on the subject assume a certain amount of >> background knowledge on the readers part, but completely ignores >> the fact that if the reader had that background knowledge he >> wouldn't need to be reading the web article. And, while I know >> that I haven't done a lot better than that myself in writing this >> posting, I do hope it helps a little. >> >> >>Again, my thanks for the help I've received on this mailing list. >> >>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 >> > 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
