[Geoserver-devel] AbstractService and geoserver extensions/extension points

Mathew_Wyatt · October 29, 2008, 6:48am

Hi,

I currently have some tiff(tagged image files) and jp2000 images which i would like to create a data coverage store for. The initial dataset is 200+ maps, and I'm not really wanting to
configure these individually by hand. I would like to implement some
functionality in Geoserver which automatically configures Geoservers
coverage store (as much a possible without human intervention) when new
data is added to the coverages repository (initially tifs/jp2's but will
allow for extension of course). Pretty much what these tickets are
related to:

http://jira.codehaus.org/browse/GEOS-2287
http://jira.codehaus.org/browse/GEOS-2289
http://jira.codehaus.org/browse/GEOS-340 - this one to a lesser degree,
but i think it is realted

I thought I would be able to initially do this as a plugin/extension, so
I checked out the latest code from the Geoserver trunk, and followed
this guide to writing plugins -
http://geoserver.org/display/GEOSDOC/3+A+Simple+PlugIn. I have followed
this guide but was unable to get it working. I tried installing the
community/hello extension aswell, but still no cigar.

When i provide my URL
(http://localhost:8080/geoserver/ows?request=autoConfigure&service=coverageStoreAutoConfigureService)
the stack trace that follows is:

29 Oct 11:35:50 ERROR [geoserver.ows] -
org.geoserver.platform.ServiceException: No service: (
coverageStoreAutoConfigureService )
    at org.geoserver.ows.Dispatcher.findService(Dispatcher.java:679)
    at org.geoserver.ows.Dispatcher.service(Dispatcher.java:331)
    at
org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:182)
    at
org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153)
    at
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
    at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
    at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809)
    at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
    at
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:501)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at
org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    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.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:178)
    at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
    at
org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)
    at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
    at
org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
    at
org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:73)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at
org.geoserver.filters.ReverseProxyFilter.doFilter(ReverseProxyFilter.java:163)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:41)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
    at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
    at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
    at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
    at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
    at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
    at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
    at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
    at java.lang.Thread.run(Thread.java:619)

and the ouput in the browser is:

<?xml version="1.0" encoding="UTF-8"?>
<ows:ExceptionReport version="1.0.0"
  xsi:schemaLocation="http://www.opengis.net/ows http://localhost:8080/geoserver/schemas/ows/1.0.0/owsExceptionReport.xsd"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ows="http://www.opengis.net/ows">
  <ows:Exception exceptionCode="InvalidParameterValue" locator="service">
    <ows:ExceptionText>No service: (
      coverageStoreAutoConfigureService )</ows:ExceptionText>
  </ows:Exception>
</ows:ExceptionReport>

So, it cant find my service. I went into the code a put in some print
statements to see if i could access my new AutoConfigure service (which
extends AbstractService) bean from the Spring context, which I could.
So, I know that my bean does exist, and it is being loaded by the Spring
context. I am pretty sure the reason it cannot find my service is
because it is of type AbstractService. In org.geoserver.ows.Dispatcher
line 653, the loadServices() method requests services/extensions from
the spring context based on the Service type:

Collection services = GeoServerExtensions.extensions(Service.class);

The question to whoever might be able to help me is: Is the tutorial for
extensions/plugins still relevant/uptodate? or have a made a
simple/critical mistake somewhere? Also in this page -
http://geoserver.org/display/GEOSDOC/Operation - the sequence diagram
depicts the Dispatcher instantiating the AbstractService, this does not
reflect what is happening in the code...

Also, is a plugin/extension approach a good one for what I would like to
achieve?

Thanks in advance.

Mat

--
Mathew Wyatt
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

Justin_Deoliveira · October 30, 2008, 2:12pm

Hi Mathew,

Using a custom service to auto configure some datastores or coverages is a neat idea :). Until we get a good REST api that is stable this probably the best approach.

As for your plug-in not working. The actual service class can extend from anything, the dispatcher makes no assumptions about this. The "Service" class loaded by the dispatcher is really just a descriptor which describes your service.

So based on the request you gave me you should have something like the following:

package com.xyz;

public class MyCoverageStoreAutoConfigureService {

    public void autoConfigure() {
        ....
    }

}

And then then in your spring applicationContext.xml file:

Is that correct? If you want to include your entire app context and the implementation class that might be helpful.

-Justin

Mathew Wyatt wrote:

Hi,

I currently have some tiff(tagged image files) and jp2000 images which i would like to create a data coverage store for. The initial dataset is 200+ maps, and I'm not really wanting to
configure these individually by hand. I would like to implement some
functionality in Geoserver which automatically configures Geoservers
coverage store (as much a possible without human intervention) when new
data is added to the coverages repository (initially tifs/jp2's but will
allow for extension of course). Pretty much what these tickets are
related to:

http://jira.codehaus.org/browse/GEOS-2287
http://jira.codehaus.org/browse/GEOS-2289
http://jira.codehaus.org/browse/GEOS-340 - this one to a lesser degree,
but i think it is realted

I thought I would be able to initially do this as a plugin/extension, so
I checked out the latest code from the Geoserver trunk, and followed
this guide to writing plugins -
http://geoserver.org/display/GEOSDOC/3+A+Simple+PlugIn. I have followed
this guide but was unable to get it working. I tried installing the
community/hello extension aswell, but still no cigar.

