Forgot to mention that I'm deploying my apps as war files. I thought maybe this:
applied but I don't know how to apply that to a war.
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.
during the "hang" the mysql and jboss processes are taking 50% of the cpu
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.
I wish that worked, but with the loggin parameter the service won't start.
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.
<bean id="photositeDataSource" class="org.springframework.jndi.JndiObjectFactoryBean"> <property name="jndiName" value="java:photosite"/> <property name="resourceRef" value="false"></property> </bean>
<resource-ref> <res-ref-name>photosite</res-ref-name> <jndi-name>photosite</jndi-name> <res-type>javax.sql.DataSource</res-type> </resource-ref>
<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>
<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>
I wish that worked
Define "that" (I provided two suggestions, I have no idea which one you are referring to)
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?
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).
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:
by changing the deployers.xml file but that blows the sever out of the water completely.
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.
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.
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)
Thanks for the explaination and thanks again for the help. Good luck.
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.