I'd back up and check your code

Something isn't right if you expected that empty struct to be an instance of your http builder

oh, it's your ver name

request

is reserved in Lucee

yeah I just realized that

You're hitting the actual request scope!

changed it and now it is different

Adobe will allow you to create a variable named after a scope, Lucee won't

the dump is an “HttpRequestBuilderImpl” and now calling the methods separately throws the same error as chaining them: Unable to make public java.net.http.HttpRequest$Builder jdk.internal.net.http.HttpRequestBuilderImpl.header(java.lang.String,java.lang.String) accessible: module java.net.http does not “exports jdk.internal.net.http” to unnamed module @6f72fefc

So Lucee has the same bug?

seems that way

at least 5.3.7.47, I’ll try upgrading it later

FWIW, for a while Clojure also had that bug when calling Java methods reflectively -- but now it walks up the inheritance tree to try to find an accessible parent to look for method calls on.

interesting

do you think I should submit this to Adobe?

I suspect CFers don't do a lot of Java interop in ways that would be affected by the module system (introduced in Java 9).

Yeah, definitely submit a bug. To both Adobe and Lucee, with a straightforward repro case - a cutdown version of what you're trying to do.

(drop the client stuff and just have the http request / builder / uri stuff and the

.header()

call -- show both the method-chaining and the individual call versions)

cool, will do. I also just realized that I’m pretty sure “client” is also reserved, lol. Should have noticed the “request” thing far earlier

Thanks for all your help @seancorfield and @bdw429s

Heh, for me it's been long enough since I did any CFML that I totally forgot about that (and I've mostly been using Railo/Lucee for more than a decade at this point).

Happy Oracle Java Update Day, for those of you who observe it...

I’m seeking some guidance about server.xml configuration (ColdFusion 2018, update 18) Here is our scenario: 1. The application source code is on a network shared drive. We can’t easily change this now, but we know it is not ideal. 2. We have “Save class files” option under “Caching” enabled so we can benefit from faster startup times. 3. We have virtual directories mapped for CFIDE, WEB-INF, and cf_scripts to the installation location. server.xml

<Context WorkDir="/opt/coldfusion2018/cfusion/runtime/conf/Catalina/localhost/tmp" docBase="/mnt/fileserver/www/distributorcentral" path="">
    <Resources>
        <PreResources base="/opt/coldfusion2018/cfusion/wwwroot/CFIDE" className="org.apache.catalina.webresources.DirResourceSet" webAppMount="/CFIDE"/>
        <PreResources base="/opt/coldfusion2018/cfusion/wwwroot/WEB-INF" className="org.apache.catalina.webresources.DirResourceSet" webAppMount="/WEB-INF"/>
        <PreResources base="/opt/coldfusion2018/cfusion/wwwroot/cf_scripts" className="org.apache.catalina.webresources.DirResourceSet" webAppMount="/cf_scripts"/>
    </Resources>
</Context>

The PreResources virtual directory mappings for CFIDE and cf_scripts are working as expected, but not the WEB-INF mapping. When the ColdFusion service is started it writes the compiled class files to

/mnt/fileserver/www/distributorcentral/WEB-INF/cfclasses

instead of

/opt/coldfusion2018/cfusion/wwwroot/WEB-INF/cfclasses

. It is highly desirable for us to have those written into the virtual directory instead of the webroot, since the former is very fast to access (being a local folder) and the latter is much slower (being a network folder). Is anyone else successfully configured in this way? Is this something that should work?

Looks like Oracle has provided their quarterly Java updates today as expected per their schedule, with updates across the Java 11, 17, and 21 (all LTS) version-streams.

@Rodney has left the channel

@seancorfield has left the channel

OK, I'm at my wit's end. CF2021, update 16. JDK 11.0.24. Trying to hit an API w/ cfhttp and I'm getting "I/O Exception: Certificate for doesn't match any of the subject alternative names: [apigee.net, *.apigee.net]". I've already done the keystore import dance. No luck. This is actually working on an older, 2016 server. I'm trying to move to the new server, but this has me stuck. Anybody encounter this before?

I've got a fresh install of Lucee 6.1, and I'm getting the following error from my own code:

No matching method for java.nio.file.Files.copy(com.amazonaws.services.s3.model.S3ObjectInputStream, sun.nio.fs.UnixPath, java.nio.file.StandardCopyOption) found. there are similar methods with the same name, but diferent arguments:
copy(java.nio.file.Path, java.nio.file.Path, java.nio.file.CopyOption[]);
copy(java.io.InputStream, java.nio.file.Path, java.nio.file.CopyOption[]);

The problem I'm having is that the constructor inputs for the second suggestion there -- a stream, a path, and a proper CopyOption -- are all 100% implemented by the things being passed into it, as verified by cfdump (for the last two) and the AWS SDK docs (pasted). Is there something I'm not doing to suggest how this should stick together?

Ah, it's a Lucee bug. https://dev.lucee.org/t/6-1-0-243-java-issues-closure-compiler/14161 is doing it.

@priyank_adobe @Mark Takata (Adobe) - Can you please arrange to have the Java installers page updated with Java 11 Update 25 (and Java 17 Update 13)? (See: https://helpx.adobe.com/coldfusion/kb/coldfusion-downloads.html#downloads3)