When i provide my URL
(http://localhost:8080/geoserver/ows?request=autoConfigure&service=coverageStoreAutoConfigureService)
the stack trace that follows is:

29 Oct 11:35:50 ERROR [geoserver.ows] -
org.geoserver.platform.ServiceException: No service: (
coverageStoreAutoConfigureService )
    at org.geoserver.ows.Dispatcher.findService(Dispatcher.java:679)
    at org.geoserver.ows.Dispatcher.service(Dispatcher.java:331)
    at
org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:182)
    at
org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153)
    at
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
    at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
    at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809)
    at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
    at
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:501)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at
org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    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.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:178)
    at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
    at
org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)
    at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
    at
org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
    at
org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:73)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at
org.geoserver.filters.ReverseProxyFilter.doFilter(ReverseProxyFilter.java:163)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:41)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
    at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
    at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
    at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
    at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
    at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
    at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
    at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
    at java.lang.Thread.run(Thread.java:619)

and the ouput in the browser is:

<?xml version="1.0" encoding="UTF-8"?>
<ows:ExceptionReport version="1.0.0"
  xsi:schemaLocation="http://www.opengis.net/ows http://localhost:8080/geoserver/schemas/ows/1.0.0/owsExceptionReport.xsd"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ows="http://www.opengis.net/ows">
  <ows:Exception exceptionCode="InvalidParameterValue" locator="service">
    <ows:ExceptionText>No service: (
      coverageStoreAutoConfigureService )</ows:ExceptionText>
  </ows:Exception>
</ows:ExceptionReport>

So, it cant find my service. I went into the code a put in some print
statements to see if i could access my new AutoConfigure service (which
extends AbstractService) bean from the Spring context, which I could.
So, I know that my bean does exist, and it is being loaded by the Spring
context. I am pretty sure the reason it cannot find my service is
because it is of type AbstractService. In org.geoserver.ows.Dispatcher
line 653, the loadServices() method requests services/extensions from
the spring context based on the Service type:

Collection services = GeoServerExtensions.extensions(Service.class);

The question to whoever might be able to help me is: Is the tutorial for
extensions/plugins still relevant/uptodate? or have a made a
simple/critical mistake somewhere? Also in this page -
http://geoserver.org/display/GEOSDOC/Operation - the sequence diagram
depicts the Dispatcher instantiating the AbstractService, this does not
reflect what is happening in the code...

Also, is a plugin/extension approach a good one for what I would like to
achieve?

Thanks in advance.

Mat

--
Mathew Wyatt
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

-------------------------------------------------------------------------
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-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Mathew_Wyatt · October 31, 2008, 11:03am

Hi Justin,

Thankyou very much. Your suggestion worked like a charm. I did have another a question regarding plugins though.

Do you recommed this way you have described (creating a Service descriptor bean which is located by the ows dispatcher, and references your plugin) as the standard way of creating a plugin? or, do you consider it OK to extend the Spring MVC AbstractController, and having a URL mapping for the plugin in the applicationContext.xml?

cheers
Mat

--
Mathew Wyatt
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

________________________________________
From: Justin Deoliveira [jdeolive@anonymised.com]
Sent: Thursday, 30 October 2008 11:12 PM
To: Wyatt, Mathew (E&M, Kensington)
Cc: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] AbstractService and geoserver extensions/extension points

Hi Mathew,

Using a custom service to auto configure some datastores or coverages is
a neat idea :). Until we get a good REST api that is stable this
probably the best approach.

As for your plug-in not working. The actual service class can extend
from anything, the dispatcher makes no assumptions about this. The
"Service" class loaded by the dispatcher is really just a descriptor
which describes your service.

So based on the request you gave me you should have something like the
following:

package com.xyz;

public class MyCoverageStoreAutoConfigureService {

    public void autoConfigure() {
        ....
    }

}

And then then in your spring applicationContext.xml file:

Is that correct? If you want to include your entire app context and the
implementation class that might be helpful.

-Justin

Mathew Wyatt wrote:

Hi,

I currently have some tiff(tagged image files) and jp2000 images which i
would like to create a data coverage store for. The initial dataset is 200+ maps, and I'm not really wanting to
configure these individually by hand. I would like to implement some
functionality in Geoserver which automatically configures Geoservers
coverage store (as much a possible without human intervention) when new
data is added to the coverages repository (initially tifs/jp2's but will
allow for extension of course). Pretty much what these tickets are
related to:

http://jira.codehaus.org/browse/GEOS-2287
http://jira.codehaus.org/browse/GEOS-2289
http://jira.codehaus.org/browse/GEOS-340 - this one to a lesser degree,
but i think it is realted

I thought I would be able to initially do this as a plugin/extension, so
I checked out the latest code from the Geoserver trunk, and followed
this guide to writing plugins -
http://geoserver.org/display/GEOSDOC/3+A+Simple+PlugIn. I have followed
this guide but was unable to get it working. I tried installing the
community/hello extension aswell, but still no cigar.

