On 04/18/2011 10:03 AM, Andrea Aime wrote:
> /**
> * Return a Resource handle for the specified resource.
> * The handle should always be a reusable resource descriptor,
> * allowing for multiple {@link Resource#getInputStream()} calls.
> *<p><ul>
> *<li>Must support fully qualified URLs, e.g. "file:C:/test.dat".
An URL object would fit the bill for this option.
> *<li>Must support classpath pseudo-URLs, e.g. "classpath:test.dat".
Hmm... I haven't tried this, but URLStreamHandler should do it, though I think
styles do not belong to the lib or classes directories.
> *<li>Should support relative file paths, e.g. "WEB-INF/test.dat".
I presume this would be the most popular option to specify WKT libraries, but
how
to do it in such a way that could be used with or without Spring and GeoServer ?
AFAIK, Java lets you either load resources using an absolute path or one that
is
relative to the current classloader and you cannot use environment variables.
Come to think of it: why don't detect (and expand) the environment variables in
the URL before loading the properties file ?
This way an absolute path URL may be rendered relative, like:
wktlib://file://${GEOSERVER_DATA_DIR}/styles/mywkt.properties
What do you think ?
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
