Debugging scripted attribute definition compilation problems

[Wessel, Keith William]

So sorry, Brent! I was barking up the wrong tree and should have done some more googling before emailing.

I was using aacli.sh which I SHOULD have mentioned... and I was getting the NoClassDefFoundError exception for javax/serverlet/ServletRequest. A post from Nate from a while back reminded me to symlink $CATALINA_HOME/lib/servlet_api.jar into $IDP_HOME/lib. Put that in, and guess what? Now my javascript errors are going to the IDP logs.

Sorry abourt that!

Nate's helpful post:
http://shibboleth.1660669.n2.nabble.com/aacli-sh-java-exception-td7579873.html

Thanks, and sorry for not giving you the big picture. Had I been running within Tomcat, this wouldn't have happened.

Keith


-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Brent Putman
Sent: Thursday, October 25, 2012 5:20 PM
To: users at shibboleth.net
Subject: Re: Debugging scripted attribute definition compilation problems


On 10/25/12 5:47 PM, Wessel, Keith William wrote:
> Thanks, Brent. Good to better understand that logging.xml isn't a comprehensive set of classes that log.

Right, it's just standard Java logging.  By convention, most classes log
to a logging category that is the same as the class name, so the list of
possible log categories is very large.  The categories are arbitrary,
however, and there are some exceptions, like for example the IdP's
access, audit and protocol message logs.

>
> Unfortunately, javax.script gave me nothing. I also tried various levels of con.sun.phobos.script.javascript.RhinoScriptEngineFactory all the way down to just com.sun.phobos as I see that class in the js jar included in the IDP.

Yeah, that would have been my next suggestion, look at the actual
implementation classes of the JSR-223 API (the Java scripting API).


>  Also, no bo, even with my log level set to ALL.
>
> Any other suggestions?


So are you literally getting no logging from any of those classes?  That
would be unusual. It's possible that, because of the way they do the
logging, it's not getting routed into the slf4j and logback framework
that we use.  We have adapters for the common things like log4j and JULI
and Apache commons logging, but perhaps that's not working in this case
for some reason.  You might check all your various container logs,
perhaps something is making it's way there, such as via stdout or stderr.

As a last resort, you might just turn on DEBUG for everything (the
<root> logger).  Warning, that will spew lots of stuff, but perhaps that
might reveal something.  Could be that the class/package in question
isn't one of the ones you've previously guessed.

Otherwise, I don't have any other suggestions at the moment.  I haven't
used the scripting plugins enough to have dealt with compilations
problems like that.  Perhaps someone else on the list has.


--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net