OK, so a few things in reply, Paul...
First, FWIW, I just ran the latest Adobe CF docker image for CF2023 (clearly reporting to be that for 2023 update 16), and I too added installModules=all. Not only does it start fine, and install all the modules, but I can run code within it that uses cfimage...and I can call functions with arguments that have a type. So whatever is amiss about your setup seems unique. But I appreciate you "just want it to work".
So first, are you confirming also that your local CF2023 is on update 16? You say it's "the same spec". Just want to be clear., since things "work" there but not in your container.
Next, someone might be tempted to wonder if this could be related to the update from April of this year, which made it be that if you make remote method calls into CFC methods and pass in any arguments, those arguments MUST defined in the CFC method. But your saying that it's merely a matter related to the TYPE of the cfargument, so it seems unrelated to the change.
Some may also be tempted to wonder if this has to do with the CF Admin setting called "disable CFC type check" (on the first settings page). But that has to do with whether CF validates what is RETURNED from a CFC method. You are clearly indicating it's about the type for the incoming cfargument instead--so that setting is unrelatd.
I'd asked if you could offer some simple code to demonstrate your problem. I've gone ahead and done that. Here is a simple test.cfm . Drop it into your /app folder within the container and run it. What does it show for you?
Note first it reports the CF version. For the current CF2023 image it should show you 2023,0,16,330828. If somehow it still reports 2023,0,15...., do a docker pull public.ecr.aws/adobe/coldfusion:latest-2023. (As you may know, Docker doesn't pull the new update if you have an older one already cached for that name, when you do a docker run or compose up.) If that pulls a new version, restart the container (compose down and up) and it will use that new one.
Then the test.cfm below does a test of using cffunction with a cfargument with a type . The first method call should work, the second should fail (for not matching the type). Do you instead get an error for both? If instead it works, then please create a similarly simple example which demonstrates your error. I'll lbe happy to run it to confirm if I see it.
Finally, the code also has a cfimage test at the top (using one of the images within the container). If your run of the page fails simply because the image package is missing, comment out the 2 lines. But as for WHY you don't have the image package, there WILL be an explanation (of why it's uniquely happening for you) and it SHOULD be clarified in the logs. I appreciate you didn't find it.
If you still don't (with this encouragement) and if this is important to solve, I suspect I could help you quickly in in a shared desktop consulting session together, in perhaps as little as 15 mins. More at carehart.org/consulting, including my rates, approach, satisfaction guarantee, and online calendar.
Anyway, here now is that code for the test.cfm:
<cfoutput>CF version is: #server.coldfusion.productversion#<br></cfoutput><hr>
<!--- test cfimage call, with an image already within the container --->
<cfimage name="testimage" source="/opt/coldfusion/cfusion/wwwroot/CFIDE/administrator/images/background.jpg">
<cfdump var="#testimage#" label="imagedump">
<hr>
<!--- test function calls with arg checking --->
<cfoutput>
Calling testfunction with arg of 1: #testfunction(1)#<br>
Calling testfunction with arg of "bob": #testfunction("bob")#<br>
</cfoutput>
<cffunction name="testfunction">
<cfargument name="arg1" default="0" type="integer">
<cfreturn "testfunction was passed #arguments.arg1#">
</cffunction>
/Charlie (troubleshooter, carehart. org)
9
Replies
AdChoices