I'm quite new with GeoServer and I'm testing it with ArcSDE 9.2 running a versioned enterprise geodatabase on MS SQL Server 2000. For the time being, I'm primarily interested in testing GeoServer for read-only use of our data (ie., no versioned editing with GeoServer).
I've run into a couple of issues with the two most recent releases of GeoServer, which I'll sum here:
GeoServer 1.6.3: My initial test last week with 1.6.3 had some encouraging results, with a nice stable connection to an ArcSDE DataStore in which I was able to create several FeatureTypes that performed nicely. The DataStore connection used an ArcSDE account that we use for read-only access to most of our layers. The issue that I found was that after the DataStore was created, every time GeoServer was started, it would create a state in our ArcSDE database. This state would create a state lock in ArcSDE that would prevent any other users from reconciling or posting edits. Closing GeoServer would leave this unclosed state, persisting the issue of nobody being able to reconcile or post edits.
GeoServer 1.6.4: I've been unable to create a stable ArcSDE DataStore. When attempting to create a FeatureType, I receive the following error:
GeoServer - Exception
The following exception was thrown:
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
After receiving this error, the layers from the DataStore are no longer available until I shut down & restart GeoServer.
I have not seen any evidence (yet) of an ArcSDE state being created by 1.6.4, but that's probably because I haven't been able to set up any FeatureTypes.
My testing on 1.6.4 has been on our non-production instance of ArcSDE. I have not yet been able to determine whether any differences in user permissions between our production & non-production instances may be contributing to this difference in results.
Any suggestions are greatly appreciated!
Thanks,
Mike Olkin
GIS Administrator, Town of Amherst
4 Boltwood Avenue, Amherst, MA 01002
PH | 413-259-3247 FX | 413-256-4006
http://gis.amherstma.gov
See Amherst in 3D: http://gis.amherstma.gov/3D
I can confirm the state locks with 1.6.3, we've run into those as well.
Best regards,
Bart
Olkin, Michael wrote:
I'm quite new with GeoServer and I'm testing it with ArcSDE 9.2 running a versioned enterprise geodatabase on MS SQL Server 2000. For the time being, I'm primarily interested in testing GeoServer for read-only use of our data (ie., no versioned editing with GeoServer).
I've run into a couple of issues with the two most recent releases of GeoServer, which I'll sum here:
GeoServer 1.6.3: My initial test last week with 1.6.3 had some encouraging results, with a nice stable connection to an ArcSDE DataStore in which I was able to create several FeatureTypes that performed nicely. The DataStore connection used an ArcSDE account that we use for read-only access to most of our layers. The issue that I found was that after the DataStore was created, every time GeoServer was started, it would create a state in our ArcSDE database. This state would create a state lock in ArcSDE that would prevent any other users from reconciling or posting edits. Closing GeoServer would leave this unclosed state, persisting the issue of nobody being able to reconcile or post edits.
GeoServer 1.6.4: I've been unable to create a stable ArcSDE DataStore. When attempting to create a FeatureType, I receive the following error:
GeoServer - Exception
The following exception was thrown: java.lang.StringIndexOutOfBoundsException: String index out of range: -1
After receiving this error, the layers from the DataStore are no longer available until I shut down & restart GeoServer.
I have not seen any evidence (yet) of an ArcSDE state being created by 1.6.4, but that's probably because I haven't been able to set up any FeatureTypes.
My testing on 1.6.4 has been on our non-production instance of ArcSDE. I have not yet been able to determine whether any differences in user permissions between our production & non-production instances may be contributing to this difference in results.
Any suggestions are greatly appreciated!
Thanks,
Mike Olkin GIS Administrator, Town of Amherst 4 Boltwood Avenue, Amherst, MA 01002 PH | 413-259-3247 FX | 413-256-4006 http://gis.amherstma.gov See Amherst in 3D: http://gis.amherstma.gov/3D
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
--
Bart van den Eijnden
OSGIS, Open Source GIS
bartvde@anonymised.com
http://www.osgis.nl
Hi Bart and Michael,
I was just going to ask you to try out the latest nightly but before doing so
I wanted to try it myself and found the arcsde extension were not including
the needed geotools jar, so I went ahead and fixed the build configuration as
per <http://jira.codehaus.org/browse/GEOS-1953>\.
That means you'll have to wait until tomorrow to pick tonight's nightly which
should include the needed jars.
That said, please test over a non production arcsde instance first, since
1.7.x is _alpha_. Yet the arcsde support should be really really better,
which doesn't mean there might not be outstanding issues still.
So if you could grab [1] and [2] tomorrow and try it out that would be of a
great help for us too. Note the GeoTools ArcSDE plugin has been reworked to
solve the threading and performance issues we were having, and so far it
seems to be a resounding success.
Cheers,
Gabriel
[1]<http://gridlock.openplans.org/geoserver/trunk/geoserver-trunk-latest-bin.zip>
[2]<http://gridlock.openplans.org/geoserver/trunk/ext-latest/geoserver-1.7.0-SNAPSHOT-arcsde-plugin.zip>
On Tuesday 27 May 2008 07:43:55 pm Bart van den Eijnden (OSGIS) wrote:
I can confirm the state locks with 1.6.3, we've run into those as well.
Best regards,
Bart
Olkin, Michael wrote:
> I'm quite new with GeoServer and I'm testing it with ArcSDE 9.2 running a
> versioned enterprise geodatabase on MS SQL Server 2000. For the time
> being, I'm primarily interested in testing GeoServer for read-only use of
> our data (ie., no versioned editing with GeoServer).
>
> I've run into a couple of issues with the two most recent releases of
> GeoServer, which I'll sum here:
>
> GeoServer 1.6.3: My initial test last week with 1.6.3 had some
> encouraging results, with a nice stable connection to an ArcSDE DataStore
> in which I was able to create several FeatureTypes that performed nicely.
> The DataStore connection used an ArcSDE account that we use for
> read-only access to most of our layers. The issue that I found was that
> after the DataStore was created, every time GeoServer was started, it
> would create a state in our ArcSDE database. This state would create a
> state lock in ArcSDE that would prevent any other users from reconciling
> or posting edits. Closing GeoServer would leave this unclosed state,
> persisting the issue of nobody being able to reconcile or post edits.
>
> GeoServer 1.6.4: I've been unable to create a stable ArcSDE DataStore.
> When attempting to create a FeatureType, I receive the following error:
> GeoServer - Exception
> The following exception was thrown:
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
>
> After receiving this error, the layers from the DataStore are no longer
> available until I shut down & restart GeoServer.
>
> I have not seen any evidence (yet) of an ArcSDE state being created by
> 1.6.4, but that's probably because I haven't been able to set up any
> FeatureTypes.
>
> My testing on 1.6.4 has been on our non-production instance of ArcSDE. I
> have not yet been able to determine whether any differences in user
> permissions between our production & non-production instances may be
> contributing to this difference in results.
>
> Any suggestions are greatly appreciated!
>
> Thanks,
>
> Mike Olkin
> GIS Administrator, Town of Amherst
> 4 Boltwood Avenue, Amherst, MA 01002
> PH | 413-259-3247 FX | 413-256-4006
> http://gis.amherstma.gov
> See Amherst in 3D: http://gis.amherstma.gov/3D
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Geoserver-users mailing list
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
On Thursday 29 May 2008 01:57:08 pm Gabriel Roldán wrote:
On Thursday 29 May 2008 12:56:25 pm bartvde@anonymised.com wrote:
> Hi Gabriel,
>
> but the zip file only contains: commons-pool and jsqlparser, not the
> actual gt2-arcsde jar?
yes, that's the build script problem I fixed yesterday and why I asked to
wait for last night build, but now I found the nightly were not built. In
another message to the list I asked Justin to look at the build logs to see
why the nightly was not built.
Okay, the nigthly is build now, so feel free to try it out at your
convenience.
[1]<http://gridlock.openplans.org/geoserver/trunk/geoserver-trunk-latest-bin.zip>
[2]<http://gridlock.openplans.org/geoserver/trunk/ext-latest/geoserver-1.7.0-SNAPSHOT-arcsde-plugin.zip>
Cheers,
Gabriel
Hello Gabriel,
i have exactly the same problem with Geoserver 1.6.4 (unstable datastore
connection to ArcSDE) as described by Michael.
I tested the "geoserver-1.7.0-SNAPSHOT-arcsde-plugin.zip" with Geoserver
1.7.0 as proposed by you [2].
The connection to ArcSDE is now stable. When i create a new feature type
from an existing ArcSDE datastore connection i get the following message in
the Geoserver Admin GUI:
GeoServer - Exception
The following exception was thrown:
java.lang.NoClassDefFoundError: org/geotools/data/QueryCapabilities
The Geoserver Logfile says:
2008-06-02 16:28:00,901 ERROR [[/geoserver170].[action]] - Servlet.service()
for servlet action threw exception
java.lang.NoClassDefFoundError: org/geotools/data/QueryCapabilities
at
org.geotools.arcsde.data.ArcSDEDataStore.getFeatureSource(ArcSDEDataStore.java:337)
at
org.vfny.geoserver.action.data.DataFeatureTypesNewAction.execute(DataFeatureTypesNewAction.java:132)
at org.vfny.geoserver.action.ConfigAction.execute(ConfigAction.java:101)
at
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431)
at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
at
org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
at
org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at
org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at
org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at
org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142)
at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at
org.acegisecurity.wrapper.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:81)
at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at
org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217)
at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106)
at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at
org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)
at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at
org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
at
org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:69)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:41)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at
org.apache.catalina.valves.FastCommonAccessLogValve.invoke(FastCommonAccessLogValve.java:482)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685)
at java.lang.Thread.run(Unknown Source)
I made the test with Oracle 9i Rel. 9.2.0.8 and ArcSDE 9.1 with the
corresponding jpe91_sdk.jar and jsde91_sdk.jar.
Any help is appreciated,
Cheers,
Cornelius
Gabriel Roldán-3 wrote:
Hi Bart and Michael,
I was just going to ask you to try out the latest nightly but before doing
so
I wanted to try it myself and found the arcsde extension were not
including
the needed geotools jar, so I went ahead and fixed the build configuration
as
per <http://jira.codehaus.org/browse/GEOS-1953>\.
That means you'll have to wait until tomorrow to pick tonight's nightly
which
should include the needed jars.
That said, please test over a non production arcsde instance first, since
1.7.x is _alpha_. Yet the arcsde support should be really really better,
which doesn't mean there might not be outstanding issues still.
So if you could grab [1] and [2] tomorrow and try it out that would be of
a
great help for us too. Note the GeoTools ArcSDE plugin has been reworked
to
solve the threading and performance issues we were having, and so far it
seems to be a resounding success.
Cheers,
Gabriel
[1]<http://gridlock.openplans.org/geoserver/trunk/geoserver-trunk-latest-bin.zip>
[2]<http://gridlock.openplans.org/geoserver/trunk/ext-latest/geoserver-1.7.0-SNAPSHOT-arcsde-plugin.zip>
On Tuesday 27 May 2008 07:43:55 pm Bart van den Eijnden (OSGIS) wrote:
I can confirm the state locks with 1.6.3, we've run into those as well.
Best regards,
Bart
Olkin, Michael wrote:
> I'm quite new with GeoServer and I'm testing it with ArcSDE 9.2 running
a
> versioned enterprise geodatabase on MS SQL Server 2000. For the time
> being, I'm primarily interested in testing GeoServer for read-only use
of
> our data (ie., no versioned editing with GeoServer).
>
> I've run into a couple of issues with the two most recent releases of
> GeoServer, which I'll sum here:
>
> GeoServer 1.6.3: My initial test last week with 1.6.3 had some
> encouraging results, with a nice stable connection to an ArcSDE
DataStore
> in which I was able to create several FeatureTypes that performed
nicely.
> The DataStore connection used an ArcSDE account that we use for
> read-only access to most of our layers. The issue that I found was
that
> after the DataStore was created, every time GeoServer was started, it
> would create a state in our ArcSDE database. This state would create a
> state lock in ArcSDE that would prevent any other users from
reconciling
> or posting edits. Closing GeoServer would leave this unclosed state,
> persisting the issue of nobody being able to reconcile or post edits.
>
> GeoServer 1.6.4: I've been unable to create a stable ArcSDE DataStore.
> When attempting to create a FeatureType, I receive the following error:
> GeoServer - Exception
> The following exception was thrown:
> java.lang.StringIndexOutOfBoundsException: String index out of range:
-1
>
> After receiving this error, the layers from the DataStore are no longer
> available until I shut down & restart GeoServer.
>
> I have not seen any evidence (yet) of an ArcSDE state being created by
> 1.6.4, but that's probably because I haven't been able to set up any
> FeatureTypes.
>
> My testing on 1.6.4 has been on our non-production instance of ArcSDE.
I
> have not yet been able to determine whether any differences in user
> permissions between our production & non-production instances may be
> contributing to this difference in results.
>
> Any suggestions are greatly appreciated!
>
> Thanks,
>
> Mike Olkin
> GIS Administrator, Town of Amherst
> 4 Boltwood Avenue, Amherst, MA 01002
> PH | 413-259-3247 FX | 413-256-4006
> http://gis.amherstma.gov
> See Amherst in 3D: http://gis.amherstma.gov/3D
>
>
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Geoserver-users mailing list
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
--
View this message in context: http://www.nabble.com/Odd-behavior-with-ArcSDE-DataStore-tp17495983p17603494.html
Sent from the GeoServer - User mailing list archive at Nabble.com.
hmm..
the exception clearly says that class is not in your classpath, which
shouldn't happen with the right combination of geoserver and arcsde extension
snapshots.
Did you also download the geosrever binary among the sde extension? or tried
the sde extension with a previous 1.7.x geoserver snapshot?
cheers,
Gabriel
On Monday 02 June 2008 05:04:50 pm Cornelius Schweizer wrote:
Hello Gabriel,
i have exactly the same problem with Geoserver 1.6.4 (unstable datastore
connection to ArcSDE) as described by Michael.
I tested the "geoserver-1.7.0-SNAPSHOT-arcsde-plugin.zip" with Geoserver
1.7.0 as proposed by you [2].
The connection to ArcSDE is now stable. When i create a new feature type
from an existing ArcSDE datastore connection i get the following message in
the Geoserver Admin GUI:
GeoServer - Exception
The following exception was thrown:
java.lang.NoClassDefFoundError: org/geotools/data/QueryCapabilities
The Geoserver Logfile says:
2008-06-02 16:28:00,901 ERROR [[/geoserver170].[action]] -
Servlet.service() for servlet action threw exception
java.lang.NoClassDefFoundError: org/geotools/data/QueryCapabilities
at
org.geotools.arcsde.data.ArcSDEDataStore.getFeatureSource(ArcSDEDataStore.j
ava:337) at
org.vfny.geoserver.action.data.DataFeatureTypesNewAction.execute(DataFeatur
eTypesNewAction.java:132) at
org.vfny.geoserver.action.ConfigAction.execute(ConfigAction.java:101) at
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProce
ssor.java:431) at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236
) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicatio
nFilterChain.java:269) at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterC
hain.java:188) at
org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacter
EncodingFilter.java:108) at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicatio
nFilterChain.java:215) at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterC
hain.java:188) at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterC
hainProxy.java:264) at
org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecu
rityInterceptor.java:107) at
org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSe
curityInterceptor.java:72) at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterC
hainProxy.java:274) at
org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslati
onFilter.java:110) at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterC
hainProxy.java:274) at
org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(An
onymousProcessingFilter.java:125) at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterC
hainProxy.java:274) at
org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(Remembe
rMeProcessingFilter.java:142) at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterC
hainProxy.java:274) at
org.acegisecurity.wrapper.SecurityContextHolderAwareRequestFilter.doFilter(
SecurityContextHolderAwareRequestFilter.java:81) at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterC
hainProxy.java:274) at
org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFi
lter.java:217) at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterC
hainProxy.java:274) at
org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106) at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterC
hainProxy.java:274) at
org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(Http
SessionContextIntegrationFilter.java:229) at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterC
hainProxy.java:274) at
org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
at
org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98
) at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicatio
nFilterChain.java:215) at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterC
hain.java:188) at
org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:69) at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicatio
nFilterChain.java:215) at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterC
hain.java:188) at
org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:41)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicatio
nFilterChain.java:215) at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterC
hain.java:188) at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.j
ava:210) at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.j
ava:174) at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:12
7) at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:11
7) at
org.apache.catalina.valves.FastCommonAccessLogValve.invoke(FastCommonAccess
LogValve.java:482) at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.jav
a:108) at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.process
Connection(Http11BaseProtocol.java:665) at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.ja
va:528) at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerW
orkerThread.java:81) at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.ja
va:685) at java.lang.Thread.run(Unknown Source)
I made the test with Oracle 9i Rel. 9.2.0.8 and ArcSDE 9.1 with the
corresponding jpe91_sdk.jar and jsde91_sdk.jar.
Any help is appreciated,
Cheers,
Cornelius
Gabriel Roldán-3 wrote:
> Hi Bart and Michael,
>
> I was just going to ask you to try out the latest nightly but before
> doing so
> I wanted to try it myself and found the arcsde extension were not
> including
> the needed geotools jar, so I went ahead and fixed the build
> configuration as
> per <http://jira.codehaus.org/browse/GEOS-1953>\.
>
> That means you'll have to wait until tomorrow to pick tonight's nightly
> which
> should include the needed jars.
> That said, please test over a non production arcsde instance first, since
> 1.7.x is _alpha_. Yet the arcsde support should be really really better,
> which doesn't mean there might not be outstanding issues still.
>
> So if you could grab [1] and [2] tomorrow and try it out that would be of
> a
> great help for us too. Note the GeoTools ArcSDE plugin has been reworked
> to
> solve the threading and performance issues we were having, and so far it
> seems to be a resounding success.
>
> Cheers,
>
> Gabriel
> [1]<http://gridlock.openplans.org/geoserver/trunk/geoserver-trunk-latest-
>bin.zip>
> [2]<http://gridlock.openplans.org/geoserver/trunk/ext-latest/geoserver-1.
>7.0-SNAPSHOT-arcsde-plugin.zip>
>
> On Tuesday 27 May 2008 07:43:55 pm Bart van den Eijnden (OSGIS) wrote:
>> I can confirm the state locks with 1.6.3, we've run into those as well.
>>
>> Best regards,
>> Bart
>>
>> Olkin, Michael wrote:
>> > I'm quite new with GeoServer and I'm testing it with ArcSDE 9.2
>> > running
>>
>> a
>>
>> > versioned enterprise geodatabase on MS SQL Server 2000. For the time
>> > being, I'm primarily interested in testing GeoServer for read-only use
>>
>> of
>>
>> > our data (ie., no versioned editing with GeoServer).
>> >
>> > I've run into a couple of issues with the two most recent releases of
>> > GeoServer, which I'll sum here:
>> >
>> > GeoServer 1.6.3: My initial test last week with 1.6.3 had some
>> > encouraging results, with a nice stable connection to an ArcSDE
>>
>> DataStore
>>
>> > in which I was able to create several FeatureTypes that performed
>>
>> nicely.
>>
>> > The DataStore connection used an ArcSDE account that we use for
>> > read-only access to most of our layers. The issue that I found was
>>
>> that
>>
>> > after the DataStore was created, every time GeoServer was started, it
>> > would create a state in our ArcSDE database. This state would create
>> > a state lock in ArcSDE that would prevent any other users from
>>
>> reconciling
>>
>> > or posting edits. Closing GeoServer would leave this unclosed state,
>> > persisting the issue of nobody being able to reconcile or post edits.
>> >
>> > GeoServer 1.6.4: I've been unable to create a stable ArcSDE DataStore.
>> > When attempting to create a FeatureType, I receive the following
>> > error: GeoServer - Exception
>> > The following exception was thrown:
>> > java.lang.StringIndexOutOfBoundsException: String index out of range:
>>
>> -1
>>
>> > After receiving this error, the layers from the DataStore are no
>> > longer available until I shut down & restart GeoServer.
>> >
>> > I have not seen any evidence (yet) of an ArcSDE state being created by
>> > 1.6.4, but that's probably because I haven't been able to set up any
>> > FeatureTypes.
>> >
>> > My testing on 1.6.4 has been on our non-production instance of ArcSDE.
>>
>> I
>>
>> > have not yet been able to determine whether any differences in user
>> > permissions between our production & non-production instances may be
>> > contributing to this difference in results.
>> >
>> > Any suggestions are greatly appreciated!
>> >
>> > Thanks,
>> >
>> > Mike Olkin
>> > GIS Administrator, Town of Amherst
>> > 4 Boltwood Avenue, Amherst, MA 01002
>> > PH | 413-259-3247 FX | 413-256-4006
>> > http://gis.amherstma.gov
>> > See Amherst in 3D: http://gis.amherstma.gov/3D
>>
>> ------------------------------------------------------------------------
>>-
>>
>> > This SF.net email is sponsored by: Microsoft
>> > Defy all challenges. Microsoft(R) Visual Studio 2008.
>> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> > _______________________________________________
>> > Geoserver-users mailing list
>> > Geoserver-users@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/geoserver-users
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Geoserver-users mailing list
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
I did not download and use the geoserver binary. I only used the sde
extension with a previous (the latest 1.7.0) geoserver snapshot. Ok, then
this is my problem.
Because i use geoserver with Apache Tomcat as .war; is it possible to
provide the latest geoserver as a .war file (instead of bin) ?
Then i could test this problem again. Thanks.
Gabriel Roldán-3 wrote:
hmm..
the exception clearly says that class is not in your classpath, which
shouldn't happen with the right combination of geoserver and arcsde
extension
snapshots.
Did you also download the geosrever binary among the sde extension? or
tried
the sde extension with a previous 1.7.x geoserver snapshot?
cheers,
Gabriel
On Monday 02 June 2008 05:04:50 pm Cornelius Schweizer wrote:
Hello Gabriel,
i have exactly the same problem with Geoserver 1.6.4 (unstable datastore
connection to ArcSDE) as described by Michael.
I tested the "geoserver-1.7.0-SNAPSHOT-arcsde-plugin.zip" with Geoserver
1.7.0 as proposed by you [2].
The connection to ArcSDE is now stable. When i create a new feature type
from an existing ArcSDE datastore connection i get the following message
in
the Geoserver Admin GUI:
GeoServer - Exception
The following exception was thrown:
java.lang.NoClassDefFoundError: org/geotools/data/QueryCapabilities
The Geoserver Logfile says:
2008-06-02 16:28:00,901 ERROR [[/geoserver170].[action]] -
Servlet.service() for servlet action threw exception
java.lang.NoClassDefFoundError: org/geotools/data/QueryCapabilities
at
org.geotools.arcsde.data.ArcSDEDataStore.getFeatureSource(ArcSDEDataStore.j
ava:337) at
org.vfny.geoserver.action.data.DataFeatureTypesNewAction.execute(DataFeatur
eTypesNewAction.java:132) at
org.vfny.geoserver.action.ConfigAction.execute(ConfigAction.java:101) at
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProce
ssor.java:431) at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236
) at
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicatio
nFilterChain.java:269) at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterC
hain.java:188) at
org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacter
EncodingFilter.java:108) at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicatio
nFilterChain.java:215) at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterC
hain.java:188) at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterC
hainProxy.java:264) at
org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecu
rityInterceptor.java:107) at
org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSe
curityInterceptor.java:72) at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterC
hainProxy.java:274) at
org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslati
onFilter.java:110) at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterC
hainProxy.java:274) at
org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(An
onymousProcessingFilter.java:125) at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterC
hainProxy.java:274) at
org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(Remembe
rMeProcessingFilter.java:142) at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterC
hainProxy.java:274) at
org.acegisecurity.wrapper.SecurityContextHolderAwareRequestFilter.doFilter(
SecurityContextHolderAwareRequestFilter.java:81) at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterC
hainProxy.java:274) at
org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFi
lter.java:217) at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterC
hainProxy.java:274) at
org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106)
at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterC
hainProxy.java:274) at
org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(Http
SessionContextIntegrationFilter.java:229) at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterC
hainProxy.java:274) at
org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
at
org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98
) at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicatio
nFilterChain.java:215) at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterC
hain.java:188) at
org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:69) at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicatio
nFilterChain.java:215) at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterC
hain.java:188) at
org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:41)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicatio
nFilterChain.java:215) at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterC
hain.java:188) at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.j
ava:210) at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.j
ava:174) at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:12
7) at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:11
7) at
org.apache.catalina.valves.FastCommonAccessLogValve.invoke(FastCommonAccess
LogValve.java:482) at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.jav
a:108) at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.process
Connection(Http11BaseProtocol.java:665) at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.ja
va:528) at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerW
orkerThread.java:81) at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.ja
va:685) at java.lang.Thread.run(Unknown Source)
I made the test with Oracle 9i Rel. 9.2.0.8 and ArcSDE 9.1 with the
corresponding jpe91_sdk.jar and jsde91_sdk.jar.
Any help is appreciated,
Cheers,
Cornelius
Gabriel Roldán-3 wrote:
> Hi Bart and Michael,
>
> I was just going to ask you to try out the latest nightly but before
> doing so
> I wanted to try it myself and found the arcsde extension were not
> including
> the needed geotools jar, so I went ahead and fixed the build
> configuration as
> per <http://jira.codehaus.org/browse/GEOS-1953>\.
>
> That means you'll have to wait until tomorrow to pick tonight's nightly
> which
> should include the needed jars.
> That said, please test over a non production arcsde instance first,
since
> 1.7.x is _alpha_. Yet the arcsde support should be really really
better,
> which doesn't mean there might not be outstanding issues still.
>
> So if you could grab [1] and [2] tomorrow and try it out that would be
of
> a
> great help for us too. Note the GeoTools ArcSDE plugin has been
reworked
> to
> solve the threading and performance issues we were having, and so far
it
> seems to be a resounding success.
>
> Cheers,
>
> Gabriel
>
[1]<http://gridlock.openplans.org/geoserver/trunk/geoserver-trunk-latest-
>bin.zip>
>
[2]<http://gridlock.openplans.org/geoserver/trunk/ext-latest/geoserver-1.
>7.0-SNAPSHOT-arcsde-plugin.zip>
>
> On Tuesday 27 May 2008 07:43:55 pm Bart van den Eijnden (OSGIS) wrote:
>> I can confirm the state locks with 1.6.3, we've run into those as
well.
>>
>> Best regards,
>> Bart
>>
>> Olkin, Michael wrote:
>> > I'm quite new with GeoServer and I'm testing it with ArcSDE 9.2
>> > running
>>
>> a
>>
>> > versioned enterprise geodatabase on MS SQL Server 2000. For the
time
>> > being, I'm primarily interested in testing GeoServer for read-only
use
>>
>> of
>>
>> > our data (ie., no versioned editing with GeoServer).
>> >
>> > I've run into a couple of issues with the two most recent releases
of
>> > GeoServer, which I'll sum here:
>> >
>> > GeoServer 1.6.3: My initial test last week with 1.6.3 had some
>> > encouraging results, with a nice stable connection to an ArcSDE
>>
>> DataStore
>>
>> > in which I was able to create several FeatureTypes that performed
>>
>> nicely.
>>
>> > The DataStore connection used an ArcSDE account that we use for
>> > read-only access to most of our layers. The issue that I found was
>>
>> that
>>
>> > after the DataStore was created, every time GeoServer was started,
it
>> > would create a state in our ArcSDE database. This state would
create
>> > a state lock in ArcSDE that would prevent any other users from
>>
>> reconciling
>>
>> > or posting edits. Closing GeoServer would leave this unclosed
state,
>> > persisting the issue of nobody being able to reconcile or post
edits.
>> >
>> > GeoServer 1.6.4: I've been unable to create a stable ArcSDE
DataStore.
>> > When attempting to create a FeatureType, I receive the following
>> > error: GeoServer - Exception
>> > The following exception was thrown:
>> > java.lang.StringIndexOutOfBoundsException: String index out of
range:
>>
>> -1
>>
>> > After receiving this error, the layers from the DataStore are no
>> > longer available until I shut down & restart GeoServer.
>> >
>> > I have not seen any evidence (yet) of an ArcSDE state being created
by
>> > 1.6.4, but that's probably because I haven't been able to set up any
>> > FeatureTypes.
>> >
>> > My testing on 1.6.4 has been on our non-production instance of
ArcSDE.
>>
>> I
>>
>> > have not yet been able to determine whether any differences in user
>> > permissions between our production & non-production instances may be
>> > contributing to this difference in results.
>> >
>> > Any suggestions are greatly appreciated!
>> >
>> > Thanks,
>> >
>> > Mike Olkin
>> > GIS Administrator, Town of Amherst
>> > 4 Boltwood Avenue, Amherst, MA 01002
>> > PH | 413-259-3247 FX | 413-256-4006
>> > http://gis.amherstma.gov
>> > See Amherst in 3D: http://gis.amherstma.gov/3D
>>
>>
------------------------------------------------------------------------
>>-
>>
>> > This SF.net email is sponsored by: Microsoft
>> > Defy all challenges. Microsoft(R) Visual Studio 2008.
>> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> > _______________________________________________
>> > Geoserver-users mailing list
>> > Geoserver-users@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/geoserver-users
>
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Geoserver-users mailing list
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
--
View this message in context: http://www.nabble.com/Odd-behavior-with-ArcSDE-DataStore-tp17495983p17618022.html
Sent from the GeoServer - User mailing list archive at Nabble.com.
indeed:
<http://gridlock.openplans.org/geoserver/trunk/geoserver-trunk-latest-war.zip>
let me know how it goes.
Gabriel
On Tuesday 03 June 2008 09:49:13 am Cornelius Schweizer wrote:
I did not download and use the geoserver binary. I only used the sde
extension with a previous (the latest 1.7.0) geoserver snapshot. Ok, then
this is my problem.
Because i use geoserver with Apache Tomcat as .war; is it possible to
provide the latest geoserver as a .war file (instead of bin) ?
Then i could test this problem again. Thanks.
Gabriel Roldán-3 wrote:
> hmm..
> the exception clearly says that class is not in your classpath, which
> shouldn't happen with the right combination of geoserver and arcsde
> extension
> snapshots.
> Did you also download the geosrever binary among the sde extension? or
> tried
> the sde extension with a previous 1.7.x geoserver snapshot?
>
> cheers,
> Gabriel
>
> On Monday 02 June 2008 05:04:50 pm Cornelius Schweizer wrote:
>> Hello Gabriel,
>>
>> i have exactly the same problem with Geoserver 1.6.4 (unstable datastore
>> connection to ArcSDE) as described by Michael.
>> I tested the "geoserver-1.7.0-SNAPSHOT-arcsde-plugin.zip" with Geoserver
>> 1.7.0 as proposed by you [2].
>>
>> The connection to ArcSDE is now stable. When i create a new feature type
>> from an existing ArcSDE datastore connection i get the following message
>> in
>> the Geoserver Admin GUI:
>>
>> GeoServer - Exception
>> The following exception was thrown:
>> java.lang.NoClassDefFoundError: org/geotools/data/QueryCapabilities
>>
>> The Geoserver Logfile says:
>>
>> 2008-06-02 16:28:00,901 ERROR [[/geoserver170].[action]] -
>> Servlet.service() for servlet action threw exception
>> java.lang.NoClassDefFoundError: org/geotools/data/QueryCapabilities
>> at
>> org.geotools.arcsde.data.ArcSDEDataStore.getFeatureSource(ArcSDEDataStor
>>e.j ava:337) at
>> org.vfny.geoserver.action.data.DataFeatureTypesNewAction.execute(DataFea
>>tur eTypesNewAction.java:132) at
>> org.vfny.geoserver.action.ConfigAction.execute(ConfigAction.java:101) at
>> org.apache.struts.action.RequestProcessor.processActionPerform(RequestPr
>>oce ssor.java:431) at
>> org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:
>>236 ) at
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
>> at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
>> at
>> javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
>>tio nFilterChain.java:269) at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
>>erC hain.java:188) at
>> org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharac
>>ter EncodingFilter.java:108) at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
>>tio nFilterChain.java:215) at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
>>erC hain.java:188) at
>> org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(Filt
>>erC hainProxy.java:264) at
>> org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterS
>>ecu rityInterceptor.java:107) at
>> org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(Filte
>>rSe curityInterceptor.java:72) at
>> org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(Filt
>>erC hainProxy.java:274) at
>> org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTransl
>>ati onFilter.java:110) at
>> org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(Filt
>>erC hainProxy.java:274) at
>> org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter
>>(An onymousProcessingFilter.java:125) at
>> org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(Filt
>>erC hainProxy.java:274) at
>> org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(Reme
>>mbe rMeProcessingFilter.java:142) at
>> org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(Filt
>>erC hainProxy.java:274) at
>> org.acegisecurity.wrapper.SecurityContextHolderAwareRequestFilter.doFilt
>>er( SecurityContextHolderAwareRequestFilter.java:81) at
>> org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(Filt
>>erC hainProxy.java:274) at
>> org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessin
>>gFi lter.java:217) at
>> org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(Filt
>>erC hainProxy.java:274) at
>> org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106)
>> at
>> org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(Filt
>>erC hainProxy.java:274) at
>> org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(H
>>ttp SessionContextIntegrationFilter.java:229) at
>> org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(Filt
>>erC hainProxy.java:274) at
>> org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:1
>>48) at
>> org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java
>>:98 ) at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
>>tio nFilterChain.java:215) at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
>>erC hain.java:188) at
>> org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:69) at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
>>tio nFilterChain.java:215) at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
>>erC hain.java:188) at
>> org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:41)
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
>>tio nFilterChain.java:215) at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
>>erC hain.java:188) at
>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
>>e.j ava:210) at
>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
>>e.j ava:174) at
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
>>:12 7) at
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
>>:11 7) at
>> org.apache.catalina.valves.FastCommonAccessLogValve.invoke(FastCommonAcc
>>ess LogValve.java:482) at
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
>>jav a:108) at
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:1
>>51) at
>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:87
>>0) at
>> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.proc
>>ess Connection(Http11BaseProtocol.java:665) at
>> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint
>>.ja va:528) at
>> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollow
>>erW orkerThread.java:81) at
>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool
>>.ja va:685) at java.lang.Thread.run(Unknown Source)
>>
>> I made the test with Oracle 9i Rel. 9.2.0.8 and ArcSDE 9.1 with the
>> corresponding jpe91_sdk.jar and jsde91_sdk.jar.
>>
>> Any help is appreciated,
>>
>> Cheers,
>> Cornelius
>>
>> Gabriel Roldán-3 wrote:
>> > Hi Bart and Michael,
>> >
>> > I was just going to ask you to try out the latest nightly but before
>> > doing so
>> > I wanted to try it myself and found the arcsde extension were not
>> > including
>> > the needed geotools jar, so I went ahead and fixed the build
>> > configuration as
>> > per <http://jira.codehaus.org/browse/GEOS-1953>\.
>> >
>> > That means you'll have to wait until tomorrow to pick tonight's
>> > nightly which
>> > should include the needed jars.
>> > That said, please test over a non production arcsde instance first,
>>
>> since
>>
>> > 1.7.x is _alpha_. Yet the arcsde support should be really really
>>
>> better,
>>
>> > which doesn't mean there might not be outstanding issues still.
>> >
>> > So if you could grab [1] and [2] tomorrow and try it out that would be
>>
>> of
>>
>> > a
>> > great help for us too. Note the GeoTools ArcSDE plugin has been
>>
>> reworked
>>
>> > to
>> > solve the threading and performance issues we were having, and so far
>>
>> it
>>
>> > seems to be a resounding success.
>> >
>> > Cheers,
>> >
>> > Gabriel
>>
>> [1]<http://gridlock.openplans.org/geoserver/trunk/geoserver-trunk-latest
>>-
>>
>> >bin.zip>
>>
>> [2]<http://gridlock.openplans.org/geoserver/trunk/ext-latest/geoserver-1
>>.
>>
>> >7.0-SNAPSHOT-arcsde-plugin.zip>
>> >
>> > On Tuesday 27 May 2008 07:43:55 pm Bart van den Eijnden (OSGIS) wrote:
>> >> I can confirm the state locks with 1.6.3, we've run into those as
>>
>> well.
>>
>> >> Best regards,
>> >> Bart
>> >>
>> >> Olkin, Michael wrote:
>> >> > I'm quite new with GeoServer and I'm testing it with ArcSDE 9.2
>> >> > running
>> >>
>> >> a
>> >>
>> >> > versioned enterprise geodatabase on MS SQL Server 2000. For the
>>
>> time
>>
>> >> > being, I'm primarily interested in testing GeoServer for read-only
>>
>> use
>>
>> >> of
>> >>
>> >> > our data (ie., no versioned editing with GeoServer).
>> >> >
>> >> > I've run into a couple of issues with the two most recent releases
>>
>> of
>>
>> >> > GeoServer, which I'll sum here:
>> >> >
>> >> > GeoServer 1.6.3: My initial test last week with 1.6.3 had some
>> >> > encouraging results, with a nice stable connection to an ArcSDE
>> >>
>> >> DataStore
>> >>
>> >> > in which I was able to create several FeatureTypes that performed
>> >>
>> >> nicely.
>> >>
>> >> > The DataStore connection used an ArcSDE account that we use for
>> >> > read-only access to most of our layers. The issue that I found was
>> >>
>> >> that
>> >>
>> >> > after the DataStore was created, every time GeoServer was started,
>>
>> it
>>
>> >> > would create a state in our ArcSDE database. This state would
>>
>> create
>>
>> >> > a state lock in ArcSDE that would prevent any other users from
>> >>
>> >> reconciling
>> >>
>> >> > or posting edits. Closing GeoServer would leave this unclosed
>>
>> state,
>>
>> >> > persisting the issue of nobody being able to reconcile or post
>>
>> edits.
>>
>> >> > GeoServer 1.6.4: I've been unable to create a stable ArcSDE
>>
>> DataStore.
>>
>> >> > When attempting to create a FeatureType, I receive the following
>> >> > error: GeoServer - Exception
>> >> > The following exception was thrown:
>> >> > java.lang.StringIndexOutOfBoundsException: String index out of
>>
>> range:
>> >> -1
>> >>
>> >> > After receiving this error, the layers from the DataStore are no
>> >> > longer available until I shut down & restart GeoServer.
>> >> >
>> >> > I have not seen any evidence (yet) of an ArcSDE state being created
>>
>> by
>>
>> >> > 1.6.4, but that's probably because I haven't been able to set up
>> >> > any FeatureTypes.
>> >> >
>> >> > My testing on 1.6.4 has been on our non-production instance of
>>
>> ArcSDE.
>>
>> >> I
>> >>
>> >> > have not yet been able to determine whether any differences in user
>> >> > permissions between our production & non-production instances may
>> >> > be contributing to this difference in results.
>> >> >
>> >> > Any suggestions are greatly appreciated!
>> >> >
>> >> > Thanks,
>> >> >
>> >> > Mike Olkin
>> >> > GIS Administrator, Town of Amherst
>> >> > 4 Boltwood Avenue, Amherst, MA 01002
>> >> > PH | 413-259-3247 FX | 413-256-4006
>> >> > http://gis.amherstma.gov
>> >> > See Amherst in 3D: http://gis.amherstma.gov/3D
>>
>> ------------------------------------------------------------------------
>>
>> >>-
>> >>
>> >> > This SF.net email is sponsored by: Microsoft
>> >> > Defy all challenges. Microsoft(R) Visual Studio 2008.
>> >> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> >> > _______________________________________________
>> >> > Geoserver-users mailing list
>> >> > Geoserver-users@lists.sourceforge.net
>> >> > https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>
>> ------------------------------------------------------------------------
>>-
>>
>> > This SF.net email is sponsored by: Microsoft
>> > Defy all challenges. Microsoft(R) Visual Studio 2008.
>> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> > _______________________________________________
>> > Geoserver-users mailing list
>> > Geoserver-users@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/geoserver-users
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Geoserver-users mailing list
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
Now it works fine, thanks.
ArcSDE datastores are now stable, i was able to create new featuretypes,
visualize them and query (feature info) in the internal openlayers preview
client.
Are you going to fix this problem also for Geoserver Version 1.6.4 stable or
just continue development/bug fixing on the newest 1.7.0 version ?
Best Regards,
Cornelius
Gabriel Roldán-3 wrote:
indeed:
<http://gridlock.openplans.org/geoserver/trunk/geoserver-trunk-latest-war.zip>
let me know how it goes.
Gabriel
On Tuesday 03 June 2008 09:49:13 am Cornelius Schweizer wrote:
I did not download and use the geoserver binary. I only used the sde
extension with a previous (the latest 1.7.0) geoserver snapshot. Ok, then
this is my problem.
Because i use geoserver with Apache Tomcat as .war; is it possible to
provide the latest geoserver as a .war file (instead of bin) ?
Then i could test this problem again. Thanks.
Gabriel Roldán-3 wrote:
> hmm..
> the exception clearly says that class is not in your classpath, which
> shouldn't happen with the right combination of geoserver and arcsde
> extension
> snapshots.
> Did you also download the geosrever binary among the sde extension? or
> tried
> the sde extension with a previous 1.7.x geoserver snapshot?
>
> cheers,
> Gabriel
>
> On Monday 02 June 2008 05:04:50 pm Cornelius Schweizer wrote:
>> Hello Gabriel,
>>
>> i have exactly the same problem with Geoserver 1.6.4 (unstable
datastore
>> connection to ArcSDE) as described by Michael.
>> I tested the "geoserver-1.7.0-SNAPSHOT-arcsde-plugin.zip" with
Geoserver
>> 1.7.0 as proposed by you [2].
>>
>> The connection to ArcSDE is now stable. When i create a new feature
type
>> from an existing ArcSDE datastore connection i get the following
message
>> in
>> the Geoserver Admin GUI:
>>
>> GeoServer - Exception
>> The following exception was thrown:
>> java.lang.NoClassDefFoundError: org/geotools/data/QueryCapabilities
>>
>> The Geoserver Logfile says:
>>
>> 2008-06-02 16:28:00,901 ERROR [[/geoserver170].[action]] -
>> Servlet.service() for servlet action threw exception
>> java.lang.NoClassDefFoundError: org/geotools/data/QueryCapabilities
>> at
>>
org.geotools.arcsde.data.ArcSDEDataStore.getFeatureSource(ArcSDEDataStor
>>e.j ava:337) at
>>
org.vfny.geoserver.action.data.DataFeatureTypesNewAction.execute(DataFea
>>tur eTypesNewAction.java:132) at
>> org.vfny.geoserver.action.ConfigAction.execute(ConfigAction.java:101)
at
>>
org.apache.struts.action.RequestProcessor.processActionPerform(RequestPr
>>oce ssor.java:431) at
>>
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:
>>236 ) at
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
>> at
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
>> at
>> javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>> at
>>
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
>>tio nFilterChain.java:269) at
>>
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
>>erC hain.java:188) at
>>
org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharac
>>ter EncodingFilter.java:108) at
>>
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
>>tio nFilterChain.java:215) at
>>
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
>>erC hain.java:188) at
>>
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(Filt
>>erC hainProxy.java:264) at
>>
org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterS
>>ecu rityInterceptor.java:107) at
>>
org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(Filte
>>rSe curityInterceptor.java:72) at
>>
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(Filt
>>erC hainProxy.java:274) at
>>
org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTransl
>>ati onFilter.java:110) at
>>
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(Filt
>>erC hainProxy.java:274) at
>>
org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter
>>(An onymousProcessingFilter.java:125) at
>>
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(Filt
>>erC hainProxy.java:274) at
>>
org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(Reme
>>mbe rMeProcessingFilter.java:142) at
>>
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(Filt
>>erC hainProxy.java:274) at
>>
org.acegisecurity.wrapper.SecurityContextHolderAwareRequestFilter.doFilt
>>er( SecurityContextHolderAwareRequestFilter.java:81) at
>>
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(Filt
>>erC hainProxy.java:274) at
>>
org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessin
>>gFi lter.java:217) at
>>
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(Filt
>>erC hainProxy.java:274) at
>>
org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106)
>> at
>>
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(Filt
>>erC hainProxy.java:274) at
>>
org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(H
>>ttp SessionContextIntegrationFilter.java:229) at
>>
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(Filt
>>erC hainProxy.java:274) at
>>
org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:1
>>48) at
>>
org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java
>>:98 ) at
>>
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
>>tio nFilterChain.java:215) at
>>
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
>>erC hain.java:188) at
>> org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:69) at
>>
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
>>tio nFilterChain.java:215) at
>>
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
>>erC hain.java:188) at
>> org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:41)
>> at
>>
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
>>tio nFilterChain.java:215) at
>>
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
>>erC hain.java:188) at
>>
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
>>e.j ava:210) at
>>
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
>>e.j ava:174) at
>>
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
>>:12 7) at
>>
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
>>:11 7) at
>>
org.apache.catalina.valves.FastCommonAccessLogValve.invoke(FastCommonAcc
>>ess LogValve.java:482) at
>>
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
>>jav a:108) at
>>
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:1
>>51) at
>>
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:87
>>0) at
>>
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.proc
>>ess Connection(Http11BaseProtocol.java:665) at
>>
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint
>>.ja va:528) at
>>
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollow
>>erW orkerThread.java:81) at
>>
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool
>>.ja va:685) at java.lang.Thread.run(Unknown Source)
>>
>> I made the test with Oracle 9i Rel. 9.2.0.8 and ArcSDE 9.1 with the
>> corresponding jpe91_sdk.jar and jsde91_sdk.jar.
>>
>> Any help is appreciated,
>>
>> Cheers,
>> Cornelius
>>
>> Gabriel Roldán-3 wrote:
>> > Hi Bart and Michael,
>> >
>> > I was just going to ask you to try out the latest nightly but before
>> > doing so
>> > I wanted to try it myself and found the arcsde extension were not
>> > including
>> > the needed geotools jar, so I went ahead and fixed the build
>> > configuration as
>> > per <http://jira.codehaus.org/browse/GEOS-1953>\.
>> >
>> > That means you'll have to wait until tomorrow to pick tonight's
>> > nightly which
>> > should include the needed jars.
>> > That said, please test over a non production arcsde instance first,
>>
>> since
>>
>> > 1.7.x is _alpha_. Yet the arcsde support should be really really
>>
>> better,
>>
>> > which doesn't mean there might not be outstanding issues still.
>> >
>> > So if you could grab [1] and [2] tomorrow and try it out that would
be
>>
>> of
>>
>> > a
>> > great help for us too. Note the GeoTools ArcSDE plugin has been
>>
>> reworked
>>
>> > to
>> > solve the threading and performance issues we were having, and so
far
>>
>> it
>>
>> > seems to be a resounding success.
>> >
>> > Cheers,
>> >
>> > Gabriel
>>
>>
[1]<http://gridlock.openplans.org/geoserver/trunk/geoserver-trunk-latest
>>-
>>
>> >bin.zip>
>>
>>
[2]<http://gridlock.openplans.org/geoserver/trunk/ext-latest/geoserver-1
>>.
>>
>> >7.0-SNAPSHOT-arcsde-plugin.zip>
>> >
>> > On Tuesday 27 May 2008 07:43:55 pm Bart van den Eijnden (OSGIS)
wrote:
>> >> I can confirm the state locks with 1.6.3, we've run into those as
>>
>> well.
>>
>> >> Best regards,
>> >> Bart
>> >>
>> >> Olkin, Michael wrote:
>> >> > I'm quite new with GeoServer and I'm testing it with ArcSDE 9.2
>> >> > running
>> >>
>> >> a
>> >>
>> >> > versioned enterprise geodatabase on MS SQL Server 2000. For the
>>
>> time
>>
>> >> > being, I'm primarily interested in testing GeoServer for
read-only
>>
>> use
>>
>> >> of
>> >>
>> >> > our data (ie., no versioned editing with GeoServer).
>> >> >
>> >> > I've run into a couple of issues with the two most recent
releases
>>
>> of
>>
>> >> > GeoServer, which I'll sum here:
>> >> >
>> >> > GeoServer 1.6.3: My initial test last week with 1.6.3 had some
>> >> > encouraging results, with a nice stable connection to an ArcSDE
>> >>
>> >> DataStore
>> >>
>> >> > in which I was able to create several FeatureTypes that performed
>> >>
>> >> nicely.
>> >>
>> >> > The DataStore connection used an ArcSDE account that we use for
>> >> > read-only access to most of our layers. The issue that I found
was
>> >>
>> >> that
>> >>
>> >> > after the DataStore was created, every time GeoServer was
started,
>>
>> it
>>
>> >> > would create a state in our ArcSDE database. This state would
>>
>> create
>>
>> >> > a state lock in ArcSDE that would prevent any other users from
>> >>
>> >> reconciling
>> >>
>> >> > or posting edits. Closing GeoServer would leave this unclosed
>>
>> state,
>>
>> >> > persisting the issue of nobody being able to reconcile or post
>>
>> edits.
>>
>> >> > GeoServer 1.6.4: I've been unable to create a stable ArcSDE
>>
>> DataStore.
>>
>> >> > When attempting to create a FeatureType, I receive the following
>> >> > error: GeoServer - Exception
>> >> > The following exception was thrown:
>> >> > java.lang.StringIndexOutOfBoundsException: String index out of
>>
>> range:
>> >> -1
>> >>
>> >> > After receiving this error, the layers from the DataStore are no
>> >> > longer available until I shut down & restart GeoServer.
>> >> >
>> >> > I have not seen any evidence (yet) of an ArcSDE state being
created
>>
>> by
>>
>> >> > 1.6.4, but that's probably because I haven't been able to set up
>> >> > any FeatureTypes.
>> >> >
>> >> > My testing on 1.6.4 has been on our non-production instance of
>>
>> ArcSDE.
>>
>> >> I
>> >>
>> >> > have not yet been able to determine whether any differences in
user
>> >> > permissions between our production & non-production instances may
>> >> > be contributing to this difference in results.
>> >> >
>> >> > Any suggestions are greatly appreciated!
>> >> >
>> >> > Thanks,
>> >> >
>> >> > Mike Olkin
>> >> > GIS Administrator, Town of Amherst
>> >> > 4 Boltwood Avenue, Amherst, MA 01002
>> >> > PH | 413-259-3247 FX | 413-256-4006
>> >> > http://gis.amherstma.gov
>> >> > See Amherst in 3D: http://gis.amherstma.gov/3D
>>
>>
------------------------------------------------------------------------
>>
>> >>-
>> >>
>> >> > This SF.net email is sponsored by: Microsoft
>> >> > Defy all challenges. Microsoft(R) Visual Studio 2008.
>> >> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> >> > _______________________________________________
>> >> > Geoserver-users mailing list
>> >> > Geoserver-users@lists.sourceforge.net
>> >> > https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>
>>
------------------------------------------------------------------------
>>-
>>
>> > This SF.net email is sponsored by: Microsoft
>> > Defy all challenges. Microsoft(R) Visual Studio 2008.
>> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> > _______________________________________________
>> > Geoserver-users mailing list
>> > Geoserver-users@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/geoserver-users
>
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Geoserver-users mailing list
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
--
View this message in context: http://www.nabble.com/Odd-behavior-with-ArcSDE-DataStore-tp17495983p17646272.html
Sent from the GeoServer - User mailing list archive at Nabble.com.