Justin Edelson created SLING-6764:
-------------------------------------
Summary: Guard against reflection failures when registering Sling
Model classes
Key: SLING-6764
URL: https://issues.apache.org/jira/browse/SLING-6764
Project: Sling
Issue Type: Improvement
Components: Extensions
Reporter: Justin Edelson
Assignee: Justin Edelson
Fix For: Sling Models Impl 1.3.10
While troubleshooting a Sling Models application today, I ran across an
interesting case which I think we should better guard against.
The model class had a dependency upon a class which was in an optionally
imported package (which was not present). When the bundle started, Sling
Models' BundleListener tried to instantiate the class and (due to the missing
package) failed to do so. Obviously, the problem here is that the import wasn't
*actually* optional.
The problem was two fold:
1) If the problematic bundle was already active when the Sling Models bundle
was activated (or updated), there was a NoClassDefError throw inside the
ModelAdapterFactory's activate method causing the component to not be fully
active. I also suspect that the deactivate method would never have been called,
although I didn't get that far.
2) If the problematic bundle was active after the Sling Models bundle was
activated, then the one problematic model class halted further processing of
model classes in that bundle.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
