Erreur ColdFusion: coldfusion.compiler.FactoredNodeAggregation ne peut pas être jeté à coldfusion.compiler.ASTfunctionDefinition

Question

coldfusion.compiler.FactoredNodeAggregation cannot be cast to coldfusion.compiler.ASTfunctionDefinition

je reçois l'erreur ci-dessus lors d'une tentative de remplacer vraiment, étiquette vraiment vieux personnalisé héritage avec une nouvelle balise personnalisée qui a un certain flux de travail importants améliorations Je n'ai qu'une idée sur la façon de déboguer ceci: commenter différentes parties du code (style de recherche binaire) jusqu'à ce qu'il compile, en rétrécissant ma recherche jusqu'à ce que je trouve le code du problème.

Quelqu'un d'autre a déjà vu cette erreur auparavant? Une idée de ce que cela pourrait être? Contextuellement, il semble que j'essaie d'utiliser ... quelque chose ... comme une fonction qui n'est pas définie comme une fonction. Cela ne me dit rien, alors je vais essayer l'idée de recherche binaire.

Mise à jour: Il fonctionne sur CF 8.0.1 et n'utilise aucun bloc <cfscript>. En utilisant la recherche binaire de commentaire, je l'ai réduit à un CFThread qui démarre un thread d'arrière-plan qui ne rejoint jamais la page (par conception).

Si je commente tout le contenu du thread, l'erreur disparaît (donc le tag cfthread lui-même ne semble pas avoir de problèmes en soi ...). Si je copie le contenu du thread dans son propre template, ce template va bien se compiler (donc le contenu du thread ne semble pas avoir de problèmes en soi ...) ... alors ... en théorie ça devrait marcher? Je ne sais pas. C'est moi avec mes bras en l'air. (WTF?)

Je pense que j'ai déjà réfuté cette idée en ne commentant pas une petite section sans que l'erreur ne revienne, mais un CFThread devrait avoir accès aux balises personnalisées locales que le modèle créant le thread aurait, à droite ? Donc, s'il y a foo.cfm, il pourrait être accessible à partir de la page comme <cf_foo>, et le thread pourrait faire la même chose?

Answer 1

La semaine dernière, j'ai été en contact avec l'équipe de ColdFusion Engineering chez Adobe à propos de ce problème et ils m'ont confirmé qu'il s'agissait d'un bug dans ColdFusion. Plus précisément, si le nombre de lignes de code à l'intérieur du corps de l'étiquette de thread était trop important, cela provoquerait une erreur de compilation. La solution de contournement, que j'ai découverte un jour ou deux avant que j'obtienne ma réponse, consiste à utiliser un <cfinclude /> pour importer le contenu de votre thread à partir d'un autre fichier; ou pour mettre le code dans une méthode quelque part et appeler cette méthode depuis l'intérieur du corps du thread. (On peut supposer que, une étiquette personnalisée ou d'autres méthodes intelligentes d'encapsulation seraient également.)

Cela explique la partie de la chose qui me conduisait absolument fou: que commentant les différentes parties du corps de fil serait parfois faire compiler ... et maintenant je sais que c'était parce que assez du corps de fil a été commenté.

Ils indiquent qu'ils ont fixé le bug, je suppose qu'il sera corrigé dans la prochaine hot-fix cumulative (si elle existe), et ColdFusion 9.

Answer 2

Oooh, c'est un que je n'ai jamais vu auparavant. En fonction de ce que le tag personnalisé fait, plutôt que de commenter différentes parties, vous pouvez essayer d'utiliser cfabort - la même technique, mais une seule ligne à modifier plutôt que de décommenter et de commenter de nouveau (ce qui peut être fastidieux et fastidieux).

Etes-vous en mesure de tester la balise personnalisée de manière isolée, avec des arguments complètement simplifiés/etc?

Si vous êtes en mesure de poster le code, il pourrait y avoir quelque chose d'étrange qui saute à une nouvelle paire d'yeux?

Answer 3

cette erreur apparaît généralement lorsque vous avez une fonction définie sur la télécommande. un peu drôle que vous l'obteniez avec un tag personnalisé cependant. Êtes-vous sûr que la balise personnalisée n'a aucune fonction? pouvez-vous poster le code?

Answer 4

Étrange que c'est une erreur de compilation. Si la base de code n'est pas trop grande, je m'assurerais que toutes les variables dans le thread et appelées udfs sont explicitement étendues.

Ensuite, je déplacerais autant de données référencées de manière externe dans la portée des arguments de thread pour isoler les interactions avec la page. Enfin, si cela ne l'efface pas, j'essaierais de balayer les noms de toutes les variables, de la fonction et d'ufd le thread accède un peu avec un préfixe de test juste pour s'assurer que vous n'avez pas atteint un bug. ou funcs provoque une collision d'espace de noms dans le jvm dans le contexte de la page d'origine.

Problème difficile.

Answer 5

Avez-vous supprimé les fichiers de classe compilés et sauvegardé la source d'origine dans un nouveau fichier au cas où quelque chose de bizarre se produirait lors d'une sauvegarde?

Answer 6

Avez-vous essayé de réinstaller CF8.01? Peut-être que certains fichiers ont été corrompus?

Answer 7

Puisque je ne peux pas commenter encore , Adam, est-ce vraiment un bug avec CF ou avec la JVM? Il existe une limite similaire sur le nombre de lignes de code pouvant être compilées dans une CFFUNCTION, mais la limite est réellement dans la JVM, pas dans la balise CF.