Reorganization of jetty-client classes.

[sbordet]

• Moved oej.client.api to oej.client

• Moved oej.client.util to oej.client

• Moved implementation classes to oej.client.internal

• Moved transports to oej.client.transport

• Moved transport implementation classes to oej.client.transport.internal

• Moved FastCGI transport classes to o.e.j.fcgi.transport

• Moved FastCGI transport implementation classes to o.e.j.fcgi.transport.internal

• Updated WebSocket core client to use only exported, non-internal, oej.client classes.

• Expanded oej.client.Destination APIs:

  • added: getOrigin(), isSecure(), getProxy(), getConnectionPool(), getHttpClient(), send(..).
  • removed: getScheme(), getHost(), getPort() because they don't uniquely identify a Destination anymore (Origin does)

• Moved destination sweeper functionality from HttpDestination to HttpClient. HttpDestination does not implement close() anymore, now relies on LifeCycle.stop()

• Moved HttpReceiver.storeCookie() logic to HttpClient.putCookie() to avoid exposing CookieManager.

• Moved HttpClient.getAcceptEncodingField() to ContentDecoder.Factories

Signed-off-by: Simone Bordet [email protected]

[sbordet]

Sorry for the mega-monster PR, but most of the changes are just changes to import statements.

Notable things to review:

• Decide whether this is worth, because it'll break all users of HttpClient out there.
  However, it aligns HTTP1, HTTP2, HTTP3 and FCGI transports to the same naming and internalizes all implementation classes, which is a good thing for future maintenance.
  Also, resolves the historical mess created by an initial distinction of classes in the api package, but then other classes considered "api" were added outside of the api package, so it was unclear what was api and what was not.
  Now no more api package, only internal for implementation classes.

• Websocket core was using what are now "internal" classes, so it was changed to only use exported classes. @lachlan-roberts, you may want to pay particular attention to this.

[gregw]

Is it worthwhile (or possible) to create deprecated classes in the old locations that extend the classes from their new locations? Or does that just prolong the porting hassles?

[sbordet]

Is it worthwhile (or possible) to create deprecated classes in the old locations that extend the classes from their new locations? Or does that just prolong the porting hassles?

It'll be duplicate names everywhere, e.g. oej.client.Request and oej.client.api.Request, etc.

I'm afraid it's going to be really messy.

Certainly oej.client.Destination has incompatible method changes, same for HttpClient.getContentDecoderFactories(), possibly other classes.

And then with maybe 20+ deprecated classes, the question is when we're going to get rid of them?

We can do a good job at documenting the migration though.

[gregw]

Perhaps a conversion script? It at least a list of regex to apply to make the main changes?

[sbordet]

Perhaps a conversion script? It at least a list of regex to apply to make the main changes?

We can create a "Migration Map" file for IntelliJ, so that people would import it in their IDE, run it (via Refactor/Migrate Packages and Classes) and the IDE will update the sources accordingly.

We can save this file in jetty-documentation/src/main/<somewhere>, and reference it from the documentation's migration guide.

[lachlan-roberts]

Shouldn't this implement Request or extend something like Request.Wrapper?

[sbordet]

@lachlan-roberts it was extending HttpRequest, but now HttpRequest is an internal class.
The only reason to extend was to also implement HttpUpgrader.Factory, and there was an instanceof check with special logic.
Now the HttpUpgrader.Factory is added as attribute to the request, so there is no strict need for this class to extend Request (which has a million methods to implement).

If you feel you want to give to this class the full Request API, then we can make it implement Request, but then we will have to reimplement all the methods.

I tried to export the internals of jetty-client to this module, but then I had horrible failures at OSGi level, which apparently it is not able to understand JPMS's export ... to ..., so the Import-Package directives were all lacking the necessary internal classes.
For this reason, I went for this current implementation, which feels better because it has a very minimal dependency on jetty-client classes (and works with OSGi).

[lachlan-roberts]

I noticed some of the methods have slightly different signature to the ones on Request, for example timeout(long value, TimeUnit unit) return value is different.

But if this class extends a Request.Wrapper (doesn't exist but is easy to generate), then it simplifies this class and stops it diverging from any further changes in the Request interface.

[sbordet]

I'll give it a go. There is the problem of the covariant return type, but I it's always been there.

The problem is that the implementation often casts down to HttpRequest, so offering a public API Request.Wrapper opens up for either ClassCastExceptions or for a major rewrite of the implementation to avoid casts.

I could probably have a private, maybe just in jetty-websocket-core, RequestWrapper class, or make CoreClientUpgradeRequest implement request, but it's a lot of code that currently is not used (only a few methods are), and it'll require changes when Request changes anyway.
I'm not opposed to have CoreClientUpgradeRequest implements Request, but I think that a has-a relationship is better than a is-a relationship for this case.
Your thoughts?

[lachlan-roberts]

I also worry that we could miss some of the API from Request that people would like to use on this.
Maybe we could just add a getRequest() method to access the Request?
But either way I think the has-a relationship will work for now.

[sbordet]

@gregw @lorban @lachlan-roberts, these are the classes to review.
All the others have changes in import statements only, or trivial changes due to package names or method signatures.

oej.client.internal.HttpDestination
oej.client.internal.HttpReceiver
oej.client.internal.HttpRequest
oej.client.transport.internal.HttpConnectionOverHTTP
oej.client.transport.internal.ProtocolHttpUpgrader
oej.client.transport.HttpClientTransportDynamic
oej.client.transport.HttpClientTransportOverHTTP
oej.client.AbstractConnectionPool
oej.client.ConnectionPool
oej.client.ContentDecoder
oej.client.ContentResponse
oej.client.Destination
oej.client.DuplexConnectionPool
oej.client.HttpClient
oej.client.HttpClientTransport
oej.client.HttpProxy
oej.client.HttpUpgrader
oej.client.LeakTrackingConnectionPool
oej.client.MultiplexConnectionPool
oej.client.RandomConnectionPool
oej.client.RoundRobinConnectionPool
oej.client.Socks4Proxy
oej.client.Synchronizable
oej.client.TimeoutCompleteListener
oej.client.ValidatingConnectionPool
jetty-client's module-info.java

oej.ee9.websocket.client.impl.DelegatedJettyClientUpgradeRequest
oej.ee9.websocket.client.JettyUpgradeListener

oej.ee10.websocket.client.impl.DelegatedJettyClientUpgradeRequest
oej.ee10.websocket.client.JettyUpgradeListener

oej.fcgi.client.transport.HttpClientTransportOverFCGI

oej.http2.client.transport.internal.HttpConnectionOverHTTP2
oej.http2.client.transport.internal.HttpSenderOverHTTP2
oej.http2.client.transport.HttpClientTransportOverHTTP2

oej.http3.client.transport.internal.HttpSenderOverHTTP3
oej.http3.client.transport.HttpClientTransportOverHTTP3

oej.websocket.core.client.internal.HttpUpgraderOverHTTP2
oej.websocket.core.client.CoreClientUpgradeRequest
oej.websocket.core.client.UpgradeListener

[lorban]

LGTM. Since you haven't modified much at the implementation level I assume that if the build passes this change should be pretty safe.

[gregw]

Nothing bad seen