This specification defines the following entities:

Figure 151.1 Jakarta RESTful Web Services Whiteboard Overview Diagram

The Figure 151.1 shows an OSGi framework running a Jakarta RESTful Web Services Whiteboard Implementation bundle. This bundle has been configured to provide two Jakarta RESTful Web Services whiteboards, each of which has a corresponding Jakarta RESTful Web Services Service Runtime Service. The various Jakarta RESTful Web Services Whiteboard services available in the framework are discovered and processed by both whiteboards.

The JakartarsServiceRuntime service represents the runtime state information of a Jakarta RESTful Web Services Whiteboard instance. This information is provided through Data Transfer Objects (DTOs). The architecture of OSGi DTOs is described in OSGi Core Release 8.

Each Jakarta RESTful Web Services Whiteboard implementation registers exactly one JakartarsServiceRuntime service per Jakarta RESTful Web Services Whiteboard. The service properties of the Jakarta RESTful Web Services Service Runtime Service can be used to target Jakarta RESTful Web Services Whiteboard services at specific Jakarta RESTful Web Services whiteboards, as described by the osgi.jakartars.whiteboard.target property in Common Whiteboard Properties.

The JakartarsServiceRuntime provides service registration properties to declare its underlying Jakarta RESTful Web Services Whiteboard. These service properties can include implementation-specific key-value pairs. They also include the following:

The Jakarta RESTful Web Services Service Runtime service provides information about registered Whiteboard services through the RuntimeDTO.

The Runtime DTO provides information about services that have been successfully registered as well as information about the Jakarta RESTful Web Services Whiteboard services that were not successfully registered. Jakarta RESTful Web Services Whiteboard services that have the required properties set but cannot be processed, are reflected in the failure DTOs. Jakarta RESTful Web Services Whiteboard services of interfaces described in this specification that do not have the required properties set are ignored and not reflected in the failure DTOs.

The Runtime DTO can be obtained using the getRuntimeDTO() method. The Runtime DTO returned provides a snapshot of the state of the Jakarta RESTful Web Services Runtime, including the Jakarta RESTful Web Services Whiteboard resources, extensions and applications that are active in each registered application. The Runtime DTO also includes information about Whiteboard services which could not be activated.

Implementations of this specification will often be backed by existing servlet containers, such as the OSGi Http Whiteboard, or a Jakarta EE application server. There may also exist implementations which bridge into a servlet container into which the OSGi Framework has been deployed as a Web Application.

In bridged situations the Jakarta RESTful Web Services Whiteboard implementation will have limited facilities for creating new Jakarta RESTful Web Services whiteboards, and may also have limited information about its environment.

Information about the surrounding Servlet Container, including ServletContext information and HttpSession data, is available to Jakarta RESTful Web Services Whiteboard resources using standard Jakarta RESTful Web Services injection behavior.

@GET
@Path("{name}")
public String interrogateSession(@PathParam("name") String name,
         @Context HttpServletRequest req) {
    HttpSession s = req.getSession();
    return String.valueOf(s.getAttribute(name));
}

A Jakarta RESTful Web Services Whiteboard implementation needs to ensure that Http Sessions are not shared amongst different Jakarta RESTful Web Services Whiteboards, or amongst different Jakarta RESTful Web Services Whiteboard applications. That is, HttpServletRequest.getSession() calls must provide different sessions for each whiteboard application with which a Jakarta RESTful Web Services whiteboard service is associated.

Even when they are created by the same Jakarta RESTful Web Services Whiteboard implementation, each Jakarta RESTful Web Services Whiteboard instance is separate, and isolated from other instances. Importantly, Jakarta RESTful Web Services Whiteboard services targeted to one Jakarta RESTful Web Services Whiteboard application must not be visible in any other Whiteboard or applications to which they are not targeted.

This isolation restriction is critical, as it ensures that different Jakarta RESTful Web Services Whiteboard applications can be configured with different, potentially overlapping, incompatible extension features.