When i provide my URL
(http://localhost:8080/geoserver/ows?request=autoConfigure&service=coverageStoreAutoConfigureService)
the stack trace that follows is:

29 Oct 11:35:50 ERROR [geoserver.ows] -
org.geoserver.platform.ServiceException: No service: (
coverageStoreAutoConfigureService )
    at org.geoserver.ows.Dispatcher.findService(Dispatcher.java:679)
    at org.geoserver.ows.Dispatcher.service(Dispatcher.java:331)
    at
org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:182)
    at
org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153)
    at
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
    at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
    at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809)
    at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
    at
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:501)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at
org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    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.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:178)
    at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
    at
org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)
    at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
    at
org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
    at
org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:73)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at
org.geoserver.filters.ReverseProxyFilter.doFilter(ReverseProxyFilter.java:163)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:41)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
    at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
    at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
    at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
    at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
    at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
    at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
    at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
    at java.lang.Thread.run(Thread.java:619)

and the ouput in the browser is:

<?xml version="1.0" encoding="UTF-8"?>
<ows:ExceptionReport version="1.0.0"
  xsi:schemaLocation="http://www.opengis.net/ows http://localhost:8080/geoserver/schemas/ows/1.0.0/owsExceptionReport.xsd"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ows="http://www.opengis.net/ows">
  <ows:Exception exceptionCode="InvalidParameterValue" locator="service">
    <ows:ExceptionText>No service: (
      coverageStoreAutoConfigureService )</ows:ExceptionText>
  </ows:Exception>
</ows:ExceptionReport>

So, it cant find my service. I went into the code a put in some print
statements to see if i could access my new AutoConfigure service (which
extends AbstractService) bean from the Spring context, which I could.
So, I know that my bean does exist, and it is being loaded by the Spring
context. I am pretty sure the reason it cannot find my service is
because it is of type AbstractService. In org.geoserver.ows.Dispatcher
line 653, the loadServices() method requests services/extensions from
the spring context based on the Service type:

Collection services = GeoServerExtensions.extensions(Service.class);

The question to whoever might be able to help me is: Is the tutorial for
extensions/plugins still relevant/uptodate? or have a made a
simple/critical mistake somewhere? Also in this page -
http://geoserver.org/display/GEOSDOC/Operation - the sequence diagram
depicts the Dispatcher instantiating the AbstractService, this does not
reflect what is happening in the code...

Also, is a plugin/extension approach a good one for what I would like to
achieve?

Thanks in advance.

Mat

--
Mathew Wyatt
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

-------------------------------------------------------------------------
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-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Justin_Deoliveira · October 31, 2008, 9:29pm

Hi Mathew,

Good question. The "ows" dispatcher is better suited to OGC style web services, and for those services is quite convenient because it provides all the code that does version negotiation, kvp parsing, etc... While it is possible to implement other "web services" inside this framework, it often does not make sense to do so.

For instance, consider all the REST stuff implemented in GeoServer today. While it might be possible to implement it in a way that went through the ows dispatcher, it does not make a whole lot of sense to do so. So for that we rolled out our own "REST" dispatcher, which is indeed another spring controller.

So... bottom line is I would say if your service is "OGC-like" and you think you could benefit from some of the aspects of the ows dispatcher, than it makes sense. Otherwise I would just set up your own controller and create a mapping directly to it.

Hope that helps :).

-Justin

Mathew.Wyatt@anonymised.com wrote:

Hi Justin,

Thankyou very much. Your suggestion worked like a charm. I did have another a question regarding plugins though.

Do you recommed this way you have described (creating a Service descriptor bean which is located by the ows dispatcher, and references your plugin) as the standard way of creating a plugin? or, do you consider it OK to extend the Spring MVC AbstractController, and having a URL mapping for the plugin in the applicationContext.xml?

cheers
Mat

--
Mathew Wyatt
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

________________________________________
From: Justin Deoliveira [jdeolive@anonymised.com]
Sent: Thursday, 30 October 2008 11:12 PM
To: Wyatt, Mathew (E&M, Kensington)
Cc: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] AbstractService and geoserver extensions/extension points

Hi Mathew,

Using a custom service to auto configure some datastores or coverages is
a neat idea :). Until we get a good REST api that is stable this
probably the best approach.

As for your plug-in not working. The actual service class can extend
from anything, the dispatcher makes no assumptions about this. The
"Service" class loaded by the dispatcher is really just a descriptor
which describes your service.

So based on the request you gave me you should have something like the
following:

package com.xyz;

public class MyCoverageStoreAutoConfigureService {

    public void autoConfigure() {
        ....
    }

}

And then then in your spring applicationContext.xml file:

<bean id="coverageStoreAutoConfigurationServiceImpl"
    class="com.xyz.CoverageStoreAutoConfigurationService"/>

<bean id=""
   class="org.geoserver.ows.Service">
    <constructor-arg index="0"
value="coverageStoreAutoConfigurationService"/>
    <constructor-arg index="1"
ref="coverageStoreAutoConfigurationServiceImpl"/>
    <constructor-arg index="1" value="1.0.0"/>
</bean>

Is that correct? If you want to include your entire app context and the
implementation class that might be helpful.

-Justin

Mathew Wyatt wrote:

Hi,

I currently have some tiff(tagged image files) and jp2000 images which i
would like to create a data coverage store for. The initial dataset is 200+ maps, and I'm not really wanting to
configure these individually by hand. I would like to implement some
functionality in Geoserver which automatically configures Geoservers
coverage store (as much a possible without human intervention) when new
data is added to the coverages repository (initially tifs/jp2's but will
allow for extension of course). Pretty much what these tickets are
related to:

