[Geoserver-users] ERROR: org.vfny.geoserver.global.ConfigurationException: FeatureTypeInfo

Dear list.

I downloaded geoserver-1.6.4b.exe and started geoserver.
next, I created new feature data set of shapefile using sample states.shp.
and edit feature type definition and schema through FeatureType Editor.
after editing feature type, I clicked submit button.
Of course, I clicked Create New SLD and set it up.
Finally, when I click apply button, some errors occur.

" teststates:states org.vfny.geoserver.global.ConfigurationException: FeatureTypeInfo teststates:::states ignored - Style ‘states_style’ not found!"

But, even though I can find states_style.sld in styles folder, this error takes place.
How to solve this problem?

Best regards,
Jeong.

008-08-13 15:11:58,234 ERROR [geoserver.global] - Could not load style states_style
java.lang.NullPointerException
at org.geotools.filter.ExpressionDOMParser.expression(ExpressionDOMParser.java:342)
at org.geotools.filter.ExpressionDOMParser.parseExpression(ExpressionDOMParser.java:96)
at org.geotools.styling.SLDParser.parseCssParameter(SLDParser.java:1886)
at org.geotools.styling.SLDParser.parseTextSymbolizer(SLDParser.java:1028)
at org.geotools.styling.SLDParser.parseRule(SLDParser.java:889)
at org.geotools.styling.SLDParser.parseFeatureTypeStyle(SLDParser.java:790)
at org.geotools.styling.SLDParser.parseStyle(SLDParser.java:737)
at org.geotools.styling.SLDParser.readDOM(SLDParser.java:282)
at org.geotools.styling.SLDParser.readXML(SLDParser.java:259)
at org.vfny.geoserver.global.Data.loadStyle(Data.java:1412)
at org.vfny.geoserver.global.Data.loadStyles(Data.java:838)
at org.vfny.geoserver.global.Data.load(Data.java:231)
at org.vfny.geoserver.action.UpdateGSAction.updateGeoserver(UpdateGSAction.java:83)
at org.vfny.geoserver.action.UpdateGSAction.execute(UpdateGSAction.java:49)
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:709)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:459)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1054)
at org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
at org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:69)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
at org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:41)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
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.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:358)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:231)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:629)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:453)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:149)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:123)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:141)
at org.mortbay.jetty.Server.handle(Server.java:303)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:452)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:721)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:509)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:349)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:320)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
2008-08-13 15:11:58,250 INFO [geoserver.global] - Loading feature type ‘DS_giant_polygon:::giant_polygon’ (layer 1/14)

hi Jeong,

The problem is that the style is failing to load, so any feature types that reference it will be ignored. You should be able to go into the web admin ui and edit the feature type so that it does not reference the bad style anymore, then restart and you should see the feature type active.

As for why the style is not loading i am not sure. Either there is a style referencing a non-existent file, or there is an error in teh SLD itself. If you include the SLD we should be able to diagnose the problem.

-Justin

Myeong Hun Jeong wrote:

Dear list.
I downloaded geoserver-1.6.4b.exe and started geoserver.
next, I created new feature data set of shapefile using sample states.shp.
and edit feature type definition and schema through FeatureType Editor.
after editing feature type, I clicked submit button.
Of course, I clicked Create New SLD and set it up.
Finally, when I click apply button, some errors occur.
" teststates:states org.vfny.geoserver.global.ConfigurationException: FeatureTypeInfo teststates:::states ignored - Style 'states_style' not found!"
But, even though I can find states_style.sld in styles folder, this error takes place.
How to solve this problem?
Best regards,
Jeong.

java.lang.NullPointerException
at org.geotools.filter.ExpressionDOMParser.expression(ExpressionDOMParser.java:342)
at org.geotools.filter.ExpressionDOMParser.parseExpression(ExpressionDOMParser.java:96)
at org.geotools.styling.SLDParser.parseCssParameter(SLDParser.java:1886)
at org.geotools.styling.SLDParser.parseTextSymbolizer(SLDParser.java:1028)
at org.geotools.styling.SLDParser.parseRule(SLDParser.java:889)
at org.geotools.styling.SLDParser.parseFeatureTypeStyle(SLDParser.java:790)
at org.geotools.styling.SLDParser.parseStyle(SLDParser.java:737)
at org.geotools.styling.SLDParser.readDOM(SLDParser.java:282)
at org.geotools.styling.SLDParser.readXML(SLDParser.java:259)
at org.vfny.geoserver.global.Data.loadStyle(Data.java:1412)
at org.vfny.geoserver.global.Data.loadStyles(Data.java:838)
at org.vfny.geoserver.global.Data.load(Data.java:231)
at org.vfny.geoserver.action.UpdateGSAction.updateGeoserver(UpdateGSAction.java:83)
at org.vfny.geoserver.action.UpdateGSAction.execute(UpdateGSAction.java:49)
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:709)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:459)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1054)
at org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
at org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:69)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
at org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:41)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
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.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:358)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:231)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:629)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:453)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:149)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:123)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:141)
at org.mortbay.jetty.Server.handle(Server.java:303)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:452)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:721)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:509)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:349)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:320)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
2008-08-13 15:11:58,250 INFO [geoserver.global] - Loading feature type 'DS_giant_polygon:::giant_polygon' (layer 1/14)

------------------------------------------------------------------------

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

------------------------------------------------------------------------

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Justin Deoliveira
Software Engineer, OpenGeo
http://opengeo.org

Hello, Geoserver community!

I'm trying to bring up the new GDAL/ImageioExt code to try out serving some legacy MrSid imagery.

Am I right in thinking that this code is included in the 1.7 beta 2 release? I've built GDAL against the LizardTech MrSid SDK and built the Java SWIG wrappers. I'm running the beta 2 release in a Tomcat 6 container with Sun Java 1.6 with "-Djava.library.path=/usr/local/gis/gdal/lib" (which is where I put the GDAL libs and wrapper libs) and an env variable GDAL_DATA="/usr/local/gis/gdal/data" (which is where the GDAL data is).

Everything comes up fine, except in the Tomcat logs I see:

11 Aug 22:17:13 INFO [geotools.factory] - Factory implementations for category GridFormatFactorySpi:
   org.geotools.gce.arcgrid.ArcGridFormatFactory
   org.geotools.gce.geotiff.GeoTiffFormatFactorySpi
   org.geotools.gce.gtopo30.GTopo30FormatFactory
   org.geotools.gce.image.WorldImageFormatFactory
   org.geotools.gce.imagemosaic.ImageMosaicFormatFactory

and nothing else (no other format factories) and in Geoserver's wcs/coverageplugins.do page I only see the usual list (as above).

Am I missing something here? Is there something else I need to do to enable the ImageIOExt-leveraging code?

Thanks for any help!

---
A. Soroka / Digital Research & Scholarship Dep't : Digital Scholarship R&D
the University of Virginia Library

ajs6f ha scritto:

Hello, Geoserver community!

I'm trying to bring up the new GDAL/ImageioExt code to try out serving some legacy MrSid imagery.

Am I right in thinking that this code is included in the 1.7 beta 2 release?

Actually not, the release notes contained that hint, but it's
not correct. It should be included in the next RC1 thought.

I've built GDAL against the LizardTech MrSid SDK and built the Java SWIG wrappers. I'm running the beta 2 release in a Tomcat 6 container with Sun Java 1.6 with "-Djava.library.path=/usr/local/gis/ gdal/lib" (which is where I put the GDAL libs and wrapper libs) and an env variable GDAL_DATA="/usr/local/gis/gdal/data" (which is where the GDAL data is).

Everything comes up fine, except in the Tomcat logs I see:

11 Aug 22:17:13 INFO [geotools.factory] - Factory implementations for category GridFormatFactorySpi:
   org.geotools.gce.arcgrid.ArcGridFormatFactory
   org.geotools.gce.geotiff.GeoTiffFormatFactorySpi
   org.geotools.gce.gtopo30.GTopo30FormatFactory
   org.geotools.gce.image.WorldImageFormatFactory
   org.geotools.gce.imagemosaic.ImageMosaicFormatFactory

and nothing else (no other format factories) and in Geoserver's wcs/ coverageplugins.do page I only see the usual list (as above).

Am I missing something here? Is there something else I need to do to enable the ImageIOExt-leveraging code?

You'll need an extra jar from GeoTools, but I don't have it handy.
Maybe someone else has... or you can just wait for 1.7.0-RC1, it's
getting close.

Cheers
Andrea

Just a guess, here, but the exception is coming from ExpressionDOMParser-- is it possible that your SLD is ill-formed and therefore cannot be loaded even though it exists?

---
A. Soroka / Digital Scholarship Services R & D
the University of Virginia Library