Jakarta RESTful Web Services resources use the Path annotation to bind themselves to particular URIs within the Jakarta RESTful Web Services container. The path annotation can be applied to the resource class, and to individual resource methods. For example the following Jakarta RESTful Web Services resource:

@Path("foo")
public class Foo {

    private final List<String> entries = 
        Arrays.asList("fizz", "buzz", "fizzbuzz");
        
    @GET
    public List<String> getFoos() {
        return Collections.unmodifiableList(entries);
    }

    @GET
    @Path("{name}")
    public String getFoo(@PathParam("name") String name) {
        if(entries.contains(name)) {
            return "A foo called " + name;
        }
        throw new IllegalArgumentException(“No foo called “ + name);
    }

}

This Jakarta RESTful Web Services resource defines two resource methods. The Path annotation applied to the class sets the base URI for all methods in the resource. The getFoos() method is therefore bound to the URI foo. The Path annotation on the getFoo() method makes this method a sub-resource which captures the next token in the URI. This method is therefore bound to URIs of the form foo/buzz.

When used as an OSGi Jakarta RESTful Web Services Whiteboard service a Jakarta RESTful Web Services resource follows the same mapping rules, but the base context(s) it uses are determined by the Application(s) to which it is mapped. For example, when mapped to the default application of a whiteboard with endpoint http://127.0.0.1/ the getFoos() method would be available at http://127.0.0.1/foo.

A key tenet of Jakarta RESTful Web Services is that all resource objects are stateless. In the Jakarta RESTful Web Services specification resources therefore have one of two scopes, they are either singleton, or request-scoped. Singleton resources are created once, potentially outside the Jakarta RESTful Web Services container, and request-scoped resources are created on-demand for each request, then discarded afterwards.

Typically Jakarta RESTful Web Services developers are encouraged to write request-scoped resources, as this makes it difficult to accidentally write stateful components. In OSGi, however, it is more common to write singleton services. On demand instances of OSGi services can be created, but only if the service is registered as a prototype scope.

The Jakarta RESTful Web Services whiteboard implementation is responsible for managing the mismatch between the OSGi service lifecycle model and the Jakarta RESTful Web Services resource lifecycle model. If the Jakarta RESTful Web Services whiteboard resource is registered as prototype scope then the implementation must treat the resources as request-scoped, creating a new service instance for each request and releasing it when the request completes. Otherwise the Jakarta RESTful Web Services whiteboard service must be registered as a singleton scope resource within the application. Singleton scope whiteboard resources must be released by the Jakarta RESTful Web Services whiteboard when the application with which they have been registered is removed from the whiteboard, even if this is only a temporary situation.

If a failure occurs when getting the resource service this will prevent the service from being used, which is reflected using a failure DTO. In such a case the system treats the resource as unusable.

When multiple Jakarta RESTful Web Services Whiteboard implementations are present all of them can potentially process the whiteboard resources. In such situations it can be useful to associate the servlet with a specific whiteboard by specifying the osgi.http.whiteboard.target property on the service.

@Component(service = MyResource.class,
      scope = ServiceScope.PROTOTYPE)
 @JakartarsResource     
 public class MyResource {
  
    @Path(“foo”)
    @GET
    public void getFoo(@Suspended AsyncResponse async) {
        Promise<String> p = doLongRunningTaskAsynchronously();
        p.onSuccess(v -> async.resume(v))
            .onFailure(t -> async.resume(t));
    }
}

@Component(service = MyResource.class,
      scope = ServiceScope.PROTOTYPE)
 @JakartarsResource     
 public class MyResource {
  
    @Path(“foo”)
    @GET
    public Promise<String> getFoo() {
        Promise<String> p = doLongRunningTaskAsynchronously();
        return p;
    }
}

