* Introduced ResponseListeners to reduce per-request allocation.
* Removed ResponseNotifier in favor of ResponseListeners.
* Introduced RequestListeners to reduce the per-request allocation.
* Removed RequestNotifier in favor of RequestListeners.
* Removed unnecessary sharing of HttpRequest.requestListeners.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
* Replaced usages of java.net.HttpCookie with oej.http.HttpCookie.
* Moved server-side only methods from HttpCookie to HttpCookieUtils.
* Introduced and implemented oej.http.HttpCookieStore.
* Removed now obsolete oej.util.HttpCookieStore.
* Introduced HttpScheme.isSecure(String), to avoid code duplication.
* Fixed handling of cookie "localhost" domain in HttpClient.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
There is now a Handler interface hierarchy:
+ Container is a Handler that has 1 or more contained Handlers.
+ Wrapper is a Container with only 1 handler and a setHandler method.
+ Collection is a Container with n handlers and a addHandler method
class are now:
+ Abstract implements Handler
+ AbstractContainer extends Abstract implements Container
+ BaseWrapper extends AbstractContainer implements Wrapper
+ Sequence extends AbstractContainer implements Collection
Lots of other associated cleanups
With issue #9166, ByteBufferPool was removed and replaced by
RetainableByteBufferPool. Since ByteBufferPool was used by
AbstractConnector, this change broke backwards compatibility with
third-party connectors such as junixsocket-jetty.
Since there's no longer any other ByteBufferPool, rename the
RetainableByteBufferPool interface, and thereby not only reinstate
compatibility with existing third-party libraries but also save a few
keystrokes.
https://github.com/eclipse/jetty.project/issues/9284
Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com>
Relaxed jetty-fcgi JPMS dependencies.
Packages generator and parser were not internal,
was just matters of exporting them.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
* rename sessions tests with eeX version in package name as it, we can indentify which test is failing with junit result
* get rid of some duplicate classes
Signed-off-by: Olivier Lamy <olamy@apache.org>
* Added a core Session abstraction
Sessions were already a core mechanism, but there was no API for them.
There is now a new Session interface that is available via the Request API. It is intended only for users of sessions.
The previous concrete class Session has been renamed to ManagedSession and it is used by classes that extend AbstractSessionManager.
* Fixed tests
* Use static method
* Updates from review
* Updates from review
Improved javadoc
used util Attributes interface.
* silence stack traces in IdleTimeoutTest by refactoring test + avoid execution of handlers over closed streams
Signed-off-by: Ludovic Orban <lorban@bitronix.be>
This was primarily done to avoid surprise of the previous behaviour of puts for a duplicate key being ignored.
The use of the AbstractMap class now provides javadoc and known/expected behaviour for key methods.
The only significant behaviour change is in the return type of some key methods, with the old/previous value replacing a boolean.
Some stream usage has also been replaced by the more efficient iterator.
* Fixed DetectorConnection buffer lifecycle.
Now `detectAndUpgrade()` does not do any buffer lifecycle.
The buffer lifecycle is handled by the callers of `detectAndUpgrade()`.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
* Fixes#9210 - Jetty 12 - Review Pool and Pool.Entry
* Extracted interface Pool, renamed implementation to ConcurrentPool.
* Extracted Pool.Entry as interface.
* Moved StrategyType to ConcurrentPool.
* Made Pool.Factory.wrap() work in order to wrap Pool instances.
* Removed constructors that were explicitly taking Pool parameters, replaced by a single Pool.Factory parameter.
* Added javadocs.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
* Remove usage of HandlerList and reduce usage of Handler.Collection
"The best part is no part" - Elon Musk!
The overwhelming usage of `HandlerList` and `Handler.Collection` was for adding the `DefaultHandler` after the main handler. This PR adds a getter/setter for a `DefaultHandler` on the server, so we no longer need to always create a `Handler.Collection` structure. This has allowed the deprecated `HandlerList` and `HandlerWrapper` classes to be removed.
In implementing this PR, several problems were found in the calculation of `InvocationType`, not least that it was assumed that an empty `Handler.Collection` was `BLOCKING`. When this issue was fixed, any dynamic addition of contexts (deployer or SPI server) failed as the `InvocationType` changed. So this PR also introduces the `isDynamic()` attribute of all `Handler.Container`s. A dynamic container will always return `BLOCKING` from `getInvocationType()`, as there is always a race with a new handler being added. A non-dynamic container will return a real `InvocationType`, calculated from its children, but it's mutator methods will ISE if contained handlers are changed.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Co-authored-by: Jan Bartel <janb@webtide.com>
Co-authored-by: Simone Bordet <simone.bordet@gmail.com>
* Introduce GracefulShutdownHandler and test
+ started with removing `@Disabled` from `GracefulStopTest.java`
+ GracefulShutdownHandler based on Callback manipulation
* Issue #9173 - Make wrapping of ServletApiResponse easier
* Fixing checkstyle and missing licenses
* Improved HttpCookie with javadoc and attribute handling
* Add documentation in "Standard Modules" section for the jmx module
* Add documentation in "Standard Modules" section for the ee8,9,10-webapp modules
* Use shorter markup tags to transclude documentation from .mod files
* Extract EE version strings into variables
* Replace literal usages of EE version numbers with custom attribute
* Use convention 'eeN' instead of 'eex' in filenames
* Update metadata tag for deploy module documentation
* Update deploy module documentation to discuss EE platform-specific deploy modules
* Add documentation for the resources module
* Add resources module into section table of contents
* Use jetty-home instead of JETTY_HOME as documentation attribute
Co-authored-by: Simone Bordet <simone.bordet@gmail.com>
* Remove @Disabled from ConnectorTimeoutTests
* Remove @Disabled from SlowClientsTest
* Remove @Disabled from SslConnectionFactoryTest
* Remove @Disabled from DetectorConnectionTest
* Disabling quiche from checkstyle
* Removing ConnectorTimeoutTest BlockingTimeout tests
+ The concept of HttpConfiguration.blockingTimeout
has been removed, these tests are no longer relevant
+ Removed the array optimized look ahead
+ version lookahead now done with getInt
+ improved test harness to check lf and crlf endings
+ added HTTP as int optimization
+ fixed bug in near miss of field cache
Signed-off-by: Greg Wilkins <gregw@webtide.com>
Co-authored-by: Greg Wilkins <gregw@webtide.com>
* util: Add support for GraalVM Native-Image resource:-URIs and Paths
GraalVM Native-Image makes its classpath resources accessible through an
opaque resource: URL scheme.
Add support for this scheme in URIUtil and PathResource.
Automatically create the NativeImageResourceFileSystem when necessary.
Also add a workaround where converting such Native-Image Paths back to
URI would yield the wrong URI (potentially a bug in GraalVM).
https://github.com/eclipse/jetty.project/issues/9116https://github.com/oracle/graal/issues/5720
* URIUtil: Suppress CodeQL false positive error about path injection
Github CodeQL code scanning reports a high-severity error "Uncontrolled
data used in path expression", because a path depends on a user-provided
value.
This is a false positive.
Suppress the error by annotating a corresponding @SuppressWarnings tag.
Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com>
* URIUtil: Removed unused code
KNOWN_SCHEMES isn't used anywhere.
* PathResource: Selectively enable resource: for GraalVM Native Image
In regular HotSpot VMs, the resource: scheme may be registered by other
clients. However, in GraalVM Native Image, this is used for classpath
resources.
This resource scheme needs to be enabled by default for Native Image
environments so we can support code that is unaware of GraalVM
internals, such as:
URL resourceURL = MyClass.class.getResource("some/resource");
Resource resource = ResourceFactory.root().newResource(resourceURL);
Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com>
* PathResourceFactory: Ignore certain RuntimeExceptions upon init
Ignore FileSystemAlreadyExistsException, ProviderNotFoundException, etc.
that may be thrown upon calling FileSystems.newFileSystem.
Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com>
* PathResource: Work-around false positive CodeQL warning
CodeQL prevents amending the call to Paths.get.
Work-around this by using a separate constructor. The additional benefit
is that URIUtil.correctResourceURI won't need to correct the URI twice.
Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com>
* PathResource: Fix "isAlias" issue with resource: URIs
Fix two more places where Native Image resource: URIs need to be
changed.
Without this change, Resource#isAlias() would return true for such URIs,
and a warning like "BaseResource resource:/some/package/ is aliased to
resource:file:///resources!/some/package/" would be logged.
* Move GraalVM Native-Image code to NativeImagePathResource/-Factory
Keep the GraalVM Native-Image code contained in custom subclasses.
We still enable the "resource:" URL scheme by default if a GraalVM
Native-Image environment is detected via System property. This allows us
to transparently support calls like
ResourceFactory.root().newResource(MyClass.class.getResorce("webapp"))
Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com>
* Refactor Graal native-image resource: handling
Detect the resource: scheme by checking the scheme of a well-known
resource instead of looking at a system property.
Rename NativeImagePathResource* to GraalIssue5720PathResource* and make
these classes package-private.
Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com>
* Only use GraalIssue5720PathResourceFactory when truly needed
Previously, we were always enabling this resource factory for GraalVM
native-image environments.
We now check if that's actually necessary.
We fall back to MountedPathResourceFactory or PathResourceFactory,
depending on whether the URL contains "!/" or not.
Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com>
+ `Server` now has setter/getter for a temp directory, which can be null
+ `Context` now has a getter for a temp directory, which is never null
+ Server root Context temp directory is either whatever is set, else a work directory, else java.io.tmpdir
+ WebInfConfiguration will still create a temp directory name, but defers to ContextHandler for creation/persistence of the temp directory
+ temp directory (and BASE) removed from the deployer, as it is now the server temp directory.
Previously, we were always enabling this resource factory for GraalVM
native-image environments.
We now check if that's actually necessary.
We fall back to MountedPathResourceFactory or PathResourceFactory,
depending on whether the URL contains "!/" or not.
`Retainable`s that return false from `canRetain()` now are noops if `retain()` is called, which allows for a simpler calling convention.
`AsyncContent` has also been reworked to allocate less and be clearer in its use of `canRetain()`.
* Fixes#8993 - Retainability of special Chunks
* Restored Jetty 11's AsyncContentProducer and related classes in jetty-ee9-nested module (src and test).
* Introduced Retainable.canRetain().
* Removed Chunk.isTerminal() and replaced it with alternative method calls.
* Clarified AsyncContent.write() in case of Chunk.Error.
* Removed AsyncContent.write(Chunk, Callback) because it was making the API confusing.
For example, AsyncContent.close() clashing with write(EOF, NOOP), or
AsyncContent.fail(x) clashing with write(Chunk.Error, NOOP), etc.
* Improved usage of Chunk.from(..., Retainable).
* Improved usage of Chunk.slice().
* Using from() in MultiPart, rather than duplicating code.
* Fixed MultiPart.Parser.Listener.onPartContent() javadocs.
* Renamed non-retaining Chunk.from() to Chunk.asChunk().
* Removed Chunk.slice() methods, inlining them where necessary.
* Carefully reviewed all usages of read()-like methods that return a Retainable instance to make sure it is released.
* Updated HTTP/2 and HTTP/3 usages of Stream.Data to follow the correct retain/release semantic.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
* Reorganization of jetty-client classes.
* 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 TunnelRequest to oej.client.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
* Avoid public/protected Logger instances.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Detect the resource: scheme by checking the scheme of a well-known
resource instead of looking at a system property.
Rename NativeImagePathResource* to GraalIssue5720PathResource* and make
these classes package-private.
Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com>
* Fixes#9141 - Thread-safe Content.Chunk#slice
* Changed Content.Chunk.slice(int, int, boolean) to have the same parameters as ByteBuffer.slice(int, int) for consistency.
* Updated Chunk.slice(int, int, boolean) javadocs.
* Update code that was calling Chunk.slice(int, int, boolean).
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Keep the GraalVM Native-Image code contained in custom subclasses.
We still enable the "resource:" URL scheme by default if a GraalVM
Native-Image environment is detected via System property. This allows us
to transparently support calls like
ResourceFactory.root().newResource(MyClass.class.getResorce("webapp"))
Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com>
Fix two more places where Native Image resource: URIs need to be
changed.
Without this change, Resource#isAlias() would return true for such URIs,
and a warning like "BaseResource resource:/some/package/ is aliased to
resource:file:///resources!/some/package/" would be logged.
CodeQL prevents amending the call to Paths.get.
Work-around this by using a separate constructor. The additional benefit
is that URIUtil.correctResourceURI won't need to correct the URI twice.
Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com>
Ignore FileSystemAlreadyExistsException, ProviderNotFoundException, etc.
that may be thrown upon calling FileSystems.newFileSystem.
Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com>
In regular HotSpot VMs, the resource: scheme may be registered by other
clients. However, in GraalVM Native Image, this is used for classpath
resources.
This resource scheme needs to be enabled by default for Native Image
environments so we can support code that is unaware of GraalVM
internals, such as:
URL resourceURL = MyClass.class.getResource("some/resource");
Resource resource = ResourceFactory.root().newResource(resourceURL);
Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com>
Github CodeQL code scanning reports a high-severity error "Uncontrolled
data used in path expression", because a path depends on a user-provided
value.
This is a false positive.
Suppress the error by annotating a corresponding @SuppressWarnings tag.
Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com>
GraalVM Native-Image makes its classpath resources accessible through an
opaque resource: URL scheme.
Add support for this scheme in URIUtil and PathResource.
Automatically create the NativeImageResourceFileSystem when necessary.
Also add a workaround where converting such Native-Image Paths back to
URI would yield the wrong URI (potentially a bug in GraalVM).
https://github.com/eclipse/jetty.project/issues/9116https://github.com/oracle/graal/issues/5720
Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com>
* core: util: TypeUtil: Use method references instead of reflection
TypeUtil currently uses reflection to convert Strings to primitive/boxed
basic types.
This may not only be a performance problem, but it also prevents
environments like GraalVM native-image to detect required methods
without the help of an agent.
Use method references (Boolean::valueOf, etc.) instead.
Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com>
* Improved javadoc
* Refactored ThreadLimitHandler to avoid lambda creation and to always execute
* Refactored DelayedHandler to avoid lambda creation and to execute only if needed
* added modules for the DelayedHandler
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Signed-off-by: Greg Wilkins <gregw@webtide.com>
Co-authored-by: Simone Bordet <simone.bordet@gmail.com>
Alternative Handler architecture.
All Handlers are Processors, which now return a boolean to indicate the request has been accepted.
The request/response/callback are no longer modal, so there is no race with the boolean return.
Optimized PathMappings.
Avoid iterations if only ServletPathSpec instances
Avoid tests for empty mappings.
Better reset implementation
Improve suffix matching
Improve exact matching
Renamed HttpStream.getNanoTimeStamp() to getNanoTime().
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Co-authored-by: Simone Bordet <simone.bordet@gmail.com>
The problem was that sometimes content bytes generated randomically ended with \r, confusing the multipart parser.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
* Improved locking for HttpReceiver.ContentSource.
Improved response failure code path.
Now either responseFailure() must be called, or exchange.responseComplete() followed by HttpReceiver.abort().
Fixed failAndClose() for HTTP/2 and HTTP/3: the connection must not be closed, stream.reset() is sufficient.
Fixed flaky test HttpClientDemandTest.testTwoListenersWithDifferentDemand().
Fixed DistributionTests.testVirtualThreadPool().
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
* Extracted some non controversial cleanups from another mega PR:
+ TypeUtil class shortname used more often and includes trailing digits
+ Fixed direct stopping/starting of a nested ContextHandler
+ Fixed null path handling in nested context
+ more tests for all of the above
* Extracted some non controversial cleanups from another mega PR:
Fixed nested doStart and doStop
* Extracted some non controversial cleanups from another mega PR:
Fixed DistributionTests
* Cleanup ContextHandler
Extracted some of the goodness from #8793:
+ Clear enter/exit scope methods rather than opaque suppliers and Runnables
+ Removed overloading of "Context" class name to avoid accidental usage of wrong type.
+ Less holding onto request/response as fields
* Cleanup ContextHandler
fixed test with no server
* Updates from review.
* Rewrite RuleProcessor
This decouples the rewrite module from the `WrapperProcessor` class, which is being considered for significant refactoring or removal.
Having a module specific version of that class allows better code readability and a more appropriate API that avoids duplication request instances.
* Fixed javadoc
* Updates from review.
* Updates from review.
Make the MimeTypes available from the server mutable.
Context MimeTypes are now wrappers over the server MimeTypes, so configuration at the server level is inherited by all contexts.