[
https://issues.apache.org/jira/browse/SLING-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14113680#comment-14113680
]
Stefan Seifert commented on SLING-3709:
---------------------------------------
having a separate {{ModelFactory}} interface is not so elegant. and the
interfaces mixes different concerns in my opinion - creating a model with
validation, and inspecting model classes and possible adaptions (which is of
more use for the internal implementation than for the consumer code).
coming back the the ["adaptTo and results ..."
discussion|http://apache-sling.73963.n3.nabble.com/adaptTo-and-results-tc4035466.html#none]
- what about a variant like:
{code:java}
// adaption with exception handling
try {
model = Models.adaptToOrThrow(resource, MyModel.class);
}
catch (ValidationException ex) {
// handle exception
}
{code}
in this case the {{ModelAdapterFactory.getAdapter}} method never throws an
exception, but collects information about validation errors or other problems
in a thread local. this thread local is read inside the helper method
{{Models.adaptToOrThrow}} and an exception is thrown if required.
in general the extensions of this ticket are a bit problematic because they
only work if the consumer code changes the way to get models (and does not use
standard adaptTo semantics). that means that other layers that work with models
(e.g. inject a model into sightly view, injects models in other models) will
still swallow these exceptions because they will use only adaptTo. but in
scenarios where the consumer code wants to handle explicit exception a helper
method like {{Models.adaptToOrThrows}} is more lightweight than having to get a
reference to an OSGi services for this.
> 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)
