[
https://issues.apache.org/jira/browse/SLING-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14086356#comment-14086356
]
Konrad Windszus commented on SLING-3709:
----------------------------------------
Since the discussion at
http://www.mail-archive.com/dev@sling.apache.org/msg31261.html did not really
come to a conclusion, I am a bit clueless how to proceed here. We urgently need
a way to deal with validation errors but obviously I could not convince
everyone that adaptTo needs to be extended/modified.
I don't think that introducing another mechanism in addition to the adaptTo
method only for Sling Models is the right way here because
a) adaptTo is already used within Sling Models (e.g. for model composition)
b) adaptTo is widely supported by custom tags/extensions in JSP and Sightly
Your proposal with wrapping an exception within the adapter does not really
work well, because we don't really want to unwrap the exception to see it (that
would be very hard to do in Sightly anyways). The approach in
http://www.mail-archive.com/dev@sling.apache.org/msg32612.html seems
technically feasible but would require a double adaptTo. (not really good
because of reasons a) and b) from above)
I tend to agree with [~fmeschbe]: ... technically a RuntimeException may always
be thrown. .... (from
http://www.mail-archive.com/dev@sling.apache.org/msg31261.html). The problem is
backwards-compatibility with that approach.
I would still prefer to use adaptTo (for the reasons listed above), but make it
configurable whether Sightly throws RuntimeExceptions or not within an OSGi
configuration (by default not) and then let the developers decide, whether to
use globally either the new behaviour or the old one!
If that is not acceptable, then we would need to invent a completely different
method of instanciating a Sling Model which right from the beginning allows to
throw RuntimeExceptions. The only questions then is how to deal with composed
models (injecting one into the other).
[~justinedelson] WDYT?
> 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
> Affects Versions: Sling Models Implementation 1.0.4, Sling Models
> Implementation 1.0.6
> Reporter: Konrad Windszus
>
> 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)
