[clebert.suconic]

The classLoader could also be a race.

The container was stopped while the setup was still being done.

The setup will call the EJB3 plugin while the container had already failed due to destination not found.

as a result we end up with no destinations.. the container fails.. the classLoader is released and we end up with the failure.

[clebert.suconic]

Andy Taylor wrote:

Clebert Suconic wrote:

I mean, if we don't use the Workerthread... we could do the setup before the server was started eventually?

Usually other services on JBoss will declare dependencies. I'm just trying to understand how this works.

I'm not sure what your first comment means.

If u create the sessions before the acyivation has fully started, messages may be delivered which would cause an error. This way messages only start getting delivered once the MDB has fully started.

Is this something that was done on the original RA, or something we/you added?

Usually dependency between services on AS is done through dependency injection.

If you deploy/undeploy very requickly you're going to see lots of races. For instance the ClassLoaderException still happens after I've fixed the CreateDestination.

The container is undeploying the MDB before start was finished. By the time start happened the classLoader was already gone.

[ataylor]

Clebert Suconic wrote:

Andy Taylor wrote:

Clebert Suconic wrote:

I mean, if we don't use the Workerthread... we could do the setup before the server was started eventually?

Usually other services on JBoss will declare dependencies. I'm just trying to understand how this works.

I'm not sure what your first comment means.

If u create the sessions before the acyivation has fully started, messages may be delivered which would cause an error. This way messages only start getting delivered once the MDB has fully started.

Is this something that was done on the original RA, or something we/you added?

Usually dependency between services on AS is done through dependency injection.

If you deploy/undeploy very requickly you're going to see lots of races. For instance the ClassLoaderException still happens after I've fixed the CreateDestination.

The container is undeploying the MDB before start was finished. By the time start happened the classLoader was already gone.

This was also done in th eoriginal RA. It has nothing to do with being dependant on something else. Like i mentioned before its there so we dont start delivery during the activation start. The work manager will do this later.

The classloader issue is something different.