[
https://issues.apache.org/jira/browse/SLING-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14113815#comment-14113815
]
Konrad Windszus edited comment on SLING-3709 at 8/28/14 3:04 PM:
-----------------------------------------------------------------
[~sseif...@pro-vision.de] I still don't get what your proposal is. Do you mean
the following behaviour:
# call resource/request.adaptTo (e.g. through the CQ Sightly Use Provider).
# Sling Models will put the missing injections into a thread local and return
null for the adapter.
What happens now is that CQ Sightly Use Provider will then just instanciate a
simple pojo and you will see no difference in Sightly!
# You call Models.adaptToOrThrow which will check the thread local and throw
exceptions in case a previous call of adaptTo was not successfull?
Is that meant here?
What happens here with other exceptions (e.g. like reflection exceptions,
exceptions in the constructor or post construct)? Are those also stored in
thread local variables?
And to answer your question: I use my own Sling Servlet Filter to catch all
Exceptions and expose them in a nice fashion to the editor (not at all on
component level). That way you can also use the develop layer in AEM6 to expose
the errors.
was (Author: kwin):
[~sseif...@pro-vision.de] I still don't get what your proposal is. Do you mean
the following behaviour:
# call resource/request.adaptTo (e.g. through the CQ Sightly Use Provider).
# Sling Models will put the missing injections into a thread local and return
null for the adapter.
What happens now is that CQ Sightly Use Provider will then just instanciate a
simple pojo and you will see no difference in Sightly!
# You call Models.adaptToOrThrow which will check the thread local and throw
exceptions in case a previous call of adaptTo was not successfull?
Is that meant here?
What happens here with other exceptions (e.g. like reflection exceptions,
exceptions in the constructor or post construct)? Are those also stored in
thread local variables?
> Sling Models: Allow caller to deal with exceptions
> --------------------------------------------------
>
> Key: SLING-3709
> URL: https://issues.apache.org/jira/browse/SLING-3709
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
> Affects Versions: Sling Models Implementation 1.0.4, Sling Models
> Implementation 1.0.6
> Reporter: Konrad Windszus
> Labels: models
>
> Currently due to the specification of the adaptTo-method to return null if
> adaptation is not possible, the caller is not notified about any exceptions
> (because they are caught within the ModelAdapterFactory).
> This is e.g. necessary to deal with validation exceptions properly (i.e.
> required field injection not possible). The problem was also discussed
> briefly in
> http://apache-sling.73963.n3.nabble.com/Silng-Models-Validation-Framework-td4033411.html.
> All exceptions either being thrown by the
> @PostConstruct method or caused by the field/method injection are not
> propagated but basically swallowed by Sling Models.
> It would be great to be able to catch those exceptions either in the view or
> in a servlet filter. I think it should be possible to throw unchecked
> exceptions in the ModelAdapterFactory.getFactory() method if it is requested
> (i.e. through a global OSGi configuration flag for Sling Models).
> WDYT?
> Would you accept such a patch or do you think this breaks the API (also
> compare with
> https://issues.apache.org/jira/browse/SLING-2712?focusedCommentId=13561516&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13561516).
> If it does not work through the adaptTo, SlingModels should provide an
> alternative way of instanciating models (and propagating exceptions),
> although this is kind of tricky, because it internally relies on adaptTo as
> well (e.g. in
> https://github.com/apache/sling/blob/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L647)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
