Web Simple Provider should also provide a Java API for resource resolution

[eliasvasylenko]

Sometimes a web application may wish to access resources provided through osgi.enroute.web.simple.provider directly in Java code for e.g. server-side rendering using nashorn. Currently afaict the only way to do this is to reimplement or hook-into the WebresourceServlet, or to resolve indirectly through the web server via URL which imo is unnecessarily complex and requires a little extra information.

It would be nice if there were a prototype-scoped service which provided all the resources available to a bundle via some sort of simple getWebResource(String glob) method.

If you agree this would be useful I'd be more than happy to PR.

Edit: I'm aware that there's a RFC and RFP for this but they look very early stages so I assume this is still a relevant reference for them and place to explore design...

[pkriens]

I can see this to be useful ... So please make a PR

[eliasvasylenko]

I've been thinking about this a lot and I feel that aggregation is not the only useful way web resource capabilities can be consumed in their current form (especially with modules and isolation now being part of the javascript language spec etc, which is part of the motivation behind #87)

The requirement/capability attributes used are pretty generic and could equally apply to any number of different loading strategies, so do we have to be opinionated about this aspect? IMO any eventual spec should acknowledge that the WebresourceServlet approach is just one possibility and the capabilities can exist independently of it.

I would really like to submit a tiered API to reflect this ...

• WebresourceServlet (serving aggregated resources over /${bsn}/${BundleVersion}/)

depends on:

• Web resource aggregator service (API aggregating globbed resources available to a bundle, i.e. what I proposed in the previous comment)

depends on:

• Web resource discovery service (direct low-level reflection over the web resource capabilities wired to a bundle)

Are you amenable to this sort of proposal?

[pkriens]

I am open to a lot as long as it is backward compatible ...

Not sure the API is needed since the resource API seems quite usable?

[eliasvasylenko]

Yeah that's fair enough I did think it might be a little unnecessary, it was just for my own convenience ;). Okay well I'll go with the original plan.