Looking good Mauro.
One last question though about dependencies. I notice that gt-xml still
depends on the geosciml schemas. Is this necessary? IDeally this dependency
could remain in app-schema specific modules where it is needed.
More comments below.
On Mon, Feb 11, 2013 at 8:13 PM, Ben Caradoc-Davies <
ben.caradoc-dav...@csiro.au> wrote:
> Mauro,
>
> I think your changes are just what we need. Please also update your branch
> to remove the duplication in gt-app-schema-resolver, so that it contains
> only those things that depend on gt-xsd-core and so cannot be folded into
> gt-xml.
>
> One other issue is synchronisation: gt-app-schema-resolver has until now
> only been used in circumstances (GeoServer startup) in which concurrent
> access is not an issue. What happens if two concurrent threads try to use
> the resolver? One thread might read a copy on disk while another is still
> downloading it. Simple synchronisation might result in nasty starvation if
> a download hangs. Core code must consider these issues and either address
> them or state that the code is not thread safe.
>
> Please also ensure that the relevant attributions are copied to gt-xml:
> modules/extension/app-schema/**app-schema-resolver/src/site/**
> apt/review.apt
>
> I also note a new copy of XMLSchema.xsd which will require attribution.
>
> As Justin is the maintainer of gt-xml, all changes there will require his
> approval.
>
Ha... i am not sure i have actually written any code in that module but
sure :)
>
> There is also an ugly, ugly hack in AppSchemaResolver: if a cache
> directory is not set, it can be configured to automatically find one if it
> recognises a *GeoServer* data directory. Ugly, but very useful, and I have
> not thought of a better way of doing it (a data store parameter, perhaps?).
> The standard for core is higher than extension; Justin may want this either
> fixed or factored out into a subclass in gt-app-schema-resolver so that he
> does not have to maintain any (more) ugly hacks. :-)
>
> Not sure. In the past I have had this same problem with some of the
embedded datastores like H2 and SpatiaLite because when running in the
GeoServer context we want them to store files in the GeoServer data
directory. To achieve this I just wrote what is essentially a spring bean
post processor to set the "base directory" after during startup. For
datastores this was made an extension point, DataStoreInitializer. Not sure
if that is useful.
Justin?
>
> Kind regards,
> Ben.
>
>
> On 11/02/13 21:31, Mauro Bartolomeoli wrote:
>
>> Hi guys,
>> I created a new branch (
>> https://github.com/mbarto/**geotools/tree/geot_4386_no_**
>> app_schema_resolver<https://github.com/mbarto/geotools/tree/geot_4386_no_app_schema_resolver>
>> ) that removes app-schema-resolver dependencies, basically porting 3
>> classes (AppSchemaResolver, AppSchemaCache and AppSchemaCatalog)
>> directly into the gt-xml module.
>> The next step would be to let app-schema-resolver depend on these to
>> remove the duplication.
>> Let me know if we can proceed this way.
>>
>> Thanks.
>> Mauro Bartolomeoli
>>
>>
>> 2013/2/7 Mauro Bartolomeoli
>> <mauro.bartolomeoli@geo-**solutions.it<mauro.bartolome...@geo-solutions.it>
>> <mailto:mauro.bartolomeoli@**geo-solutions.it<mauro.bartolome...@geo-solutions.it>
>> >>
>>
>>
>>
>>
>> 2013/2/7 Justin Deoliveira <jdeol...@opengeo.org
>> <mailto:jdeol...@opengeo.org>>
>>
>>
>> @Mauro: I am not sure it makes sense to have a library module
>> depend on an extension module. Maybe we can shuffle a few things
>> around to make this cleaner.
>>
>> @Ben: What about moving the classes from app-schema-resolver
>> that don't depend on xsd-core, like the core entity resolver
>> classes, to library/xml?
>>
>>
>> I agree with both sentences.
>>
>> I think the app-schema-resolver stuff could be easily become a
>> generic schema-resolver, useful for xml schema resolving and caching
>> in general.
>>
>> Thanks.
>> Mauro Bartolomeoli
>>
>>
>>
>>
>> --
>> ==
>> Our support, Your Success! Visit
>> http://opensdi.geo-solutions.**it<http://opensdi.geo-solutions.it>for
>> more information.
>> ==
>>
>> Dott. Mauro Bartolomeoli
>> @mauro_bart
>> Senior Software Engineer
>>
>> GeoSolutions S.A.S.
>> Via Poggio alle Viti 1187
>> 55054 Massarosa (LU)
>> Italy
>> phone: +39 0584 962313
>> fax: +39 0584 1660272
>>
>> http://www.geo-solutions.it
>> http://twitter.com/**geosolutions_it <http://twitter.com/geosolutions_it>
>>
>> ------------------------------**-------------------------
>>
>
> --
> Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au>
> Software Engineer
> CSIRO Earth Science and Resource Engineering
> Australian Resources Research Centre
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
