A container does not give any guarantees about when components will be explicitly instantiated except when created through an EJB invocation lifecycle. A container restart, like the Big Bang, is a particularly chaotic event while structure is forming.
It is best to ensure that your initialisation does not have any reliance on other EJBs, or at least has a method for gracefully dealing with such situations.
You might be able to circumvent this by setting the initial numbers of each bean to 0, until an EJB is invoked. However, not every container may support this.
You do not really want to have initialisation reliance on other components - it leads to your system being very brittle because of the coupling. You want each EJB to be stand-alone, and be self-repairing, or at least degrade it's service gracefully. Apart from the start up issues, you will need to be able to deal with conditions such as the removal of an EJB in your processing chain, the redeployment of an EJB or even the corruption of an EJB during the lifecycle of the container.
How you achieve that is your job as the designer. You might consider the use of state detection to determine whether something was successfully initialised, when executing a bean method and if not, attempting initialisation before continuing with processing work.
Many of my beans have dependecies on each other, IMHO if think this is acceptable for medium sized projects and where you are not planning on distributing your beans as off the shelf components to thired parties. I simply deploy my EJBs in an enterprise archive .EAR file, jboss does not have any difficulty resolving bean class dependencies then. I am not sure but I think jboss will deploy the beans in the order they appear in the application.xml file (please don't take my word on this), ethier way this works well for me.