Hi everybody,
I found an issue with layer groups containing other layer groups.
Shortly it can happen (and for the Murphy law, it usually happens) that when loading the catalog a layer group containing other layer groups is loaded before the referenced ones and this doesn’t allow the correct layer group initialization.
To avoid I thought to introduce some form of late binding for internal layer groups that cannot be found when needed.
Shortly, during the loading phase, when a referenced layergroup is not found some kind of placeholder is registered instead of the real layergroup. When the loading phase is finished, the catalog is inspected and the placeholders are replaced by the (now loaded) layer groups.
The same infrastructure could be reused in the future for other type of catalog objects referencing objects of the same type.
Do you like this approach?
The alternative would be to try to load layergroups in the correct order, but this would require a two phase approach also (during the first phase we need to build a tree of layergroup dependencies and on the second load groups using the ordered tree). I think this would be more complex to implement.
I already have a patch for the first approach, so let me know if it’s ok and I will create a pull request.
Mauro
–
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
Hi Mauro,
There is an existing approach to this problem and it livres in ResolvingProxy. Will that not work in this case?
-Justin
···
On Thu, Jun 13, 2013 at 6:08 AM, Mauro Bartolomeoli <mauro.bartolomeoli@anonymised.com> wrote:
Hi everybody,
I found an issue with layer groups containing other layer groups.
Shortly it can happen (and for the Murphy law, it usually happens) that when loading the catalog a layer group containing other layer groups is loaded before the referenced ones and this doesn’t allow the correct layer group initialization.
To avoid I thought to introduce some form of late binding for internal layer groups that cannot be found when needed.
Shortly, during the loading phase, when a referenced layergroup is not found some kind of placeholder is registered instead of the real layergroup. When the loading phase is finished, the catalog is inspected and the placeholders are replaced by the (now loaded) layer groups.
The same infrastructure could be reused in the future for other type of catalog objects referencing objects of the same type.
Do you like this approach?
The alternative would be to try to load layergroups in the correct order, but this would require a two phase approach also (during the first phase we need to build a tree of layergroup dependencies and on the second load groups using the ordered tree). I think this would be more complex to implement.
I already have a patch for the first approach, so let me know if it’s ok and I will create a pull request.
Mauro
–
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
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
2013/6/14 Justin Deoliveira <jdeolive@anonymised.com>
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
--
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
-------------------------------------------------------
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 <mauro.bartolomeoli@anonymised.com> wrote:
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
2013/6/14 Justin Deoliveira <jdeolive@anonymised.com>
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
–
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
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.
- It duplicates functionality provided by ResolvingProxy, and requires maintaing a “shadow” interface in parallel to LayerGroupInfo
- 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 <jdeolive@anonymised.com> wrote:
Hey Mauro,
Sure, happy to take a crack at it. Will report back shortly.
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
On Wed, Jun 19, 2013 at 11:25 AM, Mauro Bartolomeoli <mauro.bartolomeoli@anonymised.com> wrote:
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
2013/6/14 Justin Deoliveira <jdeolive@anonymised.com>
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
–
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
2013/6/20 Justin Deoliveira <jdeolive@anonymised.com>
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
Many thanks for your effort. I just needed to add one more null check to
make it work with my test case.
I added a unit test and created a pull request:
https://github.com/geoserver/geoserver/pull/255
Mauro
--
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
-------------------------------------------------------