I've run into a few cases in the past year or so where

package

access to functions doesn't work correctly. Unfortunately, none of these have been on my server -- it's all clients, where I don't have any access. But in all of the cases, I have an error message like this one:

The <methodName> package method in the <webroot>\conversion\<component>.cfc component cannot be accessed from <webroot>\Conversion\<template>.cfm.

It's also not consistent among clients. Client A might have this problem appear on page A, but page B will be fine. But Client B might have no problem on page A, but page B will be a problem. These are all on Windows, on which the file system is supposed to be case-insensitive. But you can see from the message that the paths are identical except for the case. Has anyone else run into this, and have a solution? So far the only one I've found is to take the offending

package

method, and make it

public

instead. But it would be nice to understand why it's breaking.

i'm curious as to how these methods are being called, since package access simply restricts invoking methods to those cfcs to objects in the same physical directory. is that not how you're using package?

yeah. i've got a cfm file in the directory, and it instantiates the cfc (in the same directory) and attempts to call the method. And instead of running, it throws the error. The cfm code is this:

<cfset genericEncrypt = createObject("component", "GenericEncryption")>
// some more code that runs a query
<cfscript>
	genericEncrypt.encryptFieldQuery(passportPassnumQuery, "jbPassport", "passnum");
</cfscript>

It's really pretty straight forward.

i've never used

package

with respect to anything other than cfcs invoking methods from other cfcs, not cfm templates. typically (for me), if you have a service.cfc and a dao.cfc in the same dir, service.cfc has

public

methods that front those in the dao.cfc whose methods have access

package

, so that you MUST go through the service to ultimately access dao methods, controlling how/where daos (or other 'protected' objects) may be composited together or leveraged by other areas. this is how i've traditionally used

package

access, and really for this purpose only, to isolate daos and prevent them from being called/injected from anything other than their service sibling

It's unorthodox, but if it works at all, it should work uniformly. And to be clear, the CFC is in the same dir as the code calling it, and yer using just the CFC name, not any sort of path. Also... I smell a rat here:

<webroot>\conversion\<component>
<webroot>\Conversion\<template>.cfm

Notice the difference?

And to be clear, the CFC is in the same dir as the code calling it, and yer using just the CFC name, not any sort of path.

Yes. Right.

Well: for the sake of code cleanliness if nothing else, you should get these things right. Esp if you've already noticed them. Are the clients collocated on the same one box, and using the same CFML engine / instance? Or are these completely separate installs yer talking about? I can't help but think there's a mapping in play somewhere which isn't quite right. How many Application.cfc files have you got in the entire app, and are you sure that the one you think is being used is the one being used? If you change the method access on that method to public, does the problem go away? Or is this just info you figured to tell us "just in case" (and rightly so)

These are all separate installs. Bizantine government regulations require thigns to be on-prem.

And bear in mind that whilst the Windows file system is case insensitive... Java is not. Could be some quirk of how / when class methods get compiled, and what their underlying Java names end up being (each method compiles to its own class)

sorry, happened to be on a call with said client... So yes, changing the code to public (no other changes) worked fine.