Normally, you would initialise at the instantiation of your EJB, in the EJB lifecycle. This would involve either code in the ejbCreate() method, or invoking a method from ejbCreate().
public void ejbCreate() throws javax.ejb.CreateException
Note that a stateless session bean instance is usually long running - once created, it can be used multiple times. Also, an instance may not be created at deployment. It is created when there is a need for an instance and there are no free instances in the pool.
I haven't tried with a static initializer, but it would only work when an instance is created. I suppose I have misgivings about such an implementation because it is not wrapped by an EJB exception which may be problematic to signalling to a remote client if something goes wrong.
Try performing a remote client execution of a stateless session bean method. This should force an EJB instance to be created. You could see if your initialization code works.
Sorry, my bad. I was thinking standard initialization blocks.
I think that your problem has to do with container classloading. In any case, there have been long technical discussions on the Sun JDC about this. In theory, you are not supposed to use static initializations in EJBs.
However, my test should still be valid. I'm not convinced that the initialization is absolutely tied to loading the class although the Fundamentals Vol. I states it in their simple example case. So try it and see.
Just tried it. The static initialization occurs the first time I make a call to the EJB. It doesn't mean you should do it. It just means you can do it.
I'm not sure there is any way of forcing something to occur on deployment. I can't remember a container definition that says it must provide a signal when a component is deployed - such that it is standard across all EJB container implementations. Just as there is no stipulation on when a container must initialize an EJB class.
Someone else might be able to provide some better information on the subject.
I have had a similar situation and the setContext has helped me in this. I put the code that needs to be initialized in this method and it gets invoked when the bean is created.
I believe the constructor followed by setcontext is called when the bean is initialized.