http://jira.codehaus.org/browse/GEOS-2287
http://jira.codehaus.org/browse/GEOS-2289
http://jira.codehaus.org/browse/GEOS-340 - this one to a lesser degree,
but i think it is realted

I thought I would be able to initially do this as a plugin/extension, so
I checked out the latest code from the Geoserver trunk, and followed
this guide to writing plugins -
http://geoserver.org/display/GEOSDOC/3+A+Simple+PlugIn. I have followed
this guide but was unable to get it working. I tried installing the
community/hello extension aswell, but still no cigar.

When i provide my URL
(http://localhost:8080/geoserver/ows?request=autoConfigure&service=coverageStoreAutoConfigureService)
the stack trace that follows is:

29 Oct 11:35:50 ERROR [geoserver.ows] -
org.geoserver.platform.ServiceException: No service: (
coverageStoreAutoConfigureService )
    at org.geoserver.ows.Dispatcher.findService(Dispatcher.java:679)
    at org.geoserver.ows.Dispatcher.service(Dispatcher.java:331)
    at
org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:182)
    at
org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153)
    at
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
    at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
    at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809)
    at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
    at
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:501)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at
org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    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.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:178)
    at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
    at
org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)
    at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
    at
org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
    at
org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:73)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at
org.geoserver.filters.ReverseProxyFilter.doFilter(ReverseProxyFilter.java:163)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:41)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
    at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
    at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
    at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
    at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
    at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
    at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
    at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
    at java.lang.Thread.run(Thread.java:619)

and the ouput in the browser is:

<?xml version="1.0" encoding="UTF-8"?>
<ows:ExceptionReport version="1.0.0"
  xsi:schemaLocation="http://www.opengis.net/ows http://localhost:8080/geoserver/schemas/ows/1.0.0/owsExceptionReport.xsd"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ows="http://www.opengis.net/ows">
  <ows:Exception exceptionCode="InvalidParameterValue" locator="service">
    <ows:ExceptionText>No service: (
      coverageStoreAutoConfigureService )</ows:ExceptionText>
  </ows:Exception>
</ows:ExceptionReport>

So, it cant find my service. I went into the code a put in some print
statements to see if i could access my new AutoConfigure service (which
extends AbstractService) bean from the Spring context, which I could.
So, I know that my bean does exist, and it is being loaded by the Spring
context. I am pretty sure the reason it cannot find my service is
because it is of type AbstractService. In org.geoserver.ows.Dispatcher
line 653, the loadServices() method requests services/extensions from
the spring context based on the Service type:

Collection services = GeoServerExtensions.extensions(Service.class);

The question to whoever might be able to help me is: Is the tutorial for
extensions/plugins still relevant/uptodate? or have a made a
simple/critical mistake somewhere? Also in this page -
http://geoserver.org/display/GEOSDOC/Operation - the sequence diagram
depicts the Dispatcher instantiating the AbstractService, this does not
reflect what is happening in the code...

Also, is a plugin/extension approach a good one for what I would like to
achieve?

Thanks in advance.

Mat

--
Mathew Wyatt
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

-------------------------------------------------------------------------
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-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Mathew_Wyatt · November 3, 2008, 7:59am

Hi Justin,

Thank you for you response it was very helpful. I now have yet another a question regarding attaching a view/jsp to the plugin.

I have a jsp file for my plugin (lets say - WEB-INF/jsp/coverageAutoConfigure.jsp) packaged up in a jar file, which is then deployed to geoserver/WEB-INF/lib. In order to get reference to this jsp file I need to use the classloaders getResource function, because the jsp is embedded in the jar and loaded onto the classpath, not accessible via URL:

applicationContext.getResource("classpath:WEB-INF/jsp/coverageStoreAutoConfigure.jsp")

But, I'm not sure how to redirect to this using the httpResponse, or how to get Spring MVC to load it as a view. The only solution I can come up with is to either implement my own spring mvc ViewResolver, put all the html markup in my plugin code and write it to the httpResponse (dodgy), or to add my jsp code directly to the geoserver web module (unpackaged, not ideal from a flexibility standpoint).

I'd be interested to hear your opinion on this.

cheers
Mat

--
Mathew Wyatt
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

Justin Deoliveira wrote:

Hi Mathew,

Good question. The "ows" dispatcher is better suited to OGC style web
services, and for those services is quite convenient because it provides
all the code that does version negotiation, kvp parsing, etc... While it
is possible to implement other "web services" inside this framework, it
often does not make sense to do so.

For instance, consider all the REST stuff implemented in GeoServer
today. While it might be possible to implement it in a way that went
through the ows dispatcher, it does not make a whole lot of sense to do
so. So for that we rolled out our own "REST" dispatcher, which is indeed
another spring controller.

So... bottom line is I would say if your service is "OGC-like" and you
think you could benefit from some of the aspects of the ows dispatcher,
than it makes sense. Otherwise I would just set up your own controller
and create a mapping directly to it.

Hope that helps :).

-Justin

Mathew.Wyatt@anonymised.com wrote:


Hi Justin,

Thankyou very much. Your suggestion worked like a charm. I did have another a question regarding plugins though.

