When JSON support was added in APEX, I was one of those guys who jumped up and down. Started using heavily for one of my integration project and everything was fine and dandy for couple week. Since yesterday, I have been noticing some weired behavior. The first time I noticed it, I thought it was one of those APEX issues I love to call "APEX weirdness" and hoped that it will fix itself (READ: getting fixed without us knowing). That hasn't happened. :(

Here is the issue. 

My JSON parsing code looks like this:

class SomeApexWrapper {

public static SomeApexWrapper getInstance(String jsonString)

JSONParser parser = JSON.createParser(jsonString);       

SomeApexWrapper w = (SomeApexWrapper) parser.readValueAs(SomeApexWrapper.class);

}

}

This code was working fine until two days ago. It stops working If I change any class that uses this class to parse json string. The error I get is "[Source: java.io.StringReader@21363a13; line: 1, column: 1] Don't know the type of the Apex object to deserialize"

Just saving the SomeApexWrapper  class again fixes the issue. 

Has anyone had/having this issue? Is there a permanent solution for this?

Hello,

I'm using the following command to generate the java skeleton code for the enterprise.wsld

jaxws-ri/bin/wsimport.sh -p stubs -d stubs-build -s stubs-src enterprise.wsdl

I'm getting the following errors. Does anyone know why?

Thank you.

[WARNING] src-resolve: Cannot resolve the name 'ens:sObject' to a(n) 'type definition' component.
  line 2581 of file:/C:/Jazz/salesforce/jaxws-ri/bin/enterprise.wsdl#types?schema2

[ERROR] A class/interface with the same name "com.sforce.soap.enterprise.DescribeLayout" is already in use. Use a class customization to resolve this conflict.
  line 3289 of file:/C:/Jazz/salesforce/jaxws-ri/bin/enterprise.wsdl

[ERROR] (Relevant to above error) another "DescribeLayout" is generated from here.
  line 3088 of file:/C:/Jazz/salesforce/jaxws-ri/bin/enterprise.wsdl

[ERROR] Two declarations cause a collision in the ObjectFactory class.
  line 3088 of file:/C:/Jazz/salesforce/jaxws-ri/bin/enterprise.wsdl

[ERROR] (Related to above error) This is the other declaration.  
  line 3289 of file:/C:/Jazz/salesforce/jaxws-ri/bin/enterprise.wsdl

So, I have an Apex class that uses version 10.0 of the API (Summer '07) and it references a standard SF field called UserPermissionsAvantgoUser. I can't find reference to this anywhere else but here.

Yesterday (19th May) I started receiving Apex exceptions that stated that the field does not exist, which appears to be true if you look at the meta-data for the user object.

Simple, you might think; just remove the field from the class definition in a sandbox and deploy to production through eclipse. Unfortunately, SF won't let me overwrite the class, because, according to the validation error, the original class in production is referencing a non-existant field. Catch 22...

Apart from breaking a critical web app that we've built around this class, it is also disrupting normal operation of SF because we have triggers firing on contact edits which get stuck in the invalid code, even though the triggers only apply to a subset of contacts. I'm not a happy bunny.

I've raised a support case and hope to hear back ASAP, but was wondering if anyone else has been hit by this silent change to the backwards compatibility of the API? Any workarounds for when you are denied a class overwrite due to invalid code in production?