On Aug 13, 2008, at 2:20 AM, Myeong Hun Jeong wrote:

Dear list.

I downloaded geoserver-1.6.4b.exe and started geoserver.
next, I created new feature data set of shapefile using sample states.shp.
and edit feature type definition and schema through FeatureType Editor.
after editing feature type, I clicked submit button.
Of course, I clicked Create New SLD and set it up.
Finally, when I click apply button, some errors occur.

" teststates:states org.vfny.geoserver.global.ConfigurationException: FeatureTypeInfo teststates:::states ignored - Style 'states_style' not found!"

But, even though I can find states_style.sld in styles folder, this error takes place.
How to solve this problem?

Best regards,
Jeong.

008-08-13 15:11:58,234 ERROR [geoserver.global] - Could not load style states_style
java.lang.NullPointerException
at org.geotools.filter.ExpressionDOMParser.expression(ExpressionDOMParser.java:342)
at org.geotools.filter.ExpressionDOMParser.parseExpression(ExpressionDOMParser.java:96)
at org.geotools.styling.SLDParser.parseCssParameter(SLDParser.java:1886)
at org.geotools.styling.SLDParser.parseTextSymbolizer(SLDParser.java:1028)
at org.geotools.styling.SLDParser.parseRule(SLDParser.java:889)
at org.geotools.styling.SLDParser.parseFeatureTypeStyle(SLDParser.java:790)
at org.geotools.styling.SLDParser.parseStyle(SLDParser.java:737)
at org.geotools.styling.SLDParser.readDOM(SLDParser.java:282)
at org.geotools.styling.SLDParser.readXML(SLDParser.java:259)
at org.vfny.geoserver.global.Data.loadStyle(Data.java:1412)
at org.vfny.geoserver.global.Data.loadStyles(Data.java:838)
at org.vfny.geoserver.global.Data.load(Data.java:231)
at org.vfny.geoserver.action.UpdateGSAction.updateGeoserver(UpdateGSAction.java:83)
at org.vfny.geoserver.action.UpdateGSAction.execute(UpdateGSAction.java:49)
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:709)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:459)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1054)
at org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
at org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:69)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
at org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:41)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
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.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:358)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:231)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:629)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:453)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:149)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:123)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:141)
at org.mortbay.jetty.Server.handle(Server.java:303)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:452)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:721)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:509)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:349)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:320)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
2008-08-13 15:11:58,250 INFO [geoserver.global] - Loading feature type 'DS_giant_polygon:::giant_polygon' (layer 1/14)
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

On Aug 13, 2008, at 11:50 AM, Andrea Aime wrote:

ajs6f ha scritto:

Hello, Geoserver community!
I'm trying to bring up the new GDAL/ImageioExt code to try out serving some legacy MrSid imagery.
Am I right in thinking that this code is included in the 1.7 beta 2 release?

Actually not, the release notes contained that hint, but it's
not correct. It should be included in the next RC1 thought.

Ah, thank you. This clarifies the matter.

You'll need an extra jar from GeoTools, but I don't have it handy.
Maybe someone else has... or you can just wait for 1.7.0-RC1, it's
getting close.

No problem-- I snagged them from the:

http://www.geo-solutions.it/libraries/geoserver-1.7.0-SNAPSHOT-war.zip

build.

The Java side of things looks great, now, but I'm getting SIGSEGVs like this one:

# Java VM: Java HotSpot(TM) 64-Bit Server VM (10.0-b22 mixed mode linux-amd64)
# Problematic frame:
# C [libgdal.so+0x28b0a9] GDALGetMetadata+0x9

when I try to set up a MrSid CoverageStore.

I'm assuming that this is an issue to take to GDAL, eh?

If anyone else has been down this road and can offer any advice, it would be much appreciated.

Thanks for your help, Andrea!

---
A. Soroka / Digital Scholarship Services R & D
the University of Virginia Library

On Wed, Aug 13, 2008 at 6:56 PM, ajs6f <ajs6f@anonymised.com> wrote:

On Aug 13, 2008, at 11:50 AM, Andrea Aime wrote:

ajs6f ha scritto:

Hello, Geoserver community!
I'm trying to bring up the new GDAL/ImageioExt code to try out
serving some legacy MrSid imagery.
Am I right in thinking that this code is included in the 1.7 beta
2 release?

Actually not, the release notes contained that hint, but it's
not correct. It should be included in the next RC1 thought.

Ah, thank you. This clarifies the matter.

You'll need an extra jar from GeoTools, but I don't have it handy.
Maybe someone else has... or you can just wait for 1.7.0-RC1, it's
getting close.

No problem-- I snagged them from the:

http://www.geo-solutions.it/libraries/geoserver-1.7.0-SNAPSHOT-war.zip

build.

The Java side of things looks great, now, but I'm getting SIGSEGVs
like this one:

# Java VM: Java HotSpot(TM) 64-Bit Server VM (10.0-b22 mixed mode
linux-amd64)
# Problematic frame:
# C [libgdal.so+0x28b0a9] GDALGetMetadata+0x9

when I try to set up a MrSid CoverageStore.

I'm assuming that this is an issue to take to GDAL, eh?

The binaries you are using where built on a 32 bit linux machine. I ma
not sure they would work on a 64 bit machine.
Anyway, could yuo please provide some more info about the following
items in order to help you out:
-target hw platform
-procedure you followed for the installation

ciao,
Simone.

If anyone else has been down this road and can offer any advice, it
would be much appreciated.

Thanks for your help, Andrea!

---
A. Soroka / Digital Scholarship Services R & D
the University of Virginia Library

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it

-------------------------------------------------------

On Aug 13, 2008, at 1:48 PM, Simone Giannecchini wrote:
The binaries you are using where built on a 32 bit linux machine. I ma
not sure they would work on a 64 bit machine.
Anyway, could yuo please provide some more info about the following
items in order to help you out:
-target hw platform
-procedure you followed for the installation

ciao,
Simone.

Very happily-- thanks for your help!

If you are referring to the GDAL binaries (and wrappers), they were built on this machine. The machine in question is a Fedora Core 8 VMWare virtual instance with 2 64-bit cores (2.6.24.4-64.fc8 #1 SMP x86_64). I'm using Tomcat6 yum'd from Jpackage.org running with HotSpot Java 1.6.0_06-b02 with the JAI native libs.

I used the LizardTech SDK Geo_DSDK-7.0.0.2167 for linux x86-64 and gcc4.1.

I pulled the GDAL SVN trunk and then used a very minimal config for building it, turning off everything I could (see end of email for config output). I used the trunk instead of a stable version because LizardTech has made changes to their version 7 SDK that required the GDAL folks to make changes to their code which is most easily found in the trunk. Then I built the SWIG Java wrappers as per the instructions in:

http://www.geo-solutions.it/doc/ImageioExt-SetupGuide.pdf

I provided Tomcat with the aforementioned flags for Java startup pointing to the GDAL libs and data directory. I pulled the jars that Andrea mentioned from the geo-solutions.it GeoServer 1.7 snapshot war build. Essentially I pulled everything that was in that war's WEB-INF/lib that wasn't in the beta 2 war that I got from Sourceforge.

Starting up Tomcat, I saw:

11 Aug 23:25:58 INFO [geotools.factory] - Factory implementations for category GridFormatFactorySpi:
   org.geotools.gce.arcgrid.ArcGridFormatFactory
   org.geotools.gce.geotiff.GeoTiffFormatFactorySpi
   org.geotools.gce.gtopo30.GTopo30FormatFactory
   org.geotools.gce.image.WorldImageFormatFactory
   org.geotools.coverageio.gdal.mrsid.MrSIDFormatFactory
   org.geotools.coverageio.gdal.jp2kak.JP2KFormatFactory
   org.geotools.coverageio.gdal.jp2mrsid.JP2MrSIDFormatFactory
   org.geotools.coverageio.gdal.dted.DTEDFormatFactory
   org.geotools.coverageio.gdal.erdasimg.ErdasImgFormatFactory
   org.geotools.coverageio.gdal.nitf.NITFFormatFactory
   org.geotools.gce.imagemosaic.ImageMosaicFormatFactory

which made me very happy, but when I went to try to create a CoverageStore, I was able to fill out the appropriate form (with my file location) and when I submitted, I got:

form connection params { }
11 Aug 23:27:29 INFO [geotools.factory] - Factory implementations for category GridCoverageFactory:
   org.geotools.coverage.grid.GridCoverageFactory
#
# An unexpected error has been detected by Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00002aaafbaaf0a9, pid=4000, tid=1096018256
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (10.0-b22 mixed mode linux-amd64)
# Problematic frame:
# C [libgdal.so+0x28b0a9] GDALGetMetadata+0x9

etc.

The MrSids are okay, and running gdalinfo or gdal_translate on them produces good results.

Any thoughts? Should I try building those GeoTools jars on this machine?

Thanks again for the help! Being able to use GDAL for this purpose is a wonderful idea and will really open up some great possibilities for GeoServer, so thanks for doing this work.

---
A. Soroka / Digital Scholarship Services R & D
the University of Virginia Library

On Aug 13, 2008, at 1:48 PM, Simone Giannecchini wrote:

On Wed, Aug 13, 2008 at 6:56 PM, ajs6f <ajs6f@anonymised.com> wrote:

On Aug 13, 2008, at 11:50 AM, Andrea Aime wrote:

ajs6f ha scritto:

Hello, Geoserver community!
I'm trying to bring up the new GDAL/ImageioExt code to try out
serving some legacy MrSid imagery.
Am I right in thinking that this code is included in the 1.7 beta
2 release?

Actually not, the release notes contained that hint, but it's
not correct. It should be included in the next RC1 thought.

Ah, thank you. This clarifies the matter.

You'll need an extra jar from GeoTools, but I don't have it handy.
Maybe someone else has... or you can just wait for 1.7.0-RC1, it's
getting close.

No problem-- I snagged them from the:

http://www.geo-solutions.it/libraries/geoserver-1.7.0-SNAPSHOT-war.zip

build.

The Java side of things looks great, now, but I'm getting SIGSEGVs
like this one:

# Java VM: Java HotSpot(TM) 64-Bit Server VM (10.0-b22 mixed mode
linux-amd64)
# Problematic frame:
# C [libgdal.so+0x28b0a9] GDALGetMetadata+0x9

