Ticket #448 (closed Feature Request: fixed)

Opened 11 years ago

Last modified 9 years ago

Replace Felix HTTP by OPS4J Pax Web

Reported by: jri Owned by: jri
Priority: Major Milestone: Release 4.4
Component: DeepaMehta Standard Distribution Version:
Keywords: Cc: dgf, Malte, JuergeN, carolina
Complexity: 5 Area: Runtime Environment
Module: deepamehta-core

Description (last modified by dgf) (diff)

The PluginActivator provides a registerFilter method that has to use a proprietary extension as long as the standard OSGi HTTP service not defines such mechanism. At the moment the filter registration is backed by a direct call of the extented Apache Felix HTTP Service. In the DeepaMehta standard distribution context this is fine, but it complicates the usage of Apache Karaf features like the webconsole - many of them are depending on the Pax Web HTTP Service.

The original request comes from dgf:

Und was ich bitte noch in der 4.2 Planung haben möchte: Eine Umstellung auf OPS4J Pax Web 1.1.3, so wie es von activemq-karaf 5.8.0 und webconsole-base 2.3.0 verwendet wird. Damit hätten wir einen OSGI HTTPService der Websockets unterstützt (Jetty 7.6.7).

Change History

comment:1 Changed 11 years ago by dgf

  • Description modified (diff)

comment:2 Changed 11 years ago by jri

Indeed there is a way to remove the dependency on the extented Apache Felix HTTP Service. The current DM snapshot (4.1.1-SNAPSHOT) provides a PRE_PROCESS_REQUEST core event. This allows plugins to intercept requests without registering a custom servlet filter.

At the moment the only plugin that makes use of registerFilter() is the Access Control plugin. I will adapt it accordingly. We should ready for Pax Web then.

Thanks, dgf, for readdressing this issue!

comment:3 follow-up: ↓ 4 Changed 11 years ago by jri

Core: drop Felix ExtHttpService? (#448).

The Access Control plugin doesn't register a servlet filter anymore but listens to the PRE_PROCESS_REQUEST DeepaMehta core event.

BREAKING CHANGE

PluginActivator?'s registerFilter() method is dropped.

IMPORTANT

This solution works for a standard DM installation but is not fully compatible with DM's previous request filtering behavoir. In particular a closed DM installation (read_requires_login=true) have a serious issue.

It turned out that request filtering via a servlet filter and request filtering via the PRE_PROCESS_REQUEST core event are not equivalent. While a servlet filter sees all requests a PreProcessRequestListener? sees only the requests bound to the Jersey servlet but not the requests to static resources.

As a consequence a closed DM installation is not fully closed anymore, and in case of Safari is not working at all (Safari brings up no login dialog for a 401 response when the request was sent via XHR).

So, this commit must not meet the DM production line. Further work is required. We could either 1) further adapt the DM core in the way the PRE_PROCESS_REQUEST event is fired for static resource requests as well, or we could 2) investigate weather Pax Web provides a working custom API for deploying servlet filters (an equivalent to Felix's ExtHttpService?).

See #448.

Changeset: 3468e935eef566d63dd7028592fc114787edeac2

comment:4 in reply to: ↑ 3 Changed 11 years ago by jri

Replying to jri:

We could either 1) further adapt the DM core in the way the PRE_PROCESS_REQUEST event is fired for static resource requests as well

I've choosen to follow this path now. See #480.

comment:5 Changed 11 years ago by jri