@Component(service = MyResource.class,
      scope = ServiceScope.PROTOTYPE)
 @JakartarsResource     
 public class MyResource {
  
    @Context
    Sse sse;

    @GET
    @Produces(MediaType.SERVER_SENT_EVENTS)
    public void getFoo(@Context SseEventSink sink) {
        PushStream<String> p = getStreamOfMessages();
        p.map(sse::newEvent)
            .forEach(e -> sink::send)
            .onResolve(sink::close);
    }
}

The following table describes the properties that can be used by Jakarta RESTful Web Services resources registered as Whiteboard services. Additionally, the common properties listed in Table 151.2 on page are supported.

The following example code uses Declarative Services annotations to register a Jakarta RESTful Web Services Whiteboard service.

@Component(service = MyResource.class,
      scope = ServiceScope.PROTOTYPE)
 @JakartarsResource     
 public class MyResource {
  
     @GET
     @Path("hello")
     @Produces("text/plain")
     public String sayHello(){
          return "Hello World!";
     }
 }

This example registers the resource method at: /hello. Requests for http://www.acme.com/hello map to the resource method, which is called to process the request.

To associate the above example resource with another application add the following service property:

osgi.jakartars.application.select=(osgi.jakartars.name=myApp)

This can also be added using the property annotation:

@JakartarsApplicationSelect("(osgi.jakartars.name=myApp)")

Setting this property requires a Jakarta RESTful Web Services application named myApp to be registered:

@Component(service=Application.class)
@JakartarsName("myApp")
@JakartarsApplicationBase("foo")
public class MyApplication extends Application {}

Now the whiteboard resource will be available at http://www.acme.com/foo/hello as configured by the custom Jakarta RESTful Web Services application.

By default Jakarta RESTful Web Services extensions are applied to every request, however sometimes they are only needed for a subset of resource methods. In this case a NameBinding annotation can be used to apply the extension to a subset of resource methods. The following example declares a binding annotation called FizzBuzz and uses it to bind an extension which replaces occurrences of "fizz" with "fizzbuzz".

@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@NameBinding
public @interface FizzBuzz{}

@Component
@JakartarsExtension
@FizzBuzz
public class FizzBuzzReplacer implements WriterInterceptor {

    public void aroundWriteTo(WriterInterceptorContext ctx) {
        Object entity = ctx.getEntity();
        
        if(entity != null) {
            ctx.setEntity(entity.toString()
                .replace("fizz", "fizzbuzz"));
        }
        ctx.proceed();
    }
}

@Component(service=FizzResource.class)
@JakartarsResource
@Path("fizzbuzz")
public class FizzResource {

    @GET
    @FizzBuzz
    public String getFoos() {
        return "fizz, buzz, fizzbuzz";
    }
}

The result of an http request to the fizzbuzz URI will be fizzbuzz, buzz, fizzbuzzbuzz

The Jakarta RESTful Web Services whiteboard implementation must support the use of NameBinding to limit the scope of applied whiteboard extensions.

Jakarta RESTful Web Services filters can be annotated with @PreMatching to indicate that they should be applied before the Jakarta RESTful Web Services container works out which resource should be called by the incoming request. These filters can therefore change the request such that it maps to a different resource than it would have before the filter’s operation. Pre-matching filters cannot use NameBinding as no corresponding named resource is available to the runtime when they operate.

When used in the OSGi Jakarta RESTful Web Services Whiteboard Jakarta RESTful Web Services extensions follow the same ordering rules as defined by the Jakarta RESTful Web Services specification. Where more than one extension of a particular type is available then they are ordered according to their jakarta.annotation.Priority. If two extensions of the same type have the same priority then the whiteboard implementation must break the tie by ordering the extensions according to the natural ordering of their service references, as specified in ServiceReference.compareTo, with static extensions being ranked below all whiteboard services.

The extension processing flow is as follows:

The osgi.jakartars.extension.select property described in Common Whiteboard Properties applies to extensions as well as Jakarta RESTful Web Services resources. This is because one extension may depend on another.

