hey Jukka, On 16.12.2015 09:34, Rahkonen Jukka (MML) wrote: > Hi, > > I have nothing at all to complain and I think that you managed to add the > SQLite/Spatialite datastore very quickly. It just appears that in my Windows > environment the mod_spatialite extension is not found if I put all the dll > files into lib\ext which was the only place where I could make the SpatiaLite > Plugin > https://sourceforge.net/p/jump-pilot/code/HEAD/tree/plug-ins/SpatialitePlugin/ > to find them. >
jepp, big up Nico SNIP > > I have been reading that loading extensions to SQLite can be tricky and for > example SQLite may be compiled so that loading extension is strictly denied. > We should not have that problem because we deliver also the sqlite jdbc > driver that contains suitable sqlite build inside. Different Spatialite > versions make also difference. If you are really interested in managing > possible pitfalls I believe that browsing the source code and comments of the > GDAL SQLite driver might be useful > https://trac.osgeo.org/gdal/browser#trunk/gdal/ogr/ogrsf_frmts/sqlite. But > based on your WKB, WKT, and Spatialite BLOB detection you have probably been > reading it already and then you know also where to find the GeoPackage driver > https://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogrsf_frmts/gpkg. > some background i researched just now: _our_ (DBQuery's xerial) sqlite-jdbc-*.jar ships it's binaries (win,mac,linux each 32/64bit) within and seems to load them automagically. we cannot influence that. issue with the sqlite extension libs seems to be that they are loaded by sqlite itself. all _we've_ got is the sqlite jdbc that seems to have a config switch to turn on autoloading *OR* the SELECT load_extension(...); *OR* the connection parameter "jdbc:sqlite:/...?spatialite=mod_spatialite" (is that processed by sqlite or did Larry hack that?). > > What is not handled anywhere that I have seen is the conflicts between 32 vs. > 64 bit architectures. It would be very kind for the end users to send a > clear message “WARNING: You are running OpenJUMP with {0} bit JRE but the {1} > extension is compiled for {2} bit. Extension was not loaded”. I have no idea > about how to detect the architecture of .dll or .so from java, though. now you're getting "greedy" ;).. actually there is easy no way for us to detect arch a library is compiled for. we can only try to load them and see if they fit. as the files for a library are usually named identically regardless of the platform it is important that they end up in different folders which are then used to find the correct arch lib. wrt. sqlite extension libs, we are totally screwed as they do not even are java native bindings, hence we cannot load test or anything within java. finally - i'll debug the native loading and'll try to make sure that - putting native lib's into lib/native/x86 (32bit) or lib/native/x64 (64bit) and - dependency jars under lib/ext/<subfolder>/ works properly, at least with windows right now. it should already, but obviously it doesn't for Jukka. ..ede ------------------------------------------------------------------------------ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