Do you recommed this way you have described (creating a Service descriptor bean which is located by the ows dispatcher, and references your plugin) as the standard way of creating a plugin? or, do you consider it OK to extend the Spring MVC AbstractController, and having a URL mapping for the plugin in the applicationContext.xml?

cheers
Mat

--
Mathew Wyatt
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

________________________________________
From: Justin Deoliveira [jdeolive@anonymised.com]
Sent: Thursday, 30 October 2008 11:12 PM
To: Wyatt, Mathew (E&M, Kensington)
Cc: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] AbstractService and geoserver extensions/extension points

Hi Mathew,

Using a custom service to auto configure some datastores or coverages is
a neat idea :). Until we get a good REST api that is stable this
probably the best approach.

As for your plug-in not working. The actual service class can extend
from anything, the dispatcher makes no assumptions about this. The
"Service" class loaded by the dispatcher is really just a descriptor
which describes your service.

So based on the request you gave me you should have something like the
following:

package com.xyz;

public class MyCoverageStoreAutoConfigureService {

    public void autoConfigure() {
        ....
    }

}

And then then in your spring applicationContext.xml file:

<bean id="coverageStoreAutoConfigurationServiceImpl"
    class="com.xyz.CoverageStoreAutoConfigurationService"/>

<bean id=""
   class="org.geoserver.ows.Service">
    <constructor-arg index="0"
value="coverageStoreAutoConfigurationService"/>
    <constructor-arg index="1"
ref="coverageStoreAutoConfigurationServiceImpl"/>
    <constructor-arg index="1" value="1.0.0"/>
</bean>

Is that correct? If you want to include your entire app context and the
implementation class that might be helpful.

-Justin

Mathew Wyatt wrote:


Hi,

I currently have some tiff(tagged image files) and jp2000 images which i
would like to create a data coverage store for. The initial dataset is 200+ maps, and I'm not really wanting to
configure these individually by hand. I would like to implement some
functionality in Geoserver which automatically configures Geoservers
coverage store (as much a possible without human intervention) when new
data is added to the coverages repository (initially tifs/jp2's but will
allow for extension of course). Pretty much what these tickets are
related to:

http://jira.codehaus.org/browse/GEOS-2287
http://jira.codehaus.org/browse/GEOS-2289
http://jira.codehaus.org/browse/GEOS-340 - this one to a lesser degree,
but i think it is realted

I thought I would be able to initially do this as a plugin/extension, so
I checked out the latest code from the Geoserver trunk, and followed
this guide to writing plugins -
http://geoserver.org/display/GEOSDOC/3+A+Simple+PlugIn. I have followed
this guide but was unable to get it working. I tried installing the
community/hello extension aswell, but still no cigar.

When i provide my URL
(http://localhost:8080/geoserver/ows?request=autoConfigure&service=coverageStoreAutoConfigureService)
the stack trace that follows is:

29 Oct 11:35:50 ERROR [geoserver.ows] -
org.geoserver.platform.ServiceException: No service: (
coverageStoreAutoConfigureService )
    at org.geoserver.ows.Dispatcher.findService(Dispatcher.java:679)
    at org.geoserver.ows.Dispatcher.service(Dispatcher.java:331)
    at
org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:182)
    at
org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153)
    at
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
    at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
    at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809)
    at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
    at
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:501)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at
org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    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.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:178)
    at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
    at
org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)
    at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
    at
org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
    at
org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:73)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at
org.geoserver.filters.ReverseProxyFilter.doFilter(ReverseProxyFilter.java:163)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:41)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
    at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
    at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
    at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
    at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
    at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
    at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
    at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
    at java.lang.Thread.run(Thread.java:619)

and the ouput in the browser is:

<?xml version="1.0" encoding="UTF-8"?>
<ows:ExceptionReport version="1.0.0"
  xsi:schemaLocation="http://www.opengis.net/ows http://localhost:8080/geoserver/schemas/ows/1.0.0/owsExceptionReport.xsd"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ows="http://www.opengis.net/ows">
  <ows:Exception exceptionCode="InvalidParameterValue" locator="service">
    <ows:ExceptionText>No service: (
      coverageStoreAutoConfigureService )</ows:ExceptionText>
  </ows:Exception>
</ows:ExceptionReport>

So, it cant find my service. I went into the code a put in some print
statements to see if i could access my new AutoConfigure service (which
extends AbstractService) bean from the Spring context, which I could.
So, I know that my bean does exist, and it is being loaded by the Spring
context. I am pretty sure the reason it cannot find my service is
because it is of type AbstractService. In org.geoserver.ows.Dispatcher
line 653, the loadServices() method requests services/extensions from
the spring context based on the Service type:

Collection services = GeoServerExtensions.extensions(Service.class);

The question to whoever might be able to help me is: Is the tutorial for
extensions/plugins still relevant/uptodate? or have a made a
simple/critical mistake somewhere? Also in this page -
http://geoserver.org/display/GEOSDOC/Operation - the sequence diagram
depicts the Dispatcher instantiating the AbstractService, this does not
reflect what is happening in the code...

Also, is a plugin/extension approach a good one for what I would like to
achieve?

Thanks in advance.

Mat

--
Mathew Wyatt
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

