That sounds like a good plan to me.
On Sun, Oct 27, 2013 at 12:45 AM, Darren Shepherd < darren.s.sheph...@gmail.com> wrote: > There is also a lot of static initialization. I don't know exactly > what was the issue that broke the build, but I assume its because > Transaction(Legacy) got loaded, and that class in a static block loads > db.properties, which then call some encryption utilities that will > fail if db.properties is not there. I'd rather remove the static > initializer (or atleast make it not blow up if its not there). The > tricky part is that there are so many "main class" utilities that > depend on Transaction class. I really want to standardize all > utilities that they initialize in the same way so we can clean this > stuff up, but that just takes time. > > Darren > > On Sat, Oct 26, 2013 at 11:17 AM, Laszlo Hornyak > <laszlo.horn...@gmail.com> wrote: > > Hi Alex, > > > > The build was failing again today so I have sent another quick fix with > > commit id > > 7902315287c268ff81e3b6664df6ddee7351716a looks like the build is back to > > normal. The prevous fix was reverted as after Darren's latest changes the > > jdbc driver was no longer needed for tests in that project. > > > > The tests are a bit fragile and in my opinion the reason is that the > > components are building a bit too much on the environment they are > running > > in. So writing good tests is a bit difficult in some cases, in some other > > cases almost impossible. > > > > > > > > > > On Sat, Oct 26, 2013 at 12:57 AM, Alex Huang <alex.hu...@citrix.com> > wrote: > > > >> Hi Laszlo, > >> > >> Thanks for the fix. It does fix this problem. I took a quick look. > >> > >> As I understand it from Alena, Darren had to move the initialization of > >> the LockMasterListener higher due to some problems Mike experienced. My > >> guess is that it had to be higher because Spring cannot work with the > >> ordered initialization that we used to have for the components (new, > >> configure, start) so it was moved into static which relies on jvm > >> initialization order. So moving the initialization of > LockMasterListener > >> back into start() method of ManagementServer basically will break things > >> for Mike again. I'll leave it to Darren to resolve this for now. I > don't > >> know enough about Spring loading to resolve this correctly for both > cases. > >> > >> --Alex > >> > >> > -----Original Message----- > >> > From: Laszlo Hornyak [mailto:laszlo.horn...@gmail.com] > >> > Sent: Friday, October 25, 2013 3:19 PM > >> > To: dev@cloudstack.apache.org > >> > Subject: Re: failing unit tests.... > >> > > >> > I have just sent a fix for that, looks like everything is green now. > >> Please check! > >> > > >> > > >> > On Fri, Oct 25, 2013 at 11:52 PM, Darren Shepherd < > >> > darren.s.sheph...@gmail.com> wrote: > >> > > >> > > I'll fix that. > >> > > > >> > > Darren > >> > > > >> > > On Fri, Oct 25, 2013 at 1:54 PM, Alex Huang <alex.hu...@citrix.com> > >> > wrote: > >> > > > I'm getting this failing unit test when building with the latest > >> > > > from > >> > > master. Anyone working on it or know what it is already? From the > >> > > stack, it looks like it's a problem location the jdbc driver. This > >> > > was working just yesterday. > >> > > > > >> > > > Test set: com.cloud.alert.AlertControlsUnitTest > >> > > > > >> > > > ---------------------------------------------------------------------- > >> > > --------- > >> > > > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: > >> > > > 0.175 > >> > > sec <<< FAILURE! > >> > > > warning(junit.framework.TestSuite$1) Time elapsed: 0.004 sec <<< > >> > > FAILURE! > >> > > > junit.framework.AssertionFailedError: Exception in constructor: > >> > > testInjected (java.lang.ExceptionInInitializerError > >> > > > at > >> > > > com.cloud.alert.AlertControlsUnitTest.<init>(AlertControlsUnitTest.jav > >> > > a:46) > >> > > > at > >> > > > sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > >> > > Method) > >> > > > at > >> > > > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructo > >> > > rAccessorImpl.java:57) > >> > > > at > >> > > > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCo > >> > > nstructorAccessorImpl.java:45) > >> > > > at > >> > > java.lang.reflect.Constructor.newInstance(Constructor.java:526) > >> > > > at junit.framework.TestSuite.createTest(TestSuite.java:61) > >> > > > at > >> junit.framework.TestSuite.addTestMethod(TestSuite.java:294) > >> > > > at > >> > > junit.framework.TestSuite.addTestsFromTestCase(TestSuite.java:150) > >> > > > at junit.framework.TestSuite.<init>(TestSuite.java:129) > >> > > > at > >> > > > org.junit.internal.runners.JUnit38ClassRunner.<init>(JUnit38ClassRunne > >> > > r.java:71) > >> > > > at > >> > > > org.junit.internal.builders.JUnit3Builder.runnerForClass(JUnit3Builder > >> > > .java:14) > >> > > > at > >> > > > org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder > >> > > .java:57) > >> > > > at > >> > > > org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForCl > >> > > ass(AllDefaultPossibilitiesBuilder.java:29) > >> > > > at > >> > > > org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder > >> > > .java:57) > >> > > > at > >> > > > org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:2 > >> > > 4) > >> > > > at > >> > > > org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider > >> > > .java:234) > >> > > > at > >> > > > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4P > >> > > rovider.java:134) > >> > > > at > >> > > > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider. > >> > > java:113) > >> > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native > >> Method) > >> > > > at > >> > > > >> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j > >> > > ava:57) > >> > > > at > >> > > > >> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > >> > s > >> > > orImpl.java:43) > >> > > > at java.lang.reflect.Method.invoke(Method.java:606) > >> > > > at > >> > > > org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(R > >> > > eflectionUtils.java:189) > >> > > > at > >> > > > org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke( > >> > > ProviderFactory.java:165) > >> > > > at > >> > > > org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(Provid > >> > > erFactory.java:85) > >> > > > at > >> > > > >> > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(Forke > >> > > dBooter.java:103) > >> > > > at > >> > > > >> > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:7 > >> > > 4) > >> > > > Caused by: com.cloud.utils.exception.CloudRuntimeException: Unable > >> > > > to > >> > > initialize a connection to the database for locking purposes: > >> > > > at > >> com.cloud.utils.db.Merovingian2.<init>(Merovingian2.java:74) > >> > > > at > >> > > > com.cloud.utils.db.Merovingian2.createLockMaster(Merovingian2.java:80) > >> > > > at > >> > > > com.cloud.server.LockMasterListener.<init>(LockMasterListener.java:33) > >> > > > at > >> > > > >> > com.cloud.server.ManagementServerImpl.<clinit>(ManagementServerImpl. > >> > ja > >> > > va:602) > >> > > > ... 27 more > >> > > > Caused by: java.sql.SQLException: No suitable driver found for > >> > > > >> > jdbc:mysql://localhost:3306/cloud?autoReconnect=true&prepStmtCacheSize > >> > > =517&cachePrepStmts=true&prepStmtCacheSqlLimit=4096 > >> > > > at > >> java.sql.DriverManager.getConnection(DriverManager.java:596) > >> > > > at > >> java.sql.DriverManager.getConnection(DriverManager.java:215) > >> > > > at > >> > > > >> > org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnec > >> > tio > >> > > n(DriverManagerConnectionFactory.java:75) > >> > > > at > >> > > > >> > org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(Poolabl > >> > eC > >> > > onnectionFactory.java:582) > >> > > > > >> > > > --Alex > >> > > > >> > > >> > > >> > > >> > -- > >> > > >> > EOF > >> > > > > > > > > -- > > > > EOF > -- EOF
