2013/2/12 Justin Deoliveira <jdeol...@opengeo.org>
> 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.
>
> The dependency was introduced because it was used by some tests, maybe I
can refactor these tests to use a different schema.
> 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 :)
>
So, what do you think about the synchronization issue? Do you have any
opinion / suggestion about that?
>
>> 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.
>
>>
>> Do you think we can postpone that and go on with the hack for now?
Thanks.
Mauro Bartolomeoli
--
==
Our support, Your Success! Visit 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
-------------------------------------------------------
------------------------------------------------------------------------------
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
