Framework is initializing all registered services

[doggy-dev]

The connector examines every object that is being registered as osgi service. This is undesired because this way every service factory creates a new instance and every declarative service is beeing initialized. Please use another way to determine if the registered service is a servlet. For example a service property can be used or an interface. This way you have to examine only the service reference.

[BryanHunt]

I would also recommend consideration of introducing an interface. I think an interface would also allow us to create a shim to hook in Swagger.

[hstaudacher]

Sorry, but I disagree here. The only purpose of the connector is to publish annotated services. If they will be initialized to determine, fine.

Introducing a property or and interface would make things more complicated. Also it would be a unnecessary breaking change.

[colemarkham]

I think allowing a custom filter to be supplied would be a good compromise. A custom filter could inspect a specific property, look for an interface, etc. I believe the only option now is to filter based on ID, but maybe that is already flexible enough. I agree with Holger, most existing users don't mind that all services get initialized, but in resource constrained environments that might not be acceptable.

[hstaudacher]

There was a feature request a while ago to make the service filter used for tracking configurable. E.g. to track only services starting with com.yourdomain.

Would this solve the problem?

[doggy-dev]

I don't think filtering by a prefix would solve the problem. This would impose a stict naming schema that not everybody would be happy with. There is also the question how should it be configured. I have three proposals how the framework can be bettered and backwards compatibility be preserved:

1. pass an application parameter that configures the service tracker to check only properties of service references
2. use a service to supply the service tracker :)
3. maybe a fragment supplying the service tracker with the same FQN would override the bundle supplied one. I haven't checked if the class loader goes with this but as far as I remember the class loader checks first fragments and then the bundle itself for class implementations.

[doggy-dev]

I was trying to implement the fragment solution as I find out, that I can supply a Filter for the ServiceTracker that analyses the services. My solution is to supply a com.eclipsesource.jaxrs.publisher.ResourceFilter as a service. This is obviously the right way to go and I see the issue as invalid.

Thanks for your input.

[BryanHunt]

Could you provide an example? I'd like to get this documented.

[doggy-dev]

Sure, what I did is to register a DS implementing com.eclipsesource.jaxrs.publisher.ResourceFilter with the following code:

void activate(ComponentContext ctx) throws InvalidSyntaxException {
    filter = ctx.getBundleContext().createFilter("(" + RESOURCE_PROPERTY + "=" + RESOURCE_PROPERTY_VALUE + ")");
}

@Override
public Filter getFilter() {
    return filter;
}

then register your resource service with parameter RESOURCE_PROPERTY and value RESOURCE_PROPERTY_VALUE. I hope that helps.

[hstaudacher]

That is what i was talking about. Just forgot that it is already implemented:)

[hstaudacher]

Added a wiki entry https://github.com/hstaudacher/osgi-jax-rs-connector/wiki/FAQ#how-can-i-change-the-servicetracker-filter