when I try to set up a MrSid CoverageStore.

I'm assuming that this is an issue to take to GDAL, eh?

The binaries you are using where built on a 32 bit linux machine. I ma
not sure they would work on a 64 bit machine.
Anyway, could yuo please provide some more info about the following
items in order to help you out:
-target hw platform
-procedure you followed for the installation

ciao,
Simone.

If anyone else has been down this road and can offer any advice, it
would be much appreciated.

Thanks for your help, Andrea!

---
A. Soroka / Digital Scholarship Services R & D
the University of Virginia Library

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it

-------------------------------------------------------

config.log (60.3 KB)

Ciao,
please read below...

On Wed, Aug 13, 2008 at 8:08 PM, ajs6f <ajs6f@anonymised.com> wrote:

On Aug 13, 2008, at 1:48 PM, Simone Giannecchini wrote:
The binaries you are using where built on a 32 bit linux machine. I ma
not sure they would work on a 64 bit machine.
Anyway, could yuo please provide some more info about the following
items in order to help you out:
-target hw platform
-procedure you followed for the installation

ciao,
Simone.

Very happily-- thanks for your help!

If you are referring to the GDAL binaries (and wrappers), they were built on
this machine. The machine in question is a Fedora Core 8 VMWare virtual
instance with 2 64-bit cores (2.6.24.4-64.fc8 #1 SMP x86_64). I'm using
Tomcat6 yum'd from Jpackage.org running with HotSpot Java 1.6.0_06-b02 with
the JAI native libs.

I would assume that you followed the ImageIO-ext instructions that we
have put on the project website. We have slightly customized the gdal
java bindings...

I used the LizardTech SDK Geo_DSDK-7.0.0.2167 for linux x86-64 and gcc4.1.

Ah-ah, this means troubles :-). There has been a thread recently in
the imageio-ext devel list on how to build gdal with support for mrsid
using the sdk 7.0.
I might suggest you to refer to it. For the moment we are still
providing binaries as well as supporting sdk 6.0. We should try and
switch over as soon as gdal 1.4.5 comes out.

Tomorrow, I'll ask daniele (the colleague of mine who is mainly
responsible for imageio-ext) to provide a bit more details on how to
tackle such an issue.

Ciao,
Simone.

I pulled the GDAL SVN trunk and then used a very minimal config for building
it, turning off everything I could (see end of email for config output). I
used the trunk instead of a stable version because LizardTech has made
changes to their version 7 SDK that required the GDAL folks to make changes
to their code which is most easily found in the trunk. Then I built the SWIG
Java wrappers as per the instructions in:

http://www.geo-solutions.it/doc/ImageioExt-SetupGuide.pdf

I provided Tomcat with the aforementioned flags for Java startup pointing to
the GDAL libs and data directory. I pulled the jars that Andrea mentioned
from the geo-solutions.it GeoServer 1.7 snapshot war build. Essentially I
pulled everything that was in that war's WEB-INF/lib that wasn't in the beta
2 war that I got from Sourceforge.

Starting up Tomcat, I saw:

11 Aug 23:25:58 INFO [geotools.factory] - Factory implementations for
category GridFormatFactorySpi:
org.geotools.gce.arcgrid.ArcGridFormatFactory
org.geotools.gce.geotiff.GeoTiffFormatFactorySpi
org.geotools.gce.gtopo30.GTopo30FormatFactory
org.geotools.gce.image.WorldImageFormatFactory
org.geotools.coverageio.gdal.mrsid.MrSIDFormatFactory
org.geotools.coverageio.gdal.jp2kak.JP2KFormatFactory
org.geotools.coverageio.gdal.jp2mrsid.JP2MrSIDFormatFactory
org.geotools.coverageio.gdal.dted.DTEDFormatFactory
org.geotools.coverageio.gdal.erdasimg.ErdasImgFormatFactory
org.geotools.coverageio.gdal.nitf.NITFFormatFactory
org.geotools.gce.imagemosaic.ImageMosaicFormatFactory

which made me very happy, but when I went to try to create a CoverageStore,
I was able to fill out the appropriate form (with my file location) and when
I submitted, I got:

form connection params { }
11 Aug 23:27:29 INFO [geotools.factory] - Factory implementations for
category GridCoverageFactory:
org.geotools.coverage.grid.GridCoverageFactory
#
# An unexpected error has been detected by Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00002aaafbaaf0a9, pid=4000, tid=1096018256
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (10.0-b22 mixed mode
linux-amd64)
# Problematic frame:
# C [libgdal.so+0x28b0a9] GDALGetMetadata+0x9

etc.

The MrSids are okay, and running gdalinfo or gdal_translate on them produces
good results.

Any thoughts? Should I try building those GeoTools jars on this machine?

Thanks again for the help! Being able to use GDAL for this purpose is a
wonderful idea and will really open up some great possibilities for
GeoServer, so thanks for doing this work.

---
A. Soroka / Digital Scholarship Services R & D
the University of Virginia Library

On Aug 13, 2008, at 1:48 PM, Simone Giannecchini wrote:

On Wed, Aug 13, 2008 at 6:56 PM, ajs6f <ajs6f@anonymised.com> wrote:

On Aug 13, 2008, at 11:50 AM, Andrea Aime wrote:

ajs6f ha scritto:

Hello, Geoserver community!
I'm trying to bring up the new GDAL/ImageioExt code to try out
serving some legacy MrSid imagery.
Am I right in thinking that this code is included in the 1.7 beta
2 release?

Actually not, the release notes contained that hint, but it's
not correct. It should be included in the next RC1 thought.

Ah, thank you. This clarifies the matter.

You'll need an extra jar from GeoTools, but I don't have it handy.
Maybe someone else has... or you can just wait for 1.7.0-RC1, it's
getting close.

No problem-- I snagged them from the:

http://www.geo-solutions.it/libraries/geoserver-1.7.0-SNAPSHOT-war.zip

build.

The Java side of things looks great, now, but I'm getting SIGSEGVs
like this one:

# Java VM: Java HotSpot(TM) 64-Bit Server VM (10.0-b22 mixed mode
linux-amd64)
# Problematic frame:
# C [libgdal.so+0x28b0a9] GDALGetMetadata+0x9

when I try to set up a MrSid CoverageStore.

I'm assuming that this is an issue to take to GDAL, eh?

The binaries you are using where built on a 32 bit linux machine. I ma
not sure they would work on a 64 bit machine.
Anyway, could yuo please provide some more info about the following
items in order to help you out:
-target hw platform
-procedure you followed for the installation

ciao,
Simone.

If anyone else has been down this road and can offer any advice, it
would be much appreciated.

Thanks for your help, Andrea!

---
A. Soroka / Digital Scholarship Services R & D
the University of Virginia Library

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it

-------------------------------------------------------

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it

-------------------------------------------------------

On Aug 13, 2008, at 8:12 PM, Simone Giannecchini wrote:

I would assume that you followed the ImageIO-ext instructions that we
have put on the project website. We have slightly customized the gdal
java bindings...

I'm glad you raised that point, because I had forgotten it: the instructions refer to:

