Jeff, tried your wms_store branch and couldn't get it to work. It
seemed to find 4 layers, out of 2 that I had...so not sure where the
other 2 had come from, then it choked:
Exception: ('Failed to process NAIP Imagery',
FailedRequestError('Tried to make a GET request to
http://localhost:8001/geoserver/rest/workspaces/geonode/wmsstores/NAIP/wmslayers/NAIP
Imagery.xml but got a 400 status code: \n',)
Which is the WMS layer I wanted to update. I dug around a bit but I
think I need to read up on the GeoServer REST API to make better sense
of things.
On a related issue, surely it makes sense to make gsconfig.py a
submodule like geonode-client? Figuring the best workflow to work
with it is a bit awkward and inconsistent with the rest of geonode.
It's a different repo downloaded during building from
dwins/gsconfig.py . If you don't know this and make changes it might
not be clear that your changes weren't propagated back to your repo.
In fact, another paver build call (which would be used during a
make_release) will overwrite your gsconfig directory entirely without
any warning. I couldn't even figure out where during the paver step
it did the download so I could update to use a different repo for
instance, so I don't have a clear path to even fix this. Any
suggestions are very welcome!
matt
On Fri, Mar 16, 2012 at 5:30 PM, Jeffrey Johnson <[email protected]> wrote:
> Matthew,
>
> The short answer to this is that I had to patch gsconfig.py to support
> cascaded layers. You may be able to get away with just using that and
> using updatelayers.
>
> https://github.com/jj0hns0n/gsconfig.py/tree/wms_store
>
> Give that a try and let me know if you run into any problems or if it works.
>
> Jeff
>
> On Fri, Mar 16, 2012 at 1:38 PM, Matthew Hanson
> <[email protected]> wrote:
>> Jeff,
>>
>> Are you able to use updatelayers to update GeoNode with any WMS layers
>> that are in GeoServer?
>>
>> Because for WMS layers that I *am* able to add to GeoServer
>> (forgetting the above issues), updatelayers does not work. I've
>> traced the problem into gsconfig.py where it gets the list of stores.
>> I've got two stores: one PostGIS, one WMS (cascaded). It returns
>> only the PostGIS in the list of stores and not the wms layer.
>>
>> I sort of lost track of things when I saw that GeoServer was getting
>> the list of stores from a datastores.xml file, but which didn't
>> actually exist....I don't know enough about GeoServer to know what's
>> going on, but it must create that on the fly from all the
>> datastore.xml files that exist, in each of the store directories.
>> However WMS stores do not have a datastore.xml file, instead they have
>> a wmsstore.xml file.
>>
>> So it looks like this is a problem with gsconfig.py not retrieving all
>> the stores (only dataStores and coverageStores...not sure of the
>> difference there), and that the WMS stores are left out.
>>
>> matt
>>
>>
>>
>> On Fri, Mar 16, 2012 at 10:28 AM, Matthew Hanson
>> <[email protected]> wrote:
>>> Well since I'm already using the existing version, that should be
>>> 2.1.3, so updating it won't help me with the cascading problem.
>>>
>>> On Thu, Mar 15, 2012 at 4:34 PM, David Winslow <[email protected]> wrote:
>>>> On Thu, Mar 15, 2012 at 4:13 PM, Jeffrey Johnson <[email protected]>
>>>> wrote:
>>>>>
>>>>> David,
>>>>>
>>>>> Can you describe these "other modifications". I've never run into
>>>>> trouble doing it this way, and just saying its not a good idea to do
>>>>> it this way is just not a good enough reason for me not to continue
>>>>> doing it.
>>>>
>>>>
>>>> I don't think the users' mailing list is the appropriate place for that.
>>>> Feel free to diff the sources of geoserver's web/app module with GeoNode's
>>>> geoserver-geonode-ext.
>>>>
>>>>>
>>>>> On Thu, Mar 15, 2012 at 1:07 PM, David Winslow <[email protected]>
>>>>> wrote:
>>>>> > I don't recommend just dropping the geonode-geoserver-ext JAR into a
>>>>> > standard GeoServer installation. The WAR file that we distribute has
>>>>> > some
>>>>> > modifications beyond just adding the geoserver-geonode-ext JAR. WIthout
>>>>> > them, it is non-deterministic whether or not the GeoNode integration
>>>>> > with
>>>>> > the GeoServer security system actually takes effect. (Actually, it used
>>>>> > to
>>>>> > be non-deterministic but I think now it just doesn't work.)
>>>>>
>>>>> I did this as recently as monday, and it certainly did work, and in
>>>>> fact, I carefully tested that the GeoNode based security most
>>>>> certainly was working.
>>>>>
>>>>> > The GeoNode WAR is built from GeoServer nightly jars and has all
>>>>> > bugfixes
>>>>> > that have gone into GeoServer 2.1.3. I also put together a branch to
>>>>> > bring
>>>>> > GeoNode up to the GeoServer 2.2
>>>>> > series: https://github.com/dwins/geonode/tree/geoserver-2.2 Please try
>>>>> > one
>>>>> > of those instead of trying to "geonode-ize" a regular GeoServer.
>>>>>
>>>>> Is there a reason that this geoserver-2.2 branch hasnt been submitted
>>>>> as a pull request and pulled onto master yet? Seems like it makes
>>>>> sense for us to get GeoNode up to speed with current GeoServer
>>>>> development sooner rather than later.
>>>>
>>>>
>>>> When a stable release of GeoServer 2.2 is published by the GeoServer team,
>>>> I
>>>> will verify that this branch still compiles. If so, we'll update to
>>>> GeoServer 2.2 at that time. For now though, GeoServer 2.2 is still
>>>> considered unstable by the GeoServer developers and I don't think it's
>>>> appropriate for inclusion as the default in GeoNode.
>>>>
>>>> --
>>>> David Winslow
>>>> OpenGeo - http://opengeo.org/
