14 Replies Latest reply on Aug 26, 2008 10:37 PM by zparticle

    Deployment order and MYSQL Driver class issues

    zparticle

      Okay I have a couple of problems. I'm running on JBoss 5.0.0-CR1, MS-Windows XP SP 3. My apps use Spring and iBATIS.

      I had to switch from a local data source definition (which was working) to a JNDI container based definition to get the connection pooling. The problem is JBoss keeps deploying my applications before the data source which causes the app to crash because it can't find the data source. There must be some way to control this. The only way I can get the app to deploy after the data source is to un-deploy the app and the restart the server and after the data source loads redeploy the app.

      The next issue is if I do the above to get the app deployed I then get this weird error:

      00:29:02,062 WARN [JBossManagedConnectionPool] Throwable while attempting to get a new connection: null org.jboss.resource.JBossResourceException: Could not create connection; - nested throwable: (org.jboss.resource.JBossResourceException: Apparently wrong driver class specified for URL: class: com.mysql.jdbc.Driver, url: jdbc:mysql://localhost:3306/photosite)

      I'm using mysql-connector-java-5.1.6-bin.jar which is the latest, I've got it inside of the apps WEB-INF\lib directory. I was using the 5.0 driver but got the same error so I upgraded in hopes the error would go away.

        • 1. Re: Deployment order and MYSQL Driver class issues
          zparticle

          Forgot to mention that I'm deploying my apps as war files. I thought maybe this:

          http://wiki.jboss.org/wiki/IWantToDeployMyOwnJdbcDriverInAScopedClassloader

          applied but I don't know how to apply that to a war.

          • 2. Re: Deployment order and MYSQL Driver class issues
            zparticle

            I've tried copying the mysql driver jar into the server/default/lib directory but when I hit the app it just hangs now. no response ever comes back to the browser.

            • 3. Re: Deployment order and MYSQL Driver class issues
              zparticle

              during the "hang" the mysql and jboss processes are taking 50% of the cpu

              • 4. Re: Deployment order and MYSQL Driver class issues
                peterj

                The server/default/lib directory is the correct location for the JDBC driver JAR files.

                If both MySQL and JBossAS are showing CPU usage, then you can at least be assured that the database connection was made.

                You might want to enable the general query log in MySQL to see what is going on http://dev.mysql.com/doc/refman/5.0/en/query-log.html

                During the "hang" you should take thread dumps of JBossAS to see what your code is doing. I suggest taking three or more, perhaps a second or two apart. If your code is in a loop, this should point it out.

                • 5. Re: Deployment order and MYSQL Driver class issues
                  zparticle

                  I wish that worked, but with the loggin parameter the service won't start.

                  • 6. Re: Deployment order and MYSQL Driver class issues
                    zparticle

                    Okay the hang was, of course, caused by a bug in my logic. The JNDI look up is working now. Unforutnately the app is still loading ahead the JNDI data source getting created.

                    applicationContext.xml

                    <bean id="photositeDataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
                     <property name="jndiName" value="java:photosite"/>
                     <property name="resourceRef" value="false"></property>
                     </bean>


                    jboss-web.xml
                    <resource-ref>
                     <res-ref-name>photosite</res-ref-name>
                     <jndi-name>photosite</jndi-name>
                     <res-type>javax.sql.DataSource</res-type>
                     </resource-ref>
                    


                    web.xml
                     <resource-ref>
                     <description>DB Connection</description>
                     <res-ref-name>photosite</res-ref-name>
                     <res-type>javax.sql.DataSource</res-type>
                     <res-auth>Container</res-auth>
                     </resource-ref>


                    photosite-ds.xml
                    <datasources>
                     <local-tx-datasource>
                     <jndi-name>photosite</jndi-name>
                     <connection-url>jdbc:mysql://localhost:3306/photosite</connection-url>
                     <driver-class>com.mysql.jdbc.Driver</driver-class>
                     <user-name>zxcbvzxcv</user-name>
                     <password>asfgasdfgqsd</password>
                     <min-pool-size>1</min-pool-size>
                     <max-pool-size>5</max-pool-size>
                     </local-tx-datasource>
                    </datasources>
                    




                    • 7. Re: Deployment order and MYSQL Driver class issues
                      peterj

                       

                      zparticle wrote:
                      I wish that worked


                      Define "that" (I provided two suggestions, I have no idea which one you are referring to)

                      zparticle wrote:
                      with the loggin parameter the service won't start


                      "loggin"? Is that "login" or "logging", and what "service" are you talking about? Are you running JBossAS as a service? Or are you saying that MySQL will not start if you turn on the general query log? If so, what version of MySQL are you using?

                      • 8. Re: Deployment order and MYSQL Driver class issues
                        peterj

                         

                        zparticle wrote:
                        Unforutnately the app is still loading ahead the JNDI data source getting created.


                        That is one of the joys of working with the beta of the next release - you get to put up with all of the bugs and regressions while they get worked out.

                        The default deployment ordering has been broken ever since the first beta when the deployers were re-written to be microcontainer-based instead of JMX-based. But things have gotten better - more than 1/2 of the deployment ordering issues I saw in beta4 were fixed in CR1, and I expect more will be fixed in CR2.

                        So what do you do until then? I try to remember to deploy my apps after the server starts. When I forget (which is often), I simply move my app out of the deploy directory, wait 5 seconds (the time interval between hot deploy runs) and move it back in.

                        Oh, another possibility - for now create a deploy.last directory within the deploy directory and place your war file there (leave the *-ds.xml file in the deploy directory).

                        • 9. Re: Deployment order and MYSQL Driver class issues
                          zparticle

                          typo was logging, the mysql logging. Anyway that is no longer an issue the only remaining issue is figuring out how to get the datasource to load BEFORE the application does.

                          I tried the solution listed here:

                          https://jira.jboss.org/jira/browse/JBAS-5719

                          by changing the deployers.xml file but that blows the sever out of the water completely.

                          • 10. Re: Deployment order and MYSQL Driver class issues
                            zparticle

                            Okay the deploy.last directory trick worked, thanks. I tried going back to 4.2.2 earlier but that app resouce bundles can't be found under 4.2.2 for some reason so I decided to just keep going with 5.

                            • 11. Re: Deployment order and MYSQL Driver class issues
                              zparticle

                              Just out of curiosity, doesn't the CR1 indicate this is a release candidate? How can a version be considered a release candidate when it is know to be broken?

                              I'm not trying to be an ass, but one would think this couldn't be a release candidate.

                              • 12. Re: Deployment order and MYSQL Driver class issues
                                peterj

                                Being a candidate release does not necessarily mean that nothing is broken. It is rather an indication of the feature set. That is, a candidate release contains all of the features expected in the final release. It also implies that all components are at their expected levels (that is, if CR1 contains version 2.0.1 of major component X, then the GA will contain perhaps 2.0.3 but not version 3.0, or even 2.1 (mainly because major upgrades imply user API changes and the idea is that the user APIs are stable once the product hits the CR stage)).

                                What is giving me fits, however, is the amount of configuration changes that have gone in since CR1:

                                * there is a new jmx console which is visually very different from CR1, though behaves almost the same
                                * the port binding service has finally been fixed but how port binding will be done in CR2 is vastly different than how it was done up to CR1
                                * various configuration files have been renamed (this one is my fault, I questioned some of the renaming that took place in CR1)

                                • 13. Re: Deployment order and MYSQL Driver class issues
                                  zparticle

                                  Thanks for the explaination and thanks again for the help. Good luck.

                                  • 14. Re: Deployment order and MYSQL Driver class issues
                                    zparticle

                                    Just wanted to follow up with something I've found. If you use the deploy.last directory trick and you have more than one app in that directory, when you place a new version of one of the apps in there the server gets caught in a loop constanly redeploying all of the apps.

                                    So you have to stop the server and restart it. Also I'm sure everyone knows that the server has severe memory leaks when deploying new app versions from the normal deploy directory which eventually crash the server.