The most common reason for an extension to have a dependency is for a context injection dependency. Dependencies are often provided by a ContextResolver so that they can be injected into another extension. The following example demonstrates a simple dependency on a Jackson ObjectMapper.

@JakartarsExtension
@JakartarsName("configProvider")
@Component
public class ConfigProvider implements ContextResolver {
    
    private ObjectMapper mapper = new ObjectMapper();
    
    public <T> getContext(Class<T> clazz) {
        if(ObjectMapper.class.equals(clazz)) {
            return mapper;
        }
        return null;
    }
}

@JakartarsExtension
@JakartarsExtensionSelect("(osgi.jakartars.name=configProvider)")
@Component(scope=ServiceScope.PROTOTYPE)
public class ConfiguredExtension implements WriterInterceptor {

    @Context
    private Providers providers;

    public void aroundWriteTo(WriterInterceptorContext ctx) {
        Object entity = ctx.getEntity();
        
        if(entity != null) {
            ObjectMapper mapper = providers
                    .getContextResolver(ObjectMapper.class)
                    .getContext(ObjectMapper.class);
                    
            ctx.setEntity(mapper.writeValueAsString(entity));
        }
        ctx.proceed();
    }
}

Depending on the capabilities of the Jakarta RESTful Web Services whiteboard implementation, and any statically defined extensions that make up a Jakarta RESTful Web Services Whiteboard application, there may be numerous non standard extensions available. These extensions must be represented using service properties on the Jakarta RESTful Web Services Service Runtime, or the whiteboard application as appropriate. This is why the extension select filters must also be matched against the Jakarta RESTful Web Services Service Runtime service and the whiteboard application being targeted.

Jakarta RESTful Web Services extensions have a different lifecycle from Jakarta RESTful Web Services resources, within a single application a Jakarta RESTful Web Services extension always behaves as a singleton. If a Jakarta RESTful Web Services whiteboard extension is registered as prototype scope then the whiteboard implementation must obtain a separate instance for every application to which the extension is applied. Whiteboard extension services must be released by the Jakarta RESTful Web Services whiteboard when the application with which they have been registered is removed from the whiteboard, even if this is only a temporary situation.

Jakarta RESTful Web Services extensions often require configuration, and need to be configured differently for different applications. This configuration is typically provided by a Jakarta RESTful Web Services ContextResolver and injected into fields of the extension by the Jakarta RESTful Web Services container. It is therefore highly recommended that Jakarta RESTful Web Services Whiteboard extensions are always registered as prototype scope, so that separate instances can be created for each whiteboard application.

If an extension is registered as a singleton service then it should not rely on any fields being injected by the Jakarta RESTful Web Services Whiteboard implementation. Jakarta RESTful Web Services Whiteboard implementations may support field injection for singleton extensions, however this behavior is non portable, and may lead to errors at runtime when using other implementations.

The following table describes the properties that can be used by Jakarta RESTful Web Services extensions registered as Whiteboard services. Additionally, the common properties listed in Table 151.2 on page are supported.

The following example code uses Declarative Services annotations to register a require Jakarta RESTful Web Services Whiteboard extension which provides JSON support, and requires the extension from a Jakarta RESTful Web Services whiteboard resource.

@Component(property="serialize.to=JSON")
@JakartarsExtension
public class JsonProvider implements MessageBodyReader,
      MessageBodyWriter {
    ...      
}
 
 @Component(service = Object.class,
      scope = ServiceScope.PROTOTYPE)
 @JakartarsResource
 @JakartarsExtensionSelect("(serialize.to=JSON)")
 public class MyResource {
  
     @GET
     @Path("hello")
     @Produces(MediaType.APPLICATION_JSON)
     public List<String> getList(){
          return Arrays.asList("Hello", "World!");
     }
 }

The base URI for each application within the whiteboard must be unique. If two or more applications targeting the same whiteboard are registered with the same base URI then only the first in ranking order, as specified in ServiceReference.compareTo, will be made available. All other application services with that URI will have a failure DTO created for them. The same rules also apply to the osgi.jakartars.name property, with the highest ranked service shadowing other applications with the same name.

