[Geoserver-devel] ResolvingProxy.handleOther() always returns null.

I just stumbled into this: https://osgeo-org.atlassian.net/browse/GEOS-7046 while using geoserver.

It turns out org.geoserver.catalog.impl.ResolvingProxy.handleOther() overrides ProxyBase.handleOther() to always return null instead of excecute the method. Does anyone have any idea why this is?

Torben

On Fri, May 22, 2015 at 9:14 PM, Torben Barsballe <
tbarsballe@anonymised.com> wrote:

I just stumbled into this:
https://osgeo-org.atlassian.net/browse/GEOS-7046 while using geoserver.

It turns out org.geoserver.catalog.impl.ResolvingProxy.handleOther()
overrides ProxyBase.handleOther() to always return null instead of excecute
the method. Does anyone have any idea why this is?

Hum.. nope, this goes back to the first implementation of ResolvingProxy.
Our current history does not go back as much, but in case you did not know,
there is a geoserver-history repo that has the
history from the first commit, up to the one where the new repo starts.

Here is a blame on that file in the history repo:
https://github.com/geoserver/geoserver-history/blame/master/src/main/src/main/java/org/geoserver/catalog/impl/ResolvingProxy.java

If I had to venture a guess, it's because ResolvingProxy is not meant to be
found anywhere past the catalog
loading, it should be always be replaced by a resolved version.
As far as I remember, it is being created as a placeholder allowing the
catalog to be loaded in whatever order
(even if we don't have the target object loaded yet), and then
ResolvingProxy.resolve should be called
onto all of them, which we do in the AbstractCatalogFacade.resolve family
of methods

Maybe we are missing some resolve calls in some code path?

Anyways... cc'ed Justin, he should know better than me :slight_smile:

Cheers
Andrea

--

Meet us at the INSPIRE Conference in Lisbon 25-29 May 2015! Visit
http://goo.gl/WHKDXT for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

On Mon, May 25, 2015 at 4:52 AM, Andrea Aime <andrea.aime@anonymised.com>
wrote:

On Fri, May 22, 2015 at 9:14 PM, Torben Barsballe <
tbarsballe@anonymised.com> wrote:

I just stumbled into this:
https://osgeo-org.atlassian.net/browse/GEOS-7046 while using geoserver.

It turns out org.geoserver.catalog.impl.ResolvingProxy.handleOther()
overrides ProxyBase.handleOther() to always return null instead of excecute
the method. Does anyone have any idea why this is?

Hum.. nope, this goes back to the first implementation of ResolvingProxy.
Our current history does not go back as much, but in case you did not
know, there is a geoserver-history repo that has the
history from the first commit, up to the one where the new repo starts.

Here is a blame on that file in the history repo:

https://github.com/geoserver/geoserver-history/blame/master/src/main/src/main/java/org/geoserver/catalog/impl/ResolvingProxy.java

If I had to venture a guess, it's because ResolvingProxy is not meant to
be found anywhere past the catalog
loading, it should be always be replaced by a resolved version.
As far as I remember, it is being created as a placeholder allowing the
catalog to be loaded in whatever order
(even if we don't have the target object loaded yet), and then
ResolvingProxy.resolve should be called
onto all of them, which we do in the AbstractCatalogFacade.resolve family
of methods

Maybe we are missing some resolve calls in some code path?

Anyways... cc'ed Justin, he should know better than me :slight_smile:

I think this sums it up pretty well :slight_smile: If I remember the reason for that
method correctly, it's to handle method calls that aren't getters or
setters. Such methods usually do something with data on that object but
since the proxy is just a placeholder this was meant to stub them out?

But yeah, like Andrea said if instances of ResolvingProxy are still around
it hints to most likely a referential problem in the catalog. Just glancing
at Torbens last comment on the ticket that seems to be the case.

Cheers
Andrea

--

Meet us at the INSPIRE Conference in Lisbon 25-29 May 2015! Visit
http://goo.gl/WHKDXT for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

On Mon, May 25, 2015 at 4:13 PM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:

I think this sums it up pretty well :slight_smile: If I remember the reason for that
method correctly, it's to handle method calls that aren't getters or
setters. Such methods usually do something with data on that object but
since the proxy is just a placeholder this was meant to stub them out?

But yeah, like Andrea said if instances of ResolvingProxy are still around
it hints to most likely a referential problem in the catalog. Just glancing
at Torbens last comment on the ticket that seems to be the case.

Hi Justin,
in these cases, shouldn't we do something other than leaving the
ResolvingProxy around?
Like setting null, or finding a default?

Cheers
Andrea

--

Meet us at the INSPIRE Conference in Lisbon 25-29 May 2015! Visit
http://goo.gl/WHKDXT for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

Right. A few ways we could take this. One end of the spectrum is what we do now and just be silent, other end would be to full on fail at startup. In between are the options you suggest. Not sure which one would be best… perhaps finding a default with a pretty clear log message.

···

On Mon, May 25, 2015 at 8:26 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Mon, May 25, 2015 at 4:13 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi Justin,
in these cases, shouldn’t we do something other than leaving the ResolvingProxy around?
Like setting null, or finding a default?

Cheers

Andrea

==
Meet us at the INSPIRE Conference in Lisbon 25-29 May 2015! Visit http://goo.gl/WHKDXT for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.


I think this sums it up pretty well :slight_smile: If I remember the reason for that method correctly, it’s to handle method calls that aren’t getters or setters. Such methods usually do something with data on that object but since the proxy is just a placeholder this was meant to stub them out?

But yeah, like Andrea said if instances of ResolvingProxy are still around it hints to most likely a referential problem in the catalog. Just glancing at Torbens last comment on the ticket that seems to be the case.

If we do stick with the current implementation and be silent, then I think we will want better error reporting somewhere downstream, because as it stands this problem manifests in GeoServer admin as NullPointerExceptions and Session Timeout pages, making the actual cause very difficult to determine. If the missing resource is touched by a cascading delete, you get a NullPointerException as in the ticket. If you try to view one of the invalid resources, GeoServer gives some error, and the UI displays a Session Timeout page, despite the fact that the session has not timed out.

Torben

···

On Mon, May 25, 2015 at 4:50 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Right. A few ways we could take this. One end of the spectrum is what we do now and just be silent, other end would be to full on fail at startup. In between are the options you suggest. Not sure which one would be best… perhaps finding a default with a pretty clear log message.

On Mon, May 25, 2015 at 8:26 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Mon, May 25, 2015 at 4:13 PM, Justin Deoliveira <jdeolive@…403…> wrote:

Hi Justin,
in these cases, shouldn’t we do something other than leaving the ResolvingProxy around?
Like setting null, or finding a default?

Cheers

Andrea

==
Meet us at the INSPIRE Conference in Lisbon 25-29 May 2015! Visit http://goo.gl/WHKDXT for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.


I think this sums it up pretty well :slight_smile: If I remember the reason for that method correctly, it’s to handle method calls that aren’t getters or setters. Such methods usually do something with data on that object but since the proxy is just a placeholder this was meant to stub them out?

But yeah, like Andrea said if instances of ResolvingProxy are still around it hints to most likely a referential problem in the catalog. Just glancing at Torbens last comment on the ticket that seems to be the case.

On Tue, May 26, 2015 at 1:55 AM, Torben Barsballe <
tbarsballe@anonymised.com> wrote:

If we do stick with the current implementation and be silent, then I think
we will want better error reporting somewhere downstream, because as it
stands this problem manifests in GeoServer admin as NullPointerExceptions
and Session Timeout pages, making the actual cause very difficult to
determine. If the missing resource is touched by a cascading delete, you
get a NullPointerException as in the ticket. If you try to view one of the
invalid resources, GeoServer gives some error, and the UI displays a
Session Timeout page, despite the fact that the session has not timed out.

I like trying to find a default better, with a prominent log, as you have
found the web pages and the rest of GeoServer in general
do not react well, and those would be a lot of places to change, and to
remember to keep in a good reporting state in the future.
The message should be something like "Could not locate referenced style a
in workspace b, replacing with a default style".

We could also validate objects as we return them from the catalog and log
all invalid bits, but that would likely have a visible
performance impact

Cheers
Andrea

--

Meet us at the INSPIRE Conference in Lisbon 25-29 May 2015! Visit
http://goo.gl/WHKDXT for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------