On 04/19/2011 08:36 AM, Andrea Aime wrote: > On Tue, Apr 19, 2011 at 8:02 AM, Luca Morandini >> >> I did not get it: how would the software know which is the parent dir in >> different >> environment (GS or uDIG, for instance) ? > > I guess you're thinking configurable, I'm thinking programmable. ... > I don't pretend to have the above compile, just to give you an idea.
I got the idea, but I don't like the prospect of putting a dependency on mark-wkt in GeoServer or uDIG or whatever. I mean, it would be easy in GS to inject the "wktRoot" in WKT using Spring, but that would force the user to modify GS whenever a new release is installed, while I am aiming for something real pluggable: just put the JAR in your lib and you're done. >> I am investigating Jody's suggestion of implementing the same mechanism used >> to >> use external images (via ExternalGraphic and xlink): I presume that may be >> the >> optimal solution (bar the xlink part). > > That works too. As said, it's a configuration based approach, it sets up front > the range of possibilities, you have classpath and one folder, no other > loading > mechanisms can be injected. Ah.. hmm... I understand your point of view, but since it has been used for external graphic, it makes sense to use it for WKT shapes too. As a user, I would love to use something I am already familiar with. As a final remark: shall I cache the WKT library ? That would be easy to do and I expect these libraries to be rather light on the memory... but how to invalidate the cache when the library itself changes ? Is there a file listener in GT ? Regards, Luca Morandini http://www.lucamorandini.it ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
