You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description
Jetty XML syntax allow to call methods of any class via reflection.
However, when calling JDK methods, they may return JDK-private implementation classes that are not accessible from Jetty code.
This surfaced in particular while working on #8863, where a new Jetty module for the thread pool that supports virtual threads need to call JDK methods that return JDK-private classes.
For that example, we have:
<!-- returns JDK private class ThreadBuilders.VirtualThreadBuilder -->
<Callclass="java.lang.Thread"name="ofVirtual">
<!-- Throws IllegalAccessException: class org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration cannot access a member of class java.lang.ThreadBuilders$VirtualThreadBuilder (in module java.base) with modifiers "public volatile" -->
<Callname="name">virtual</Call>
</Call>
The JDK-private class ThreadBuilders.VirtualThreadBuilder is not accessible, but its JDK-public ancestor Thread.Builder is.
The proposal is to change slightly the semantic of the Call element to support this:
The second Call element specifies the class attribute that should be used to reflect the method named name but it performs a virtual call, not a static call (because it is in the context of an enclosing Call element).
Ambiguities are easily resolved because it's always possible to ask a Method if it is static and if so perform the invocation passing null as the target of the invocation.
The text was updated successfully, but these errors were encountered:
Now <Call>, <Get> and <Set> elements can use the "class" attribute
to specify the exact class to perform method lookup.
Improved support for <Property>, <SystemProperty> and <Env> so that
attribute "name" is now optional (as specified in the DTD), and a
"deprecated" attribute may be present instead.
This is necessary to terminally deprecate properties that have
no replacement.
Signed-off-by: Simone Bordet <[email protected]>
…8915)
* Fixes#8913 - Review Jetty XML syntax to allow calling JDK methods
Now `<Call>`, `<Get>` and `<Set>` elements can use the `class` attribute
to specify the exact class to perform method lookup.
Improved support for `<Property>`, `<SystemProperty>` and `<Env>` so that
attribute `name` is now optional (as specified in the DTD), and a
`deprecated` attribute may be present instead.
This is necessary to terminally deprecate properties that have
no replacement.
Signed-off-by: Simone Bordet <[email protected]>
Now <Call>, <Get> and <Set> elements can use the "class" attribute
to specify the exact class to perform method lookup.
Improved support for <Property>, <SystemProperty> and <Env> so that
attribute "name" is now optional (as specified in the DTD), and a
"deprecated" attribute may be present instead.
This is necessary to terminally deprecate properties that have
no replacement.
Signed-off-by: Simone Bordet <[email protected]>
Jetty version(s)
10+
Description
Jetty XML syntax allow to call methods of any class via reflection.
However, when calling JDK methods, they may return JDK-private implementation classes that are not accessible from Jetty code.
This surfaced in particular while working on #8863, where a new Jetty module for the thread pool that supports virtual threads need to call JDK methods that return JDK-private classes.
For that example, we have:
The JDK-private class
ThreadBuilders.VirtualThreadBuilder
is not accessible, but its JDK-public ancestorThread.Builder
is.The proposal is to change slightly the semantic of the
Call
element to support this:The second
Call
element specifies theclass
attribute that should be used to reflect the method namedname
but it performs a virtual call, not a static call (because it is in the context of an enclosingCall
element).Ambiguities are easily resolved because it's always possible to ask a
Method
if it isstatic
and if so perform the invocation passingnull
as the target of the invocation.The text was updated successfully, but these errors were encountered: