Hi,
I’m going to deprecate this module, now that its functionality has been merged
into org.apache.sling.scripting.sightly and we already have two releases where
the core HTL engine provides the Use-API UseProvider capable of loading Sling
Models.
Thanks,
Radu
> On 16 Apr 2020, at 09:54, Konr
Yes, moving it to another module is totally fine. Still I would prefer to keep
it in a dedicated class and not mix it with pojo java use provider. But that is
your call...
Konrad
> Am 16.04.2020 um 09:18 schrieb Radu Cotescu :
>
> Hi,
>
> Ok, I’ll keep the implementation relying on the Model
Hi,
Ok, I’ll keep the implementation relying on the ModelFactory, but will move it
to the JavaUseProvider, with an optional import of the
org.apache.sling.models.factory package. I just don’t want a separate module
any more for just one class, with a lot of duplication. Hope that’s fine for
yo
Wrapping the exception is ok as long as the old exception is still accessible.
One can easily write a ServletFilter which catches (and unwraps) the exception
to throw the 500!
With the adaptTo approach the exception will never hit any servlet filter!
> On 15. Apr 2020, at 18:04, Radu Cotescu wr
But that already happens in this case. If none of the Use providers can provide
an object the HTL engine throws a SightlyException. The logging I mentioned is
only supposed to help with debugging.
> On 15 Apr 2020, at 17:56, Konrad Windszus wrote:
>
> My point is: Noone should catch such a non
My point is: Noone should catch such a non-recoverable development exception.
Otherwise the underlying bug might slip through. So logging is IMHO not
sufficient. The exception should bubble up and lead to a 500 status!
> On 15. Apr 2020, at 17:54, Radu Cotescu wrote:
>
> Hi Konrad,
>
> I know
Hi Konrad,
I know about that subtle difference, but couldn’t we log the failure of
instantiating the model in the adapter factories? It’s anyways not something we
can recover from. In case of a failure of the SlingModelsUseProvider
instantiating the model we wrap the original exception in a
or
/browse/SLING-3709
<https://issues.apache.org/jira/browse/SLING-3709>
> On 15. Apr 2020, at 14:55, Radu Cotescu wrote:
>
> Hi,
>
> In the context of SLING-9320 and SLING-9207 (the bigger picture) I was
> wondering if we couldn’t deprecate the
> org.apache.s
Hi,
In the context of SLING-9320 and SLING-9207 (the bigger picture) I was
wondering if we couldn’t deprecate the
org.apache.sling.scripting.sightly.models.provider module completely. The
JavaUseProvider from org.apache.sling.scripting.sightly seems to handle Sling
Models just fine through
