Hey Justin, On Mon, Mar 5, 2012 at 10:47 PM, Justin Deoliveira <jdeol...@opengeo.org> wrote: > Hey Gabriel, > > The ui is looking great, nice work. cool, thanks.
> I took it for a spin today when doing > some last testing for the layer/group and style per workspace changes, and > unfortunately ran into issues testing the case we discussed earlier today > when a layer group with the same name exists globally and within a > workspace. I don't remember having such discussion (yesterday) but don't trust my mind anyway. > > The DefaultTileLAyerCatalog does not like this. Which makes sense since it > is totally unaware of layer group workspaces. However, something problematic > that it does is that it allows me to create two such layer groups (although > it does seem to fail in the background) but it prevents me from starting up > the server. Essentially leaving the server configuration corrupt without a > way to fix it past hacking on the configuration files directly. Okay. Yes it makes sense for it to fail as layer group names have been always unique. Unfortunately GWC doesn't distinguish between layer identity (name) and identifier (id). It uses name as both, which is bad, and something I already started to change, although not sure when will be able to make a full switch. So far the integrated GWC layers use a unique identifier to match it's corresponding layerinfo or layergroupinfo, which is a step forward in the right direction. Pulling up the following sentence so my comment doesn't get too far away from the above: > Anyways, I would like to work with you to get this specific issue resolved > since as it stands this blocks the completion of GSIP 73. Sounds good. For the time being, I just committed a patch that avoids creating a tile layer for a layergroup with duplicate name. The log will get an error message on purpose, but won't avoid the layergroup to be saved. With this you should be able to commit your patch for GSIP 73. Next step is to find a way forward on integrating gwc with the changes from GSIP 73, and perhaps with the whole local workspace work, in a nicer way. For which I'll try to summarize a plan on a separate thread taking into account what we've talked about today on Skype and my research after it. Aside: I found another gap that'd prevent proper functioning: it seems it is possible to create two layer groups with the same name in the same workspace. What I did is to create a separate "tasmania" layer group in the "topp" workspace, save it, and after that assign it the default workspace and save it again. It got saved and both showed up in the layer group page. > > Obviously we will have to fix this specific case Done as far as it goes as noted previously. I tried your patch for GSIP 73 without the commits for GEOS-4460 and noted that, although it didn't break, it didn't work nicely with gwc either. Like in GSIP 73 doesn't take gwc into account at all. The tile layer settings do get created as part of the metadata map for a layergroup that has a workspace set, but that tile layer will never see the outer world, just because gwc is not prepared to do so. In any case I take it as my responsibility as I haven't had a chance to look deeper into what all these local workspace related work means for integrated gwc. And we just found out with duplicate layer groups the first or worse symptom of it so far. That said, it is hard being the only one that cares and that gets the complaints, or so I feel. In any case I plea (again) to the wider geoserver developers community to think also on what the consequences for gwc would be upon any proposal that might affect it, and to provide patches or raise the discussion early so I can make sure to ask for time to spend on it. Recognizing gwc is an important part of geoserver, whether one uses it himself or not, or has the time and interest to become a contributor or not. > but it brings me to a > deeper issue that i meant to bring up previously. And that is that it might > be wise to include an off switch all together for embedded gwc. I know I > have run into problems with it myself, and others have reported similar > issues on the list and the fix unfortunately seems to be often to simply > remove the gwc jars altogether from a geoserver install. It would be nice to > instead be able to simply set a system parameter or a global config property > that would do this. I realize this is probably quite a bit of work though. I would rather work towards making it robust enough so that if you don't want to use it just remove the tile layers and disable the 'create a tile layer for every new added layer' functionality. Both things are already possible, as is disabling the specific gwc provided services (tms, wmts, wms-c). Diskquota not breaking a clustered (well, load balanced) set up is not yet, unfortunately. I think that's what you meant. A global enablement switch would be indeed quite some work, and it's already quite hard to keep gwc completely decoupled. In fact I think it's the only non-extension module that's pluggable. Patches are welcomed though. Although a simpler way of achieving that would be a separate web module that doesn't include the gwc dependency, or rather a profile in the current web-app module that excludes it, so that you can have two war files, one with gwc and another without. Cheers, Gabriel > > -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
