web-dev-qa-db-fra.com

IntelliJ IDEA Le débogueur ne fonctionne pas sur un projet Grails

Je ne peux pas déboguer mon code dans Intellij IDEA. Lorsque le mode de débogage est actif et en cours d'exécution, mais que "v" n'est pas coché pour les points d'arrêt et représentant un point d'arrêt valide et pouvant être arrêté. 

Voir l'image: http://prntscr.com/1w0owu .

Je cherche vraiment une réponse sur le Web. Qu'est-ce que je suppose de faire?

41
ricardogobbo

J'ai essayé tous les mentionnés ici sans succès . La seule information utile est ici .

Pour l’essentiel, vous devez désactiver l’exécution forkée en ajoutant ce qui suit à grails-app/conf/BuildConfig.groovy

grails.project.fork = [
    test: false,
    run: false
]

Le débogage est maintenant disponible dans IntelliJ IDEA Ultimate Edition v.12.1.6 uniquement par le débogage ordinaire sans débogage distant . Testé sur Grails 2.3.1, Java 1.7.0_45, Windows 7 64 bits.

74
Igors

Essaye ça:

Dans l’idée, choisissezModifier les configurationsdans la liste en regard du bouton "Exécuter". Ajoutez ensuiteRemote, choisissez votre nom et les paramètres de configuration à distance par défaut. (port 5005 etc)

Exécutez votre application depuis la console en utilisant

grails run-app --debug-fork

En principe, choisissez votre configuration dans la liste et cliquez sur le bouton de débogage lorsque les informations d’affichage de la console:

Listening for transport dt_socket at address: 5005
18
akn

Depuis Grails 2.3, forked execution pour plusieurs commandes Grails (par exemple, run-app, test-app) était introduit . Si vous venez de déboguer une application Grails à partir d'IntelliJ IDEA, le processus GrailsStarter sera démarré options de débogage sur. La sortie sur la console IDEA sera:

/usr/lib/jvm/default-Java/bin/Java -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:59935,suspend=y,server=n [...] /opt/idea-IU-133.330/lib/idea_rt.jar org.codehaus.groovy.grails.cli.support.GrailsStarter [...] run-app Connected to the target VM, address: '127.0.0.1:59935', transport: 'socket'

L'application elle-même sera lancée dans un processus séparé nommé ForkedTomcatServer. C’est là que votre code s’exécute et que votre débogueur doit réellement se connecter à.

Pour ce faire, définissez debug: true dans BuildConfig.groovy dans la configuration run de grails.project.fork. Exécutez simplement Grails maintenant à partir de IDEA (ne pas déboguer) et vous verrez la ligne suivante dans la console lorsque l'application est prête à servir les requêtes HTTP:

Listening for transport dt_socket at address: 5005

C'est là que vous voulez diriger un configuration d'exécution à distance } vers. Dès que votre débogueur distant est connecté, émettez une requête HTTP et le débogage fonctionnera.

Vous pouvez également désactiver l'exécution fourchue pour les commandes Grails de compilation/test/exécution/guerre/console en définissant la valeur associée à l'entrée de commande dans grails.project.fork à false. Mais vous perdrez alors les avantages de l’exécution forkée ajoutée dans Grails 2.3.

8
jack_kerouac

Le débogage d’une application grails (2.3+) peut être effectué de deux manières.

1. Solution simple: désactiver le débogage

éditez BuildConfig.groovy:

grails.project.fork = [
    war: [maxMemory: 768, minMemory: 64, debug: false, maxPerm: 256, fork ...
    run: [maxMemory: 768, minMemory: 64, debug: false, maxPerm: 256, fork ...

à

grails.project.fork = [
    war: [maxMemory: 768, minMemory: 64, debug: false, maxPerm: 256, fork ...
    run: false,

Avantages:

  • Simple à faire (et poursuivre votre développement)

Les inconvénients:

  • Cela supprime la possibilité d'effectuer le remplacement du code d'exécution. Cela signifie que si vous modifiez le code, il ne sera plus récupéré automatiquement et vous devrez redémarrer l'application pour voir les modifications. Cela peut prendre beaucoup de temps.

2. Solution impliquée: débogage du runtime forké

Il s'agit d'une solution un peu plus complexe dans laquelle vous associez un débogueur à une application grails en cours d'exécution. Il est décrit plus en détail dans cet article de blog .

Après l’installation, vous disposez d’une configuration d’exécution supplémentaire qui vous permet de démarrer Grails en mode fork, et d’une autre configuration d’exécution supplémentaire vous permettant de déboguer ce mode. Le problème, c'est que vous devez commencer les deux ou que cela ne fonctionne pas.

Avantages:

  • Vous avez à la fois le débogage et le remplacement du code d'exécution
  • Cela n'interfère pas avec le démarrage de l'application en mode normal. (c'est-à-dire que vous avez des options supplémentaires)

Les inconvénients:

  • L'installation prend un peu de temps
  • Le démarrage en mode débogage nécessite un processus plus complexe en deux étapes (c’est-à-dire qu’il prend plus de temps)

Considérations

La solution 2 est généralement supérieure dans le sens où elle permet la flexibilité. Personnellement, je n’utilise pas beaucoup le débogage, donc commencez simplement en mode normal. Lorsque je veux déboguer, je redémarre en mode débogage.

La solution 1 est strictement préférable si vous avez besoin de déboguer et de redémarrer souvent. Par exemple, lorsque vous travaillez sur vos classes de domaine ou sur la configuration de votre base de données dans votre fichier BootStrap.groovy.

6
GhostEcho

Avez-vous vu cet article? Il détaille la marche à suivre et me permet de surmonter mon problème.

http://mrhaki.blogspot.com/2013/12/grails-goodness-debugging-app-in-forked.html

4
Peter Kahn

Aucune des autres réponses ne fonctionne pour moi sur Grails 3.x en 2016 avec Intellij 15.0.4. Cela fonctionne pour moi:

Lancez grails dans intellij avec cette commande:

run-app  --debug-jvm

La console doit générer: "Écoute de transport dt_socket à l'adresse: 5005 L'application Grails s'exécutant à http: // localhost: 8080 in environnement: développement"

Vous pouvez maintenant ajouter une nouvelle configuration de type "Remote" dans Intellij. Puis lancez-le avec ses valeurs par défaut.

Et la nouvelle fenêtre de la console de débogage doit écrire: "Connecté à la machine virtuelle cible, adresse: 'localhost: 5005', transport: 'socket'"

Terminé.

Pour les personnes intéressées, la référence à la documentation de Grails 3.x pour le démarrage d'un serveur à déboguer se trouve à la section 2.8, runningAndDebuggingAnApplication:

http://grails.github.io/grails-doc/3.1.x/guide/gettingStarted.html#runningAndDebuggingAnApplication

"Il existe plusieurs façons d'exécuter la classe Application. Si vous utilisez un IDE, vous pouvez simplement cliquer avec le bouton droit de la souris sur la classe et l'exécuter directement à partir de votre IDE, ce qui démarrera votre application Grails ..__ C'est également utile pour le débogage car vous pouvez déboguer directement à partir de IDE sans avoir à connecter un débogueur distant lorsque vous utilisez la commande run-app --debug-jvm à partir de la ligne de commande. "

Note importante. Lorsque j'ai essayé le "cliquez simplement avec le bouton droit de la souris sur la classe et l'exécutez directement à partir de votre IDE", l'application a démarré. Cependant, toutes les demandes que j'ai envoyées à mon contrôleur ont généré 500 erreurs avec le message suivant: "Impossible de résoudre la vue portant le nom '/ myendpoint' dans le servlet portant le nom 'grailsDispatcherServlet'.

Donc, je suis revenu aux instructions ci-dessus. 

4
Ed J

Ceci est une affaire très simple avec Grails 3 et Idée (2016.1). Il n'est plus nécessaire de modifier aucun fichier, comme recommandé dans les autres réponses.

Pour une raison quelconque, l'icône de débogage dans la barre d'outils Idée est grisée. Il vous suffit donc de naviguer jusqu'au point d'entrée de votre application (la classe qui utilise la méthode principale statique void qui démarre l'application), cliquez sur l'une des flèches d'exécution la gouttière de gauche et sélectionnez l'option de débogage.

À partir de la documentation JetBrains:

https://www.jetbrains.com/help/idea/2016.1/getting-started-with-grails-3.html

Application de débogage de Grails 3

IntelliJ IDEA vous permet de déboguer votre application Grails 3 en utilisant Application.groovy.

Dans la fenêtre de l'outil Projet, ouvrez le répertoire init et cliquez avec le bouton droit de la souris sur le fichier Application.groovy Dans la liste déroulante, sélectionnez Debug Grails: 'name' grails3_debug_app Vous pouvez également utiliser l'éditeur pour lancer le débogage processus.

2
pmcollins

J'ai testé avec intellij le dernier en date avec Grails 2.3.4 sur Mac Os x Lion.

Ensuite, j'ai suivi le conseil d'Igors et il fonctionne sans mode fork.

grails.project.fork = [
    test: false,
    run: false
]

S'il vous plaît vérifier les détails documentation Grails

si vous voulez déboguer en mode fork, vous devriez vérifier les explications suivantes sur le blog. 

http://blog.jdriven.com/2013/12/grails-goodness-debugging-app-forked-mode/

1
daimon

Juste trois suppositions:

Essayez d'exécuter run-app, pas run-war, les deux devraient fonctionner, mais il se peut que run-war ne fonctionne tout simplement pas.

Ou: essayez de déboguer à distance depuis la console:

grails -debug run-app, puis connectez-vous avec le débogage distant dans Idea.

En dernier recours, rétrograder votre projet aux versions précédentes de Grails pourrait fonctionner. Oui, c'est vraiment énervant.

J'espère que cela t'aides.

1
Andrey Chaschev

Checkout this blog sur le débogage du mode Forks Grails.

0
biniam

Cela ne devrait jamais être la configuration par défaut et être laissé au choix de l'individu. Il est pénible de faire deux configurations simplement pour que cette chose fonctionne en mode débogage dans intellij. Vous devez d’abord configurer ou modifier la configuration d’exécution normale en ajoutant "--debug-fork" après run-app. Deuxièmement, vous devez configurer le débogage distant, tout en acceptant toutes les valeurs par défaut. Ensuite, vous devez exécuter la configuration d'exécution et, lorsque cette opération est en cours d'exécution, vous exécutez la configuration de débogage. Quelle douleur. Je préfère totalement renoncer à courir sans l'option fork en développant. Le temps, c'est de l'argent et je n'ai pas le temps de traîner. Voir l'explication de M. HAKI à ce sujet. http://blog.jdriven.com/2013/12/grails-goodness-debugging-app-forked-mode/

0
Beaumont Muni