CODES.getAllCodeTypes() is a convenience wrapper for ICodeService.getAllCodeTypes().
And the default scout implemementation CodeService.getAllCodeTypes() contains a default implementation that tries to optimize the trade-off between expensive full-code spidering and best coding practice.
However i would recommend to use a custom CodeService in such cases that subclass scout CodeService or fully implement ICodeService.
This is also useful to adapt code caching and discovery needs to the project needs.
I do not quite agree. The default implementation's intention is surely good (speed!), but if you are not aware of the behaviour you can easly spend lots of time debugging your code... I think the least one could have expected is, that this "tweak" is documented. All I could find (Scout 3.8 ) is the JavaDoc on ICodeService.getAllCodeTypeClasses(classPrefix) that says "returns all codetype classes from bundles with classPrefix". This clearly does not hold for the default implementation when you pass "" as classPrefix.
Besides, how much of a performance boost is it really? Can we really save time by not looking at classes that do not start with the bundle symbolic name? (Especially if you follow the convention to always prefix your classes with the BSN.)
Thanks for the comments. Good points.
However in order to help I need at least a proposals for a change or a javadoc enhancement.
Otherwise it will stay as is (see post from Thu, 11 April 2013 12:28)
Maybe the javadoc enhancement would be a good point to start.
If agreed, please create a bugzilla with specific content.
Bundle symbolic name (BSN): com.myapp.shared.core
Code type class:
With the current implementation:
The result of CodeService#getAllCodeType(String) is the same:
* CodeType1 and CodeType2 are found,
* CodeType3 is not found
This is independently from the classPrefix value:
Meaning that classPrefix parameter is totally ignored when it comes to look for the CodeType classes.
The contract of the ICodeService#getAllCodeType(String) defined on the interface is not clear. The problem is this classPrefix String parameter. This should be defined independently form the current CodeService implementation (and the optimization choices that have been made there).
We can say:
1. The String parameter is a "context" speeding up the bundle lookup by providing some context (approximate name of the bundle). It can be ignored by the class implementing the Interface. [This is more or less the semantic today]
2. All the founded classes need to have their absolute name starting with this prefix. [this would be a semantic modification]
Additionally to that, the default CodeType Service makes the choice to implement the contract by ignoring the classes that are not located in a java package that is a subpackage of the BSN (bundle symbolic name). This is acceptable because it is a good practice. We just need to document it properly in order to let people know (and avoiding time lost like for myself).
Can you tell what you think/know? It will help for the redaction of the bug.