[Geoserver-devel] Getting a way to directly set the OGC service exception details from service code

GeoServer GeoServer Developer
1

Hi,
our service exception handling work in such a way that build the output message
from the list of messages in the stack trace below the first ServiceException found.
p

Sometimes this is not desirable, as it often makes the message long and ugly,
when the code throwing the exception has all the information it needs to properly
setup a full OGC service exception response (message, code and locator).
One such case is processes built with WPS in mind, which could do their own
internal (complex) validation of inputs, or just report about hiccups occurred during
the processing, without the need for the messages to be variously glazed by exception
wrapping.

Given that we already have a deep tree of exceptions, with some subtrees handling
OWS 2.0 specific things, creating a custom exception class (like HTTPErrorCodeException)
would not work.
Instead I would like to introduce a special interface, DirectOGCException, that could be then
implemented by multiple ServiceException subclasses

The Dispatcher code handling exception would first try to do a full drill down in the current
stack trace, if one of those is found, then the exception writing code would receive it
directly, with no extra glaze around it.

Feedback?

Cheers
Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 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

2

Not a bad approach, would the DirectOGCException take over responsibility for writing the entire exemption response document?

···

Jody Garnett

On Mon, Jun 9, 2014 at 7:12 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
our service exception handling work in such a way that build the output message
from the list of messages in the stack trace below the first ServiceException found.
p

Sometimes this is not desirable, as it often makes the message long and ugly,
when the code throwing the exception has all the information it needs to properly
setup a full OGC service exception response (message, code and locator).
One such case is processes built with WPS in mind, which could do their own
internal (complex) validation of inputs, or just report about hiccups occurred during
the processing, without the need for the messages to be variously glazed by exception
wrapping.

Given that we already have a deep tree of exceptions, with some subtrees handling
OWS 2.0 specific things, creating a custom exception class (like HTTPErrorCodeException)
would not work.
Instead I would like to introduce a special interface, DirectOGCException, that could be then
implemented by multiple ServiceException subclasses

The Dispatcher code handling exception would first try to do a full drill down in the current
stack trace, if one of those is found, then the exception writing code would receive it
directly, with no extra glaze around it.

Feedback?

Cheers
Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 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

HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://www.hpccsystems.com

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

3

On Mon, Jun 9, 2014 at 12:05 PM, Jody Garnett <jody.garnett@anonymised.com>
wrote:

Not a bad approach, would the DirectOGCException take over responsibility
for writing the entire exemption response document?

No, it would just provide the building blocks, different OWS versions need
the exception
document to be encoded in a different way, and we already have writers for
those that
take a ServiceException as an input.

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 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

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

4

Which of the ServiceException subclasses will implement the interface? All of them?

Wondering about cases where delegation goes on and internally one service delegates to another? Following this approach as I understand it the delegate service exception is what would be reported unless the delegating service is also a direct exception… hence my question above.

···

On Mon, Jun 9, 2014 at 4:09 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://www.hpccsystems.com

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

Justin Deoliveira
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive

On Mon, Jun 9, 2014 at 12:05 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Not a bad approach, would the DirectOGCException take over responsibility for writing the entire exemption response document?

No, it would just provide the building blocks, different OWS versions need the exception
document to be encoded in a different way, and we already have writers for those that
take a ServiceException as an input.

Cheers

Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 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

5

On Mon, Jun 9, 2014 at 3:27 PM, Justin Deoliveira <jdeolive@anonymised.com

wrote:

Which of the ServiceException subclasses will implement the interface? All
of them?

On no, for starters, a single WPSServiceException subclass.
Developer will implement more as they see a need for it.

In WPS the need is clear enough, the WPS process developer wants to
communicate an error
back to the client without the rest of the machinery to get in the way.

Wondering about cases where delegation goes on and internally one service
delegates to another? Following this approach as I understand it the
delegate service exception is what would be reported unless the delegating
service is also a direct exception... hence my question above.

I see. WPS wise, the issue might occur if the process is used as a
rendering transformation... which is probably what we want anyways, or not?
Hypotetically, say WCS/WFS used it somewhere (maybe a geoserver specific
store), and WPS was integrating into them, that would be the
inputs of a process failing, so something the user specified... seems again
something that would work well even if we expose just the
innermost exception

Generally speaking, this exception would bypass, reporting wise, the layers
in the middle, and it's thrown on purpose by the programmer
just to get that effect, so I believe it should be fine.

None of the existing code or exceptions would be affected, only new code
written on purpose to leverage the marker interface would
use it.

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 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

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

6

Any more comment? Ok to go?

Cheers
Andrea

···

On Mon, Jun 9, 2014 at 3:32 PM, Andrea Aime <andrea.aime@anonymised.com…1268…> wrote:

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 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

