Missing instrumented class in my tc-config.xml

Wessel, Keith William kwessel at illinois.edu
Wed Aug 8 12:10:35 EDT 2012

For anyone interested, I've added the reported missing class to my boot jar file so that users who do something crazy like switch NetIDs mid-session will get something more useful than a blank screen. It's not much more useful, but at least they know they broke something:

The system encountered an error at Wed Aug 8 10:50:59 2012
To report this problem, please contact the site administrator at
consult at illinois.edu
Please include the following message in any email:
opensaml::FatalProfileException at (https://shib-sp-dev.cites.illinois.edu/Shibboleth.sso/SAML2/POST)
SAML response contained an error.
Error from identity provider:
Status: urn:oasis:names:tc:SAML:2.0:status:Responder
Sub-Status: urn:oasis:names:tc:SAML:2.0:status:AuthnFailed

Seems our developers are happy with anything rather than nothing, so that's where we're leaving it. If anyone has suggestions at a prettier error message, I'd love to hear about them.


-----Original Message-----
From: Wessel, Keith William 
Sent: Tuesday, August 07, 2012 4:34 PM
To: users at shibboleth.net
Subject: RE: Missing instrumented class in my tc-config.xml

Looking in the list archives a little depper and checking my log again, I see that this is the dreaded "Authenticated principal does not match previously authenticated principal" error.

Our developers got this by using different test NetIDs with forcedAuth enabled within a single IDP session.

They were trying to handle the case that someone lets an officemate log into the app shortly after they were logged in and did an SP logout.

So, amending my earlier question, I'm not going to add this class to the boot jar to fix the problem of principals changing. Rather, I'm going to do it so that the user gets something other than a blank screen in their browser which is the current result.

I'm guessing the below actions from my last message should address this, but I'm still wanting to make sure I add it right. So, my below questions are still out there if someone wants to give them a shot.


-----Original Message-----
From: Wessel, Keith William 
Sent: Tuesday, August 07, 2012 2:55 PM
To: users at shibboleth.net
Subject: Missing instrumented class in my tc-config.xml


We've just had our first SP hit our IDP cluster that has forced authentication enabled, and it looks like they found a missing instrumented class in our tc-config.xml. As this isn't in the tc-config.xml on the wiki either, I thought I should ask before adding it to make sure Terracotta's coaching me right.

Below is the block from the idp-process.log spit out by Terracotta telling me what to do.

1. Is it safe to add this instrumented-class to tc-config.xml?
2. Do I need to add any honor-transient tag to the block and mark it as true as is seen in many of the others?
3. Is there a reason this sin't in tc-config.xml on the wiki?

Thanks. Block frm thelog is:

Attempt to set the field of a shared object to an instance of a non-portable class. This
unshareable class has not been included for sharing in the configuration.

For more information on this issue, please visit our Troubleshooting Guide at:

Thread                 : TP-Processor144
JVM ID                 : VM(35)
Non-portable field name: edu.internet2.middleware.shibboleth.idp.authn.LoginContext.authnException
Non-included class     : edu.internet2.middleware.shibboleth.idp.authn.ForceAuthenticationException

Under most circumstances, you should only be adding classes for your
application. If you are adding classes for frameworks or code not written by
you, then you should consider finding a Terracotta Integration Module (TIM)
that matches the framework you are using.

As an example, if the non-portable class listed below is
net.sf.ehcache.CacheManager, you should consider using the ehcache TIM.

It is also possible that some or all of the classes above are truly
non-portable, the solution is then to mark the referring field as transient.
For more information on non-portable classes see the Troubleshooting Guide.

Action to take:

1) Reconfigure to include the unshareable classes
   * edit your tc-config.xml file
   * locate the <dso> element
   * add this snippet inside the <dso> element


   * if there is already an <instrumented-classes> element present, simply add
     the new includes inside it


PS: Scott, I'm starting to think you're right that life would be easier without Terracotta. No, I'm past starting, actually.

More information about the users mailing list