sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Norman <eric.d.nor...@gmail.com>
Subject Re: New "capabilities" module, feedback welcome
Date Fri, 22 Jun 2018 23:28:02 GMT
Honestly, I haven't seen any explanation of the use cases that would
justify the complexity of the solution.

You seem to be creating a resource in the reposotory whose sole purpose is
to trigger rendering by the servlet bound to the resource type.

With that in mind, my inclination would be to replace the
capability_resource/renderer_servlet/shadow_acl_node solution with a single
servlet that is mounted at /system/capabilities and remove all the sling
specific semantics from the equation.  No resource or shadow resource would
be necessary.

I would expect that a request that returns a report of registered OSGi
services shouldn't need to know anything else about sling components
running in the same container.

The rendering and access control could easily be dealt with within the
servlet impl and not require all of the complex administration of the
proposed solution.

But then again, I may not fully grasp the goals of your use case.

Regards,
Eric

On Fri, Jun 22, 2018, 7:06 AM Jason E Bailey <jeb@apache.org> wrote:

> After looking into it more, I'm kinda surprised that you didn't go with
> the more Sling/ RESTful approach of
>
> $ curl -s -u admin:admin
> http://localhost:8080/org/apache/sling/capabilities.1.json | jq .
>
> {
>     "osgi": {
>       "framework.bundle.symbolic.name": "org.apache.felix.framework",
>       "framework.bundle.version": "5.6.10"
>     },
>     "jvm": {
>       "java.specification.version": "1.8",
>       "java.vm.version": "25.171-b11",
>       "java.vm.vendor": "Oracle Corporation"
>     }
> }
>
> You could then control access via ACL and just have the resourceType
> report itself rather then everything.
>
>
> - Jason
>
> On Wed, Jun 20, 2018, at 9:38 AM, Bertrand Delacretaz wrote:
> > Hi,
> >
> > I've been working on a (very simple) module to create a "capabilities"
> > endpoint, where a Sling instance can let HTTP clients know about its
> > version levels, presence or absence of certain services etc.
> >
> > It's at
> https://github.com/apache/sling-whiteboard/tree/master/capabilities
> > and if no one is opposed I'll move it to its own module and make a
> > first release later this week.
> >
> > Feedback is welcome.
> >
> > -Bertrand
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message