On Mon, Jun 9, 2014 at 3:27 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Which of the ServiceException subclasses will implement the interface? All of them?

On no, for starters, a single WPSServiceException subclass.
Developer will implement more as they see a need for it.

In WPS the need is clear enough, the WPS process developer wants to communicate an error
back to the client without the rest of the machinery to get in the way.

Wondering about cases where delegation goes on and internally one service delegates to another? Following this approach as I understand it the delegate service exception is what would be reported unless the delegating service is also a direct exception… hence my question above.

I see. WPS wise, the issue might occur if the process is used as a rendering transformation… which is probably what we want anyways, or not?
Hypotetically, say WCS/WFS used it somewhere (maybe a geoserver specific store), and WPS was integrating into them, that would be the
inputs of a process failing, so something the user specified… seems again something that would work well even if we expose just the
innermost exception

Generally speaking, this exception would bypass, reporting wise, the layers in the middle, and it’s thrown on purpose by the programmer
just to get that effect, so I believe it should be fine.

None of the existing code or exceptions would be affected, only new code written on purpose to leverage the marker interface would
use it.

Cheers

Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 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

7

On Mon, Jun 9, 2014 at 7:32 AM, Andrea Aime <andrea.aime@anonymised.com>
wrote:

On Mon, Jun 9, 2014 at 3:27 PM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:

Which of the ServiceException subclasses will implement the interface?
All of them?

On no, for starters, a single WPSServiceException subclass.
Developer will implement more as they see a need for it.

In WPS the need is clear enough, the WPS process developer wants to
communicate an error
back to the client without the rest of the machinery to get in the way.

Wondering about cases where delegation goes on and internally one service
delegates to another? Following this approach as I understand it the
delegate service exception is what would be reported unless the delegating
service is also a direct exception... hence my question above.

I see. WPS wise, the issue might occur if the process is used as a
rendering transformation... which is probably what we want anyways, or not?

Hmmmm... not so sure. The outer exception gives us context about the entire
request chain. I find this information useful when all I have to go off of
is a users stack trace.

There is also the issue of service compliance. If i am accessing data
through the WMS service shouldn't I always get a WMS service exception
back? The specs often place restrictions on things like error codes, etc...
that should be returned in specific error cases. That info would be lost
here.

Hypotetically, say WCS/WFS used it somewhere (maybe a geoserver specific

store), and WPS was integrating into them, that would be the
inputs of a process failing, so something the user specified... seems
again something that would work well even if we expose just the
innermost exception

Generally speaking, this exception would bypass, reporting wise, the
layers in the middle, and it's thrown on purpose by the programmer
just to get that effect, so I believe it should be fine.

None of the existing code or exceptions would be affected, only new code
written on purpose to leverage the marker interface would
use it.

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 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

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

--
*Justin Deoliveira*
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive <https://twitter.com/j_deolive&gt;

8

On Thu, Jun 12, 2014 at 12:07 AM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:

Wondering about cases where delegation goes on and internally one
service delegates to another? Following this approach as I understand it
the delegate service exception is what would be reported unless the
delegating service is also a direct exception... hence my question above.

I see. WPS wise, the issue might occur if the process is used as a
rendering transformation... which is probably what we want anyways, or not?

Hmmmm... not so sure. The outer exception gives us context about the
entire request chain. I find this information useful when all I have to go
off of is a users stack trace.

The full stack trace would still be available in the logs. By default, we
don't generate full stack traces, but you're right that they are available
when one enables "verbose exception reporting"

There is also the issue of service compliance. If i am accessing data
through the WMS service shouldn't I always get a WMS service exception
back? The specs often place restrictions on things like error codes, etc...
that should be returned in specific error cases. That info would be lost
here.

I cannot think of a case where we'd lose the info for the specific issue of
rendering transformations, because they are running inside the
StreamingRenderer, when that happens the StreamingRenderer has to wrap the
exceptions inside a RuntimeException (the paint
method cannot throw checked exceptions), which go straight to the
Dispatcher error handler, so there is never a code nor a location
to start with.
You are right that the special exception treatment will set a code and a
location that might be foreign to WMS, but I don't see the
spec forbidding using extra code. It says, however, some about the codes
that it defines (right above Table E.1, page 71):
"This International Standard defines several exception codes in Table E.1.
Servers shall not use these codes for
meanings other than those specified. Clients may use these codes to
automate responses to service exceptions."

One example:
"InvalidPoint", "GetFeatureInfo request contains invalid I or J value."

So indeed if a process used InvalidPoint to speak about one of its inputs,
and the exception was throws running GetMap,
it would end up violating the spec.

