Ok, took a closer look, and it is indeed a bit of pain this issue. So, here
are my thoughts.
My two issues with your patch are as follows.
1. It duplicates functionality provided by ResolvingProxy, and requires
maintaing a "shadow" interface in parallel to LayerGroupInfo
2. The "late binding" is already done by CatalogImpl.resolve(LayerGroupInfo)
It is a tricky problem to be sure, i couldn't come up with a great
solution, but here is a patch.
https://gist.github.com/jdeolive/5825868
On Thu, Jun 20, 2013 at 11:55 AM, Justin Deoliveira <[email protected]>wrote:
> Hey Mauro,
>
> Sure, happy to take a crack at it. Will report back shortly.
>
>
> On Wed, Jun 19, 2013 at 11:25 AM, Mauro Bartolomeoli <
> [email protected]> wrote:
>
>>
>>
>>
>> 2013/6/14 Justin Deoliveira <[email protected]>
>>
>>> Hi Mauro,
>>>
>>> There is an existing approach to this problem and it livres in
>>> ResolvingProxy. Will that not work in this case?
>>>
>>> -Justin
>>>
>>>
>> Hi Justin,
>> I had a look at ResolvingProxy, but the problem seems to be that the
>> Proxy created by it is not useful to prevent catalog load from failing if
>> nested layergroups are present.
>> I would be very glad if you, or someone else wishing to help, can have a
>> look at my current fix for the issue before making the pull request.
>> You can find it here:
>> https://github.com/mbarto/geoserver/commit/197780165b83efe7202a1d4ac462036c59495ccd
>>
>> As I was saying in the last email, I built an explicit Proxy (LateBinding
>> stuff), implementing some of the LayerGroupInfo interface methods to avoid
>> failures during Catalog loading.
>> I don't know if the ResolvingProxy could be adapted to accomplish the
>> same task. I tried in several ways, but didn't find how to make it work in
>> this situation.
>>
>> The late binding phase executes at the end of the loading when all the
>> Catalog objects should be available.
>>
>> Maybe when doing late binding, some of the checks done during "normal"
>> loading should be repeated after the binding has been done (I'm thinking of
>> loops checking and so on).
>>
>> Thanks.
>> Mauro
>> --
>> ==
>> Our support, Your Success! Visit http://opensdi.geo-solutions.it for
>> more information.
>> ==
>>
>> Dott. Mauro Bartolomeoli
>> @mauro_bart
>> Senior Software Engineer
>>
>> GeoSolutions S.A.S.
>> Via Poggio alle Viti 1187
>> 55054 Massarosa (LU)
>> Italy
>> phone: +39 0584 962313
>> fax: +39 0584 1660272
>>
>> http://www.geo-solutions.it
>> http://twitter.com/geosolutions_it
>>
>> -------------------------------------------------------
>>
>
>
>
> --
> 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 Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
