I receive an error "TRANSFER_REQUIRES_READ"  if I try to change the OwnerId of a custom object in my unit tests. I have tried setting the role of the user in question (within the unit test) to our "System Administrator" role, but this yields nothing, I still get the same error. I've also attempted to create a UserRecordAccess object in the test with UserId set to this user, HasReadAccess set to `true', and RecordId set to the custom object, but Salesforce rejects this as well, returning an error stating that UserId field is read-only on UserRecordAccess objects.

I configured an email service in a sandbox environment. I set it up to receive from all email addresses and to bounce on any sort of error. I also set the service up to route all error emails to my email address. I then added a single email address for this new email service.

In my testing, I could see clearly in the debug logs that my emails were being sent to this service address as expected, with all the calls to Messaging methods looking good. I could see that my service handler class was being considered, because I would receive an email when the class had errors which are caught by static analysis (invalid type casts, in this case). So, I fixed those errors and tried to send to this address again.

Strangely, I cannot at all get my email service handler code to execute in this sandbox. A similar service (the configuration is identical as far as I can see) has run smoothly in our production org for many months and I do not have an immediate reason to suspect it. I added code to this handler which immediately should send me an email with the contents of the inbound message as this notification's body. However, even this simple action never occurs, and I never receive the email from the service handler.

It seems that this is some configuration issue, but allow me to show my code.

Here is the code that I use from the Developer Console to send a simple message to my email service:

Messaging.SingleEmailMessage msg = new Messaging.SingleEmailMessage();
msg.setToAddresses(new String[] {
    /* The email service's address */
});
msg.setSubject('test');
msg.setPlainTextBody('Test');
Messaging.sendEmail(new Messaging.SingleEmailMessage[] { msg });

And here is the code from the top of my service handler:

global Messaging.InboundEmailResult handleInboundEmail(
            Messaging.InboundEmail email, 
            Messaging.InboundEnvelope envelope) {
    String body = email.plainTextBody;
    Messaging.SingleEmailMessage mail = new Messaging.SingleEmailMessage();
    String[] testAddresses = new String[] {
        /* My personal address */
    };
    mail.setToAddresses(testAddresses);
    mail.setSubject('Response');
    mail.setPlainTextBody(body);
    Messaging.sendEmail(new Messaging.SingleEmailMessage[] { mail });

Does anybody have an idea about what is going on? I also tried composing a plain email from my mail client and sending it to the service address, and got no reply/bounce/anything of the sort.

I do not see that Apex exposes a class data type. Is this correct? Is there no way to assign a class to a variable in Apex? My research thus far indicates that Apex does not support any sort of metaprogramming, not even string evaluation. It seems most issues surrounding this question are centered on standard/custom object reflection, but I am seeking a way to pass classes around such that `Class myClass = SomeApexClass` can be instantiated with `new myClass(args...)`.

I recently upgraded my Force.com IDE (and all projects) to the Winter '12 release. Since upgrading, I've been observing that when I attempt to run unit tests against an Apex class, it often takes a very long time to execute. Even relatively simple tests sometimes take a minute or two to complete. The time doesn't seem to be spent during test execution, but rather during the "preparing results..." phase (based on the progress indicator in the IDE). Reducing the log level doesn't seem to have any impact one way or the other. I've also seen it simply get stuck in the "preparing results..." phase to the point where I had to kill the Eclipse process. Anyone else seeing this?