-------------------------------------------------------------------------
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-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Justin_Deoliveira · November 3, 2008, 4:05pm

Hi Mathew,

Like you, i never found an easy way to do this. One thing we have tried in GeoServer for quite some time is to break the user interface up into modules... but the problem is what are you finding, JSP's are not designed to be loaded dynamically from the classpath, but compiled from a single static location.

So basically we gave up :). For GeoServer 2.0 we adopted a new user interface framework called "Wicket". It is not JSP based and therefore is quite easy to distribute UI components into jars and have a "pluggable" UI. You can check it out on GeoServer trunk if you wish.

-Justin

Mathew Wyatt wrote:

Hi Justin,

Thank you for you response it was very helpful. I now have yet another a question regarding attaching a view/jsp to the plugin.

I have a jsp file for my plugin (lets say - WEB-INF/jsp/coverageAutoConfigure.jsp) packaged up in a jar file, which is then deployed to geoserver/WEB-INF/lib. In order to get reference to this jsp file I need to use the classloaders getResource function, because the jsp is embedded in the jar and loaded onto the classpath, not accessible via URL:

applicationContext.getResource("classpath:WEB-INF/jsp/coverageStoreAutoConfigure.jsp")

But, I'm not sure how to redirect to this using the httpResponse, or how to get Spring MVC to load it as a view. The only solution I can come up with is to either implement my own spring mvc ViewResolver, put all the html markup in my plugin code and write it to the httpResponse (dodgy), or to add my jsp code directly to the geoserver web module (unpackaged, not ideal from a flexibility standpoint).

I'd be interested to hear your opinion on this.

cheers
Mat

--
Mathew Wyatt
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

Justin Deoliveira wrote:

Hi Mathew,

Good question. The "ows" dispatcher is better suited to OGC style web
services, and for those services is quite convenient because it provides
all the code that does version negotiation, kvp parsing, etc... While it
is possible to implement other "web services" inside this framework, it
often does not make sense to do so.

For instance, consider all the REST stuff implemented in GeoServer
today. While it might be possible to implement it in a way that went
through the ows dispatcher, it does not make a whole lot of sense to do
so. So for that we rolled out our own "REST" dispatcher, which is indeed
another spring controller.

So... bottom line is I would say if your service is "OGC-like" and you
think you could benefit from some of the aspects of the ows dispatcher,
than it makes sense. Otherwise I would just set up your own controller
and create a mapping directly to it.

Hope that helps :).

-Justin

Mathew.Wyatt@anonymised.com wrote:

Hi Justin,

Thankyou very much. Your suggestion worked like a charm. I did have another a question regarding plugins though.

Do you recommed this way you have described (creating a Service descriptor bean which is located by the ows dispatcher, and references your plugin) as the standard way of creating a plugin? or, do you consider it OK to extend the Spring MVC AbstractController, and having a URL mapping for the plugin in the applicationContext.xml?

cheers
Mat

--
Mathew Wyatt
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

________________________________________
From: Justin Deoliveira [jdeolive@anonymised.com]
Sent: Thursday, 30 October 2008 11:12 PM
To: Wyatt, Mathew (E&M, Kensington)
Cc: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] AbstractService and geoserver extensions/extension points

Hi Mathew,

Using a custom service to auto configure some datastores or coverages is
a neat idea :). Until we get a good REST api that is stable this
probably the best approach.

As for your plug-in not working. The actual service class can extend
from anything, the dispatcher makes no assumptions about this. The
"Service" class loaded by the dispatcher is really just a descriptor
which describes your service.

So based on the request you gave me you should have something like the
following:

package com.xyz;

public class MyCoverageStoreAutoConfigureService {

    public void autoConfigure() {
        ....
    }

}

And then then in your spring applicationContext.xml file:

<bean id="coverageStoreAutoConfigurationServiceImpl"
    class="com.xyz.CoverageStoreAutoConfigurationService"/>

<bean id=""
   class="org.geoserver.ows.Service">
    <constructor-arg index="0"
value="coverageStoreAutoConfigurationService"/>
    <constructor-arg index="1"
ref="coverageStoreAutoConfigurationServiceImpl"/>
    <constructor-arg index="1" value="1.0.0"/>
</bean>

Is that correct? If you want to include your entire app context and the
implementation class that might be helpful.

-Justin

Mathew Wyatt wrote:


Hi,

I currently have some tiff(tagged image files) and jp2000 images which i
would like to create a data coverage store for. The initial dataset is 200+ maps, and I'm not really wanting to
configure these individually by hand. I would like to implement some
functionality in Geoserver which automatically configures Geoservers
coverage store (as much a possible without human intervention) when new
data is added to the coverages repository (initially tifs/jp2's but will
allow for extension of course). Pretty much what these tickets are
related to:

http://jira.codehaus.org/browse/GEOS-2287
http://jira.codehaus.org/browse/GEOS-2289
http://jira.codehaus.org/browse/GEOS-340 - this one to a lesser degree,
but i think it is realted

I thought I would be able to initially do this as a plugin/extension, so
I checked out the latest code from the Geoserver trunk, and followed
this guide to writing plugins -
http://geoserver.org/display/GEOSDOC/3+A+Simple+PlugIn. I have followed
this guide but was unable to get it working. I tried installing the
community/hello extension aswell, but still no cigar.

