On Thu, Jun 12, 2014 at 2:23 AM, Andrea Aime <[email protected]>
wrote:
> On Thu, Jun 12, 2014 at 12:07 AM, Justin Deoliveira <
> [email protected]> 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
[email protected]
@j_deolive <https://twitter.com/j_deolive>
------------------------------------------------------------------------------
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://p.sf.net/sfu/hpccsystems
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
