Anyone run across an issue with component extends ...
# cfml-general
b
Anyone run across an issue with component extends in CF 2023? We are dealing with a component extends issue where CF is not properly resolving the path. If we turn trusted cache on, the issue goes away, but not good for development, of course. The first component is being instantiated with a full path and the component being extended is using a relative path (in the same folder in this case). We have tried it with the full path, but that did not resolve the issue. The errors we are seeing: "Could not find the ColdFusion component or interface" "Ensure that the name is correct and that the component or interface exists."
a
So to be clear you have something like
o = new com.example.someapp.somepackage.SomeThing()
, and
SomeThing.cfc
has
extends=SomeOtherThing
, and
SomeOtherThing.cfc
is also in
com.example.someapp.somepackage
?
j
Yes, that lines up with what we are seeing. If the
extends="SomeOtherThing"
is not on the
SomeThing
component, we can instantiate
SomeThing
successfully. If the extends is there, however, the failure can occur, and the instantiation of
SomeThing
ends up failing.
a
And
o = new com.example.someapp.somepackage.SomeOtherThing()
works OK? I've seen unexpected errors when trying to extended a CFC that won't compile.
j
I am trying to confirm via a test, but at the moment it is deciding to play nicely. Working on getting it to break again so I can confirm. However, by the nature of it running correctly right now, I would say that the component is compiling successfully.
👍 1
Update on this issue: We were able to reproduce the problem and have found a workaround that will work well enough for us. Here is a further breakdown of our problem and what we did to resolve it:
Copy code
Directory structure

Web Root
    Applications
        Application1
            lib
                components
                    SomeThing.cfc
                    SomeOtherThing.cfc
            Application.cfc
        Application2
            ...
    URL rewriting rule to send traffic to Application1 or Application2 as appropriate
Copy code
SomeThing.cfc

component extends="SomeOtherThing" {
    public function init() {}
}
Instantiating
SomeThing.cfc
via
CreateObject("component", "lib.components.SomeThing")
or
new lib.components.SomeThing()
results in the following error:
Copy code
Detail: Ensure that the name is correct and that the component or interface exists.
Message: Could not find the ColdFusion component or interface lib.components.SomeOtherThing
Observations • The issue appears to be related to ColdFusion getting confused on path resolution to the extended component. Additional notes • We are able to create an object of SomeOtherThing.cfc directly without issue. The problem only occurs when another component is extending it. • We confirmed that SomeThing.cfc, when not extending SomeOtherThing, is able to create instances of SomeOtherThing using CreateObject() with the following paths: (These tests were just to verify that ColdFusion could find the component once it was within SomeThing). ◦ SomeOtherThing ◦ lib.components.SomeOtherThing ◦ applications.Application1.lib.components.SomeOtherThing • The issue often goes away by turning on Trusted Cache (which is of course not viable for a development, and sometimes testing platform), but comes back when Trusted Cache is turned back off. • If ColdFusion does eventually figure out the extends correctly, it will remember it until the server/service is restarted. Resolution
Copy code
Use an application specific mapping in Application.cfc to the `lib` directory as such:

this.mappings = {
    "/lib" = ExpandPath("./lib")
};
b
Suggestion:
Copy code
SomeThing.cfc

component extends="applications.Application1.lib.components.SomeOtherThing" {
    public function init() {}
}
j
bkbk, thanks for the suggestion. I didn't make it clear in my updated explanation above, but we also attempted
SomeOtherThing
,
lib.components.SomeOtherThing
, and
applications.Application1.lib.components.SomeOtherThing
for the
extends
value. None of them worked, unfortunately.