[
https://issues.apache.org/jira/browse/SLING-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14113707#comment-14113707
]
Konrad Windszus commented on SLING-3709:
----------------------------------------
Whether the method within the ModelFactory is called {{adaptToOrThrow}} or
{{createModel}} I don't care that much to be honest. I need to make that an
OSGi service, because otherwise were would you put the code for instanciation
and throwing exceptions? What is {{Models}} in your example? Is that a new
class within the Sling Models API bundle? In most of the cases where you call
that ModelFactory, you are in an OSGi component anyhow, and there it is cheap
to inject other services.
Since the discussion around adaptTo didn't come to a conclusion I started with
my own interface only dedicated to do instanciation and allowing to throw
exceptions for Sling Models.
The methods {{isModelClass}} and {{canCreateFromAdaptable}} are necessary for
the clients.
I use those internally for a custom Sightly Use Provider [1]. With Sightly Use
the different providers are asked to provide an instance of the requested
class. The Sling Model Factory Use Provider is only throwing an exception or
providing an instance if
a) we are dealing with a Sling Model (checked via {{isModelClass}})
b) that class can be adapted from the given Adaptable (checked via
{{canAdaptFromAdaptable}})
In all other cases it would return null, meaning the other Use Providers would
be asked.
If I would rely on exceptions to figure that out, that Use Provider would come
with a severe performance drawback (as this is asked always first).
The same logic could be implemented with a custom JSP tag.
[1] -
https://dev.day.com/docs/en/aem/6-0/develop/ref/javadoc/io/sightly/java/api/UseProvider.html
> 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)