The default application is implicitly created by the whiteboard and has the name .default. The default application has a lower ranking than all registered services. Therefore an application registered with a base of / will shadow a default application bound at /.

A whiteboard application service may set an osgi.jakartars.name of .default to replace the default application. This technique may be used to rebind the default application to a base uri other than /.

If a whiteboard application fails (for example if the service get fails), or cannot be immediately deployed (for example if it has an unsatisfied osgi.jakartars.extension.select) then any applications that it shadows are still shadowed and relevant failure DTOs are created for all of the applications.

It is possible for an application to require additional whiteboard extensions before it is eligible to be hosted by the whiteboard. When making this determination the Whiteboard implementation must perform a dry-run validation of the osgi.jakartars.extension.select filter, applying all of the whiteboard extensions targeted to the application before determining whether the application's requirements are met.

The following table describes the properties that can be used by Jakarta RESTful Web Services applications registered as Whiteboard services. Additionally, the common properties listed in Table 151.2 on page are supported, except for the osgi.jakartars.application.select property.

In Jakarta RESTful Web Services the @Context annotation may be used to inject the Application instance into a resource or extension. Application configuration properties can also be injected using the Configuration type.

When using the Jakarta RESTful Web Services Whiteboard it can also be necessary to access the service properties associated with the application hosting the resource, for example to allow customization of the resource's response. To this end, the Jakarta RESTful Web Services whiteboard implementation must make the Application service properties available as a Map in the configuration. The key used to store this map is osgi.jakartars.application.serviceProperties, and it can be found in any injected Configuration instance.

Furthermore, for Feature and DynamicFeature extensions the application service properties must be visible in the FeatureContext passed to the extension when applying it to the application. The FeatureContext interface provides programmatic access to the Configuration for the application, so this visibility is achieved in the same manner as for an injected Configuration instance.

In the case where the hosting application is not an OSGi service, for example a Whiteboard implementation may choose to provide its default application as an internal detail, then the osgi.jakartars.application.serviceProperties map must exist containing the osgi.jakartars.name of the application and the service properties associated with the JakartarsServiceRuntime service.

The following example code uses Declarative Services annotations to register a Jakarta RESTful Web Services Whiteboard application, and shows how to target an additional whiteboard resource to that application.

@Component(service=Application.class)
@JakartarsApplicationBase("example")
@JakartarsName("myApp")
public class MyApplication extends Application {
    public Set<Class<?>> getClasses() {
        return new HashSet<>(Arrays.asList(StaticResource.class));
    }      
}
 
 @Component(service = MyResource.class,
      scope = ServiceScope.PROTOTYPE)
 @JakartarsResource
 @JakartarsApplicationSelect("(osgi.jakartars.name=myApp)")
 public class MyResource {
  
     @GET
     @Path("hello")
     @Produces("text/plain")
     public List<String> getList(){
          return Arrays.asList("Hello", "World!");
     }
 }

The MyResource service will be available at http://www.acme.com/example/hello

While Container extensions can be made available using whiteboard services, the same is not true for Clients. There are two main reasons for this:

In order to add filters, interceptors, readers and writers to the Jakarta RESTful Web Services client users should use the ClientBuilder#register() method when building their client.

The Jakarta RESTful Web Services client API supports both synchronous and asynchronous calls. In Jakarta RESTful Web Services 2.1 the asynchronous behavior of the client was extended using the RxInvoker (reactive invoker) interface. All clients are required to support a reactive invoker which returns CompletionStage instances, however in OSGi the common representation of an asynchronous return is the Promise. This specification therefore provides the PromiseRxInvoker interface which can be used to obtain Promises from the Jakarta RESTful Web Services client.