#Flags to build optimized relese version
CXX_OPTFLAGS = O1
C_OPTFLAGS = O1

in GDALmake.opt, but for the life of me, I couldn't find those variables set anywhere in that file. (Perhaps I should reiterate that I am using the GDAL trunk source, not the stable version that is recommended by the imageio-ext instructions.) Perhaps I should have set them anew?

I used the LizardTech SDK Geo_DSDK-7.0.0.2167 for linux x86-64 and gcc4.1.

Ah-ah, this means troubles :-). There has been a thread recently in
the imageio-ext devel list on how to build gdal with support for mrsid
using the sdk 7.0. I might suggest you to refer to it. For the moment we are still
providing binaries as well as supporting sdk 6.0. We should try and
switch over as soon as gdal 1.4.5 comes out.

Ah-- now we find the worst problem-- I haven't subscribed to that list, so I'm less informed than I should be. {grin} I'll rectify that mistake promptly.

Tomorrow, I'll ask daniele (the colleague of mine who is mainly
responsible for imageio-ext) to provide a bit more details on how to
tackle such an issue.

Thank you so much! I hope I'll be able to contribute something useful towards this issue with LizardTech SDK 7.

Meanwhile, hopefully this conversation will have informed the geoserver users to stick with LizardTech SDK 6 for now. {grin}

---
A. Soroka / Digital Scholarship Services R & D
the University of Virginia Library

I pulled the GDAL SVN trunk and then used a very minimal config for building
it, turning off everything I could (see end of email for config output). I
used the trunk instead of a stable version because LizardTech has made
changes to their version 7 SDK that required the GDAL folks to make changes
to their code which is most easily found in the trunk. Then I built the SWIG
Java wrappers as per the instructions in:

http://www.geo-solutions.it/doc/ImageioExt-SetupGuide.pdf

I provided Tomcat with the aforementioned flags for Java startup pointing to
the GDAL libs and data directory. I pulled the jars that Andrea mentioned
from the geo-solutions.it GeoServer 1.7 snapshot war build. Essentially I
pulled everything that was in that war's WEB-INF/lib that wasn't in the beta
2 war that I got from Sourceforge.

Starting up Tomcat, I saw:

11 Aug 23:25:58 INFO [geotools.factory] - Factory implementations for
category GridFormatFactorySpi:
org.geotools.gce.arcgrid.ArcGridFormatFactory
org.geotools.gce.geotiff.GeoTiffFormatFactorySpi
org.geotools.gce.gtopo30.GTopo30FormatFactory
org.geotools.gce.image.WorldImageFormatFactory
org.geotools.coverageio.gdal.mrsid.MrSIDFormatFactory
org.geotools.coverageio.gdal.jp2kak.JP2KFormatFactory
org.geotools.coverageio.gdal.jp2mrsid.JP2MrSIDFormatFactory
org.geotools.coverageio.gdal.dted.DTEDFormatFactory
org.geotools.coverageio.gdal.erdasimg.ErdasImgFormatFactory
org.geotools.coverageio.gdal.nitf.NITFFormatFactory
org.geotools.gce.imagemosaic.ImageMosaicFormatFactory

which made me very happy, but when I went to try to create a CoverageStore,
I was able to fill out the appropriate form (with my file location) and when
I submitted, I got:

form connection params { }
11 Aug 23:27:29 INFO [geotools.factory] - Factory implementations for
category GridCoverageFactory:
org.geotools.coverage.grid.GridCoverageFactory
#
# An unexpected error has been detected by Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00002aaafbaaf0a9, pid=4000, tid=1096018256
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (10.0-b22 mixed mode
linux-amd64)
# Problematic frame:
# C [libgdal.so+0x28b0a9] GDALGetMetadata+0x9

etc.

The MrSids are okay, and running gdalinfo or gdal_translate on them produces
good results.

Any thoughts? Should I try building those GeoTools jars on this machine?

Thanks again for the help! Being able to use GDAL for this purpose is a
wonderful idea and will really open up some great possibilities for
GeoServer, so thanks for doing this work.

---
A. Soroka / Digital Scholarship Services R & D
the University of Virginia Library

On Aug 13, 2008, at 1:48 PM, Simone Giannecchini wrote:

On Wed, Aug 13, 2008 at 6:56 PM, ajs6f <ajs6f@anonymised.com> wrote:

On Aug 13, 2008, at 11:50 AM, Andrea Aime wrote:

ajs6f ha scritto:

Hello, Geoserver community!
I'm trying to bring up the new GDAL/ImageioExt code to try out
serving some legacy MrSid imagery.
Am I right in thinking that this code is included in the 1.7 beta
2 release?

Actually not, the release notes contained that hint, but it's
not correct. It should be included in the next RC1 thought.

Ah, thank you. This clarifies the matter.

You'll need an extra jar from GeoTools, but I don't have it handy.
Maybe someone else has... or you can just wait for 1.7.0-RC1, it's
getting close.

No problem-- I snagged them from the:

http://www.geo-solutions.it/libraries/geoserver-1.7.0-SNAPSHOT-war.zip

build.

The Java side of things looks great, now, but I'm getting SIGSEGVs
like this one:

# Java VM: Java HotSpot(TM) 64-Bit Server VM (10.0-b22 mixed mode
linux-amd64)
# Problematic frame:
# C [libgdal.so+0x28b0a9] GDALGetMetadata+0x9

when I try to set up a MrSid CoverageStore.

I'm assuming that this is an issue to take to GDAL, eh?

The binaries you are using where built on a 32 bit linux machine. I ma
not sure they would work on a 64 bit machine.
Anyway, could yuo please provide some more info about the following
items in order to help you out:
-target hw platform
-procedure you followed for the installation

ciao,
Simone.

If anyone else has been down this road and can offer any advice, it
would be much appreciated.

Thanks for your help, Andrea!

---
A. Soroka / Digital Scholarship Services R & D
the University of Virginia Library

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it

-------------------------------------------------------

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it

-------------------------------------------------------

Hi Jeong,

(please keep replies on the list :))

The problem with your SLD is the <ogc:PropertyName> on line 27. It contains no text inside of it which is causing the SLD parser to choke. While the parser should handle this situation more gracefully since technically the SLD is still valid, you can fix this by specifying the attribute to label by. Something like:

<ogc:PropertyName>NAME</ogc:PropertyName>

-Justin

Myeong Hun Jeong wrote:

Thank you. Justin.
I tested Geoserver serval times and found that the reason of the error is an error in the SLD.
But, I can't understand why there are some errors in SLD because the SLD file was created by Geoserver UI(by clicking Create new SLD)
So, If I change another style in Style Editor, It's run well.
Why this problem take place? and If I edit a SLD file manually, what is a good way to edit it?
are ther some auto generating SLD software?
I attatched bml_bldg_as_style.sld file created by Geoserver UI.
Best regards,
Jeong.

