Well it was just a the NotCompliantMBeanException being wrapped in a UndeclaredThrowableException, I was about to commit a fix but I just notice ffang got in there first.
/Eoghan 2009/10/20 Guillaume Nodet <[email protected]> > I think the problem comes from the fact that the spring jmx assembler > not being set up. > > On Tue, Oct 20, 2009 at 16:00, Eoghan Glynn <[email protected]> wrote: > >> On a side note, I'm seing a lot of those exceptions in the log: > >> Caused by: javax.management. NotCompliantMBeanException: > >> ... > >> Not sure exactly where they come from, but we need to fix those. > > > > I'm on this NotCompliantMBeanException issue, should have a fix shortly > > (tracked via SMX4NMR-165). > > > > Cheers, > > Eoghan > > > > > > 2009/10/14 Guillaume Nodet <[email protected]> > > > >> On a side note, I'm seing a lot of those exceptions in the log: > >> > >> Caused by: javax.management.NotCompliantMBeanException: MBean class > >> org.apache.servicemix.nmr.management.ManagedEndpoint does not > >> implement DynamicMBean, neither follows the Standard MBean conventions > >> (javax.management.NotCompliantMBeanException: Class > >> org.apache.servicemix.nmr.management.ManagedEndpoint is not a JMX > >> compliant Standard MBean) nor the MXBean conventions > >> (javax.management.NotCompliantMBeanException: > >> org.apache.servicemix.nmr.management.ManagedEndpoint: Class > >> org.apache.servicemix.nmr.management.ManagedEndpoint is not a JMX > >> compliant MXBean) > >> > >> Not sure exactly where they come from, but we need to fix those. > >> > >> On Wed, Oct 14, 2009 at 10:02, Guillaume Nodet <[email protected]> > wrote: > >> > FWIW, I've slightly changed the startup mechanism for smx4 so that all > >> > the bundles are resolved as completely as possible (i.e. not having > >> > optional imports that could be solved, but aren't due to bundles start > >> > up order). > >> > > >> > To avoid a bad interaction between fileinstall and the features > >> > service around the deployment of the activemq-broker.xml, i've moved > >> > the broker config into the etc/ folder and use a feature with the > >> > spring url handler to deploy this one. This way, fileinstall does not > >> > try to deploy the activemq-broker.xml, but it's taken in charge by the > >> > boot features mechanism. The problem was that fileinstall was trying > >> > to start the generated activemq-broker bundle, thus forcing the > >> > resolution of bundles before it was actually necessary and was causing > >> > problems with unresolved optional imports. The downside is that you > >> > can't change the etc/activemq-broker.xml and expect it to be > >> > redeployed automatically. Instead, you'll have to osgi:refresh the > >> > bunde after any change, but I don't think it's a big drawback. > >> > This change also seem to have had a good impact on startup time, but > >> > I'll dig a bit more into that, as my cpu consumption is not very high, > >> > so I think we can still improve things here. > >> > > >> > -- > >> > Cheers, > >> > Guillaume Nodet > >> > ------------------------ > >> > Blog: http://gnodet.blogspot.com/ > >> > ------------------------ > >> > Open Source SOA > >> > http://fusesource.com > >> > > >> > >> > >> > >> -- > >> Cheers, > >> Guillaume Nodet > >> ------------------------ > >> Blog: http://gnodet.blogspot.com/ > >> ------------------------ > >> Open Source SOA > >> http://fusesource.com > >> > > > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com >
