Hi Konrad,
Thanks for reviewing the changes at [1].
On Thu, Jul 10, 2025 at 7:47 PM Konrad Windszus <k...@apache.org> wrote:
> ...I do have a concern with using a generic service interface like
> java.util.function.predicate in OSGi...
> ...I would actually prefer to come up with a dedicated (functional) interface
> for Resource
> predicates and define name values for different usage scenarios as constants
> of
> that interface...
So something like this?
public interface ResourceHidingPredicate extends Predicate<Resource> {
// This name is probably not needed in the end, see below
public String SERVLET_RESOLVER_HIDE = "sling.servlet.resolver.hide";
}
I agree that it's better in terms of type safety, but where do we put this API?
I wouldn't want to change the Sling API bundle just for this minor
thing, that creates too much coupling and release/deployment trouble
IMO.
I could put this new API in the servlets resolver bundle in a new
(exported) org.apache.sling.servlets.resolver.api package, as it's
really specific to that bundle. Having it there actually removes the
need for a name on the service, you just register a
org.apache.sling.servlets.resolver.api.ResourceHidingPredicate service
and that's good.
The full class name then clearly expresses that it's a Predicate meant
for hiding resources in the servlets resolver.
In this way there's no dependency trouble, the new servlets resolver
bundle can also be used with older versions of the Sling API bundle,
and bundles that want to register a ResourceHidingPredicate will not
resolve if the servlets resolver bundle is too old for that, I think
that's clean.
WDYT?
-Bertrand
[1]
https://github.com/apache/sling-org-apache-sling-servlets-resolver/commit/26edac2f39ca2f61fc9aeeada61426b78ec8252c
