* Fix overlays with CombinedResource
* Improvements to CombinedResource for AnnotationParser
* Added `contains` and `getPathTo` methods to the Resource API, so they can be used by the AnnotationParser
* Fixed numerous bugs in CombinedResource list and getAllResources
* handles cross file system copy as well.
* Reduced fallback to URI string manipulation.
---------
Co-authored-by: gregw <gregw@webtide.com>
Co-authored-by: Joakim Erdfelt <joakim.erdfelt@gmail.com>
* Issue #7408 fix scope of maven dependencies for ee10
* Issue #7408 fix scope of maven dependencies for ee10 jspc and restore it test which were disabled
* Issue #7408 fix scope of maven dependencies for ee9 maven plugin
* Issue #7408 fix scope of maven dependencies for ee9 jspc and restore it test which were disabled
* Issue #7408 fix scope of maven dependencies for ee8 maven plugin
* Issue #7408 fix scope of maven dependencies for ee8 jspc and restore it test which were disabled
---------
Signed-off-by: Olivier Lamy <olamy@apache.org>
* Updating various old/moved URL references found across project (`jetty-10.0.x`) (#10098)
+ Now that the migration of `https://eclipse.org/jetty/` to `https://eclipse.dev/jetty/` has occurred, it is time to review the URI use in our project
+ Updated URLs in poms
+ Added more URIs to XmlConfiguration
+ Updated URLs in module files
+ Updated URLs in documentation
+ Updated URLs in HTML
+ Correcting bad double-scheme URLs (eg: `http://https://www.eclipse...`)
+ Updating text in *.mod files
+ Removing `/current/` from path `/jetty/documentation/current/`
+ Fixing mailing list URL
+ Fixing github URL references in jsps
---------
Signed-off-by: Joakim Erdfelt <joakim.erdfelt@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>
* 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>
ResourceCollection should not have a path
Nor name, nor filename unless all resources agree on it.
revert combine and related methods to return Resource and not explicitly a ResourceCollection, as if there is only 1, then a collection is not needed
cleanup ResourceCollection creation. Avoid sanity checks on resolved resources.
* Resource `resolve()` and `newResource()` return null on resources that do not exist
* Introduce `Resources` utility methods and use them
* Updating javadoc
* QuickStart generation based on Path, usage based on Resource
* QuickStart usage in jetty-maven-plugin uses Path
* Cleanup MavenWebAppContext constructor exceptions
* Improving quickStart stream filtering and array conversion
* Creating WEB-INF, if missing, now more reliable