Hi,
Here's how it would look like:
GT:
https://github.com/sampov2/geotools/commit/5b838eea027014c0149bea9015b5323118d389db
GS:
https://github.com/sampov2/geoserver/commit/a3013d12d9f72a3f95f4db2f7bf5f78a0a94b1b9
Sampo
On Mon, May 5, 2014 at 9:43 AM, Sampo Savolainen <
sampo.savolai...@spatin
On Wed, Apr 30, 2014 at 10:57 AM, Andrea Aime
wrote:
> On Wed, Apr 30, 2014 at 8:44 AM, Sampo Savolainen <
> sampo.savolai...@spatineo.com> wrote:
>
>> Hi Andrea,
>>
>> Do you have any further thoughts on this or should I come up with another
>> strategy for passing the configuration objects?
>>
>
On Wed, Apr 30, 2014 at 8:44 AM, Sampo Savolainen <
sampo.savolai...@spatineo.com> wrote:
> Hi Andrea,
>
> Do you have any further thoughts on this or should I come up with another
> strategy for passing the configuration objects?
>
Thanks for the diff. I believe it's ok... I have some generic co
Hi Andrea,
Do you have any further thoughts on this or should I come up with another
strategy for passing the configuration objects?
Sampo
On Mon, Apr 28, 2014 at 9:03 AM, Sampo Savolainen <
sampo.savolai...@spatineo.com> wrote:
>
>
>
> On Fri, Apr 25, 2014 at 5:34 PM, Andrea Aime > wrote:
On Fri, Apr 25, 2014 at 5:34 PM, Andrea Aime
wrote:
> On Fri, Apr 25, 2014 at 4:16 PM, Sampo Savolainen <
> sampo.savolai...@spatineo.com> wrote:
>
>> We don't wrap stores at the ResourcePool level, if we do, it's
>>> happening higher level in the security
>>> wrappers. ResourcePool gets the stor
On Fri, Apr 25, 2014 at 4:16 PM, Sampo Savolainen <
sampo.savolai...@spatineo.com> wrote:
> We don't wrap stores at the ResourcePool level, if we do, it's happening
>> higher level in the security
>> wrappers. ResourcePool gets the stores from the factories directly, there
>> are no intermediaries
On Fri, Apr 25, 2014 at 4:21 PM, Andrea Aime
wrote:
> On Fri, Apr 25, 2014 at 2:47 PM, Sampo Savolainen <
> sampo.savolai...@spatineo.com> wrote:
>
>> Generalizing this is definitely one way to go. I'm a bit wary of starting
>>> doing that, especially since from the looks of it, the SQL view
>>> i
On Fri, Apr 25, 2014 at 2:47 PM, Sampo Savolainen <
sampo.savolai...@spatineo.com> wrote:
> Generalizing this is definitely one way to go. I'm a bit wary of starting
>> doing that, especially since from the looks of it, the SQL view
>> implementation looks a bit iffy. See the third line you quoted
On Fri, Apr 25, 2014 at 3:18 PM, Andrea Aime
wrote:
> On Fri, Apr 25, 2014 at 11:33 AM, Sampo Savolainen <
> sampo.savolai...@spatineo.com> wrote:
>
>> Hi,
>>
>> The XStreamPersister Andrea designed is working great for me after I made
>> the small change I mentioned a few hours ago. But this stil
On Fri, Apr 25, 2014 at 11:33 AM, Sampo Savolainen <
sampo.savolai...@spatineo.com> wrote:
> Hi,
>
> The XStreamPersister Andrea designed is working great for me after I made
> the small change I mentioned a few hours ago. But this still leaves part of
> the problem of feeding featuretype.xml conf
One additional strategy comes to mind. The metadata could be put in the
Query hints. A reference to the complete metadata map could be injected as
a single entry in the query hints. This would require little or no
refactoring. All that is required is a common entry point for queries where
this hint
Hi,
The XStreamPersister Andrea designed is working great for me after I made
the small change I mentioned a few hours ago. But this still leaves part of
the problem of feeding featuretype.xml configuration to DataStores /
FeatureSources.
The parsed metadata is part of the GS catalog FeatureTypeI
12 matches
Mail list logo
