5

When I query SymbolTable using Tooling API there are not any protected modifiers at all! Every protected word is replaced with private. The field classBody shows all protected keywords as they are but SymbolTable doesn't show any of them.

What is the reason for that? Is that a bug or it has some sense?

  • Have you logged a case with Salesforce Support? – Marty C. Dec 9 '14 at 22:32
  • I can't open an issue because I have only developer edition account. Or do you mean something else? I would like to do something like that but don't know how. – Liudmila Likhovid Dec 9 '14 at 22:35
  • No, you're right. If you're not a Salesforce customer or partner, I don't think you'll be able to log a case. :-( – Marty C. Dec 9 '14 at 23:19
  • Even if you are a partner but without premier support, they close the case if it's related to development. Sounds like a bug. Would be great if someone with PS could report it. – Uwe Heim Dec 10 '14 at 9:54
  • I see you've raised the question on the developer forums. I've found support will usually get back to you in a week (or month...). It is a frustratingly slow way to raise a platform bug/issue, but it usually pays off if you are persistent. – Daniel Ballinger Dec 18 '14 at 7:28
6

Update from Salesforce support:

I checked with R&D regarding this, and they are releasing an enhancement to allow all modifiers in the next version of the API, which is 34 (Summer '15). -Shashank
Source


It appears that at the API level protected isn't supported.

Extract from the Tooling API v32.0 WSDL:

<xsd:simpleType name="SymbolVisibility">
 <xsd:restriction base="xsd:string">
  <xsd:enumeration value="Global"/>
  <xsd:enumeration value="Public"/>
  <xsd:enumeration value="Private"/>
 </xsd:restriction>
</xsd:simpleType>

Note the absence of protected. It can't be returned, so it appears they send back private instead.

You also see hints of this in the documentation for SymbolTable:

SymbolTable visibility options

It does seem odd the protected isn't represented, as it is valid in Apex access modifier.

  • Yeah I noticed this part in documentation later. Either it's odd or it has some meaning that we don't understand. – Liudmila Likhovid Dec 17 '14 at 23:40
  • I suspect it will take someone inside Salesforce to answer the why of it. A couple of guesses: 1) They based the API on what access modifiers were allowed for a constructor and did a hack work around for protected properties rather than add in protected. 2) protected access modifiers have some sort of odd internal representation that gets lost in the transition to a SymbolTable. – Daniel Ballinger Dec 18 '14 at 7:21
  • I work at Salesforce and can look into this. Curious to know myself. Querying ApexClass is a possible workaround, but requires parsing the Body: SELECT Id, Name, Body FROM ApexClass – dlog Dec 31 '14 at 5:49
  • @dlog Thanks, I'd be interested to know what comes of it. – Daniel Ballinger Dec 31 '14 at 8:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.