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).
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://p.sf.net/sfu/hpccsystems
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
