On Tue, Apr 19, 2011 at 10:06 AM, Luca Morandini <luca.morandi...@gmail.com> wrote: > 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.
The interface would not be the GeoServer one, you roll your own in your own module, GeoServer just impleemnts or uses it. You get no dependency towards GS, it's the other way around. > 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. Works for me. Mind, GS will have to tell you where the data dir is, so it's going to need some code in the GeoServer side too. > As a final remark: shall I cache the WKT library ? Sounds like a good idea, maybe using SoftValueHashMap so that it scales up to thousands of libraries (if we ever get there) > 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 ? Nope. Again, in GeoServer we have code calling onto the caches when the admin uses the "reload" button or equivalent restlet. You can build a GeoServer plugin that builds on top of your module and registers the appropriate listeners to do the cleanups. But if you push for this module to become supported I'd just make GS core dependent on it :-) Cheers Andrea -- ------------------------------------------------------- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 mob: +39 333 8128928 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ------------------------------------------------------- ------------------------------------------------------------------------------ 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
