[Building Sakai] Getting root EntityBroker errors/exceptions

Steven Githens swgithen at mtu.edu
Wed Apr 29 08:32:24 PDT 2009


Aaron Zeckoski wrote:
> You can turn on emailing of errors using
> "direct.error.email=blah at something.com" in sakai.properties but this
> is not what you want.
>
> The original exception from getUserMemberships is attached to this
> exception but not printed out by default. I could probably add in an
> option to print more information if you want but this one looks fairly
> clear. There are a few exceptions I handle explicitly and all the rest
> just pass through. These ones are handled because they can be thrown
> from the provider to indicate certain conditions as per the javadoc:
> SecurityException - operation not allowed - becomes 401/403
> EntityNotFoundException - not found - becomes 404
> FormatUnsupportedException - invalid type requested - becomes 406
> IllegalArgumentException (this one) - request does not have valid
> argument - becomes 400
> UnsupportedOperationException - attempted to perform invalid operation
> - becomes 400
>
> I would recommend getting out the debugger in this case anyway, but if
> that is not enough then I can probably add an option to handle the
> error more explicitly.
>   
I think we'll need some option to display more of the regular 
information in the logs for development.  Will no line number or fully 
qualified java class/method name it's pretty hard to get moving.  I'm 
not even sure where I would set a break point if I wanted to look at the 
entity broker exception. ( Well I do, but I'm not sure if other people 
would, although I ran into this for something else a few days ago, and 
just the breakpoint in the constructors for the Java SDK exceptions to 
figure out who was making them. ).

This one was sort of easy because it was in the same project and I could 
grep for the message, but it seems inevitable to cause headaches for 
tracking down sometimes simple things.  ( Like this problem would have 
been pretty easy to see with just a stacktrace and not a debugger. ).

But yeah, since we are supposed to throw those to signal HTTP return 
codes sometimes, it would make sense that they wouldn't always want to 
be in there.

Would it be possible to at least add the line number and fully qualified 
location of the exception to the existing output?  I would say even if 
it was intentional to throw these, that we would still want these, 
especially for logging in production.

And then maybe have the option to turn on full stack traces for everything.

-s
> -AZ
>
>
> On Wed, Apr 29, 2009 at 3:39 PM, Steven Githens <swgithen at mtu.edu> wrote:
>   
>> Hi all,
>>
>> This is on Sakai trunk.  I wonder if I'm missing a logging level or
>> configuration property, but how do we turn on output for the original
>> exception errors in the logs for EntityBroker feeds.  It makes sense
>> that we don't want it to show up in the browser, but right now in the
>> logs it just gives the exception message with no line number or stack trace:
>>
>> Ex:
>> WARN Could not process entity: /assignment2 (400)[null]: Cannot execute
>> custom action (sitelist): Illegal arguments: Null userId or contextId
>> passed to getUserMemberships (rethrown)
>>
>> Thanks,
>> Steve
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>
>>     
>
>
>
>   



More information about the sakai-dev mailing list