Hi Guillaume,
I just created SMXNMR-166 and commited a fix.
The fact is that for proxy reference(mbeanServer in this case), we
should catch UndeclaredThrowableException and then use getCause() to
determine if the actual exception is NotCompliantMBeanException or
not. But still not clear why we didn't see this problem before.
Eoghan, sorry, not realize you are working on it and already create a
jira for it, please review my commit with SMXNMR-166, if I'm wrong,
just correct me.
Thanks
Freeman
On 2009-10-20, at 下午10:01, Guillaume Nodet wrote:
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
--
Freeman Fang
------------------------
Open Source SOA: http://fusesource.com
