[FLS] Provide mean to obtain the address of the remote that send a request

[HannesWell]

Within a handler passed to passage's FLS JettyHandler it can be of interest to know the sender of a request, e.g. to log it:

JettyServer server = new JettyServer(() -> new JettyHandler((NetRequest request) -> {
  // handle the request
  // obtain the remote address
}));
server.launch(address, port);

With a org.eclipse.jetty.server.Request one can use Request.getRemoteAddr(jettyRequest) to obtain that information, as suggested in https://github.com/eclipse-passage/passage/pull/1259. But neither NetRequest or its JettyRequest implementation provide access to the original Request and Passage's JettyServer and JettyHandler are not extensible and therefore do not allow to use a custom/extended JettyRequest (which is also final). An extension that grants access to the original Jetty Request probably gives the greatest flexibility and would therefore be welcome. The simplest way would be to provide an getter for the origin field of the JettyRequest.

[eparovyshnaya]

Dear @HannesWell

Eclipse Passage FLS was designed and implemented as a demo product to illustrate Eclipse Passage power. This statement is really important to keep in mind during any discussions regarding the product.

Any changes to FLS in the current product form-factor (demo) must serve this purpose.

Meaning, if FLS eventually stops doing demonstration because of a disfunction, then changes fixing this disfunctions are welcome. Like recent #1258.

Change you requested does not serve main purpose of FLS, just lays additional burden without any benefit to the product. It looks like the change is requested for convenience of another derived product, unknown to us.

Been that said, it worth mentioning that despite FLS was never intended to grow to a fully functional or/and reusable product, it can be productized to this grade with a proper effort. Advantage of this new product form-factor would be official API and extension points, which could allow to build derived product in a more efficient way.

We estimate effort to be several man-months, which we can dedicate, if supported. Eclipse Passage FLS productization could definitely serve well to Eclipse Passage product family and open source community in general.

[HannesWell]

Thank you @eparovyshnaya for your elaboration.

Change you requested does not serve main purpose of FLS, just lays additional burden without any benefit to the product. It looks like the change is requested for convenience of another derived product, unknown to us.

That's right.

We estimate effort to be several man-months, which we can dedicate, if supported. Eclipse Passage FLS productization could definitely serve well to Eclipse Passage product family and open source community in general.

While it would be nice to have fully productization of the FLS it would not be worth the effort for us since the current state is sufficient for us and I can also achieve this on other (of course less clean and elegant) ways and I'm happy to contribute from time to time when there is some need.

[eparovyshnaya]

Thank you for information @HannesWell .

Then I'm closing the ticket.

We are looking forward for further collaboration.