Hi Miguel, Alright, so I assume this case is closed.
Regards and have a nice day Felix Am Mittwoch, den 12.09.2007, 13:02 +0100 schrieb Miguel Matos: > Hi again, > > Felix Meschberger wrote: > > Hi Migueal, > > > > Am Mittwoch, den 12.09.2007, 11:46 +0100 schrieb Miguel Matos: > > > > > > So you would have to make sure the JMX > > > > Server knows about how to load the MBeans from within the Bundles - > > > > given that Bundles may come and go, this sounds like tricky. Generally I > > > > try no to use the JMX Server to create MBeans because of these issues. > > > > > > > > > > > How do you create the MBeans ? > > > > > > > Generally, I have my internal services and state objects, which register > > themselves with the JMX Server, either directly or using some > > ProxyMBean. > > > > But I have to admit, that I never had a requirement to have the > > JMX-based administrator create MBeans - and when there was the slightest > > chance, there could be such a requirement, I quickly found a > > workaround :-) > > > > > Well that is what I did ;) Instead of having the jmx server create > the MBeans I create them as a normal obejct and then register them > with the mbeanserver solving the problem of the classloading by the > jmx side. > The mbeans used are dynamic mbeans and there is no difference in > creating them by jmx or by "hand" by the application and later > registering them. > > > > As a side question is this a general problem when using reflection in > > > a osgi environment? > > > > > > > Reflection in itself is not the primary issue. The problem is tampering > > with class loading. And this is somewhat involved if you come from the > > traditional Java ClassLoader hierarchy model where each class loader > > knows all classes of its ancestor class loaders. > > > > In OSGi environment, each bundle has its class loader which only asks > > its parent class loader under certain circumstances (mainly > > bootdelegation classes). Generally, a bundle class loader only knows > > about its imports and the bundle-contained classes. > > > > One option to find solutions regarding class loaders and bundles might > > be to implement a class loader along the lines of the Equinox > > BundleProxyClassLoader recipe [1]. > > > > > Well I no longer need a custom classloader but I will have a look at > the recipe to help me dive deeper in the inner workings of osgi ;) > > Thanks for your help > > Miguel Matos > > Regards > > Felix > > > > [1] http://wiki.eclipse.org/BundleProxyClassLoader_recipe > > > > > > > Miguel Matos > > > > > > > Hope this helps. > > > > > > > > Regards > > > > Felix > > > > > > > > Am Dienstag, den 11.09.2007, 23:28 +0100 schrieb MMatos: > > > > > > > > > > > > > Hello! > > > > > > > > > > I've been playing with apache felix for some months. Now I am > > > > > building > > > > > a bundle that depends on external jars and use a bit of reflection. > > > > > > > > > > To overcome the problem of the external library I have used the > > > > > Bundle-ClassPath: manifest header. > > > > > > > > > > Currently my problem is when I tried to load a class using > > > > > reflection > > > > > and I get a class not found exception. > > > > > > > > > > > > > > > javax.management.ReflectionException: The MBean class could not be > > > > > loaded by the default loader repository > > > > > at > > > > > com.sun.jmx.mbeanserver.MBeanInstantiatorImpl.findClassWithDefaultLoaderRepository(MBeanInstantiatorImpl.java:61) > > > > > at > > > > > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.createMBean(DefaultMBeanServerInterceptor.java:271) > > > > > at > > > > > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.createMBean(DefaultMBeanServerInterceptor.java:211) > > > > > at > > > > > com.sun.jmx.mbeanserver.JmxMBeanServer.createMBean(JmxMBeanServer.java:408) > > > > > at > > > > > kAdapt.mbeanServer.MainServer.registerMBean(MainServer.java:131) > > > > > > > > > > > > > > > Caused by: java.lang.ClassNotFoundException: > > > > > kAdapt.mbeanServer.InfoMBean > > > > > at > > > > > com.sun.jmx.mbeanserver.ClassLoaderRepositorySupport.loadClass(ClassLoaderRepositorySupport.java:208) > > > > > at > > > > > com.sun.jmx.mbeanserver.ClassLoaderRepositorySupport.loadClass(ClassLoaderRepositorySupport.java:128) > > > > > at > > > > > com.sun.jmx.mbeanserver.MBeanInstantiatorImpl.findClassWithDefaultLoaderRepository(MBeanInstantiatorImpl.java:58) > > > > > ... 18 more > > > > > > > > > > > > > > > The class in question kAdapt.mbeanServer.InfoMBean is of course in > > > > > the > > > > > package hierarchy but the osgi classloader seems to miss it ... > > > > > I would like to know why this happens and the solution. > > > > > > > > > > ( In this particular problem the class failing to load is an MBean > > > > > when > > > > > trying to create it > > > > > -->> at > > > > > com.sun.jmx.mbeanserver.MBeanInstantiatorImpl.findClassWithDefaultLoaderRepository(MBeanInstantiatorImpl.java:61) > > > > > but I think that this problem will happen whenever one uses > > > > > reflection > > > > > ... Am I right ? > > > > > ) > > > > > > > > > > I tried with DynamicImport-Package but without success too ... > > > > > > > > > > Here is my manifest > > > > > > > > > > Manifest-Version: 1.0 > > > > > Archiver-Version: Plexus Archiver > > > > > Created-By: Apache Maven > > > > > Build-Jdk: 1.5.0_12 > > > > > Bundle-Activator: kAdapt.Activator > > > > > DynamicImport-Package: kAdapt.mbeanServer <<---- the class not > > > > > found > > > > > is here > > > > > Bundle-ClassPath: .,kAdapt,js-1.6R5.jar > > > > > Import-Package: org.osgi.framework;version=1.3,org.osgi.service.log;ve > > > > > rsion=1.3,javax.management.remote,javax.management,javax.xml.parsers, > > > > > org.w3c.dom,org.xml.sax > > > > > Bundle-ManifestVersion: 2 > > > > > > > > > > Any guidance will be greatly appreciated. > > > > > > > > > > Miguel Matos > > > > > > > > > > PS: I think I could use the jmx facilities provided by felix ( I am > > > > > already doing that in another bundle, but that is not the point in my > > > > > question....)) > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] For > > > additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