2008/8/14 Justin Deoliveira <jdeolive@anonymised.com <mailto:jdeolive@anonymised.com>>

    hi Jeong,

    The problem is that the style is failing to load, so any feature
    types that reference it will be ignored. You should be able to go
    into the web admin ui and edit the feature type so that it does not
    reference the bad style anymore, then restart and you should see the
    feature type active.

    As for why the style is not loading i am not sure. Either there is a
    style referencing a non-existent file, or there is an error in teh
    SLD itself. If you include the SLD we should be able to diagnose the
    problem.

    -Justin

    Myeong Hun Jeong wrote:

        Dear list.
         I downloaded geoserver-1.6.4b.exe and started geoserver.
        next, I created new feature data set of shapefile using sample
        states.shp.
        and edit feature type definition and schema through FeatureType
        Editor.
        after editing feature type, I clicked submit button.
        Of course, I clicked Create New SLD and set it up.
        Finally, when I click apply button, some errors occur.
         " teststates:states
        org.vfny.geoserver.global.ConfigurationException:
        FeatureTypeInfo teststates:::states ignored - Style
        'states_style' not found!"
         But, even though I can find states_style.sld in styles folder,
        this error takes place.
        How to solve this problem?
         Best regards,
        Jeong.
          008-08-13 15:11:58,234 ERROR [geoserver.global] - Could not
        load style states_style
        java.lang.NullPointerException
         at
        org.geotools.filter.ExpressionDOMParser.expression(ExpressionDOMParser.java:342)
         at
        org.geotools.filter.ExpressionDOMParser.parseExpression(ExpressionDOMParser.java:96)
         at
        org.geotools.styling.SLDParser.parseCssParameter(SLDParser.java:1886)
         at
        org.geotools.styling.SLDParser.parseTextSymbolizer(SLDParser.java:1028)
         at org.geotools.styling.SLDParser.parseRule(SLDParser.java:889)
         at
        org.geotools.styling.SLDParser.parseFeatureTypeStyle(SLDParser.java:790)
         at org.geotools.styling.SLDParser.parseStyle(SLDParser.java:737)
         at org.geotools.styling.SLDParser.readDOM(SLDParser.java:282)
         at org.geotools.styling.SLDParser.readXML(SLDParser.java:259)
         at org.vfny.geoserver.global.Data.loadStyle(Data.java:1412)
         at org.vfny.geoserver.global.Data.loadStyles(Data.java:838)
         at org.vfny.geoserver.global.Data.load(Data.java:231)
         at
        org.vfny.geoserver.action.UpdateGSAction.updateGeoserver(UpdateGSAction.java:83)
         at
        org.vfny.geoserver.action.UpdateGSAction.execute(UpdateGSAction.java:49)
         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:709)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
         at
        org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:459)
         at
        org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1054)
         at
        org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
         at
        org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
         at
        org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:69)
         at
        org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
         at org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:41)
         at
        org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
         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.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
         at
        org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:358)
         at
        org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:231)
         at
        org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:629)
         at
        org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:453)
         at
        org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:149)
         at
        org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:123)
         at
        org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:141)
         at org.mortbay.jetty.Server.handle(Server.java:303)
         at
        org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:452)
         at
        org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:721)
         at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:509)
         at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
         at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:349)
         at
        org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:320)
         at
        org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
        2008-08-13 15:11:58,250 INFO [geoserver.global] - Loading
        feature type 'DS_giant_polygon:::giant_polygon' (layer 1/14)

        ------------------------------------------------------------------------

        -------------------------------------------------------------------------
        This SF.Net email is sponsored by the Moblin Your Move
        Developer's challenge
        Build the coolest Linux based applications with Moblin SDK & win
        great prizes
        Grand prize is a trip for two to an Open Source event anywhere
        in the world
        http://moblin-contest.org/redirect.php?banner_id=100&url=/
        <http://moblin-contest.org/redirect.php?banner_id=100&url=/&gt;

        ------------------------------------------------------------------------

        _______________________________________________
        Geoserver-users mailing list
        Geoserver-users@lists.sourceforge.net
        <mailto:Geoserver-users@lists.sourceforge.net>
        https://lists.sourceforge.net/lists/listinfo/geoserver-users

    -- Justin Deoliveira
    Software Engineer, OpenGeo
    http://opengeo.org/&gt;

--
Justin Deoliveira
Software Engineer, OpenGeo
http://opengeo.org

Hi,
Several months ago, during our work of getting GDAL working under Linux from Java, we have noticed that, after building GDAL without setting those C??_FLAGS when generating JAVA Bindings, JVM crashes with sigsegv errors. I will checkout GDAL 1.5.x and I will look for them.

Anyway I need some more info in order to better know your procedure.
Which jar containing the generated java bindings are you using? (This jar contains the native calls to the libgdaljni.so)

You said that you copied all the “new” jars from the WEB-INF/lib folder. Therefore I guess you have also copied the imageio-ext-gdal-1.0-SNAPSHOT.jar.
This file is the gdal.jar produced by SWIG when generating java bindings (It has been renamed like this to know the proper imageio-ext / GDAL version). Since imageio-ext is actually built against gdal 1.4.4, the imageio-ext libs contained in that geoserver release leverage on a GDAL 1.4.4 version, unless you have replaced our imageio-ext-gdal-1.0-SNAPSHOT.jar with your SWIG’s generated gdal.jar relying on a GDAL 1.5.x version.
However, I have noticed in the past (more info on the imageio-ext dev ML archive) that the SWIG Bindings produced by version 1.5.X are slightly different with respect to the ones coming from 1.4.4. Therefore, in that circumstance I have created an unofficial small patch for an user which needed to work with GDAL 1.5 and MrSID 7 to use it with our ImageIO-ext project.

Let me know.

Best Regards,
Daniele

On Thu, Aug 14, 2008 at 2:28 AM, ajs6f <ajs6f@anonymised.com> wrote:

On Aug 13, 2008, at 8:12 PM, Simone Giannecchini wrote:

I would assume that you followed the ImageIO-ext instructions that we
have put on the project website. We have slightly customized the gdal
java bindings…

I’m glad you raised that point, because I had forgotten it: the
instructions refer to:

#Flags to build optimized relese version
CXX_OPTFLAGS = O1
C_OPTFLAGS = O1

in GDALmake.opt, but for the life of me, I couldn’t find those
variables set anywhere in that file. (Perhaps I should reiterate that
I am using the GDAL trunk source, not the stable version that is
recommended by the imageio-ext instructions.) Perhaps I should have
set them anew?

I used the LizardTech SDK Geo_DSDK-7.0.0.2167 for linux x86-64 and
gcc4.1.
Ah-ah, this means troubles :-). There has been a thread recently in
the imageio-ext devel list on how to build gdal with support for mrsid
using the sdk 7.0. I might suggest you to refer to it. For the
moment we are still
providing binaries as well as supporting sdk 6.0. We should try and
switch over as soon as gdal 1.4.5 comes out.

Ah-- now we find the worst problem-- I haven’t subscribed to that
list, so I’m less informed than I should be. {grin} I’ll rectify that
mistake promptly.

Tomorrow, I’ll ask daniele (the colleague of mine who is mainly
responsible for imageio-ext) to provide a bit more details on how to
tackle such an issue.

Thank you so much! I hope I’ll be able to contribute something useful
towards this issue with LizardTech SDK 7.

Meanwhile, hopefully this conversation will have informed the
geoserver users to stick with LizardTech SDK 6 for now. {grin}


A. Soroka / Digital Scholarship Services R & D
the University of Virginia Library

I pulled the GDAL SVN trunk and then used a very minimal config for
building
it, turning off everything I could (see end of email for config
output). I
used the trunk instead of a stable version because LizardTech has
made
changes to their version 7 SDK that required the GDAL folks to make
changes
to their code which is most easily found in the trunk. Then I built
the SWIG
Java wrappers as per the instructions in:

http://www.geo-solutions.it/doc/ImageioExt-SetupGuide.pdf

I provided Tomcat with the aforementioned flags for Java startup
pointing to
the GDAL libs and data directory. I pulled the jars that Andrea
mentioned
from the geo-solutions.it GeoServer 1.7 snapshot war build.
Essentially I
pulled everything that was in that war’s WEB-INF/lib that wasn’t in
the beta
2 war that I got from Sourceforge.

Starting up Tomcat, I saw:

11 Aug 23:25:58 INFO [geotools.factory] - Factory implementations for
category GridFormatFactorySpi:
org.geotools.gce.arcgrid.ArcGridFormatFactory
org.geotools.gce.geotiff.GeoTiffFormatFactorySpi
org.geotools.gce.gtopo30.GTopo30FormatFactory
org.geotools.gce.image.WorldImageFormatFactory
org.geotools.coverageio.gdal.mrsid.MrSIDFormatFactory
org.geotools.coverageio.gdal.jp2kak.JP2KFormatFactory
org.geotools.coverageio.gdal.jp2mrsid.JP2MrSIDFormatFactory
org.geotools.coverageio.gdal.dted.DTEDFormatFactory
org.geotools.coverageio.gdal.erdasimg.ErdasImgFormatFactory
org.geotools.coverageio.gdal.nitf.NITFFormatFactory
org.geotools.gce.imagemosaic.ImageMosaicFormatFactory

which made me very happy, but when I went to try to create a
CoverageStore,
I was able to fill out the appropriate form (with my file location)
and when
I submitted, I got:

form connection params { }
11 Aug 23:27:29 INFO [geotools.factory] - Factory implementations for
category GridCoverageFactory:
org.geotools.coverage.grid.GridCoverageFactory

An unexpected error has been detected by Java Runtime Environment:

SIGSEGV (0xb) at pc=0x00002aaafbaaf0a9, pid=4000, tid=1096018256

Java VM: Java HotSpot™ 64-Bit Server VM (10.0-b22 mixed mode

linux-amd64)

Problematic frame:

C [libgdal.so+0x28b0a9] GDALGetMetadata+0x9

etc.

The MrSids are okay, and running gdalinfo or gdal_translate on them
produces
good results.

Any thoughts? Should I try building those GeoTools jars on this
machine?

Thanks again for the help! Being able to use GDAL for this purpose
is a
wonderful idea and will really open up some great possibilities for
GeoServer, so thanks for doing this work.


A. Soroka / Digital Scholarship Services R & D
the University of Virginia Library

On Aug 13, 2008, at 1:48 PM, Simone Giannecchini wrote:

On Wed, Aug 13, 2008 at 6:56 PM, ajs6f <ajs6f@anonymised.com> wrote:

On Aug 13, 2008, at 11:50 AM, Andrea Aime wrote:

