[
https://issues.apache.org/jira/browse/SLING-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson resolved SLING-6764.
-----------------------------------
Resolution: Fixed
fixed in r1789734
> 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)
