>> Yes, if he has the class. However, I thought his original question on users@ >> said that he wanted to be able to list all class available in a class space.
Yes this is my goal-plated requirement, and what I ultimately would want to do, but partially reimplementing the OSGi class loader search process seems beyond my scope/ability. Here is the development time problem I would like to solve, again the problem might very well be a beginner problem that developers with OSGi knowledge might not face. I frequently (seem to) run into issues that result in Class loading related exceptions, doing a manual inspection of the manifest headers, I often come to the conclusion that the class should have been in the class space of the bundle that is causing the exception, at this state it would be great to have a tool to visually inspect the classes that are available in the bundle class space along with the jars from which the classes are being loaded, this diagnostic information would, I think, help in determining the error in the Manifest headers sooner and lessen my pain attempting to understand OSGi. Having understood the scope of the work that needs to be implemented I think I have decided to settle for option 2 -> user does a search by class name and a bundle id I intend to provide class meta information in the event that the class is available in the bundle class space, else use PackageAdmin.getBundle(java.lang.Class clazz) to retreive the bundle and display its information. >From Karl's and Niclas responses above, my initial though was that Niclas is correct, in that I want to know where a particular class comes from for a specific bundle class space. Based on what I understand, a class may be loaded from 2 separate locations, in different class spaces, so I think I need step 3. 1) Get the package name from the class name. 2) Locate all bundles exporting that package. 3) Check which Bundle Classloader equals the class classloader. >From Karl's response I took a look at the Javadoc for PackageAdmin ___ public Bundle getBundle(java.lang.Class clazz) Returns the bundle from which the specified class is loaded. The class loader of the returned bundle must have been used to load the specified class. If the class was not loaded by a bundle class loader then null is returned. __ This seems to imply that my understanding of class being (potentially) loaded from multiple bundles in different class spaces is incorrect, what exactly am I missing? My approach to try to implement this is as follows Try and fix https://issues.apache.org/jira/browse/FELIX-574 https://issues.apache.org/jira/browse/FELIX-566 to get an understanding of how the web console code is organized, I took a first stab at 574 and know what to do to fix this. On 566, I think I should be able to address it, once I have 574 addressed. Only after then do I intend to try implementing the additional servlet for performing the class and bundle id based search. Once again thank you all for chiming in, greatly appreciated as it makes my understand a little better each time. Thanks Bhaskar On Fri, Jun 6, 2008 at 9:40 AM, Richard S. Hall <[EMAIL PROTECTED]> wrote: > Niclas Hedhman wrote: >> >> On Friday 06 June 2008 01:47, Richard S. Hall wrote: >> >>> >>> In some >>> cases, this won't be so easy, because you might have to look into the >>> contents of embedded JAR files... >>> >> >> Well, if he has the class (which I believe was the initial question), then >> I think the process would be much easier. >> >> 1) Get the package name from the class name. >> 2) Locate all bundles exporting that package. >> 3) Check which Bundle Classloader equals the class' classloader. >> >> No? >> > > Yes, if he has the class. However, I thought his original question on users@ > said that he wanted to be able to list all class available in a class space. > I could be remembering incorrectly. Nevertheless, you are correct, and as > Karl points out, if that is all he wants to do, it is really easy. > > -> richard > >> Cheers >> >
