Unable to load class because the bundle wiring is no longer valid

[ComLock]

I have some code in main.js that creates a node on startup,
and some code in main.js disposer that deletes a node in application stop.

When you start and stop an installed app this works fine.

However when you deploy a new version of the app it looks like the disposer code fail because the app has already been removed.

[ComLock]

Maybe running a potentially long running operation on application stop, is a bad idea.

If I had lib-app I would not need to do that in this instance.
#6671

[ComLock]

@GlennRicaud told me to assign this one to you @rymsha

[GlennRicaud]

The question is: Is the disposer supposed to be blocking or not?
If yes, then there might be a bug here
If not, then is there a good workaround

[ComLock]

Unfortunately workaround idea to send a event didn't work either :(

2020-02-28 11:06:00,158 ERROR c.e.x.c.impl.app.ApplicationRegistry - Error invalidating application [ScriptRuntimeFactoryDelegate]
java.lang.IllegalStateException: Invalid BundleContext.
at org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:491)
at org.apache.felix.framework.BundleContextImpl.getServiceReference(BundleContextImpl.java:340)
at org.apache.felix.framework.BundleContextImpl.getServiceReference(BundleContextImpl.java:361)
at com.enonic.xp.script.impl.service.ServiceRefImpl.findService(ServiceRefImpl.java:33)
at com.enonic.xp.script.impl.service.ServiceRefImpl.get(ServiceRefImpl.java:22)
at com.enonic.xp.lib.event.EventSenderHelper.send(EventSenderHelper.java:63)
at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$1718$1197A$event.L:1#send(com.enonic.app.explorer.collector.web.crawler:/lib/xp/event.js:52)
at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$1716$352851A$main.L:1#L:13581#unregister(com.enonic.app.explorer.collector.web.crawler:/main.js:13609)
at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$1714$434962$main.L:1#L:15743#L:15760(com.enonic.app.explorer.collector.web.crawler:/main.js:15761)
at jdk.nashorn.javaadapters.java_lang_Runnable.run(Unknown Source)
at java.base/java.util.HashMap$Values.forEach(HashMap.java:976)
at com.enonic.xp.script.impl.executor.ScriptExecutorImpl.runDisposers(ScriptExecutorImpl.java:349)
at com.enonic.xp.script.impl.executor.ScriptExecutorManager.invalidate(ScriptExecutorManager.java:63)
at com.enonic.xp.script.impl.standard.ScriptRuntimeImpl.invalidate(ScriptRuntimeImpl.java:42)
at com.enonic.xp.script.impl.standard.ScriptRuntimeFactoryImpl.lambda$invalidate$0(ScriptRuntimeFactoryImpl.java:54)
at java.base/java.util.concurrent.CopyOnWriteArrayList.forEach(CopyOnWriteArrayList.java:803)
at com.enonic.xp.script.impl.standard.ScriptRuntimeFactoryImpl.invalidate(ScriptRuntimeFactoryImpl.java:54)
at com.enonic.xp.script.impl.ScriptRuntimeFactoryDelegate.invalidate(ScriptRuntimeFactoryDelegate.java:47)
at com.enonic.xp.core.impl.app.ApplicationRegistry.invalidate(ApplicationRegistry.java:72)
at com.enonic.xp.core.impl.app.ApplicationServiceImpl.invalidate(ApplicationServiceImpl.java:624)
at com.enonic.xp.core.impl.app.event.ApplicationInvalidatorListener.onApplicationEvent(ApplicationInvalidatorListener.java:31)
at com.enonic.xp.core.impl.app.event.ApplicationInvalidatorListener.onEvent(ApplicationInvalidatorListener.java:23)
at com.enonic.xp.core.impl.event.EventMulticaster.publish(EventMulticaster.java:51)
at com.enonic.xp.core.impl.event.EventMulticaster.publish(EventMulticaster.java:43)
at com.enonic.xp.core.impl.event.EventPublisherImpl.lambda$dispatchEvent$0(EventPublisherImpl.java:74)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)

[rymsha]

There is no fix until #7799 and #7842 are fixed.

Long running and resurrecting tasks (the ones which resubmit themselves) will behave poorly during application redeploy. Strictly speaking it will be always so by their nature.

For long running tasks workaround is to not release a new version during their work. Also split them into smaller/granular tasks.

For resurrecting ones - use cron instead.

[ComLock]

Sending a single event, shouldn't really be a long running or resurrecting task. Is it a task at all? I'm not using the task API.

Perhaps you are saying that the disposer is a task?

[rymsha]

https://discuss.enonic.com/t/deployment-failed-in-enonic-due-to-sql-dependency/2141

[rymsha]

#7978 may make it even worse. But it is a tradeoff. We currently can't have a reliable disposer and guarantee stable redeploy.
For now I would recommend to avoid using disposer to do data cleanup. For similar reasons why finalize is deprecated n Java:

• no guarantees it will be called.
• no guarantees that data is available.

[rymsha]

starting from 7.2.3 disposers should run on a ACTIVE app (before it was STOPPING and potentially STOPPED - which would cause the issue).

Disposers must be avoided still.