app-schema drops CRS from geometries, no srsName encoded
Key: GEOT-2639
URL: http://jira.codehaus.org/browse/GEOT-2639
Project: GeoTools
Issue Type: Bug
Components: data app-
The ID is not really set until you commit. This is for compatibility
with external services (such as a database or Web Feature Server that
cannot assign an ID until you send the content to them with a commit).
There are facilities to track the change in ID with feature even
notification if you like
My deployments are Websphere deployments and I use the connection pooling of
Websphere, otherwise I would be an enemy of myself in case of
troubleshooting with the IBM Websphere support.
I am really neutral on this and I do not use DBCP.
Andrea Aime writes:
> Justin Deoliveira ha scritto
Justin Deoliveira ha scritto:
> I would be fine with straight switching. It seems we don't lose any
> functionality and if anything we gain some performance. Any down side?
>
> I guess it might be nice to give the user the choice, allowing them to
> swap but not sure how much it gains us. And th
I would be fine with straight switching. It seems we don't lose any
functionality and if anything we gain some performance. Any down side?
I guess it might be nice to give the user the choice, allowing them to
swap but not sure how much it gains us. And they can fall back on JNDI
in such cases.
Justin Deoliveira ha scritto:
> I thought we discussed this before and agreed that we should go through
> a proper deprecation cycle before moving them, leaving them in plugin.
> Although I might just be confused.
>
> That said we could move them to un-supported but keep them active by
> defaul
I thought we discussed this before and agreed that we should go through
a proper deprecation cycle before moving them, leaving them in plugin.
Although I might just be confused.
That said we could move them to supported but keep them active by
default in the unsupported/pom.xml so they show up
Hi all,
I have a problem retrieving the ID of the added feature.
Having a FeatureStore from a shapefile I do the next:
Transaction transaction = store.getTransaction();
Set fidSet =
store.addFeatures(DataUtilities.collection(featuresArray));
transaction.commit();
The problem is that after add
Andrea Aime ha scritto:
> Hi,
> I've been experimenting a little with connection pools performance
> and it seems the C3P0 connection pool
> (http://sourceforge.net/projects/c3p0/)
> is designed for slightly better scalability than the DBCP one we're
> using today.
>
> In particular in a WMS requ
Let ImageMosaic module depends on imageio-ext-gdal module as for 2.5.x
--
Key: GEOT-2638
URL: http://jira.codehaus.org/browse/GEOT-2638
Project: GeoTools
Issue Type: Task
I was already wondering about having the "old" db2 datastore in the plugins
directory. Move it.
Andrea Aime writes:
> Hi,
> any reason for still having the old postgis and db2 datastore in
> "plugins" instead of "unsupported"?
> We should also deprecate the datastore classes and invite people
Mark connections as read only when possible
---
Key: GEOT-2637
URL: http://jira.codehaus.org/browse/GEOT-2637
Project: GeoTools
Issue Type: Improvement
Components: data jdbc-ng
Affects Ve
Hi,
any reason for still having the old postgis and db2 datastore in
"plugins" instead of "unsupported"?
We should also deprecate the datastore classes and invite people
to move over to NG.
http://svn.osgeo.org/geotools/trunk/modules/plugin/
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo
Andrea Aime wrote:
> Ben Caradoc-Davies ha scritto:
>> This is a documentation issue. Decent examples, such as Andrea's JNDI
>> tutorial, make things much easier. I spent more time getting JNDI to
>> work with embedded Jetty.
>
> Hmmm... I guess when we think about "user" we think different thin
14 matches
Mail list logo
