The EJB passivation pool, created at startup, is actually activated only at first use, when an EJB gets passivated. This cause the pool's thread keeping in its context a reference to the context class loader. When the passivation is called, the context class loader is the application class loader.

This actually cause the server keeping a thread which still refers to an application's class loader, even when the application is undeployed.
To avoid such a leak, I changed a few things in org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl

a) In the constructor PassivatingBackingCacheImpl(StatefulObjectFactory<V>, BackingCacheEntryFactory<K, V, E>, ReplicationPassivationManager<K, E>, BackingCacheEntryStore<K, V, E>, ThreadFactory, ScheduledExecutorService), after

 this.executor = executor;

I added:

if (this.executor != null) {
	this.executor.execute(new Runnable(){
	   public void run()
	   {
	   }});
}

b) In the methodstart(), after

 this.executor = Executors.newScheduledThreadPool(1, this.threadFactory);

I added:

if (this.executor != null) {
	this.executor.execute(new Runnable(){
	   public void run()
	   {
	   }});
}

This only works because the pools contains only 1 thread.

In addition to this, it seems that the references to the EJB is sometimes not cleaned at undeploy. To do so, I had to change in the stop method:

if (this.threadFactory != null) {
    this.executor.shutdownNow();
}

to

if (this.executor != null) {
    this.executor.shutdownNow();
}

Looks like a bug, but I'm not really sure. Anyway, this cleaned the reference to the EJB in the current pool task.