[
https://issues.apache.org/jira/browse/SLING-8069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved SLING-8069.
------------------------------------
Resolution: Fixed
Fixed in
[https://github.com/apache/sling-org-apache-sling-models-impl/commit/d56cf5f3013c2095b876c408510c29ec71ea3b05.]
[~paul.bjorkstrand] Thanks a lot for the contribution and your patience.
> Sling Models: Enable constructor injection to use non-public constructors
> -------------------------------------------------------------------------
>
> Key: SLING-8069
> URL: https://issues.apache.org/jira/browse/SLING-8069
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
> Affects Versions: Models Impl 1.4.10
> Reporter: Paul Bjorkstrand
> Assignee: Konrad Windszus
> Priority: Minor
> Fix For: Models Implementation 1.5.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> In Sling Models, you cannot use a non-public constructor to inject. Looking
> through the code, there doesn't seem to be any clear reason for this
> restriction. In my opinion, constructor injection should allow any
> constructor visibility.
> Here are some discussion points:
> * Private fields are allowed for use, so disallowing private constructors
> seems unnecessary.
> * Private constructors may be bad practice (difficult to test), but Sling
> should not be telling users how to write their Java code. This is especially
> true for models, since it should work with POJOs, as stated in the
> documentation. It would be trivial to add checks to just allow default,
> protected, or public, but I feel that logic is unnecessary.
> * Non-public methods could also be allowed, but that can be a separate
> ticket.
> ** A prerequisite of this would be to allow setter injection on models in
> the first place. Again, not the subject of this ticket.
> * Threading concerns are minimal, but there could be possible deadlocks, as
> with any multi-threaded application that uses locks. In general, I think
> locking similar to how it is done in {{InjectableField}} would be sufficient.
> The risk of deadlock would be similar to the risk of the locking in
> {{injectableField.set(Object, Result<Object>)}}.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
