search

eclipse-passage / passage

Define and control license checks and usage constraints for OSGi / RCP / IDE
https://www.eclipse.org/passage/
Eclipse Public License 2.0
6 stars 8 forks source link

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

Closed HannesWell closed 6 months ago

HannesWell commented 6 months ago

Within the FLS it can be of interest to know the sender of a request, e.g. to log it somewhere.

This adds a corresponding remoteAddress() method to NetRequest to obtain it.

Alternatively JettyRequest could grant access to the origin Jetty Request, but this would add parts of Jetty's API to the API of Passage (but personally I would be perfectly fine with that too).

codecov[bot] commented 6 months ago

Codecov Report

Attention: 3 lines in your changes are missing coverage. Please review.

Comparison is base (12031b8) 33.45% compared to head (3cae239) 33.47%.

Files Patch % Lines
...ipse/passage/lbc/internal/jetty/StatedRequest.java 0.00% 1 Missing :warning:
...lipse/passage/lic/internal/jetty/JettyRequest.java 0.00% 1 Missing :warning:
...pse/passage/lbc/base/tests/RequestConstructed.java 0.00% 1 Missing :warning:
Additional details and impacted files ```diff @@ Coverage Diff @@ ## master #1259 +/- ## ============================================ + Coverage 33.45% 33.47% +0.02% Complexity 359 359 ============================================ Files 1175 1175 Lines 25763 25766 +3 Branches 1594 1594 ============================================ + Hits 8619 8626 +7 + Misses 16623 16619 -4 Partials 521 521 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

eparovyshnaya commented 6 months ago

Dear @HannesWell

In order to keep Passage Core architecture consistent, solid and away of sporradic changes we came up with set of rules, which must be followed by anyone willing to contribute to the product development.

In this particular case it worth mentioning that no commit should be offered without ticket reference.

Regarding you proposal. (And this discussion should rather be hosted in a proper ticket.)

One of principles we've build Passage Core architecture is that it is closed for modification and open for extenssion.

You offer modification: NetRequest is a concise and sufficient interface for its aim; Ii describes request essential data and is obliged to carry no convenience information. You propose to bestow rather excessibe demand for its implementations which spoils the clean purpose of the interface.

There is parameter method in this interface, that can actually respond to your custom queries, you just need to create you implementation of this interface.

If there is still no way to plug your own extension for this interface that does what you need for your purposes, we should rather discuss this extension mechanism, instead of modification of existing solution for your needs.

So I offer you to take a step back, raise a ticket, elaborate you needs, so we could locate an extension point(s) and and devise a solution.

In the current form request does not fit with the project architecture line of evolution.

HannesWell commented 6 months ago

So I offer you to take a step back, raise a ticket, elaborate you needs, so we could locate an extension point(s) and and devise a solution.

Created https://github.com/eclipse-passage/passage/issues/1260.