ajs6f ha scritto:

Hello, Geoserver community!
I’m trying to bring up the new GDAL/ImageioExt code to try out
serving some legacy MrSid imagery.
Am I right in thinking that this code is included in the 1.7 beta
2 release?

Actually not, the release notes contained that hint, but it’s
not correct. It should be included in the next RC1 thought.

Ah, thank you. This clarifies the matter.

You’ll need an extra jar from GeoTools, but I don’t have it handy.
Maybe someone else has… or you can just wait for 1.7.0-RC1, it’s
getting close.

No problem-- I snagged them from the:

http://www.geo-solutions.it/libraries/geoserver-1.7.0-SNAPSHOT-war.zip

build.

The Java side of things looks great, now, but I’m getting SIGSEGVs
like this one:

Java VM: Java HotSpot™ 64-Bit Server VM (10.0-b22 mixed mode

linux-amd64)

Problematic frame:

C [libgdal.so+0x28b0a9] GDALGetMetadata+0x9

when I try to set up a MrSid CoverageStore.

I’m assuming that this is an issue to take to GDAL, eh?

The binaries you are using where built on a 32 bit linux machine.
I ma
not sure they would work on a 64 bit machine.
Anyway, could yuo please provide some more info about the following
items in order to help you out:
-target hw platform
-procedure you followed for the installation

ciao,
Simone.

If anyone else has been down this road and can offer any advice, it
would be much appreciated.

Thanks for your help, Andrea!


A. Soroka / Digital Scholarship Services R & D
the University of Virginia Library


This SF.Net email is sponsored by the Moblin Your Move Developer’s
challenge
Build the coolest Linux based applications with Moblin SDK & win
great
prizes
Grand prize is a trip for two to an Open Source event anywhere in
the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/


Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it



This SF.Net email is sponsored by the Moblin Your Move Developer’s
challenge
Build the coolest Linux based applications with Moblin SDK & win
great
prizes
Grand prize is a trip for two to an Open Source event anywhere in
the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/


Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it



This SF.Net email is sponsored by the Moblin Your Move Developer’s challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/


Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Eng. Daniele Romagnoli
Software Engineer

GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 328 0559267

http://www.geo-solutions.it


Thanks so much for helping-- see my inline responses below.
---
A. Soroka / Digital Scholarship Services R & D
the University of Virginia Library

On Aug 14, 2008, at 6:08 AM, Daniele Romagnoli wrote:

Several months ago, during our work of getting GDAL working under Linux from Java, we have noticed that, after building GDAL without setting those C??_FLAGS when generating JAVA Bindings, JVM crashes with sigsegv errors. I will checkout GDAL 1.5.x and I will look for them.
Anyway I need some more info in order to better know your procedure.
Which jar containing the generated java bindings are you using? (This jar contains the native calls to the libgdaljni.so)

I'm assuming that this is the imageio-ext-gdal-1.0-SNAPSHOT.jar that I pulled from the 1.7-SNAPSHOT war. I did not use the gdal.jar generated by my GDAL SWIG build because I did not correctly understand the need to-- see below for my latest adventure trying to correct that mistake.

You said that you copied all the "new" jars from the WEB-INF/lib folder. Therefore I guess you have also copied the imageio-ext-gdal-1.0-SNAPSHOT.jar.

True, although I now understand why that was a mistake, as you describe below.

This file is the gdal.jar produced by SWIG when generating java bindings (It has been renamed like this to know the proper imageio-ext / GDAL version). Since imageio-ext is actually built against gdal 1.4.4, the imageio-ext libs contained in that geoserver release leverage on a GDAL 1.4.4 version, unless you have replaced our imageio-ext-gdal-1.0-SNAPSHOT.jar with your SWIG's generated gdal.jar relying on a GDAL 1.5.x version. However, I have noticed in the past (more info on the imageio-ext dev ML archive) that the SWIG Bindings produced by version 1.5.X are slightly different with respect to the ones coming from 1.4.4.

I think I understand your point here. In an effort to correct this problem, I just tried to rebuild my GDAL (just as I had done before) in order to use the SWIG-generated jar associated with my (trunk) build of GDAL. Surprisingly, I got a:

[slab@anonymised.com java]$ make build
...
/bin/sh /usr/local/gis/gdal/src/gdal/libtool --mode=link g++ -shared /usr/local/gis/gdal/src/gdal/libgdal.la gdal_wrap.o -o libgdaljni.so
libtool: link: g++ gdal_wrap.o -o .libs/libgdaljni.so /usr/local/gis/gdal/src/gdal/.libs/libgdal.so -L/usr/local/gis/gdal/src/mrsid/Geo_DSDK-7.0.0.2167//lib/Release -L/usr/local/gis/gdal/src/mrsid/Geo_DSDK-7.0.0.2167//3rd-party/lib/Release -lrt -ldl -lltidsdk -lpthread
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: ld returned 1 exit status
make: *** [libgdaljni.so] Error 1

which is a most unexpectedly basic error to receive in this context. I'm going to continue trying, perhaps rolling back my GDAL source to the latest version that includes corrections for the MrSID version 7 SDK, which I think should be 1.5. Since I have once already been able to build the SWIG Java jar using the trunk code, I should think I can do it again. Of course, I would happily dispense with the trunk code and use 1.5 with your patch (mentioned below).

Therefore, in that circumstance I have created an unofficial small patch for an user which needed to work with GDAL 1.5 and MrSID 7 to use it with our ImageIO-ext project.
Let me know.

I would be -extremely- grateful for that patch. It seems like that's exactly what I need to get all the pieces together.

---
A. Soroka / Digital Scholarship Services R & D
the University of Virginia Library

On Thu, Aug 14, 2008 at 2:28 AM, ajs6f <ajs6f@anonymised.com> wrote:
On Aug 13, 2008, at 8:12 PM, Simone Giannecchini wrote:
> I would assume that you followed the ImageIO-ext instructions that we
> have put on the project website. We have slightly customized the gdal
> java bindings...

I'm glad you raised that point, because I had forgotten it: the
instructions refer to:

#Flags to build optimized relese version
CXX_OPTFLAGS = O1
C_OPTFLAGS = O1

in GDALmake.opt, but for the life of me, I couldn't find those
variables set anywhere in that file. (Perhaps I should reiterate that
I am using the GDAL trunk source, not the stable version that is
recommended by the imageio-ext instructions.) Perhaps I should have
set them anew?

>> I used the LizardTech SDK Geo_DSDK-7.0.0.2167 for linux x86-64 and
>> gcc4.1.
> Ah-ah, this means troubles :-). There has been a thread recently in
> the imageio-ext devel list on how to build gdal with support for mrsid
> using the sdk 7.0. I might suggest you to refer to it. For the
> moment we are still
> providing binaries as well as supporting sdk 6.0. We should try and
> switch over as soon as gdal 1.4.5 comes out.

Ah-- now we find the worst problem-- I haven't subscribed to that
list, so I'm less informed than I should be. {grin} I'll rectify that
mistake promptly.

> Tomorrow, I'll ask daniele (the colleague of mine who is mainly
> responsible for imageio-ext) to provide a bit more details on how to
> tackle such an issue.

Thank you so much! I hope I'll be able to contribute something useful
towards this issue with LizardTech SDK 7.

Meanwhile, hopefully this conversation will have informed the
geoserver users to stick with LizardTech SDK 6 for now. {grin}

