Re: Question about error handling
org.apache.usergrid.rest.exceptions.UncaughtException","error_id":"f5752c99-31d9-11e6-b858-080027cf389a"} On 16/06/16 22:43, Dave wrote: > Hi Petteri, > > That's definitely a bug; Usergrid should never return HTTP 500 > internal server error unless Cassandra or ElasticSearch is > inaccessible. Is there a stack trace that goes along with that error? > > Dave > > > On Tue, Jun 14, 2016 at 10:38 AM Petteri Sulonen > <petteri.sulo...@avaintec.com <mailto:petteri.sulo...@avaintec.com> <mailto:petteri.sulo...@avaintec.com <mailto:petteri.sulo...@avaintec.com>>> > wrote: > > Hi, everybody -- > > I'm evaluating Usergrid for our cloud services, and am starting to > come > to grips with it. I have a question about error handling. > > I've noticed that the errors Usergrid returns seem somewhat > inconsistent. For example, when attempting to GET an entity that > doesn't > exist directly from the collection (omitting org and app from path for > clarity): > > GET /things/ferrari > > will return an error "entity_not_found", but attempting to GET the > same > entity through a connection where I "own" the entity: > > GET /users/me/owns/things/ferrari > > will return an "uncaught" error, with error_description "Internal > Server > Error." > > Is this intentional? I was expecting to get an "entity_not_found" > error > in both cases, as I think this would be a pretty common situation to > have in a system where entities are created and deleted dynamically. > > (If /things/ferrari actually exists and I own it, both queries > return it > as expected, so that's cool.) > > If I've understood the design intent behind Usergrid correctly, these > connections are extremely important because I can map permissions to > them. Therefore it's not always possible to access objects directly > under the collection, as the user may only have permission to access > objects through a connection (e.g. "owns"). I like this scheme a lot, > it's simple, intuitive, yet powerful. > > If I've misunderstood something, I would greatly appreciate being set > straight. > > Thanks in advance, > > Petteri > > smime.p7s Description: S/MIME Cryptographic Signature
Re: Question about error handling
645)
> at
>
> org.apache.usergrid.services.ServiceRequest.execute(ServiceRequest.java:245)
> at
>
> org.apache.usergrid.services.ServiceRequest.invokeMultiple(ServiceRequest.java:281)
> at
>
> org.apache.usergrid.services.ServiceRequest.execute(ServiceRequest.java:248)
> at
>
> org.apache.usergrid.services.ServiceRequest.execute(ServiceRequest.java:212)
> at
>
> org.apache.usergrid.rest.applications.ServiceResource.executeServiceRequest(ServiceResource.java:315)
> at
>
> org.apache.usergrid.rest.applications.ServiceResource.executeGet(ServiceResource.java:361)
> at sun.reflect.GeneratedMethodAccessor115.invoke(Unknown Source)
> at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
>
> com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
> at
>
> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
> at
>
> com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
> at
>
> com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
> at
>
> com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:137)
> at
>
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
> at
>
> com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:137)
> at
>
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
> at
>
> com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:137)
> at
>
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
> at
>
> com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:137)
> at
>
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
> at
>
> com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:137)
> at
>
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
> at
>
> com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:137)
> at
>
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
> at
>
> com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:137)
> at
>
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
> at
>
> com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
> at
>
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
> at
>
> com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
> at
>
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1542)
> at
>
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1473)
> ... 38 more
> 04:44:47,717 ERROR AbstractExceptionMapper:106 - Server Error (500):
>
> {"error":"uncaught","timestamp":1465872287717,"duration":0,"error_description":"Internal
> Server
>
> Error","exception":"org.apache.usergrid.rest.exceptions.UncaughtException","error_id":"f5752c99-31d9-11e6-b858-080027cf389a"}
>
>
>
>
> On 16/06/16 22:43, Dave wrote:
> > Hi Petteri,
> >
> > That's definitely a bug; Usergrid should never return HTTP 500
> > internal server error unless Cassandra or ElasticSearch is
> > inaccessible. Is there a stack trace that goes along with that error?
> >
> > Dave
> >
> >
> > On Tue, Jun 14, 2016 at 10:38 AM Petteri Sulonen
> > <petteri.sulo...@avaintec.com <mailto:petteri.sulo...@avaintec.com>>
> > wrote:
> >
> > Hi, everybody --
> >
> > I'm evaluating Usergrid for our cloud services, and am starting to
> > come
> > to grips with it. I have a question about error handling.
> >
> > I've noticed that the errors Usergrid returns seem somewhat
> > inconsistent. For example, when attempting to GET an entity that
> > doesn't
> > exist directly from the collection (omitting org and app from path
> for
> > clarity):
> >
> > GET /things/ferrari
> >
> > will return an error "entity_not_found", but attempting to GET the
> > same
> > entity through a connection where I "own" the entity:
> >
> > GET /users/me/owns/things/ferrari
> >
> > will return an "uncaught" error, with error_description "Internal
> > Server
> > Error."
> >
> > Is this intentional? I was expecting to get an "entity_not_found"
> > error
> > in both cases, as I think this would be a pretty common situation to
> > have in a system where entities are created and deleted dynamically.
> >
> > (If /things/ferrari actually exists and I own it, both queries
> > return it
> > as expected, so that's cool.)
> >
> > If I've understood the design intent behind Usergrid correctly, these
> > connections are extremely important because I can map permissions to
> > them. Therefore it's not always possible to access objects directly
> > under the collection, as the user may only have permission to access
> > objects through a connection (e.g. "owns"). I like this scheme a lot,
> > it's simple, intuitive, yet powerful.
> >
> > If I've misunderstood something, I would greatly appreciate being set
> > straight.
> >
> > Thanks in advance,
> >
> > Petteri
> >
> >
>
>
>
Re: Question about error handling
)
at
com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:137)
at
com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at
com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
at
com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at
com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
at
com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1542)
at
com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1473)
... 38 more
04:44:47,717 ERROR AbstractExceptionMapper:106 - Server Error (500):
{"error":"uncaught","timestamp":1465872287717,"duration":0,"error_description":"Internal
Server
Error","exception":"org.apache.usergrid.rest.exceptions.UncaughtException","error_id":"f5752c99-31d9-11e6-b858-080027cf389a"}
On 16/06/16 22:43, Dave wrote:
Hi Petteri,
That's definitely a bug; Usergrid should never return HTTP 500
internal server error unless Cassandra or ElasticSearch is
inaccessible. Is there a stack trace that goes along with that error?
Dave
On Tue, Jun 14, 2016 at 10:38 AM Petteri Sulonen
<petteri.sulo...@avaintec.com <mailto:petteri.sulo...@avaintec.com>>
wrote:
Hi, everybody --
I'm evaluating Usergrid for our cloud services, and am starting to
come
to grips with it. I have a question about error handling.
I've noticed that the errors Usergrid returns seem somewhat
inconsistent. For example, when attempting to GET an entity that
doesn't
exist directly from the collection (omitting org and app from path for
clarity):
GET /things/ferrari
will return an error "entity_not_found", but attempting to GET the
same
entity through a connection where I "own" the entity:
GET /users/me/owns/things/ferrari
will return an "uncaught" error, with error_description "Internal
Server
Error."
Is this intentional? I was expecting to get an "entity_not_found"
error
in both cases, as I think this would be a pretty common situation to
have in a system where entities are created and deleted dynamically.
(If /things/ferrari actually exists and I own it, both queries
return it
as expected, so that's cool.)
If I've understood the design intent behind Usergrid correctly, these
connections are extremely important because I can map permissions to
them. Therefore it's not always possible to access objects directly
under the collection, as the user may only have permission to access
objects through a connection (e.g. "owns"). I like this scheme a lot,
it's simple, intuitive, yet powerful.
If I've misunderstood something, I would greatly appreciate being set
straight.
Thanks in advance,
Petteri
smime.p7s
Description: S/MIME Cryptographic Signature
Question about error handling
Hi, everybody -- I'm evaluating Usergrid for our cloud services, and am starting to come to grips with it. I have a question about error handling. I've noticed that the errors Usergrid returns seem somewhat inconsistent. For example, when attempting to GET an entity that doesn't exist directly from the collection (omitting org and app from path for clarity): GET /things/ferrari will return an error "entity_not_found", but attempting to GET the same entity through a connection where I "own" the entity: GET /users/me/owns/things/ferrari will return an "uncaught" error, with error_description "Internal Server Error." Is this intentional? I was expecting to get an "entity_not_found" error in both cases, as I think this would be a pretty common situation to have in a system where entities are created and deleted dynamically. (If /things/ferrari actually exists and I own it, both queries return it as expected, so that's cool.) If I've understood the design intent behind Usergrid correctly, these connections are extremely important because I can map permissions to them. Therefore it's not always possible to access objects directly under the collection, as the user may only have permission to access objects through a connection (e.g. "owns"). I like this scheme a lot, it's simple, intuitive, yet powerful. If I've misunderstood something, I would greatly appreciate being set straight. Thanks in advance, Petteri smime.p7s Description: S/MIME Cryptographic Signature
