[jira] [Resolved] (SLING-6764) Guard against reflection failures when registering Sling Model classes

["Justin Edelson (JIRA)" <ji...@apache.org>]

     [ 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)