Hi, Apologies for not responding more quickly; I'm a non-committer, so I was actually offline when the patch hit master.
I think the behavior Likitha observed would happen if a developer updated to latest master, and started the management server, but didn't redeploy the management server database first. My understanding is that unless you're upgrading between versions (e.g. 4.1 to 4.2), the only way to make sure you pick up new database changes / config values in development is to drop and deploy the database after updating. This is because the management server would look at the existing database, see that it's at 4.2 already, and decide not to run any upgrade SQL. Since we can't get the new database change / config value from upgrade SQL in this case, we have to drop and deploy the database. If I'm missing anything, please let me know - from what I've seen, this seems to be normal practice, but if there's a better way, I'm happy to make any changes needed. Thanks, Dave. On Thu, Apr 4, 2013 at 4:10 AM, Chip Childers <chip.child...@sungard.com>wrote: > On Wed, Apr 03, 2013 at 06:45:44PM +0000, Pranav Saxena wrote: > > I happened to see that Hugo enabled the midonet plugin in both > client/tomcatconf/componentContext.xml.in and client/tomcatconf/ > nonossComponentContext.xml.in on top of Dave's commit on supporting > midonet plugin. Perhaps ,that fixed the issue actually. > > That would make sense, given the exception that was being raised. > > > > > -----Original Message----- > > From: srivatsav.prasa...@gmail.com [mailto:srivatsav.prasa...@gmail.com] > On Behalf Of prasanna > > Sent: Thursday, April 04, 2013 12:10 AM > > To: dev@cloudstack.apache.org > > Subject: Re: Master - jetty run failure > > > > I'm not seeing this on the latest master. Perhaps something wrong with > nonOss component context? Are you running nonOss by any chance? > > > > On 3 April 2013 23:23, Pranav Saxena <pranav.sax...@citrix.com> wrote: > > > Possible workaround until that issue is fixed - Revering these two > commits - eddf7b9357bc18497b8cb16a6c6f3382ac52f61c and > 44567453e0511e3090ac22518113b283cfa26b4b to have jetty running > successfully. > > > > > > -----Original Message----- > > > From: Likitha Shetty [mailto:likitha.she...@citrix.com] > > > Sent: Wednesday, April 03, 2013 11:15 PM > > > To: dev@cloudstack.apache.org > > > Cc: Hugo Trippaers > > > Subject: Master - jetty run failure > > > > > > On latest master when I run jetty, > > > > > > ERROR [utils.component.ComponentContext] (Timer-2:) Unhandled > > > exception > > > javax.naming.ConfigurationException: Could not find midonet API > location in config > > > at > com.cloud.network.element.MidoNetElement.configure(MidoNetElement.java:148) > > > at > com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:111) > > > at > com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:50) > > > at java.util.TimerThread.mainLoop(Timer.java:534) > > > at java.util.TimerThread.run(Timer.java:484) > > > Exception in thread "Timer-2" java.lang.RuntimeException: Unable to > configure > com.cloud.network.element.MidoNetElement_EnhancerByCloudStack_c688f431 > > > at > com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:114) > > > at > com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:50) > > > at java.util.TimerThread.mainLoop(Timer.java:534) > > > at java.util.TimerThread.run(Timer.java:484) > > > Caused by: javax.naming.ConfigurationException: Could not find midonet > API location in config > > > at > com.cloud.network.element.MidoNetElement.configure(MidoNetElement.java:148) > > > at > com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:111) > > > ... 3 more > > > > > > Thank you, > > > Likitha >
