This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I am getting below error when deploying our enterprise application's ear on clustered JBoss-5.1.0.GA AS. Our ear consists of one web application and several EJB (2.x) applications. We are using Spring for instantiating EJB beans and other POJOs and then injecting them into required places.
After analyzing below stack trace I found that before EJB beans gets bound to their JNDI names, Spring context loading starts wherein these EJB beans are looked up through their respective JNDI names and there it fails as EJB beans are yet not bound!
The same ear works fine on a non-clustered JBoss-5.1.0.GA AS. There, observing its console I have found that, it deploys EJB in 3 steps: (1) Installing, (2) Deploying, and (3) Binding to their JNDI name and then the Spring context loading starts so there it is able to successfully lookup EJBs using their respective JNDI names, as shown in below stack trace which I have copied from the console output of when deploying same ear (without clustering changes) on same but non-clustered JBoss-5.1.0.GA AS:
I have gone through JBoss-5.1.0.GA AS release notes, gone through JBoss Messaging 1.4 User Guide, also searched JBoss Forums and googled a lot but still didn't got solution to it.
Could anyone please help me out in this issue? Thanks in advance for any help.
This actually has been discussed in the JBoss forums. I was thinking of pointing you to those threads, but i am not able to access them right now (I just wish that the JBoss forums were much more stable).
The issue here was that the EJB jars were getting deployed after the war. This affected both EJB3.x and EJB2.x applications. For EJB2.x applications, there was one other issue which would cause this kind of deployment errors (hard to recollect with the forums down). I remember that (atleast for EJB3.x applications), the issue was fixed in AS-5.1.0. So you shouldn't have been seeing this issue. More strangely you seem to be running into issue only with the "all" configuration. Looking at the logs i don't seem anything obviously wrong with the location of your application in the "all" configuration, so not sure what's causing the issue. I'll wait for the forums to be up, before searching through some threads there to get more details.
Thank you very much Jaikiran. Then links you suggested helped me a lot - even the very first one was the correct answer.
Later, I also found in JBoss-5.1.0.GA many services uses database and hence we need to change 'DefaultDS' datasource in many service xml to our configured one.
But at point again I got stuck. Very first time, JBoss starts it creates several tables - several for JMS, one for hiLo sequence and one for EJbTimerService - TIMERS. Now once this TIMERS table is created and next time you start your JBoss, it gives exception : ERROR**, java.sql.SQLException: Table 'TIMERS' already exists and JBoss start up fails. I managed disabling 'Creation of' other tables by configuring them, but for this 'TIMERS' table I didn't found anywhere any configuration having any attribute like '<attribute name="CreateTable">false</attribute>'. And hence, am stuck at it as now what do to for it.
Do you know Jaikiran how we can disable 'creating TIMERS table on JBoss StartUp'? At present we are not using JBoss Timer service.
Thanks again for your very helpful reply which helped us solving our previous pain-problem.
Joined: Oct 01, 2009
I got solution to my problem after very hard sincere efforts. It was related to 'wrong version of mysql driver being used by us with JBoss-5.1.0.GA AS for communicating with MySQL'. The hint I got was from the reply to my post on JBoss-Forum (http://community.jboss.org/message/519172#519172.) where from I got to see the code of a class of JBoss AS responsible for firing the 'CREATE TABLE TIMERS ...' query; In the code, I found that it was already firing a SELECT query (before firing CREATE TABLE query) to detect if the table already exists, and if it exists then do not fire the CREATE TABLE query. This guided me to think that is it happening that 'SELECT' query is not getting run properly but the 'CREATE TABLE' query is getting run ...? From my past experience, i just thought that, is it happening that the SELECT query is having syntax/or consists of keywords that the older version of MySQL/J connectors (e.g. v3.1.11 which we are using currently) are not able to get in and hence not the query execution fails or any such kind of pbm is happening due to which the above said code think that the table does not exist and therfore need to fire CREATE TABLE query. So if it is that then it should be solvable by using a more newer / latest version of MYSQL/J connector. So, I downloaded latest version of MySQL/J connector v5.1.10, and tried that. And, yes! it worked out. The above mentioned exception 'TIMERS table already exists' disappeared! It got solved. This confirmed my thought process and also gave me the solution. I thought I should post the solution and the process involved here to complete the actual post let it benefit to anyone else who may/might come across such a (or a similar kind of) problem.
Rupesh Bhadeshiya wrote: I thought I should post the solution and the process involved here to complete the actual post let it benefit to anyone else who may/might come across such a (or a similar kind of) problem.
Thanks for posting the solution - it's going to be useful for someone else who runs into this