Patrick, I think SchemaResolver does exactly what you want. You can ship schemas bundled in jars, and the resolver will download missing schemas from the net and store them in a persistent local file cache. The implementation is designed to correctly resolve even the nastiest cross-source relative imports (e.g. an import that starts with ../../.. in a schema stored in a cached file that must be resolved to a jar; SchemaResolver remembers the schema canonical location to achieve this). It even has support for schemas URLs with query components (e.g. WFS DescribeFeatureType links in GetFeature responses), stored by hash, thanks to Adam Brown's work on gt-wfs-ng.
SchemaResolver was originally implemented for gt-app-schema and GeoServer app-schema so this information on its behaviour may be useful: http://docs.geoserver.org/latest/en/user/data/app-schema/app-schema-resolution.html The GeoServer documentation is much more detailed than the GeoTools documentation: http://docs.geotools.org/latest/userguide/extension/app-schema.html#application-schema-resolver You will need to instantiate a SchemaCache, instantiate a SchemaResolver that uses it, and write an EntityResolver wrapper to use the SchemaResolver. Use Parser.setEntityResolver to enable it. There are similar methids to configure error handling. Have a look at this EntityResolver used in AppSchemaValidator: https://github.com/geotools/geotools/blob/master/modules/extension/app-schema/app-schema-resolver/src/main/java/org/geotools/xml/AppSchemaValidator.java#L339 I have not tried using SchemaCache/SchemaResolver outside app-schema, but I know that it has been used in gt-wfs-ng for complex feature parsing support with a different type of parser so I am confident that you have a decent chance of success using it with Parser. There are also some SchemaResolver-compatible schema bundles packaged with Maven that you can use for schemas you want to ship in jars: http://download.osgeo.org/webdav/geotools/org/geotools/schemas/ See for example this GeoTools pom: https://github.com/geotools/geotools/blob/master/modules/extension/app-schema/app-schema-resolver/pom.xml For example, if you want to ship GML 3.2.1 jars, include a dependency like: <dependency> <groupId>org.geotools.schemas</groupId> <artifactId>gml-3.2</artifactId> <version>3.2.1-1</version> </dependency> The schema artifacts are packaged using GeoTools poms but the schemas are not managed by this project. The jars are just a forward cache. The poms use maven-antrun-plugin to download schemas and build schema jars. They are not run as part of the GeoTools build, and jars are deployed manually: https://github.com/geotools/geotools/tree/master/modules/extension/app-schema/app-schema-packages Many of the schemas have not been updated since August 2010, so may not reflect minor OGC schema tweaking. Please let me know if this causes problems as we can update them if necessary. OGC promise that their tweaking is backwards compatible so instance documents should remain valid. The old schemas we have are known to work with GeoTools and GeoServer. OGC XLink changes have not been applied to the code. Kind regards, Ben. On 22/01/16 05:06, Patrick Valsecchi wrote: > Hi > > After investigating some transient slowness in Mapfish Print (a webapp that > uses GeoTools V11.0) I've found out that for each and every GML it is > parsing, it is downloading the XSDs from external web sites. For example > [1]. > > That causes us several problems: > > 1. Very very slow if the web site serving the XSD is totally swamped. > The other day, fetching this resource was taking an average of 50s. > 2. Slow because fetching stuff the other side of the world is never as > fast as locally. Today's RTT with [1] is 124ms. > 3. Doesn't work if the machine running GeoTools doesn't have web access. > > I've checked the code of GeoTools and looks like there is a class for > caching XSDs and even using a resource files instead: SchemaResolver [2]. > But this guy is not used when parsing GML. > > I've checked the master branch of GeoTools and this problem seems to be > still there. I've checked GeoServer and looks like they have not a very > different usage of the Parser class. > > Our code can be found on github in [3]. > > So, how do I fix all that? I need to be able to have some XSDs stored in > the project resources and I need to have some caching of the other schemas. > > Thanks for your help. > > [1] http://schemas.opengis.net/wfs/1.1.0/wfs.xsd > > [2] > http://docs.geotools.org/latest/javadocs/org/geotools/xml/resolver/SchemaResolver.html#getSimpleHttpResourcePath-java.net.URI- > > [3] > https://github.com/mapfish/mapfish-print/blob/master/core/src/main/java/org/mapfish/print/map/geotools/GmlLayer.java#L186 > > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > > > > _______________________________________________ > GeoTools-Devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > -- Ben Caradoc-Davies <[email protected]> Director Transient Software Limited <http://transient.nz/> New Zealand ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ GeoTools-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