It is the responsibility of the Jakarta RESTful Web Services whiteboard implementation to create instances of PromiseRxInvoker. The exact mechanism by which instances are created is undefined, however it is possible to register a portable factory to create PromiseRxInvoker instances by implementing the RxInvokerProvider interface and registering this type with the Jakarta RESTful Web Services client. This portable implementation, however, is forced to use a blocking model by the underlying Jakarta RESTful Web Services API, and so implementations may choose to implement a more optimized non-blocking model using internal types.

Clients of this specification may make use of the PromiseRxInvoker using normal Jakarta RESTful Web Services idioms. For example:

Client client = clientBuilder.build();
Promise<String> p = client.target(REST_SERVICE_URL)
    .path("/foo")
    .path("/{name}")
    .resolveTemplate("name", buzz)
    .request()
    .rx(PromiseRxInvoker.class)
    .get(String.class);

In Jakarta RESTful Web Services 2.1 support was added for Server Sent Events. These events are consumed by a REST client using the SseEventSource. The SseEventSource is not created by a Jakarta RESTful Web Services client instance, but is normally created using a static factory method, which does not work in a modular environment. Therefore the Jakarta RESTful Web Services whiteboard implementation must register a SseEventSourceFactory service in the service registry. This object serves as a factory for the Jakarta RESTful Web Services SSE types.

Note that the SseEventSource has no way to register filters or message body processors. All of the filters and necessary processors must be registered with the Jakarta RESTful Web Services client that is used to create the WebTarget used when building the SseEventSource. A client may therefore consume Server Sent Events in the following way:

Client client = clientBuilder.build();

WebTarget target = client.target(REST_SERVICE_URL)
    .path("/foo")
    .path("/{name}")
    .resolveTemplate("name", buzz);

SseEventSource source = sseFactory.newSource(target);
    
source.register(event -> doSomething(event));
    
source.open();

A SseEventSource may easily be converted into a PushEventSource (and consequently a PushStream) as follows. Note that the implementation does not respond to back-pressure requests and should typically be used with a buffer.

SseEventSource source = sseBuilder.newSource(target);
    
PushEventSource<InboundSseEvent> pes = pec ->
        source.register(e -> {
                                try {
                                    if(pec.accept(PushEvent.data(e)) < 0) {
                                        source.close();
                                    }
                                } catch (Exception e) {
                                    try {
                                        pec.accept(PushEvent.error(e));
                                    } finally {
                                        source.close();
                                    } 
                                }
                            },
                        t -> pec.accept(PushEvent.error(t)),
                        () -> pec.accept(PushEvent.close()));
        source.open();
        return source;
    };

A common use of the Jakarta RESTful Web Services extension mechanism is to provide support for additional media types, both for consuming incoming requests and for producing responses. All Jakarta RESTful Web Services whiteboards must implicitly support text/plain and application/xml (using JAXB), however commonly used media types, such as application/json must be provided as an extension.

To ensure that whiteboard resources can depend on support for a particular media type in a portable way this specification defines the osgi.jakartars.media.type property. This property key should be registered with one or more media types that are supported, and may be provided by:

The term general purpose is used to indicate that the media type support must not require implementation specific mapping metadata (for example annotations) and should, at a minimum, work with the OSGi scalar types and DTOs. The property key is available as a constant in JAKARTA_RS_MEDIA_TYPE.

@Component(service = MyResource.class,
      scope = ServiceScope.PROTOTYPE)
 @JakartarsResource
 @JSONRequired
 @Produces(MediaType.APPLICATION_JSON)  
 public class MyResource {
  
    @Path(“foo”)
    @GET
    public List<String> getFoos() {
        return Arrays.asList("foo", "bar", "baz");
    }
}

@Component(scope = ServiceScope.PROTOTYPE)
 @JakartarsExtension
 @JakartarsMediaType(MediaType.APPLICATION_JSON)
 public class MyFeature implements Feature {
  
    public boolean configure(FeatureContext context) {
    		context.register(MyJSONCodec.class);
        return true;
    }
}