That said, these cases seems relatively unlikely, I would just point out
these issues in the special exception javadoc
and make this the implementors responsibility (after all, any code using
the existing
HttpErrorCodeException is in the same boat, using it in a normal pre OWS
2.0 service will result in a spec violation too,
not only we don't use valid codes anymore, we don't build a service
exception at all... btw, we should probably amend the
javadoc of that exception too to clarify this).

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 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

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

9

On Thu, Jun 12, 2014 at 2:23 AM, Andrea Aime <andrea.aime@anonymised.com>
wrote:

On Thu, Jun 12, 2014 at 12:07 AM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:

Wondering about cases where delegation goes on and internally one
service delegates to another? Following this approach as I understand it
the delegate service exception is what would be reported unless the
delegating service is also a direct exception... hence my question above.

I see. WPS wise, the issue might occur if the process is used as a
rendering transformation... which is probably what we want anyways, or not?

Hmmmm... not so sure. The outer exception gives us context about the
entire request chain. I find this information useful when all I have to go
off of is a users stack trace.

The full stack trace would still be available in the logs. By default, we
don't generate full stack traces, but you're right that they are available
when one enables "verbose exception reporting"

There is also the issue of service compliance. If i am accessing data
through the WMS service shouldn't I always get a WMS service exception
back? The specs often place restrictions on things like error codes, etc...
that should be returned in specific error cases. That info would be lost
here.

I cannot think of a case where we'd lose the info for the specific issue
of rendering transformations, because they are running inside the
StreamingRenderer, when that happens the StreamingRenderer has to wrap the
exceptions inside a RuntimeException (the paint
method cannot throw checked exceptions), which go straight to the
Dispatcher error handler, so there is never a code nor a location
to start with.
You are right that the special exception treatment will set a code and a
location that might be foreign to WMS, but I don't see the
spec forbidding using extra code. It says, however, some about the codes
that it defines (right above Table E.1, page 71):
"This International Standard defines several exception codes in Table E.1.
Servers shall not use these codes for
meanings other than those specified. Clients may use these codes to
automate responses to service exceptions."

One example:
"InvalidPoint", "GetFeatureInfo request contains invalid I or J value."

So indeed if a process used InvalidPoint to speak about one of its inputs,
and the exception was throws running GetMap,
it would end up violating the spec.

That said, these cases seems relatively unlikely, I would just point out
these issues in the special exception javadoc
and make this the implementors responsibility (after all, any code using
the existing
HttpErrorCodeException is in the same boat, using it in a normal pre OWS
2.0 service will result in a spec violation too,
not only we don't use valid codes anymore, we don't build a service
exception at all... btw, we should probably amend the
javadoc of that exception too to clarify this).

Not sure if HttpErrorCodeException is a good precedent since afaik it isn't
really used in error cases. The only usages of it I see are for KML for
empty regions, which doesn't really work like in a typical OGC context, and
for Caching WMS to send back a Not Modified, which isn't an error case.

When you say leave it up to the implementor to deal with how would that
look if they wanted to throw back the right exception for the service? They
would to have to retype the exception to another type?

Anyways, it would be nice to hear from others with an opinion. And since we
are talking of potential spec breaking I am thinking a GSIP may be in order.

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 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

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

--
*Justin Deoliveira*
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive <https://twitter.com/j_deolive&gt;

10

On Thu, Jun 12, 2014 at 4:17 PM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:

That said, these cases seems relatively unlikely, I would just point out

these issues in the special exception javadoc
and make this the implementors responsibility (after all, any code using
the existing
HttpErrorCodeException is in the same boat, using it in a normal pre OWS
2.0 service will result in a spec violation too,
not only we don't use valid codes anymore, we don't build a service
exception at all... btw, we should probably amend the
javadoc of that exception too to clarify this).

Not sure if HttpErrorCodeException is a good precedent since afaik it
isn't really used in error cases. The only usages of it I see are for KML
for empty regions, which doesn't really work like in a typical OGC context,
and for Caching WMS to send back a Not Modified, which isn't an error case.

My point was, it's there, and it can be abused in any way by implementors
(process ones too).

When you say leave it up to the implementor to deal with how would that
look if they wanted to throw back the right exception for the service? They
would to have to retype the exception to another type?

They would have to build a specific subclass that implements the marker
interface.
That said.. where is it that we are actually recognizing the exceptions
that way? Like, in WMS we throw only ServiceException, there is no such a
thing as
WMSException, and where we have it, are we really making use of it, or is
it more just a convention that we adopted?
When Gabriel refactored the hell out of WMS he dropped WMServiceException
under the notion that is was useless... I was not too happy at the time,
but indeed I cannot say I've ever needed a special subclass for it.

Anyways, it would be nice to hear from others with an opinion. And since
we are talking of potential spec breaking I am thinking a GSIP may be in
order.

Yep, let's hear from others

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 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

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