---
A. Soroka / Digital Scholarship Services R & D
the University of Virginia Library
>
>>
>> I pulled the GDAL SVN trunk and then used a very minimal config for
>> building
>> it, turning off everything I could (see end of email for config
>> output). I
>> used the trunk instead of a stable version because LizardTech has
>> made
>> changes to their version 7 SDK that required the GDAL folks to make
>> changes
>> to their code which is most easily found in the trunk. Then I built
>> the SWIG
>> Java wrappers as per the instructions in:
>>
>> http://www.geo-solutions.it/doc/ImageioExt-SetupGuide.pdf
>>
>> I provided Tomcat with the aforementioned flags for Java startup
>> pointing to
>> the GDAL libs and data directory. I pulled the jars that Andrea
>> mentioned
>> from the geo-solutions.it GeoServer 1.7 snapshot war build.
>> Essentially I
>> pulled everything that was in that war's WEB-INF/lib that wasn't in
>> the beta
>> 2 war that I got from Sourceforge.
>>
>> Starting up Tomcat, I saw:
>>
>> 11 Aug 23:25:58 INFO [geotools.factory] - Factory implementations for
>> category GridFormatFactorySpi:
>> org.geotools.gce.arcgrid.ArcGridFormatFactory
>> org.geotools.gce.geotiff.GeoTiffFormatFactorySpi
>> org.geotools.gce.gtopo30.GTopo30FormatFactory
>> org.geotools.gce.image.WorldImageFormatFactory
>> org.geotools.coverageio.gdal.mrsid.MrSIDFormatFactory
>> org.geotools.coverageio.gdal.jp2kak.JP2KFormatFactory
>> org.geotools.coverageio.gdal.jp2mrsid.JP2MrSIDFormatFactory
>> org.geotools.coverageio.gdal.dted.DTEDFormatFactory
>> org.geotools.coverageio.gdal.erdasimg.ErdasImgFormatFactory
>> org.geotools.coverageio.gdal.nitf.NITFFormatFactory
>> org.geotools.gce.imagemosaic.ImageMosaicFormatFactory
>>
>> which made me very happy, but when I went to try to create a
>> CoverageStore,
>> I was able to fill out the appropriate form (with my file location)
>> and when
>> I submitted, I got:
>>
>> form connection params { }
>> 11 Aug 23:27:29 INFO [geotools.factory] - Factory implementations for
>> category GridCoverageFactory:
>> org.geotools.coverage.grid.GridCoverageFactory
>> #
>> # An unexpected error has been detected by Java Runtime Environment:
>> #
>> # SIGSEGV (0xb) at pc=0x00002aaafbaaf0a9, pid=4000, tid=1096018256
>> #
>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (10.0-b22 mixed mode
>> linux-amd64)
>> # Problematic frame:
>> # C [libgdal.so+0x28b0a9] GDALGetMetadata+0x9
>>
>> etc.
>>
>> The MrSids are okay, and running gdalinfo or gdal_translate on them
>> produces
>> good results.
>>
>> Any thoughts? Should I try building those GeoTools jars on this
>> machine?
>>
>> Thanks again for the help! Being able to use GDAL for this purpose
>> is a
>> wonderful idea and will really open up some great possibilities for
>> GeoServer, so thanks for doing this work.
>>
>> ---
>> A. Soroka / Digital Scholarship Services R & D
>> the University of Virginia Library
>>
>> On Aug 13, 2008, at 1:48 PM, Simone Giannecchini wrote:
>>
>>> On Wed, Aug 13, 2008 at 6:56 PM, ajs6f <ajs6f@anonymised.com> wrote:
>>>>
>>>> On Aug 13, 2008, at 11:50 AM, Andrea Aime wrote:
>>>>>
>>>>> ajs6f ha scritto:
>>>>>>
>>>>>> Hello, Geoserver community!
>>>>>> I'm trying to bring up the new GDAL/ImageioExt code to try out
>>>>>> serving some legacy MrSid imagery.
>>>>>> Am I right in thinking that this code is included in the 1.7 beta
>>>>>> 2 release?
>>>>>
>>>>> Actually not, the release notes contained that hint, but it's
>>>>> not correct. It should be included in the next RC1 thought.
>>>>
>>>> Ah, thank you. This clarifies the matter.
>>>>
>>>>> You'll need an extra jar from GeoTools, but I don't have it handy.
>>>>> Maybe someone else has... or you can just wait for 1.7.0-RC1, it's
>>>>> getting close.
>>>>
>>>> No problem-- I snagged them from the:
>>>>
>>>> http://www.geo-solutions.it/libraries/geoserver-1.7.0-SNAPSHOT-war.zip
>>>>
>>>> build.
>>>>
>>>> The Java side of things looks great, now, but I'm getting SIGSEGVs
>>>> like this one:
>>>>
>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (10.0-b22 mixed mode
>>>> linux-amd64)
>>>> # Problematic frame:
>>>> # C [libgdal.so+0x28b0a9] GDALGetMetadata+0x9
>>>>
>>>> when I try to set up a MrSid CoverageStore.
>>>>
>>>> I'm assuming that this is an issue to take to GDAL, eh?
>>>
>>> The binaries you are using where built on a 32 bit linux machine.
>>> I ma
>>> not sure they would work on a 64 bit machine.
>>> Anyway, could yuo please provide some more info about the following
>>> items in order to help you out:
>>> -target hw platform
>>> -procedure you followed for the installation
>>>
>>> ciao,
>>> Simone.
>>>
>>>>
>>>> If anyone else has been down this road and can offer any advice, it
>>>> would be much appreciated.
>>>>
>>>> Thanks for your help, Andrea!
>>>>
>>>> ---
>>>> A. Soroka / Digital Scholarship Services R & D
>>>> the University of Virginia Library
>>>>
>>>> -------------------------------------------------------------------------
>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>> challenge
>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>> great
>>>> prizes
>>>> Grand prize is a trip for two to an Open Source event anywhere in
>>>> the
>>>> world
>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>> _______________________________________________
>>>> Geoserver-users mailing list
>>>> Geoserver-users@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>>>
>>>
>>> --
>>> -------------------------------------------------------
>>> Eng. Simone Giannecchini
>>> President /CEO GeoSolutions S.A.S.
>>> Via Carignoni 51
>>> 55041 Camaiore (LU)
>>> Italy
>>>
>>> phone: +39 0584983027
>>> fax: +39 0584983027
>>> mob: +39 333 8128928
>>>
>>> http://www.geo-solutions.it
>>>
>>> -------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win
>> great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in
>> the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Geoserver-users mailing list
>> Geoserver-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>
>
> --
> -------------------------------------------------------
> Eng. Simone Giannecchini
> President /CEO GeoSolutions S.A.S.
> Via Carignoni 51
> 55041 Camaiore (LU)
> Italy
>
> phone: +39 0584983027
> fax: +39 0584983027
> mob: +39 333 8128928
>
> http://www.geo-solutions.it
>
> -------------------------------------------------------

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
-------------------------------------------------------
Eng. Daniele Romagnoli
Software Engineer

GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 328 0559267

http://www.geo-solutions.it

-------------------------------------------------------

Hi again,

On Thu, Aug 14, 2008 at 6:44 PM, ajs6f <ajs6f@anonymised.com> wrote:

Thanks so much for helping-- see my inline responses below.


A. Soroka / Digital Scholarship Services R & D
the University of Virginia Library

On Aug 14, 2008, at 6:08 AM, Daniele Romagnoli wrote:

Several months ago, during our work of getting GDAL working under Linux from Java, we have noticed that, after building GDAL without setting those C??_FLAGS when generating JAVA Bindings, JVM crashes with sigsegv errors. I will checkout GDAL 1.5.x and I will look for them.
Anyway I need some more info in order to better know your procedure.
Which jar containing the generated java bindings are you using? (This jar contains the native calls to the libgdaljni.so)

I’m assuming that this is the imageio-ext-gdal-1.0-SNAPSHOT.jar that I pulled from the 1.7-SNAPSHOT war. I did not use the gdal.jar generated by my GDAL SWIG build because I did not correctly understand the need to-- see below for my latest adventure trying to correct that mistake.

You said that you copied all the “new” jars from the WEB-INF/lib folder. Therefore I guess you have also copied the imageio-ext-gdal-1.0-SNAPSHOT.jar.

True, although I now understand why that was a mistake, as you describe below.

This file is the gdal.jar produced by SWIG when generating java bindings (It has been renamed like this to know the proper imageio-ext / GDAL version). Since imageio-ext is actually built against gdal 1.4.4, the imageio-ext libs contained in that geoserver release leverage on a GDAL 1.4.4 version, unless you have replaced our imageio-ext-gdal-1.0-SNAPSHOT.jar with your SWIG’s generated gdal.jar relying on a GDAL 1.5.x version. However, I have noticed in the past (more info on the imageio-ext dev ML archive) that the SWIG Bindings produced by version 1.5.X are slightly different with respect to the ones coming from 1.4.4.

I think I understand your point here. In an effort to correct this problem, I just tried to rebuild my GDAL (just as I had done before) in order to use the SWIG-generated jar associated with my (trunk) build of GDAL. Surprisingly, I got a:

[slab@anonymised.com java]$ make build

/bin/sh /usr/local/gis/gdal/src/gdal/libtool --mode=link g++ -shared /usr/local/gis/gdal/src/gdal/libgdal.la gdal_wrap.o -o libgdaljni.so
libtool: link: g++ gdal_wrap.o -o .libs/libgdaljni.so /usr/local/gis/gdal/src/gdal/.libs/libgdal.so -L/usr/local/gis/gdal/src/mrsid/Geo_DSDK-7.0.0.2167//lib/Release -L/usr/local/gis/gdal/src/mrsid/Geo_DSDK-7.0.0.2167//3rd-party/lib/Release -lrt -ldl -lltidsdk -lpthread
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/…/…/…/…/lib64/crt1.o: In function _start': (.text+0x20): undefined reference to main’
collect2: ld returned 1 exit status
make: *** [libgdaljni.so] Error 1

