Cross Origin error except when trace logging enabled

I have a pretty standard spring REST service. It has been working just fine until one of our clients tried to use one particular method that had not been called from a browser before. This method is getting the familiar Cross Origin error. No other methods in our service get the error as we have implemented spring's version of a CORS filter.

We could not duplicate the error on our development or test systems, only on production. To try and figure out what was going on, we used Probe to temporarily set the production logs to TRACE. Suddenly the method worked perfectly, no error. We were able to confirm that setting the logs to TRACE or ALL on all 3 systems cleared the error, whereas DEBUG and above resulted in the error (development and test systems are default set to ALL). I have further narrowed it down to setting just our service implementation class to TRACE fixes the problem.

To make it even more confusing, I found a way to not get the error on that method regardless of the logging level. The input for that method is a session id in the standard format, such as 1891d2f2-3510-4e12-af62-132098424ae4. If I remove the hyphens, or basically put any value in there without hyphens, the method does not get a cross origin error. Of course the method does not return data, just the expected error of session id not found. But you wouldn't get that message if cross origin stops the call. Unfortunately I don't really have a way to create a valid session id without the hyphens. Other methods that have a session id as a parameter or as part of the request body do not get an error, only this one where the id is part of the url.

The versions we are using:

• Java 6


• Spring 4.1.4


• log4j 1.2.16


• Tomcat 7.0.52


• jquery 1.11.1

Example request URL:

http://ift.tt/1OWJJ8q

Controller Request Mapping:

@Autowired
private MyManagementService mms;

@RequestMapping(value="/getsession/{sessionId}", method=RequestMethod.GET)
@ResponseStatus(HttpStatus.OK)
@Transactional(readOnly=true)
public @ResponseBody Session getSession(@PathVariable("sessionId") String sessionId) throws MyServiceException {
    Session s = mms.getSession(sessionId);
    return s;
}

Implemented Service Method:

@Override
@Transactional(readOnly=true)
public Session getSession(String sessionId) throws MyRequestedDataNotFoundException {
    logger.info("Retrieve session [{}]", sessionId);
    Session session = Session.findSession(sessionId);
    if (session==null) {
        String message = String.format("Session [%s] was requested by [%s] but could not be found", sessionId, SecurityAttributeHelper.getAuthenticatedUser());
        logger.warn(message);
        throw new MyRequestedDataNotFoundException(message);
    }
    return session;
}

Javascript to call the method:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js" type="text/javascript">
<script type="text/javascript">
var $ = jQuery.noConflict();

$(document).ready(function () {
  $.support.cors = true;
});

function makeCall(turl,user,pass) {
  console.log(turl);
  $.ajax({
    url: turl,
    type: "GET",
    data: null,
    dataType: "json",
    headers: {
        "Authorization": "Basic " + btoa(user+":"+pass),
        "Content-Type": "application/json"
    },
    success : function(d){
        alert("Success");
        console.log(d);
    },
    error : function(e){
        alert("Error");
        console.log(e);
    }
  });
}
</script>

Sample of the logs when successful: (nothing in logs if error)

2015-03-31 21:35:13,484 TRACE ** >>> getSession: called by [MYUSER] starts with args([1891d2f2-3510-4e12-af62-132098424ae4]) ** com.mycompany.myservice.service.MyManagementServiceImpl
2015-03-31 21:35:13,486 INFO  ** Retrieve session [1891d2f2-3510-4e12-af62-132098424ae4] ** com.mycompany.myservice.service.MyManagementServiceImpl
2015-03-31 21:35:13,853 TRACE ** <<< getSession: called by [MYUSER] ends with data = [Session[key1=value1,key2=value2,key3=value3]] ** com.mycompany.myservice.service.MyManagementServiceImpl

To get around the issue, we have temporarily set that class file to TRACE in production, but that is not a good long term solution. Any ideas for what might be causing the problem?