[ 
https://issues.apache.org/jira/browse/SLING-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14113842#comment-14113842
 ] 

Stefan Seifert commented on SLING-3709:
---------------------------------------

my example was not targeted at the sightly - sling models integration, but when 
you want to adapt a model yourself in your code. as your usecase is completely 
different let us forget my proposal for now, it will not help (although the 
problems you mentioned should be solvable).

if your real goal and usecase is only to have a nicer representation of sling 
model adaptions error (instead of just having them in the sling error log as it 
is the case now) i wonder if there are not easier and more straightforward 
solutions than extending the sling models API in this way plus a custom use 
provider. i've not yet looked into the inner workings of the AEM6 develop layer 
yet, so i have currently no idea what might be alternatives to push this error 
information to it.

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

Reply via email to