New core event: RESOURCE_REQUEST_FILTER (#480, #448).

This event allows to intercept with requests to static resources, both bundle resources and file system resources.

Listener interface: de.deepamehta.core.service.event.ResourceRequestFilterListener?
Listener method: void resourceRequestFilter(HttpServletRequest? servletRequest)

To abort request processing throw a javax.ws.rs.WebApplicationException?.
DeepaMehta will send the response wrapped in that WAE then (status code, headers, text entity).

BREAKING CHANGES

2 Core events are renamed:

PreProcessRequestListener? -> ServiceRequestFilterListener?
preProcessRequest() -> serviceRequestFilter()

PreSendResponseListener? -> ServiceResponseFilterListener?
preSendResponse() -> serviceResponseFilter()

IMPORTANT

Dropping of the Felix ExtHttpService? should be now complete. This branch could be merged into master.

In order to be nearly compatible with the (now dropped) registerFilter() method your plugin can consider implementing both, ServiceRequestFilterListener? and (the new) ResourceRequestFilterListener?. This ensures to intercept with each kind of request, that is service method requests (REST) as well as static resource requests (bundle resources and file system resources).

For the sake of completeness: the behavoir resulting from implementing both listeners is not fully equivalent as with registerFilter(). While the listeners see only requests bound to the registered URI namespaces the former servlet filter saw absolutely all requests, also the ones resulting in 404 Not Found. However, in practice this difference should not be relevant.

The Access Control plugin makes use of the new ResourceRequestFilterListener?. Thus a private DeepaMehta installation works like before, also in Safari (see #448).

See #480.

Changeset: c16c598f94f5179af050ab24b724a73d2aadece9

comment:6 Changed 11 years ago by jri

  • Cc JuergeN added

comment:7 Changed 11 years ago by Jörg Richter

Provision: Pax Web 1st try - no success (#448).

An out-of-the-box try with Pax Web 1.1.3 was not successful.
Calling the Webclient results in 403 Forbidden.
http://localhost:8080/de.deepamehta.webclient/
No clue.

Strangely the same URL called from curl results in 200 OK but with an empty message body (and no Content-Length header).
I'll keep investigating this.

There is a new "pax-web" branch.

See #448.

comment:8 Changed 11 years ago by Jörg Richter

Pax Web serves static resources (#448).

After intense experimentation with different Felix versions (3.2.1, 3.2.2, 4.0.3), that is OSGi 4.2/4.3 specs, Bundle versions (in particular File Install), Pax Web versions (1.x, 2.x, 3.x), and different configurations (in particular File Install's noInitialDelay), there is a minor progress: With Felix 4.0.3 and Pax Web 1.1.3 we can serve static resources!

The 403 Forbidden mentioned before was a result of the different ways Felix HTTP Jetty and Pax Web pass resource names to a org.osgi.service.http.HttpContext?.

However the REST services (the Jersey servlet) are *not* functional. So DM is not yet working with Pax Web.

Furthermore I identified a serious bug (related to resouce registration) in Pax Web 3.0.2 that was not there in Pax Web 2.x or Pax Web 1.x. I will inform the Pax Web guys about that.

The overall experience with Pax Web is very frustrating. There are a lot of different versions and no one knows which work together with Felix version on standard bundle versions resp. what are Pax Web bugs. I tried about 100 ;-) combinations and it seems the *only* one that could yield the minor progress mentioned above is Felix 4.0.3 and Pax Web 1.1.3 and setting File Install's noInitialDelay setting to true (plus doing an ugly workaround in the felix.fileinstall.dir configuration). Other Pax Web versions, even other 1.1.x ones, do not work.

Perhaps it is not by accident Danny suggested to use Pax Web 1.1.3 as this is the version deployed by Karaf as well. Other users also report about lot of bugs in Pax Web.

Another field of horror is the Felix File Install bundle, which also exists in a lot of differnt versions, all behaving differnetly. A lot of exceptions are thrown, more or less OSGi internal ones, so the developer has little chance to understand what is going on.

Now I will try to get the REST services working, that is the Jersey servlet (there are a lot of verisions ;-). Frankly spoken, for the moment I don't feel confident to get it running, and for the moment I don't know how much time I should still spend on this frustrating ground. But who knows, perhaps I get little more insights or minor progress that will boost my motivation.

See #448.

comment:9 Changed 11 years ago by jri

I filed an issue regarding resource registration in Pax Web 3.0.2:
https://ops4j1.jira.com/browse/PAXWEB-634

comment:10 Changed 11 years ago by Jörg Richter

Pax Web success! (#448).

The REST services (the Jersey servlet) is working.
Finally DM runs with Pax Web!

The solution was to register the Jersey servlet at "/*" instead of "/" (which I think is not OSGi compliant and does not work with Felix HTTP Jetty as well). So a single asterisk character did the trick.

You can test it in the "pax-web" branch.

What is missing now is the adaption of the SSL configuration parameters.

BTW: with Pax Web we finally have the opportunity to set the Jetty webserver to listen on a specific network interface (see #39).

You might not consider this possible: yesterday I bought a bottle of spaish red wine called Asterisk. The label is all blank but with a single * on it.

See #448.

comment:11 Changed 11 years ago by dgf

  • Version 4.1 deleted
  • Milestone changed from Release 4.2 to Release 4.1.4

comment:12 Changed 11 years ago by jri

  • Milestone Release 4.1.4 deleted

comment:13 Changed 10 years ago by jri

  • Status changed from new to accepted
  • Cc carolina added
  • Owner set to jri
  • Milestone set to Release 4.4

We will try to make Pax Web DM's standard HTTP service implementation up from DM 4.4, replacing Felix HTTP Jetty once and for all.

DM 4.4 is scheduled for release mid Sep 2014.

comment:14 Changed 10 years ago by Jörg Richter

Core: replace Felix HTTP by Pax Web (#448).

Felix HTTP Jetty is now replaced by Pax Web once and for all (hopefully).

We have Pax Web 3.1.2 with a Jetty 8 (that means Servlet API 3.0).

Also we have Felix 4.4 (that means OSGi 5) now (see #703).

We're still on JDK 6.

DM with Pax Web can be tested on the "pax-web-3" branch.
This is merged into master soon and will be part of the upcoming DM 4.4 release.

See #448.

comment:15 Changed 10 years ago by Jörg Richter

Pax Web fix: no session timeout (#448).

New config parameter in global pom.xml:

<org.ops4j.pax.web.session.timeout>0</org.ops4j.pax.web.session.timeout>

The amount in minutes when a session times out at server-side.
Set 0 for no time out.

Pending related Pax Web: HTTPS configuration.

See #448.

comment:16 Changed 10 years ago by Jörg Richter

Core: replace Felix HTTP by Pax Web (#448).

Felix HTTP Jetty is now replaced by Pax Web once and for all (hopefully).

We have Pax Web 3.1.2 with a Jetty 8 (that means Servlet API 3.0).

Also we have Felix 4.4 (that means OSGi 5) now (see #703).

We're still on JDK 6.

DM with Pax Web can be tested on the "pax-web-3" branch.
This is merged into master soon and will be part of the upcoming DM 4.4 release.

See #448.

comment:17 Changed 10 years ago by Jörg Richter

Pax Web fix: no session timeout (#448).

New config parameter in global pom.xml:

<org.ops4j.pax.web.session.timeout>0</org.ops4j.pax.web.session.timeout>

The amount in minutes when a session times out at server-side.
Set 0 for no time out.

Pending related Pax Web: HTTPS configuration.

See #448.

comment:18 Changed 10 years ago by Jörg Richter

Core: replace Felix HTTP by Pax Web (#448).

Felix HTTP Jetty is now replaced by Pax Web once and for all (hopefully).

We have Pax Web 3.1.2 with a Jetty 8 (that means Servlet API 3.0).

Also we have Felix 4.4 (that means OSGi 5) now (see #703).

We're still on JDK 6.

DM with Pax Web can be tested on the "pax-web-3" branch.
This is merged into master soon and will be part of the upcoming DM 4.4 release.

See #448.

comment:19 Changed 10 years ago by Jörg Richter

Pax Web fix: no session timeout (#448).

New config parameter in global pom.xml:

<org.ops4j.pax.web.session.timeout>0</org.ops4j.pax.web.session.timeout>

The amount in minutes when a session times out at server-side.
Set 0 for no time out.

Pending related Pax Web: HTTPS configuration.

See #448.

comment:20 Changed 10 years ago by Jörg Richter

HTTPS configuration for Pax Web (#448).

New config properties in global POM:

org.osgi.service.http.port.secure -- The HTTPS port. Default is 8443.

org.osgi.service.http.secure.enabled -- To enable HTTPS set this to true. Default is false.

`org.ops4j.pax.web.ssl.keystore -- The path to the .keystore file.

org.ops4j.pax.web.ssl.password -- The Key Password (as entered in the keytool).

org.ops4j.pax.web.ssl.keypassword -- The Keystore Password (as entered in the keytool).

Note the confusing wording of the 2 Pax Web password properties.

For keytool usage to create a keystore and a key pair and a self-signed certificate see #295.

See #448.

comment:22 Changed 10 years ago by Jörg Richter

HTTPS configuration for Pax Web (#448).

New config properties in global POM:

org.osgi.service.http.port.secure -- The HTTPS port. Default is 8443.

org.osgi.service.http.secure.enabled -- To enable HTTPS set this to true. Default is false.

`org.ops4j.pax.web.ssl.keystore -- The path to the .keystore file.

org.ops4j.pax.web.ssl.password -- The Key Password (as entered in the keytool).

org.ops4j.pax.web.ssl.keypassword -- The Keystore Password (as entered in the keytool).

Note the confusing wording of the 2 Pax Web password properties.

For keytool usage to create a keystore and a key pair and a self-signed certificate see #295.

See #448.

comment:24 Changed 10 years ago by jri

  • Status changed from accepted to closed
  • Resolution set to fixed

comment:25 Changed 9 years ago by jri

  • Status changed from closed to reopened
  • Resolution fixed deleted

The ROOT_APPLICATION_PATH constant should be a config property.
Distros can be assembled without branching/compilation then.

comment:26 Changed 9 years ago by Jörg Richter <jri@…>

In 71e30b9448c34754e7b639280173b600f07a683e/deepamehta:

New config property: "dm4.webservice.path" (#448).

Only these 2 values are supported:

  /     For use with Apache Felix HTTP (the default)
  /*    For use with OPS4J Pax Web

This way a distribution assembler may choose between Felix HTTP and Pax Web without branching/compiling.

See #448.

comment:27 Changed 9 years ago by Jörg Richter <jri@…>

In 182241a239e8ae8736243f51762ac6966e5928b0/deepamehta:

Adapt SSL config properties to Felix HTTP (#448).

See #448.

comment:28 Changed 9 years ago by jri

  • Status changed from reopened to closed
  • Resolution set to fixed

As of DM 4.7 we switched back from Pax Web to Felix HTTP. This is because the way Pax Web utilizes the session manager (see ticket:815#comment:13). As a consequence private and collaborative DM file repositories (#815) are not working.

Note: See TracTickets for help on using tickets.