Community
Participate
Working Groups
Created attachment 107710 [details] Patch to add HttpServiceSelector to branding extension point Currently RAP registers with all available HttpService instances. However, it would be nice if someone can filter the service instance. For example, a secure admin application should only bind to a secure HttpService instance listening on a different (non-public) port. The implementation in the attached patch proposes to add this via the branding extension point.
Note, this mimics the feature available in the Euqinox HTTP registry extension points.
Created attachment 107802 [details] Patch for ResourceManagerFactory to register with all available HttpService instances This patch adds support for ResourceManagerFactory to register with all available HttpService instances. Ideally, it would be great to limit the registration to only the service instance an application is registered with. However, I haven't spent enough time to investigate this approach.
Created attachment 107803 [details] Patch for ResourceManagerFactory to register with all available HttpService instances updated patch to remove formatting changes
Created attachment 115256 [details] Patch for org.eclipse.rap.ui.workbench I've updated the patch to the current head.
It seems that this request does not have enough priorities to be accepted within RAP. My question now is, how should the right solution look like? Ideally, I'd be happy to disable the default HttpService registration completely and just have a RAP Servlet that I register myself with any HttpService I like. The RAP Servlet could allow to only start a specific application. I manged to register my own instance of RequestHandler with any HttpService instance of my choice. However, the interaction with resources (ResourceManager) is still problematic. The current OSGi implementation only works with one HttpService. It seems that some rework is necessary to refactor the ResourceManager to support multiple independent applications. Are there any plans to rework RAP (maybe as part of e4)?
Gunnar, we'll take a look at this these days. Sorry for the long delay. As you already mentioned, it's not one of the high prio items on our list but we see the need to act in this case.
(In reply to comment #6) > Gunnar, we'll take a look at this these days. Sorry for the long delay. As you > already mentioned, it's not one of the high prio items on our list but we see > the need to act in this case. I'd be happy to work with you on this issue. As I mentioned, there are several possibilities. We just need to discuss what the best option might be...
Gunnar, sorry for delaying this issue. I've set it to P2 to remember to address it for the upcoming release. Will look at your patches and come back to you for discussion.
Ralf, I've opend bug 335811 which explains our dilemma. We'd like to run our RAP based Admin UI on one port and also provide a HttpService for downstream consumers on another (configurable) port (eg. 8080). We'd like our RAP admin UI to be available on one port only. This port should also not expose other RAP applications except ours.
Hi Gunnar, does this patch work for you already? Or do you see other problems that also keep you from using RAP in this scenario right now? And, do you know of any other project that allow specify service filters in an extension point? If we decide to make it a sub-element for the branding EP, it would be good to follow an established pattern if there is one...
Created attachment 188501 [details] HttpService selector patch That's the patch that I'm using currently. It should apply against today's HEAD cleanly. The concept of the HttpService selector is borrowed from the Equinox HttpService Registry. If you look at the filters/resources/servlets extension points they all use this context in order to limit the registration to a specific service.
(In reply to comment #11) > Created attachment 188501 [details] > HttpService selector patch The patch also supports a "default" filter. By setting a system property (eg. in config.ini) it's possible to prevent registration of RAP applications with specific (eg. "internal") HttpService instances. This could be used to prevent registrations of RAP applications with the Eclipse help system HttpService.
After some further discussion with Ralf it looks like there are some low hanging fruits as well as some necessary major refactorings long-term in order to support multiple RAP instances (RWT engines) within a single OSGi framework with many HttpService instance. Some (random) notes from the discussion below: - Ralf opened bug 337100 for resource manager simplifications (low hanging fruit) - allowing multiple RWT engines is the best way to go but likely too risky for 1.4 (given we are past M5 already) - this patch works with a single RWT engine - the filter API introduced in the patch should be internal/provisional (it's likely to change with multiple RWT engines because this affects other areas)
Gunnar, I implemented experimental and unofficial support for filtering HttpServices. With the resolution of bug 337787, it should now be possible to run a separate RWT engine for every HttpService. However, I don't have the environment to evaluate this at the moment. Could you give this implementation a spin with Gyrex? I'd also be interested in a simple setup with two HttpServices. If you could come up with a snippet or a bundle that starts two services programmatically, that would be interesting. For the implementation, I mostly followed your approach of adding an additional element to a branding extension. Unlike your patch, I kept the name "filter" intead of "selector" to avoid having two different names for the same concept. I also left out the string parameter to keep the solution simple. So for now, your can only use a class that implements Filter.
(In reply to comment #14) > Gunnar, I implemented experimental and unofficial support for filtering > HttpServices. With the resolution of bug 337787, it should now be possible to > run a separate RWT engine for every HttpService. However, I don't have the > environment to evaluate this at the moment. Could you give this implementation > a spin with Gyrex? Works like a charm. > I'd also be interested in a simple setup with two HttpServices. If you could > come up with a snippet or a bundle that starts two services programmatically, > that would be interesting. You can have a look at the activator of our admin bundle which starts an embedded Jetty HttpService. http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.gyrex/admin/bundles/org.eclipse.gyrex.admin.ui/src/org/eclipse/gyrex/admin/ui/internal/AdminUiActivator.java?view=markup&revision=1.3&root=Technology_Project The relevant API is org.eclipse.equinox.http.jetty.JettyConfigurator. ---- final Dictionary<String, Object> settings = new Hashtable<String, Object>(3); settings.put(JettyConstants.OTHER_INFO, "my-custom-identifier-for-the-filter"); settings.put(JettyConstants.HTTP_ENABLED, Boolean.TRUE); settings.put(JettyConstants.HTTP_PORT, 1234); JettyConfigurator.startServer("my-server", settings); ---- Later on you can create a filter like this: "(&(objectClass=org.osgi.service.http.HttpService)(other.info=my-custom-identifier-for-the-filter))"
Thanks for the snippet! I could successfully start a second Jetty / HTTP Service. That's very helpful for testing. Since running multiple RWT engines is still a new feature, we should give it some time to stabilize before we open up API. I'd suggest that we head for an API for filters in the next release.
One thing I noticed is the missing option to select a default service. Once you have multiple instances it might be desirable to bind non-filtered RAP extensions to a "default" service.
We'll have to come up with a public API in 1.5.
FYI. Thanks to the new Application API in RAP 1.5 M7 I no longer require this. Thus, I'll remove bug 335811 from the "blocks" list. However, I think it's still worthwhile to allow applications to not be registered on all available HttpService instances.
Thanks for letting us know, Gunnar! I'll keep the solution in place now anyway because we're already approaching RCs and the code does not hurt. Since it's hidden API, we might remove it later.
Since we can only have one workbench instance at a time, any solution for bug 377414 that allows to restrict the workbench to start at a certain port or HttpService would also resolve this bug.