The Jakarta RESTful Web Services Whiteboard implementation bundle must provide the osgi.implementation capability with name osgi.jakartars. This capability can be used by provisioning tools and during resolution to ensure that a Jakarta RESTful Web Services Whiteboard implementation is present to process the Whiteboard services defined in this specification. The capability must also declare a uses constraint for the jakarta.ws.rs.* specification packages, and for the and OSGi Jakarta RESTful Web Services Whiteboard package. The version of this capability must match the version of this specification:

Provide-Capability: osgi.implementation;
       osgi.implementation="osgi.jakartars";
       uses:="jakarta.ws.rs, jakarta.ws.rs.client, jakarta.ws.rs.container,
              jakarta.ws.rs.core, jakarta.ws.rs.ext, jakarta.ws.rs.sse, 
              org.osgi.service.jakartars.whiteboard";
       version:Version="2.0"

This capability must follow the rules defined for the osgi.implementation Namespace.

The Jakarta RESTful Web Services Whiteboard implementation must provide a capability in the osgi.contract namespace with the name JakartaRESTfulWebServices if it exports the Jakarta RESTful Web Services specification packages. See [5] Portable Java Contract Definitions.

Providing the osgi.contract capability enables developer to build portable bundles for packages that are not versioned under OSGi Semantic Versioning rules. For more details see osgi.contract Namespace.

If the Jakarta RESTful Web Services API is provided by another bundle, the Jakarta RESTful Web Services Whiteboard implementation must be a consumer of the API and require the contract.

The bundle providing the JakartarsServiceRuntime service must provide a capability in the osgi.service namespace representing this service. This capability must also declare a uses constraint for the org.osgi.service.jakartars.runtime and org.osgi.service.jakartars.runtime.dto packages:

Provide-Capability: osgi.service;
  objectClass:List<String>=
    "org.osgi.service.jakartars.runtime.JakartarsServiceRuntime";
  uses:="org.osgi.service.jakartars.runtime,
         org.osgi.service.jakartars.runtime.dto"

The bundle providing the jakarta.ws.rs.client.ClientBuilder service must also provide a capability in the osgi.service namespace representing this service. This capability must declare that the service is prototype scope, and that there is a uses constraint for the jakarta.ws.rs.client package:

Provide-Capability: osgi.service;
  objectClass:List<String>="jakarta.ws.rs.client.ClientBuilder";
  uses:="jakarta.ws.rs.client,org.osgi.service.jakartars.client";
  service.scope="prototype"

The bundle providing the org.osgi.service.jakartars.client.SseEventSourceFactory service must also provide a capability in the osgi.service namespace representing this service. This capability must declare a uses constraint for the org.osgi.service.jakartars.client package:

Provide-Capability: osgi.service;
  objectClass:List<String>=
    "org.osgi.service.jakartars.client.SseEventSourceFactory";
  uses:="org.osgi.service.jakartars.client"

These capabilities must follow the rules defined for the osgi.service Namespace.

Bundles that need to register Jakarta RESTful Web Services Whiteboard services must be granted ServicePermission[interfaceName, REGISTER] where interface name is the relevant Jakarta RESTful Web Services Whiteboard service interface name.

The Http Whiteboard implementation must be granted ServicePermission[*, GET] to retrieve the Jakarta RESTful Web Services Whiteboard services from the service registry.

Bundles that need to introspect the state of the Jakarta RESTful Web Services runtime will need ServicePermission[org.osgi.service.jakartars.runtime.JakartarsServiceRuntime, GET] to obtain the Jakarta RESTful Web Services Service Runtime service and access the DTO types.

This specification does not require that the Jakarta RESTful Web Services Whiteboard implementation is granted All Permission or wraps calls to the Jakarta RESTful Web Services Whiteboard services in a doPrivileged block. Therefore, it is the responsibility of the Jakarta RESTful Web Services Whiteboard services to use a doPrivileged block when performing privileged operations.