sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Radu Cotescu (JIRA)" <>
Subject [jira] [Resolved] (SLING-7755) JavaUseProvider might attempt to instantiate interfaces or abstract classes
Date Mon, 27 Aug 2018 16:35:00 GMT


Radu Cotescu resolved SLING-7755.
       Resolution: Fixed
    Fix Version/s: Scripting HTL Testing 1.0.12-1.4.0
                   Scripting HTL Testing Content 1.0.12-1.4.0

Applied PRs in:
 # [commit 360df4e|]
 # [commit 5169606|]
 # [commit d41ff5a|]

> JavaUseProvider might attempt to instantiate interfaces or abstract classes
> ---------------------------------------------------------------------------
>                 Key: SLING-7755
>                 URL:
>             Project: Sling
>          Issue Type: Bug
>          Components: Scripting
>    Affects Versions: Scripting Sightly Engine 1.0.18
>            Reporter: Santiago García Pimentel
>            Assignee: Radu Cotescu
>            Priority: Major
>             Fix For: Scripting HTL Testing Content 1.0.12-1.4.0, Scripting HTL Testing
1.0.12-1.4.0, Scripting HTL Engine 1.0.56-1.4.0
>          Time Spent: 1h 20m
>  Remaining Estimate: 0h
> If you have a data-sly-use which receives a FQN of an interface or abstract class, the
Java Use provider will not make any checks and will try to instantiate it anyway, causing
a java.lang.NoSuchMethodException com.example.InterfaceName.<init>().
> This is a problem when your code base normally relies in an adapter factory to get implementation
of an interface and the adaptTo returns null, causing sightly to try the java Use provider
> The Java Use provider should not attempt to instantiate blindly classes that it receives.

This message was sent by Atlassian JIRA

View raw message