0

I'm trying to set up in my Eclipse neon.3 (4.6.3):

  • Payara Server container (4.1.2.174)
  • JRebel agent 7.1.3

for an application packaged in EAR format. In the deploy process, no error is displayed in the Payara or JRebel log. I get the following messages regarding my EJB's:

2017-12-12T14:52:50.933-0200|INFORMAÇÕES: 2017-12-12 14:52:50 JRebel: Watching 'alfa.bc.logistica.core.ejb.AlfaTransportadorEJB' for changes
2017-12-12T14:52:50.936-0200|INFORMAÇÕES: Portable JNDI names for EJB AlfaTransportadorEJB: [java:global/alfa.bc.logistica.ee/alfa.bc.logistica.core.em/AlfaTransportadorEJB!alfa.bc.logistica.core.remote.AlfaTransportadorRemote, java:global/alfa.bc.logistica.ee/alfa.bc.logistica.core.em/AlfaTransportadorEJB]

When I make any changes to their monitored classes (for example AlfaTransportadorEJB), the changes are not made to the container, but the .class files are compiled and generated successfully in the target directory of my classpath (in the IDE option "Build automatically" = true).

Apparently the .class files are not "deploy" on container to do the reloading process of Class Loading.

Additional Information:

For JRebel configuration I followed this tutorial.

For the same version of the respective EAR application, the "reloading of classes" is done successfully using Glassfish 4.1 with Jrebel 7.0.5. However in this case, in deploy process, the container says the following.

.

2017-12-12T15:02:24.167-0200|Informações: 2017-12-12 15:02:24 JRebel: Directory 'C:\Documentos\cooperateEE\logistica\alfa.bc.logistica.core.em\target\classes' will be monitored for changes.
... <another logs here> ...
2017-12-12T15:03:45.994-0200|Informações: 2017-12-12 15:03:45 JRebel: Watching 'alfa.bc.logistica.core.ejb.AlfaTransportadorEJB' for changes
2017-12-12T15:03:45.998-0200|Informações: Portable JNDI names for EJB AlfaTransportadorEJB: [java:global/alfa.bc.logistica.ee/alfa.bc.logistica.core.em/AlfaTransportadorEJB!alfa.bc.logistica.core.remote.AlfaTransportadorRemote, java:global/alfa.bc.logistica.ee/alfa.bc.logistica.core.em/AlfaTransportadorEJB]

I think JRebel is not monitoring the target directory to then reload the compiled .class files in conteiner.

What is the reason JRebel does not identify my target directory like the above log says ("will be monitored for changes") ?

  • The `will be monitored for changes` is printed if a module contains a rebel.xml with a valid path. The rebel.xml needs to be located in the root of EJB jars and in `WEB-INF/classes` of WARs. EAR-s don't need rebel.xml themselves, only their submodules. Are you saying that the exact same EAR when deployed to glassfish works, but not with the payara server, or are there any differences between them? – Murka Dec 12 '17 at 17:40
  • @Murka yes, the `rebel.xml` file is in the root folder of the project with the EJB jars, and yes, the same version of the application with the `rebel.xml` files results in a different behavior. I just did another test with JRebel version 7.0.5 with Payara, but I got the same results. It looks like Payara is causing some different behavior on JRebel. – Darlyn Vailatti Dec 12 '17 at 17:50
  • In that case it needs deeper investigation. For that enable trace level logging via JRebel Configuration -> Advanced -> Log level: Trace. Then start payara and try to make changes that don't reload and submit a support ticket via Help -> JRebel -> Submit a Support Ticket. Also include the link to this question. – Murka Dec 13 '17 at 13:45

1 Answers1

0

I found the problem. Comparing jrebel.log between Glassfish (that works) and payara (that does not work), I realized that for Payara, the log says:

2017-12-22 08:04:47.012 INFO  [10] [Banner]      
#############################################################
2017-12-22 08:04:47.012 INFO  [10] [Banner]  
2017-12-22 08:04:47.013 INFO  [10] [Banner]  Legacy Agent 7.0.5 (201702281652)
2017-12-22 08:04:47.013 INFO  [10] [Banner]  (c) Copyright ZeroTurnaround AS, Estonia, Tartu.
2017-12-22 08:04:47.014 INFO  [10] [Banner]  
2017-12-22 08:04:47.015 INFO  [10] [Banner]  Over the last 10 days JRebel prevented
2017-12-22 08:04:47.015 INFO  [10] [Banner]  at least 66 redeploys/restarts saving you about 2.7 hours.
2017-12-22 08:04:47.017 INFO  [10] [Banner]  
2017-12-22 08:04:47.017 INFO  [10] [Banner]  JRebel started in remote server mode.
2017-12-22 08:04:47.025 INFO  [10] [Banner]  
2017-12-22 08:04:47.026 INFO  [10] [Banner]  
2017-12-22 08:04:47.026 INFO  [10] [Banner]      
#############################################################

JRebel started in remote server mode

While in glassfish this message is not logged. So I followed this link in JRebel documentation and disable remote server mode removing the VM options on container:

-Drebel.remoting_plugin=false

So in short, the problem was that JRebel was being initialized with the active server mode parameter