Dear David, Thank you for your replying, it's working now.
I'm very interested to prepare posts into my blog and training courses about the famous OpenEJB. These kinds of tips are significants to supply good supports. Mickael David Blevins wrote: > > 1. Forcefully flush the pool: http://gist.github.com/168083 > > In this approach we reduce our client connection pool to 1 and then > use an internal call to evict it from the pool. The result is you are > guaranteed to get a new connection when you want one. > > 2. Use the multicast failover/retry: http://gist.github.com/168106 > > Here we edit the conf/multicast.properties file and set 'disabled' to > false so the mutlicast support starts up. The code then uses the > multicast URI to connect to the server. We also set a system property > "openejb.client.requestretry" to "true". The result is that the > client will listen for a server on the multicast channel when you try > and connect (will wait for the configured timeout). If/When a server > shows up it will send the request to it. If at any time the server > disappears, the "requestretry" property will cause the client to go > back to multicast listening. The new server is discovered and the > request goes to it. > > 3. Deploy/undeploy to the same server > > That said, if the ultimate goal is to write some tooling to help you > deploy/undeploy apps, there is a real "powerhouse" way to do it. This > is what I'd do: http://gist.github.com/168121 > > In that scenario we use the Deployer EJB to deploy and undeploy > applications as well as get metadata about existing applications. The > command line deploy/undeploy commands actually use this EJB under the > covers. This way there is no need to restart the server and no need > for Thread.sleep statements. The deploy method will block till the > app is fully deployed and ready to be executed, the undeploy command > will block until the app is fully undeployed. It does expose you to > the internal AppInfo metadata which is tweaked once in a while, but is > a pretty stable object tree overall. Certainly you could write some > heavy duty tooling with that information. > > > Hope this helps! > > If you get the urge to blog about it, we're happy to point to it in > our blog. > > > -David > > -- View this message in context: http://www.nabble.com/Starting-OpenEJB-server-from-a-java-code.-tp24643630p25006239.html Sent from the OpenEJB User mailing list archive at Nabble.com.
