Glassfish support about hotswapagent HOT 14 OPEN

@edudant does it work for you after setting the org.osgi.framework.bootdelegation property? I'm still getting java.lang.NoClassDefFoundError: org/hotswap/agent/config/PluginManager. My configuration inside glassfish/config/osgi.properties is:

org.osgi.framework.bootdelegation=${eclipselink.bootdelegation}, \
org.hotswap.agent.annotation, org.hotswap.agent.annotation.*, \
org.hotswap.agent.javassist, org.hotswap.agent.javassist.*, \
org.hotswap.agent.command, org.hotswap.agent.command.*, \
org.hotswap.agent.config, org.hotswap.agent.config.*, \
org.hotswap.agent.logging, org.hotswap.agent.logging.*, \
org.hotswap.agent.plugin, org.hotswap.agent.plugin.*, \
org.hotswap.agent.util, org.hotswap.agent.util.*, \
org.hotswap.agent.watch, org.hotswap.agent.watch.*, \
com.sun.btrace, com.sun.btrace.*, \
org.netbeans.lib.profiler, org.netbeans.lib.profiler.*

from hotswapagent.

@edudant, I've got the same problem. Setting org.osgi.framework.bootdelegation property didn't help.

Also adding JVM option -Dorg.glassfish.additionalOSGiBundlesToStart didn't work.

from hotswapagent.

You must place hotswap-agent.jar into domains/domain1/lib/ext folder. After that problem with ClassNoFoundExeception and ClassDefFoundError have been solved, but than have been occur another problem. When I change code and swap it than throw exception and changes not apply:

java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:497)
    at org.hotswap.agent.annotation.handler.WatchEventCommand.onWatchEvent(WatchEventCommand.java:163)
    at org.hotswap.agent.annotation.handler.WatchEventCommand.executeCommand(WatchEventCommand.java:51)
    at org.hotswap.agent.command.impl.CommandExecutor.run(CommandExecutor.java:25)
Caused by: java.lang.IllegalStateException: This web container has not yet been started
    at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1675)
    at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1633)
    at org.hotswap.agent.plugin.hotswapper.HotswapperPlugin.watchReload(HotswapperPlugin.java:66)
    ... 7 more

from hotswapagent.

Thanks for contributing the config. That saved me a lot of time. For me it is now functional with the latest GIT version of hotswap-agent and DCEVM-light-8u66 with JDK 8u66. I used the same osgi config.inside my domain.xml and placed the jar inside ext folder.I did not tested all, but I could at least update a Managed Bean.

from hotswapagent.

Payara 4.1.1163 start with the following logs:

HOTSWAP AGENT: 21:53:35.341 INFO (org.hotswap.agent.HotswapAgent) - Loading Hotswap agent {0.4.0-SNAPSHOT} - unlimited runtime class redefinition.
HOTSWAP AGENT: 21:53:36.858 INFO (org.hotswap.agent.config.PluginRegistry) - Discovered plugins: [Hotswapper, WatchResources, AnonymousClassPatch, Hibernate, Hibernate3JPA, Hibernate3, Spring, Jersey2, Jetty, Tomcat, ZK, Logback, Log4j2, MyFaces, Mojarra, Seam, ELResolver, WildFlyELResolver, OsgiEquinox, Proxy, WebObjects, Weld, JBossModules, ResteasyRegistry, Gae, Deltaspike, JavaBeans]
Launching GlassFish on Felix platform
Exception in thread "Thread-3" java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.remove(HashMap.java:1443) at org.hotswap.agent.command.impl.SchedulerImpl.processCommands(SchedulerImpl.java:84) at org.hotswap.agent.command.impl.SchedulerImpl.access$100(SchedulerImpl.java:16) at org.hotswap.agent.command.impl.SchedulerImpl$2.run(SchedulerImpl.java:119)

What's wrong?

from hotswapagent.

It looks it couldn't happened...

from hotswapagent.

But I get this exception again and again. And reloading didn't work. May be need some additional information? I can fix this exception very simply - use concurrent set. And in my fork I do this. But why this happen?

from hotswapagent.

I didn't see it at first glance, but there is a new command scheduled in command execution somewhere in HA. There should be ConcurrentHashMap as you suggested or copy of or original. Thank you for report !

from hotswapagent.

Thanks for related works. I build latest version of hotswap and could do simple reloading of simple class. Hotswap couldn't reload fields inject into EJB, but method reloading is works. All is good on small project. But I deploy massive production web project with many dependencies and get dead lock. jstack log in attached file.

jstack.txt

from hotswapagent.

I've commented out the problematic classloader lock. It should be more stable now. But the risk of dedlock is not removed and still persists. As a last option you can increase timeout at this line , but this is hack. We must find out better solution for the new (delayed) release.

from hotswapagent.

Thanks for fix deadlock. I continue research and adapt functionality of reloading and get a some problem with project structure. I have main single war archive with many dependency. Application logic which I want reload placed in such dependencies. I try change class of some dependencies and nothing happens. I suppose that "extraClasspath" property is need for my purpose. But how I must used it? I try simply set path to .class file for dependent project ({absolute_path}/target/classes/) but this wasn't help. Or for such purpose need special plugin?

from hotswapagent.

Honestly I didn't test the extraClasspath on Payara yet. You can pass global params directly in command line

-javaagent:<path>hotswap-agent.jar= extraClasspath=<...>

if you set params into application classes folder then theses params will be applied (and will be visible) locally in the application classloader. But the most important is the fact that the application classloader must be patched by hotswapagent to support the extraClasspath extension. Until now we have patches for Tomcat, Jetty and Wildfy not for Payara/Glassfish - may be there is the problem.

from hotswapagent.

from hotswapagent.

1.1.0-SNAPSHOT release includes improved support for glassfish. It is no more necessary to define bootdelegation to hotswap's agent classes. Hotswap-agent.jar in domain/lib/ext is still needed.

from hotswapagent.