Please note that “jboss-app.xml” and “jboss.xml” serve different purposes. jboss.xml is used for configuring EJB, including jndi, whereas jboss-app.xml is used for configuring class loader, ear deployment etc. Both are proprietary deployment descriptors.

I found the JNDI lookup failure was in the constructor of one of the web service impl classes. Perhaps the JNDI context is not fully setup at that point in the load? I made the lookups lazy so they aren't loaded in the constructor. This got me past the current problem but I think I'm now stuck with the problem I had when I tried to deploy this app to 5.1.0.

Yes moving the lookup out of constructor helped. I guess 4.2.3's different web service impl didn't instantiate an instance of the EJB during the boot phase.

Regarding the loop I'm now getting - I can only run it using the run.bat (not from Eclipse) - Is there a way to force a stack trace dump from Windows? Or perhaps still launch from run.bat but with some debug settings and then get Eclipse to attach to it and pause it when it gets into the loop?

Here is the stack trace for AS 6. Very similar up to a point (BeanMetaDataDeployer.deploy), the code is processing different beans on eash suspend of the thread but whether or not it is looping or just extremely slow at progressing through the several hundread SFSB I can't say for sure. What took 8 minutes to boot in 4.2.3 is still going after an hour on 6. Perhaps there is some sort of cyclical dependency? I will do some trial and error to reduce the number of SFSB in the EAR, seeing if a reduced number boots and then re-adding until it breaks again.

I've managed to get the app to start - by removing a large number of EJBs (SFSB). However the boot time, even with less EJBs, is still slower than 4.2.3 and from what I observed, suspending the thread whilst booting, is that there seems to be some inefficient list/array handling related to EJB contexts. The rate of deploying EJBs speeds up as the lists got smaller. But the code was instantiating new lists, each containing details of the hundreds of EJBs that make up the app. The array seemed to be the exact size required meaning every time it needed to change a new one was instantiated and the content loaded. This app has hundreds of EJBs. I think the original deployment with all EJBs present was suffering some sort of exponential degradation of list/array processing.

The class is a CopyOnWriteArrayList and is called from AbstractKernelController.resolveContexts.

This looks bad and actually reminds me of a fix (in MC?) that was done after AS 5.1.0 was released. How many EJBs do you have? How many @EJB injection or <depends> do you have? Would it be possible for you to share this application, so that we can take a look and fix the issue within JBoss AS?

I could share but it would require you to have Oracle installed, to run schema setup etc.

The app has approx 1100 SFSB - each also having several (say 5) injected EJBs.

there is also about 200 JPA entities.

If you really want I can upload the ear onto an FTP server, a JMX console ear to do schema and instructions.

The main ear is about 50MB.

I've got the app deploying but it takes about twice as long as 4.2.3 did. I did the exercise of removing beans and then readding and I think the only changes I ended up making was to increase the max memory setting and to compile usig JDK6 (was 5).I'm pretty sure that 5.1.0 had the same "loop/slow boot" issue as 6.0.0.