Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 23 Next »

Module Maintainer:

Saul Farber / Gabriel Roldán

Status:

(star) (star) (star) (error)

Email Help:

Geotools-gt2-users@lists.sourceforge.net

Volunteer:

geotools-devel@lists.sourceforge.net

Plugin:

DataStore

Plug-in provides access to an ArcSDE server.

Module Status

(tick) The arcsde module is stable for data reading, most pending issues refers to transaction support.

(tick) The arcsde module is stable for transactional data modification.

(tick) The arcsde module is currently a part of the nightly build

(error) The test suite is not being run as a part of the nightly build as there is no build profile which would connect it to a live SDE instance to perform tests.

Recent Development (as of August 2008)

For the 2.2.x branch the arcsde module has returned to the build process with a stub jar to replace ESRI dependencies.

For the 2.3.x branch, there is an initial implementation of ArcSDE Raster Support.  You can find out about it here.

For the 2.4.x branch arcsde is working on returning to supported status; we need to provide a profile for nightly builds to run. ArcSDE Raster Support is also available on 2.4.x as well. You can find out about it at the ArcSDE Raster Support page.

For the 2.5.x branch arcsde has been almost completely rewritten, it no longer extends AbstractDatatore and the code is much easier to follow. Internally it protects all SeConnection use behind a Queue (rather than a Lock) as a way of addressing concurrent usage in a fair manner.
Also, it has been extended to support the read and edition of versioned tables, limited to edit the default version.

IP Review

Please refer to:

Outstanding Issues

com.atlassian.confluence.macro.MacroExecutionException: JIRA project does not exist or you do not have permission to view it.

Development

ArcSDE has two great module maintainers looking after it Saul Farber and Gabriel Roland.

We have a couple short term goals:

  • We have run into problems when using the ArcSDEDatastore from uDig; when performing an Edit (ie writing) a desktop client is quite willing to be drawing at the same time.
  • When using a low number of connections it is quite easy to leave the DataStore without enough SeConnections to answer basic questions such as describing a FeatureType is.

Getting ArcSDE to 'supported' status

There are five 'support stars' to earn. In order to get the ArcSDE module to supported status, we need at least four, and eventually five.

status

description

(question)

Passes IP check, basically has correct headers

(question)

Releasable - has no non blocking bugs in jira

(star)

Used in anger - Used by GeoServer or uDig on large real world datasets – used by MassGIS to serve the statewide landuse dataset. Takes 15 minutes to grind through the renderer, but it works!

(question)

Optimized - has been tuned to meet hard performance requirements (example shapefile)

(star)

Supported - user docs, module maintainer watches user list, answers email etc.. – Both Gabriel Roldán and Saul Farber watch the list. Javadocs could use a review.

The current DataStore is not stable when

Design and Research Pages

Building a Working ArcSDE using the jsde jars

To connect to ArcSDE from java code, ESRI publishes a java library which is split across 2, 3 or 4 jars (depending on the version you use). These "java-to-ArcSDE connector jars" are here called the 'jsde' jars, so as to seperate them from our own ArcSDE module.

The ArcSDE module relies on the jsde jars for all its direct communication to ArcSDE, as indeed any java-based ArcSDE client application does. However, due to concerns about redistributing ESRI's jsde jars, geotools wanted to avoid having everyone who built gt2 download the jsde jars from the geotools maven site. This was accomplished by the use of a 'dummy' api, which is an exact mimic of the jsde api, only it doesn't actually do anything. It's simply classes which allow compilation of the ArcSDE module, without actually having or downloading the jsde jar files.

If you want to actually connect to ArcSDE using the ArcSDE module, you'll need to download the jsde jars and instruct maven to actually use them when building the ArcSDE module.

You have to build your module against the jsde jars if you want to use it to really access ArcSDE

Icon

There have been reports of problems if you:
1. Build the ArcSDE module against the dummy api
2. Copy the ArcSDE module into their application, leaving the dummy api behind
3. Copy the actual jsde jars into their application
4. Run the dummy-built module against the real jsde jars and try to access ArcSDE and fetch data

Mostly these problems have to do with static final constants which have different values and get inlined by the compiler. There is a jira issue to track this, so if you need to do the above, check it out

The jsde jars are actually very easily available. You can download the 9.1 jars here Just unroll the tar, zip and then tar files that you get, and extract the jsde_sdk.jar and jsde_pde.jar files.

Here's how to build the ArcSDE module with the real jsde jars:

geotools version

sde version

instructions

2.2.x

any

Modify the module pom.xml to include dependencies on com.esri:jsde_sdk:9.0,com.esri:jsde_jpe:9.0 and com.esri:jsde_concurrent:9.0. All these dependencies are commented out in the pom.xml, you just need to uncomment them and rebuild.

2.3.x

any

Modify the module pom.xml to include dependencies on com.esri:jsde_sdk:9.0,com.esri:jsde_jpe:9.0 and com.esri:jsde_concurrent:9.0. All these dependencies are commented out in the pom.xml, you just need to uncomment them and rebuild.

2.4.x (trunk)

9.0

add the parameter -DhaveSDEJars=true to your maven build command. Something like this will work just fine:

Note that the jsde version 9.0 jars are publically available at maven.geotools.fr, so your maven build will just automatically download these and build everything correctly.

2.4.x (trunk)

other than 9.0

add both the parameter -DhaveSDEJars=true and -Dsde.version=<version> to your maven build command. Something like this will work:

Note that no versions other than jsde 9.0 are available via a maven repository, so you'll need to inject:

  • com.esri:jsde_sdk:YOURVERSION
  • com.esri:jsde_jpe_sdk:YOURVERSION
  • com.esri:jsde_concurrent:YOURVERSION
  • (for version 9.2) com.esri:jsde_icu4j:YOURVERSION
    into your local maven repository yourself. Something like this should do the trick (once you've downloaded/tracked down the jars you wish to inject):
  • No labels