Hey Gabriel,
Good point. I haven't put much thought into that and to be honest have more
or less done no testing with gwc.
At first thought I think that it should "just work". Since gwc operates
behind the ows dispatcher, the thread local should be set and so gwc should
see the same workspace local view of the catalog and configuration that the
ows services see. But for sure some testing is in order. Not sure what a
great test plan would be... i guess a simple test would be to try a
"cachable" wms request, but though a virtual service endpoint and for a
layer that resides in a different workspace. The result should be an error
that the layer does not exist.
AS for gwc contributing its own ServiceInfo objects and having that play
nice with the workspace local services stuff. Currently the way it is wired
up is that the service gets listed on the workspace edit page if the
service has an admin page. So that is why the gwc service objects don't
show up currently.
GWC follows a bit of a different pattern in than the typical services in
that it aggregates a bunch of services (wmts, tms, etc...). The those
ServiceInfo's are wired up now they wouldn't work with the workspace local
services stuff. If they were first class citizens like the other
ServiceInfo objects, that is persisted by GeoServerImpl, etc... then it
would transparently work. And I guess adding individual ServiceAdminPage's
for them.
Anyways, something to talk through for sure. Perhaps we can do an IRC
breakout.
On Tue, Dec 20, 2011 at 8:55 PM, Gabriel Roldan <[email protected]> wrote:
> Thanks for putting this up Justin, looks good at a first glance.
>
> I wonder though how all this affect GWC? like in does it work with the
> integrated gwc out of the box (specially the virtual services work),
> or what the gwc integration would need to consider to be called
> virtual services + workspace local settings compatible?
> Have you put any thought/testing onto that?
> If not I'd like you to help me think about it. One thing that comes to
> mind would be to make sure /<ws>/ows end points are respected by gwc.
> Another would be for gwc to contribute its own ServiceInfo
> implementations for its publishing services (tms, wmts, wmsc, etc), so
> that they're catched up by the ws local settings page? anything else?
>
> TIA,
> Gabriel
>
> On Tue, Dec 20, 2011 at 11:24 PM, Justin Deoliveira
> <[email protected]> wrote:
> > `Hi all,
> >
> > I put together a proposal for the workspace specific settings discussed
> last
> > week:
> >
> > http://geoserver.org/display/GEOS/GSIP+67+-+Workspace+Local+Settings
> >
> > Feedback much appreciated.
> >
> > -Justin
> >
> > --
> > Justin Deoliveira
> > OpenGeo - http://opengeo.org
> > Enterprise support for open source geospatial.
> >
> >
> >
> ------------------------------------------------------------------------------
> > Write once. Port to many.
> > Get the SDK and tools to simplify cross-platform app development. Create
> > new or port existing apps to sell to consumers worldwide. Explore the
> > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> > http://p.sf.net/sfu/intel-appdev
> > _______________________________________________
> > Geoserver-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> >
>
>
>
> --
> Gabriel Roldan
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