When i provide my URL
(http://localhost:8080/geoserver/ows?request=autoConfigure&service=coverageStoreAutoConfigureService)

the stack trace that follows is:

29 Oct 11:35:50 ERROR [geoserver.ows] -
org.geoserver.platform.ServiceException: No service: (
coverageStoreAutoConfigureService )
    at org.geoserver.ows.Dispatcher.findService(Dispatcher.java:679)
    at org.geoserver.ows.Dispatcher.service(Dispatcher.java:331)
    at
org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:182)
    at
org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153)

    at
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)

    at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)

    at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809)

    at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)

    at
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:501)

    at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)

    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

    at
org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)

    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)

    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

    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.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:178)

    at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)

    at
org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)

    at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)

    at
org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)

    at
org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)

    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)

    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

    at org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:73)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)

    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

    at
org.geoserver.filters.ReverseProxyFilter.doFilter(ReverseProxyFilter.java:163)

    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)

    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

    at org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:41)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)

    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

    at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)

    at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)

    at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)

    at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)

    at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)

    at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)

    at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)

    at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)

    at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
    at java.lang.Thread.run(Thread.java:619)

and the ouput in the browser is:

<?xml version="1.0" encoding="UTF-8"?>
<ows:ExceptionReport version="1.0.0"
  xsi:schemaLocation="http://www.opengis.net/ows http://localhost:8080/geoserver/schemas/ows/1.0.0/owsExceptionReport.xsd"

  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ows="http://www.opengis.net/ows">
  <ows:Exception exceptionCode="InvalidParameterValue" locator="service">
    <ows:ExceptionText>No service: (
      coverageStoreAutoConfigureService )</ows:ExceptionText>
  </ows:Exception>
</ows:ExceptionReport>

So, it cant find my service. I went into the code a put in some print
statements to see if i could access my new AutoConfigure service (which
extends AbstractService) bean from the Spring context, which I could.
So, I know that my bean does exist, and it is being loaded by the Spring
context. I am pretty sure the reason it cannot find my service is
because it is of type AbstractService. In org.geoserver.ows.Dispatcher
line 653, the loadServices() method requests services/extensions from
the spring context based on the Service type:

Collection services = GeoServerExtensions.extensions(Service.class);

The question to whoever might be able to help me is: Is the tutorial for
extensions/plugins still relevant/uptodate? or have a made a
simple/critical mistake somewhere? Also in this page -
http://geoserver.org/display/GEOSDOC/Operation - the sequence diagram
depicts the Dispatcher instantiating the AbstractService, this does not
reflect what is happening in the code...

Also, is a plugin/extension approach a good one for what I would like to
achieve?

Thanks in advance.

Mat

--
Mathew Wyatt
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

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

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-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Justin_Deoliveira · November 3, 2008, 4:08pm

FYI,

Based on what you are doing I think this may be of interest. Recently the plan has been announced to open source an ingestion engine for GeoServer. What it does is basically sit as a repository for one to "drop" data into. Shapefiles, coverages, etc... The engine then watches the repository and when it finds new data auto configures GeoServer via REST interfaces.

So this probably directly applies to what you were doing. AS for timelines when this will come to be that is still a bit hazy. Other folks should have a better idea of this.

-Justin

Mathew Wyatt wrote:

Hi Justin,

Thank you for you response it was very helpful. I now have yet another a question regarding attaching a view/jsp to the plugin.

I have a jsp file for my plugin (lets say - WEB-INF/jsp/coverageAutoConfigure.jsp) packaged up in a jar file, which is then deployed to geoserver/WEB-INF/lib. In order to get reference to this jsp file I need to use the classloaders getResource function, because the jsp is embedded in the jar and loaded onto the classpath, not accessible via URL:

applicationContext.getResource("classpath:WEB-INF/jsp/coverageStoreAutoConfigure.jsp")

But, I'm not sure how to redirect to this using the httpResponse, or how to get Spring MVC to load it as a view. The only solution I can come up with is to either implement my own spring mvc ViewResolver, put all the html markup in my plugin code and write it to the httpResponse (dodgy), or to add my jsp code directly to the geoserver web module (unpackaged, not ideal from a flexibility standpoint).

I'd be interested to hear your opinion on this.

cheers
Mat

--
Mathew Wyatt
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

Justin Deoliveira wrote:

Hi Mathew,

Good question. The "ows" dispatcher is better suited to OGC style web
services, and for those services is quite convenient because it provides
all the code that does version negotiation, kvp parsing, etc... While it
is possible to implement other "web services" inside this framework, it
often does not make sense to do so.

For instance, consider all the REST stuff implemented in GeoServer
today. While it might be possible to implement it in a way that went
through the ows dispatcher, it does not make a whole lot of sense to do
so. So for that we rolled out our own "REST" dispatcher, which is indeed
another spring controller.

So... bottom line is I would say if your service is "OGC-like" and you
think you could benefit from some of the aspects of the ows dispatcher,
than it makes sense. Otherwise I would just set up your own controller
and create a mapping directly to it.

Hope that helps :).

-Justin

Mathew.Wyatt@anonymised.com wrote:


Hi Justin,

Thankyou very much. Your suggestion worked like a charm. I did have another a question regarding plugins though.

