[ 
https://issues.apache.org/jira/browse/SLING-13071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18053949#comment-18053949
 ] 

Robert Munteanu commented on SLING-13071:
-----------------------------------------

I _think_ the problem is in this piece of code ( 
https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/f7f73e2feefb39a4496a85a093fe834aca92fb01/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/use/JavaUseProvider.java#L212-L227
 ):

{code:java}
        if (adaptable != null) {
            LOG.debug("Trying to instantiate class {} as sling adapter via 
adaptable.adaptTo().", cls);
            adaptableResult = adaptable.adaptTo(cls);
        }
        if (adaptableResult == null && jakartaRequest != null) {
            LOG.debug("Trying to instantiate class {} as sling adapter via 
jakarta request.adaptTo().", cls);
            adaptableResult = jakartaRequest.adaptTo(cls);
        }
        if (adaptableResult == null && javaxRequest != null) {
            LOG.debug("Trying to instantiate class {} as sling adapter via 
javax request.adaptTo().", cls);
            adaptableResult = javaxRequest.adaptTo(cls);
        }
        if (adaptableResult == null && resource != null) {
            LOG.debug("Trying to instantiate class {} as sling adapter via 
resource.adaptTo().", cls);
            adaptableResult = resource.adaptTo(cls);
        }
{code}

The logic is correct - both the javax and jakarta requests are checked for 
adaption. As far as I can tell though, the javax request is a 
JakartaToJavaxRequestWrapper whose adaptTo delegates to the wrapper Jakarta 
adaption - 
https://github.com/apache/sling-org-apache-sling-api/blob/b8dfc565efea7c58a1aee5495e6078a88676530b/src/main/java/org/apache/sling/api/wrappers/JakartaToJavaxRequestWrapper.java#L202-L204
 .

> HTL use objects that adapt from the javax SlingHttpServletRequest cannot be 
> instantiated a Jakarta context 
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: SLING-13071
>                 URL: https://issues.apache.org/jira/browse/SLING-13071
>             Project: Sling
>          Issue Type: Bug
>          Components: HTL
>            Reporter: Robert Munteanu
>            Assignee: Robert Munteanu
>            Priority: Major
>             Fix For: Scripting HTL Engine 2.0.2-1.4.0
>
>
> The following preconditions are sufficient to trigger the error:
> - app running in a Jakarta context ( e.g. Sling Starter 14-SNAPSHOT)
> - a HTL has a data-sly-use instruction for a Pojo without a default 
> constructor
> - an AdapterFactory exists that adapts from SlingHttpServletRequest to the 
> Pojo
> The {{JavaUseProvider}} will fail to adapt from the request and fall back to 
> trying the default constructor, with an error such as
> {noformat}
> Caused by: java.lang.NoSuchMethodException: 
> org.apache.sling.starter.testservices.exported.RequestHashCodePojo.<init>()
>       at java.base/java.lang.Class.getConstructor0(Class.java:3187)
>       at java.base/java.lang.Class.getDeclaredConstructor(Class.java:2491)
>       at 
> org.apache.sling.scripting.sightly.impl.engine.extension.use.JavaUseProvider.loadObject(JavaUseProvider.java:244)
>       at 
> org.apache.sling.scripting.sightly.impl.engine.extension.use.JavaUseProvider.provide(JavaUseProvider.java:133)
>       at 
> org.apache.sling.scripting.sightly.impl.engine.extension.use.UseRuntimeExtension.call(UseRuntimeExtension.java:69)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to