On Tue, Feb 12, 2013 at 7:34 AM, Mauro Bartolomeoli <
mauro.bartolome...@geo-solutions.it> wrote:
>
>
>
> 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.
>
> Oops, sorry I missed that it was a test scope dependency. No worries then,
no need to change.
>
>
>> 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?
>
Hmmm... i guess i will delegate back to Ben on this since I don't know this
code. What would the impact be of simply declaring the class non thread
safe? Again I am lacking the context of usage here. If it is a problem in
this case then I guess my question is how much effort involved in making
the class thread safe with read timeouts to avoid hanging.
>
>>> 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?
>
No objection here.
>
> 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
>
> -------------------------------------------------------
>
--
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