which is a most unexpectedly basic error to receive in this context. I’m going to continue trying, perhaps rolling back my GDAL source to the latest version that includes corrections for the MrSID version 7 SDK, which I think should be 1.5. Since I have once already been able to build the SWIG Java jar using the trunk code, I should think I can do it again. Of course, I would happily dispense with the trunk code and use 1.5 with your patch (mentioned below).

Therefore, in that circumstance I have created an unofficial small patch for an user which needed to work with GDAL 1.5 and MrSID 7 to use it with our ImageIO-ext project.
Let me know.

I would be -extremely- grateful for that patch. It seems like that’s exactly what I need to get all the pieces together.

The patch won’t solve basic errors you are talking about. It simply allows to generate Bindings for 1.5.x to be used by our Java based ImageIO-Ext project (Since some declaration have been changed on 1.5.x producing no more coherents java bindings). The patch is in attachment (it needs to be applied from this location: gdal/swig/include).

A side note: I will be away for a week for holidays. In the meantime, in case of problems, I suggest you to check the imageio-ext dev mailing list. Especially, the threads with subject “Gdal 1…5 with imageio-ext patch” and “Errors reading MrSID on linux”. They may contain useful tips.

Regards,
Daniele


A. Soroka / Digital Scholarship Services R & D
the University of Virginia Library

On Thu, Aug 14, 2008 at 2:28 AM, ajs6f <ajs6f@anonymised.com> wrote:
On Aug 13, 2008, at 8:12 PM, Simone Giannecchini wrote:

I would assume that you followed the ImageIO-ext instructions that we
have put on the project website. We have slightly customized the gdal
java bindings…

I’m glad you raised that point, because I had forgotten it: the
instructions refer to:

#Flags to build optimized relese version
CXX_OPTFLAGS = O1
C_OPTFLAGS = O1

in GDALmake.opt, but for the life of me, I couldn’t find those
variables set anywhere in that file. (Perhaps I should reiterate that
I am using the GDAL trunk source, not the stable version that is
recommended by the imageio-ext instructions.) Perhaps I should have
set them anew?

I used the LizardTech SDK Geo_DSDK-7.0.0.2167 for linux x86-64 and
gcc4.1.
Ah-ah, this means troubles :-). There has been a thread recently in
the imageio-ext devel list on how to build gdal with support for mrsid
using the sdk 7.0. I might suggest you to refer to it. For the
moment we are still
providing binaries as well as supporting sdk 6.0. We should try and
switch over as soon as gdal 1.4.5 comes out.

Ah-- now we find the worst problem-- I haven’t subscribed to that
list, so I’m less informed than I should be. {grin} I’ll rectify that
mistake promptly.

Tomorrow, I’ll ask daniele (the colleague of mine who is mainly
responsible for imageio-ext) to provide a bit more details on how to
tackle such an issue.

Thank you so much! I hope I’ll be able to contribute something useful
towards this issue with LizardTech SDK 7.

Meanwhile, hopefully this conversation will have informed the
geoserver users to stick with LizardTech SDK 6 for now. {grin}


A. Soroka / Digital Scholarship Services R & D
the University of Virginia Library

I pulled the GDAL SVN trunk and then used a very minimal config for
building
it, turning off everything I could (see end of email for config
output). I
used the trunk instead of a stable version because LizardTech has
made
changes to their version 7 SDK that required the GDAL folks to make
changes
to their code which is most easily found in the trunk. Then I built
the SWIG
Java wrappers as per the instructions in:

http://www.geo-solutions.it/doc/ImageioExt-SetupGuide.pdf

I provided Tomcat with the aforementioned flags for Java startup
pointing to
the GDAL libs and data directory. I pulled the jars that Andrea
mentioned
from the geo-solutions.it GeoServer 1.7 snapshot war build.
Essentially I
pulled everything that was in that war’s WEB-INF/lib that wasn’t in
the beta
2 war that I got from Sourceforge.

Starting up Tomcat, I saw:

11 Aug 23:25:58 INFO [geotools.factory] - Factory implementations for
category GridFormatFactorySpi:
org.geotools.gce.arcgrid.ArcGridFormatFactory
org.geotools.gce.geotiff.GeoTiffFormatFactorySpi
org.geotools.gce.gtopo30.GTopo30FormatFactory
org.geotools.gce.image.WorldImageFormatFactory
org.geotools.coverageio.gdal.mrsid.MrSIDFormatFactory
org.geotools.coverageio.gdal.jp2kak.JP2KFormatFactory
org.geotools.coverageio.gdal.jp2mrsid.JP2MrSIDFormatFactory
org.geotools.coverageio.gdal.dted.DTEDFormatFactory
org.geotools.coverageio.gdal.erdasimg.ErdasImgFormatFactory
org.geotools.coverageio.gdal.nitf.NITFFormatFactory
org.geotools.gce.imagemosaic.ImageMosaicFormatFactory

which made me very happy, but when I went to try to create a
CoverageStore,
I was able to fill out the appropriate form (with my file location)
and when
I submitted, I got:

form connection params { }
11 Aug 23:27:29 INFO [geotools.factory] - Factory implementations for
category GridCoverageFactory:
org.geotools.coverage.grid.GridCoverageFactory

An unexpected error has been detected by Java Runtime Environment:

SIGSEGV (0xb) at pc=0x00002aaafbaaf0a9, pid=4000, tid=1096018256

Java VM: Java HotSpot™ 64-Bit Server VM (10.0-b22 mixed mode

linux-amd64)

Problematic frame:

C [libgdal.so+0x28b0a9] GDALGetMetadata+0x9

etc.

The MrSids are okay, and running gdalinfo or gdal_translate on them
produces
good results.

Any thoughts? Should I try building those GeoTools jars on this
machine?

Thanks again for the help! Being able to use GDAL for this purpose
is a
wonderful idea and will really open up some great possibilities for
GeoServer, so thanks for doing this work.


A. Soroka / Digital Scholarship Services R & D
the University of Virginia Library

On Aug 13, 2008, at 1:48 PM, Simone Giannecchini wrote:

On Wed, Aug 13, 2008 at 6:56 PM, ajs6f <ajs6f@anonymised.com> wrote:

On Aug 13, 2008, at 11:50 AM, Andrea Aime wrote:

ajs6f ha scritto:

Hello, Geoserver community!
I’m trying to bring up the new GDAL/ImageioExt code to try out
serving some legacy MrSid imagery.
Am I right in thinking that this code is included in the 1.7 beta
2 release?

Actually not, the release notes contained that hint, but it’s
not correct. It should be included in the next RC1 thought.

Ah, thank you. This clarifies the matter.

You’ll need an extra jar from GeoTools, but I don’t have it handy.
Maybe someone else has… or you can just wait for 1.7.0-RC1, it’s
getting close.

No problem-- I snagged them from the:

http://www.geo-solutions.it/libraries/geoserver-1.7.0-SNAPSHOT-war.zip

build.

The Java side of things looks great, now, but I’m getting SIGSEGVs
like this one:

Java VM: Java HotSpot™ 64-Bit Server VM (10.0-b22 mixed mode

linux-amd64)

Problematic frame:

C [libgdal.so+0x28b0a9] GDALGetMetadata+0x9

when I try to set up a MrSid CoverageStore.

I’m assuming that this is an issue to take to GDAL, eh?

The binaries you are using where built on a 32 bit linux machine.
I ma
not sure they would work on a 64 bit machine.
Anyway, could yuo please provide some more info about the following
items in order to help you out:
-target hw platform
-procedure you followed for the installation

ciao,
Simone.

If anyone else has been down this road and can offer any advice, it
would be much appreciated.

Thanks for your help, Andrea!


A. Soroka / Digital Scholarship Services R & D
the University of Virginia Library


This SF.Net email is sponsored by the Moblin Your Move Developer’s
challenge
Build the coolest Linux based applications with Moblin SDK & win
great
prizes
Grand prize is a trip for two to an Open Source event anywhere in
the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/


Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it



This SF.Net email is sponsored by the Moblin Your Move Developer’s
challenge
Build the coolest Linux based applications with Moblin SDK & win
great
prizes
Grand prize is a trip for two to an Open Source event anywhere in
the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/


Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it



This SF.Net email is sponsored by the Moblin Your Move Developer’s challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/


Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Eng. Daniele Romagnoli
Software Engineer

GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 328 0559267

http://www.geo-solutions.it



To unsubscribe, e-mail: dev-unsubscribe@anonymised.com
For additional commands, e-mail: dev-help@anonymised.com

Eng. Daniele Romagnoli
Software Engineer

GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 328 0559267

http://www.geo-solutions.it


gdalswigincludepatch.txt (4.91 KB)