Re: com.ibm.ejs.container.ContainerEJBException: Unable toinitialize<br> d - Websphere

This is a discussion on Re: com.ibm.ejs.container.ContainerEJBException: Unable toinitialize<br> d - Websphere ; Hi, As was mentioned in a previous posting, you will need to look at other locations in the SystemOut.log file for messages that indicate why WAS could not start up your EJB. Possible causes include a corrupted deployment descriptor, corrupted ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Re: com.ibm.ejs.container.ContainerEJBException: Unable toinitialize<br> d

  1. Re: com.ibm.ejs.container.ContainerEJBException: Unable toinitialize<br> d

    Hi,

    As was mentioned in a previous posting, you will need to look at other locations in the SystemOut.log file for messages that indicate why WAS could not start up your EJB. Possible causes include a corrupted deployment descriptor, corrupted binding or extension definition files, or the inability for the container to load one or more classes required by the EJB (for example because they were not included in the application or otherwise made available to WAS).



    Starting in WAS 6.0, the EJB container does not start all the EJBs in your application at the time the application itself starts -- this is to improve startup time of your application and of the app server itself. Rather, we changed to a "lazy" or "deferred" initialization mechanism, where EJBs are started up when they are first used by the application.



    If you want to have the EJB container start up all your EJBs at the time the application is first started (similar to the pre-v6.0 behavior), follow the instructions in the WAS InfoCenter at http://publib.boulder.ibm.com /infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/te jb_ecnt2.html . Then you will see all errors right away when you first start up the application.



    Regards...Randy

  2. Re: com.ibm.ejs.container.ContainerEJBException: Unable to initialize

    Hi,
    Ugh, I'd forgotten that some of these 'class not found' type errors were moved sometime ago from appearing in the SystemOut.log, to appearing as FFDC events. Glad you found the cause though.

    Randy

    benjamin_j_maisano@uhc.com wrote:
    >
    > Apparently we need to re-structure our EAR file, though I would have thought this would be the same as in WAS 5.0/5.1. Anyway, thanks for the information, it was very sutle message I didn't see in standard system out.


  3. Re: com.ibm.ejs.container.ContainerEJBException: Unable toinitialize

    So for the error it suggests

    This is often caused by having the class at a higher point in the classloader hierarchy

    I'm not sure how to restructure our EAR. The SessionAdapter class is in our BasicsJ2EE.jar file which is referenced by the EJB and Web Projects and in the EAR it seems at both levels.



    Could it being at both levels cause a problem?



    The EAR project references the project the EJB needs, what else should be done? The Web project calles the EJB project, and the EJB project uses this other class from another project which isn't part of Web or EJB projects. Both web and EJB are in the same EAR as well as the other "utility" jar project in the EAR, how should this be structured?



    Do I need to change the class loader policy in any way? I think it WAS 6.1 console has a couple options:

    Class loader order Classes loaded with parent class loader first **I have this one

    Classes loaded with application class loader first



    WAR class loader policy Class loader for each WAR file in application **I have this one

    Single class loader for application

  4. Re: com.ibm.ejs.container.ContainerEJBException: Unable toinitialize

    FYI, I fixed this by setting my classloader policy to Application from module at the EAR project application.xml level.

  5. Re: com.ibm.ejs.container.ContainerEJBException: Unable toinitialize

    I had the same issue, and imho appears to be a bug. I too got the "class not found" on a websphere generated stub class EJSLocalStatelessOrderSummaryManagerLocal_cdae2eda . So I found this class by type (cntl-t in RAD7), and found there was the same class with a different suffix. I deleted the classes (manually), and then perform a "Prepare for deployment". This fixed the issue.



    Prior to this I cleaned class in all projects, published, removed the project. Nothing work, except the above procedure.



    This process took about 2 hours from my day to figure out (or stumble onto the solution .

+ Reply to Thread