Do you recommed this way you have described (creating a Service descriptor bean which is located by the ows dispatcher, and references your plugin) as the standard way of creating a plugin? or, do you consider it OK to extend the Spring MVC AbstractController, and having a URL mapping for the plugin in the applicationContext.xml?

cheers
Mat

--
Mathew Wyatt
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

________________________________________
From: Justin Deoliveira [jdeolive@anonymised.com]
Sent: Thursday, 30 October 2008 11:12 PM
To: Wyatt, Mathew (E&M, Kensington)
Cc: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] AbstractService and geoserver extensions/extension points

Hi Mathew,

Using a custom service to auto configure some datastores or coverages is
a neat idea :). Until we get a good REST api that is stable this
probably the best approach.

As for your plug-in not working. The actual service class can extend
from anything, the dispatcher makes no assumptions about this. The
"Service" class loaded by the dispatcher is really just a descriptor
which describes your service.

So based on the request you gave me you should have something like the
following:

package com.xyz;

public class MyCoverageStoreAutoConfigureService {

    public void autoConfigure() {
        ....
    }

}

And then then in your spring applicationContext.xml file:

<bean id="coverageStoreAutoConfigurationServiceImpl"
    class="com.xyz.CoverageStoreAutoConfigurationService"/>

<bean id=""
   class="org.geoserver.ows.Service">
    <constructor-arg index="0"
value="coverageStoreAutoConfigurationService"/>
    <constructor-arg index="1"
ref="coverageStoreAutoConfigurationServiceImpl"/>
    <constructor-arg index="1" value="1.0.0"/>
</bean>

Is that correct? If you want to include your entire app context and the
implementation class that might be helpful.

-Justin

Mathew Wyatt wrote:


Hi,

I currently have some tiff(tagged image files) and jp2000 images which i
would like to create a data coverage store for. The initial dataset is 200+ maps, and I'm not really wanting to
configure these individually by hand. I would like to implement some
functionality in Geoserver which automatically configures Geoservers
coverage store (as much a possible without human intervention) when new
data is added to the coverages repository (initially tifs/jp2's but will
allow for extension of course). Pretty much what these tickets are
related to:

http://jira.codehaus.org/browse/GEOS-2287
http://jira.codehaus.org/browse/GEOS-2289
http://jira.codehaus.org/browse/GEOS-340 - this one to a lesser degree,
but i think it is realted

I thought I would be able to initially do this as a plugin/extension, so
I checked out the latest code from the Geoserver trunk, and followed
this guide to writing plugins -
http://geoserver.org/display/GEOSDOC/3+A+Simple+PlugIn. I have followed
this guide but was unable to get it working. I tried installing the
community/hello extension aswell, but still no cigar.

When i provide my URL
(http://localhost:8080/geoserver/ows?request=autoConfigure&service=coverageStoreAutoConfigureService)
the stack trace that follows is:

29 Oct 11:35:50 ERROR [geoserver.ows] -
org.geoserver.platform.ServiceException: No service: (
coverageStoreAutoConfigureService )
    at org.geoserver.ows.Dispatcher.findService(Dispatcher.java:679)
    at org.geoserver.ows.Dispatcher.service(Dispatcher.java:331)
    at
org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:182)
    at
org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153)
    at
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
    at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
    at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809)
    at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
    at
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:501)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at
org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    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.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:178)
    at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
    at
org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)
    at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
    at
org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
    at
org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:73)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at
org.geoserver.filters.ReverseProxyFilter.doFilter(ReverseProxyFilter.java:163)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:41)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
    at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
    at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
    at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
    at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
    at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
    at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
    at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
    at java.lang.Thread.run(Thread.java:619)

and the ouput in the browser is:

<?xml version="1.0" encoding="UTF-8"?>
<ows:ExceptionReport version="1.0.0"
  xsi:schemaLocation="http://www.opengis.net/ows http://localhost:8080/geoserver/schemas/ows/1.0.0/owsExceptionReport.xsd"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ows="http://www.opengis.net/ows">
  <ows:Exception exceptionCode="InvalidParameterValue" locator="service">
    <ows:ExceptionText>No service: (
      coverageStoreAutoConfigureService )</ows:ExceptionText>
  </ows:Exception>
</ows:ExceptionReport>

So, it cant find my service. I went into the code a put in some print
statements to see if i could access my new AutoConfigure service (which
extends AbstractService) bean from the Spring context, which I could.
So, I know that my bean does exist, and it is being loaded by the Spring
context. I am pretty sure the reason it cannot find my service is
because it is of type AbstractService. In org.geoserver.ows.Dispatcher
line 653, the loadServices() method requests services/extensions from
the spring context based on the Service type:

Collection services = GeoServerExtensions.extensions(Service.class);

The question to whoever might be able to help me is: Is the tutorial for
extensions/plugins still relevant/uptodate? or have a made a
simple/critical mistake somewhere? Also in this page -
http://geoserver.org/display/GEOSDOC/Operation - the sequence diagram
depicts the Dispatcher instantiating the AbstractService, this does not
reflect what is happening in the code...

Also, is a plugin/extension approach a good one for what I would like to
achieve?

Thanks in advance.

Mat

--
Mathew Wyatt
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

-------------------------------------------------------------------------
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-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

-------------------------------------------------------------------------
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-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.