[jira] [Updated] (KARAF-2508) make osgi:find-class a more useful command
[ https://issues.apache.org/jira/browse/KARAF-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-2508: Fix Version/s: (was: 2.4.4) (was: 4.0.1) (was: 3.0.5) > make osgi:find-class a more useful command > -- > > Key: KARAF-2508 > URL: https://issues.apache.org/jira/browse/KARAF-2508 > Project: Karaf > Issue Type: Improvement > Components: karaf-shell >Affects Versions: 2.3.3 >Reporter: Amichai Rothman >Priority: Minor > > I recently had to track down which bundle contains a certain class, and found > the find-class command wanting. A few simple improvements would make it much > more useful: > 1. Add an --exact/-e option which doesn't automatically add asterisks at both > ends of the string. In my case I was looking for the javax.jms.Connection > class, and since the search is only on the last part of the name, this > returned all classes in all packages which have the word Connection in their > name, which added up to hundreds of results. with --exact I could look for > what I want exactly, or choose to add asterisks at one or both ends > explicitly in the search string if I wanted to. > 2. Add a --local/-l option which adds BundleWiring.LISTRESOURCES_LOCAL to the > listResources method call bitmask. With the current implementation, it > returns both bundles containing the given class name and classes that import > it from other bundles, which is useful in some cases. But with the --local > option it could show only the bundles that actually contain the class > (whether exported or not, unlike the exports command), which is far more > useful in tracking down some classloading issues. > 3. Add the bundle ID (at least) on the beginning of every printed line. This > makes it amenable to grepping (without it a grep loses all bundle > information, which is the whole point of using this command). > 4. As a somewhat more complex alternative to #3, it would be nice if you > could specify a fully qualified class name and not only the last part of the > name. The command can split the search string around periods, pass the last > part to listResources, then internally grep/match the full name. That would > make it truly flexible in finding classes. Asterisks would have to be treated > accordingly. > I think adding these options (#1-#3 are trivial implementations), or at least > some of them, would make the command extremely useful when performing > classloading diagnosis. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KARAF-2508) make osgi:find-class a more useful command
[ https://issues.apache.org/jira/browse/KARAF-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-2508: Assignee: (was: Jean-Baptiste Onofré) > make osgi:find-class a more useful command > -- > > Key: KARAF-2508 > URL: https://issues.apache.org/jira/browse/KARAF-2508 > Project: Karaf > Issue Type: Improvement > Components: karaf-shell >Affects Versions: 2.3.3 >Reporter: Amichai Rothman >Priority: Minor > > I recently had to track down which bundle contains a certain class, and found > the find-class command wanting. A few simple improvements would make it much > more useful: > 1. Add an --exact/-e option which doesn't automatically add asterisks at both > ends of the string. In my case I was looking for the javax.jms.Connection > class, and since the search is only on the last part of the name, this > returned all classes in all packages which have the word Connection in their > name, which added up to hundreds of results. with --exact I could look for > what I want exactly, or choose to add asterisks at one or both ends > explicitly in the search string if I wanted to. > 2. Add a --local/-l option which adds BundleWiring.LISTRESOURCES_LOCAL to the > listResources method call bitmask. With the current implementation, it > returns both bundles containing the given class name and classes that import > it from other bundles, which is useful in some cases. But with the --local > option it could show only the bundles that actually contain the class > (whether exported or not, unlike the exports command), which is far more > useful in tracking down some classloading issues. > 3. Add the bundle ID (at least) on the beginning of every printed line. This > makes it amenable to grepping (without it a grep loses all bundle > information, which is the whole point of using this command). > 4. As a somewhat more complex alternative to #3, it would be nice if you > could specify a fully qualified class name and not only the last part of the > name. The command can split the search string around periods, pass the last > part to listResources, then internally grep/match the full name. That would > make it truly flexible in finding classes. Asterisks would have to be treated > accordingly. > I think adding these options (#1-#3 are trivial implementations), or at least > some of them, would make the command extremely useful when performing > classloading diagnosis. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KARAF-2508) make osgi:find-class a more useful command
[ https://issues.apache.org/jira/browse/KARAF-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-2508: Fix Version/s: (was: 2.4.3) 2.4.4 > make osgi:find-class a more useful command > -- > > Key: KARAF-2508 > URL: https://issues.apache.org/jira/browse/KARAF-2508 > Project: Karaf > Issue Type: Improvement > Components: karaf-shell >Affects Versions: 2.3.3 >Reporter: Amichai Rothman >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 3.0.5, 4.0.1, 2.4.4 > > > I recently had to track down which bundle contains a certain class, and found > the find-class command wanting. A few simple improvements would make it much > more useful: > 1. Add an --exact/-e option which doesn't automatically add asterisks at both > ends of the string. In my case I was looking for the javax.jms.Connection > class, and since the search is only on the last part of the name, this > returned all classes in all packages which have the word Connection in their > name, which added up to hundreds of results. with --exact I could look for > what I want exactly, or choose to add asterisks at one or both ends > explicitly in the search string if I wanted to. > 2. Add a --local/-l option which adds BundleWiring.LISTRESOURCES_LOCAL to the > listResources method call bitmask. With the current implementation, it > returns both bundles containing the given class name and classes that import > it from other bundles, which is useful in some cases. But with the --local > option it could show only the bundles that actually contain the class > (whether exported or not, unlike the exports command), which is far more > useful in tracking down some classloading issues. > 3. Add the bundle ID (at least) on the beginning of every printed line. This > makes it amenable to grepping (without it a grep loses all bundle > information, which is the whole point of using this command). > 4. As a somewhat more complex alternative to #3, it would be nice if you > could specify a fully qualified class name and not only the last part of the > name. The command can split the search string around periods, pass the last > part to listResources, then internally grep/match the full name. That would > make it truly flexible in finding classes. Asterisks would have to be treated > accordingly. > I think adding these options (#1-#3 are trivial implementations), or at least > some of them, would make the command extremely useful when performing > classloading diagnosis. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KARAF-2508) make osgi:find-class a more useful command
[ https://issues.apache.org/jira/browse/KARAF-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-2508: Fix Version/s: (was: 4.0.0) 4.0.1 > make osgi:find-class a more useful command > -- > > Key: KARAF-2508 > URL: https://issues.apache.org/jira/browse/KARAF-2508 > Project: Karaf > Issue Type: Improvement > Components: karaf-shell >Affects Versions: 2.3.3 >Reporter: Amichai Rothman >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 2.4.3, 3.0.5, 4.0.1 > > > I recently had to track down which bundle contains a certain class, and found > the find-class command wanting. A few simple improvements would make it much > more useful: > 1. Add an --exact/-e option which doesn't automatically add asterisks at both > ends of the string. In my case I was looking for the javax.jms.Connection > class, and since the search is only on the last part of the name, this > returned all classes in all packages which have the word Connection in their > name, which added up to hundreds of results. with --exact I could look for > what I want exactly, or choose to add asterisks at one or both ends > explicitly in the search string if I wanted to. > 2. Add a --local/-l option which adds BundleWiring.LISTRESOURCES_LOCAL to the > listResources method call bitmask. With the current implementation, it > returns both bundles containing the given class name and classes that import > it from other bundles, which is useful in some cases. But with the --local > option it could show only the bundles that actually contain the class > (whether exported or not, unlike the exports command), which is far more > useful in tracking down some classloading issues. > 3. Add the bundle ID (at least) on the beginning of every printed line. This > makes it amenable to grepping (without it a grep loses all bundle > information, which is the whole point of using this command). > 4. As a somewhat more complex alternative to #3, it would be nice if you > could specify a fully qualified class name and not only the last part of the > name. The command can split the search string around periods, pass the last > part to listResources, then internally grep/match the full name. That would > make it truly flexible in finding classes. Asterisks would have to be treated > accordingly. > I think adding these options (#1-#3 are trivial implementations), or at least > some of them, would make the command extremely useful when performing > classloading diagnosis. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KARAF-2508) make osgi:find-class a more useful command
[ https://issues.apache.org/jira/browse/KARAF-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-2508: Fix Version/s: (was: 4.0.0.M3) 4.0.0 > make osgi:find-class a more useful command > -- > > Key: KARAF-2508 > URL: https://issues.apache.org/jira/browse/KARAF-2508 > Project: Karaf > Issue Type: Improvement > Components: karaf-shell >Affects Versions: 2.3.3 >Reporter: Amichai Rothman >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 4.0.0, 2.4.3, 3.0.5 > > > I recently had to track down which bundle contains a certain class, and found > the find-class command wanting. A few simple improvements would make it much > more useful: > 1. Add an --exact/-e option which doesn't automatically add asterisks at both > ends of the string. In my case I was looking for the javax.jms.Connection > class, and since the search is only on the last part of the name, this > returned all classes in all packages which have the word Connection in their > name, which added up to hundreds of results. with --exact I could look for > what I want exactly, or choose to add asterisks at one or both ends > explicitly in the search string if I wanted to. > 2. Add a --local/-l option which adds BundleWiring.LISTRESOURCES_LOCAL to the > listResources method call bitmask. With the current implementation, it > returns both bundles containing the given class name and classes that import > it from other bundles, which is useful in some cases. But with the --local > option it could show only the bundles that actually contain the class > (whether exported or not, unlike the exports command), which is far more > useful in tracking down some classloading issues. > 3. Add the bundle ID (at least) on the beginning of every printed line. This > makes it amenable to grepping (without it a grep loses all bundle > information, which is the whole point of using this command). > 4. As a somewhat more complex alternative to #3, it would be nice if you > could specify a fully qualified class name and not only the last part of the > name. The command can split the search string around periods, pass the last > part to listResources, then internally grep/match the full name. That would > make it truly flexible in finding classes. Asterisks would have to be treated > accordingly. > I think adding these options (#1-#3 are trivial implementations), or at least > some of them, would make the command extremely useful when performing > classloading diagnosis. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KARAF-2508) make osgi:find-class a more useful command
[ https://issues.apache.org/jira/browse/KARAF-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-2508: Fix Version/s: (was: 3.0.4) 3.0.5 > make osgi:find-class a more useful command > -- > > Key: KARAF-2508 > URL: https://issues.apache.org/jira/browse/KARAF-2508 > Project: Karaf > Issue Type: Improvement > Components: karaf-shell >Affects Versions: 2.3.3 >Reporter: Amichai Rothman >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 4.0.0.M3, 2.4.3, 3.0.5 > > > I recently had to track down which bundle contains a certain class, and found > the find-class command wanting. A few simple improvements would make it much > more useful: > 1. Add an --exact/-e option which doesn't automatically add asterisks at both > ends of the string. In my case I was looking for the javax.jms.Connection > class, and since the search is only on the last part of the name, this > returned all classes in all packages which have the word Connection in their > name, which added up to hundreds of results. with --exact I could look for > what I want exactly, or choose to add asterisks at one or both ends > explicitly in the search string if I wanted to. > 2. Add a --local/-l option which adds BundleWiring.LISTRESOURCES_LOCAL to the > listResources method call bitmask. With the current implementation, it > returns both bundles containing the given class name and classes that import > it from other bundles, which is useful in some cases. But with the --local > option it could show only the bundles that actually contain the class > (whether exported or not, unlike the exports command), which is far more > useful in tracking down some classloading issues. > 3. Add the bundle ID (at least) on the beginning of every printed line. This > makes it amenable to grepping (without it a grep loses all bundle > information, which is the whole point of using this command). > 4. As a somewhat more complex alternative to #3, it would be nice if you > could specify a fully qualified class name and not only the last part of the > name. The command can split the search string around periods, pass the last > part to listResources, then internally grep/match the full name. That would > make it truly flexible in finding classes. Asterisks would have to be treated > accordingly. > I think adding these options (#1-#3 are trivial implementations), or at least > some of them, would make the command extremely useful when performing > classloading diagnosis. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KARAF-2508) make osgi:find-class a more useful command
[ https://issues.apache.org/jira/browse/KARAF-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-2508: Fix Version/s: (was: 2.4.2) 2.4.3 > make osgi:find-class a more useful command > -- > > Key: KARAF-2508 > URL: https://issues.apache.org/jira/browse/KARAF-2508 > Project: Karaf > Issue Type: Improvement > Components: karaf-shell >Affects Versions: 2.3.3 >Reporter: Amichai Rothman >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 3.0.4, 4.0.0.M3, 2.4.3 > > > I recently had to track down which bundle contains a certain class, and found > the find-class command wanting. A few simple improvements would make it much > more useful: > 1. Add an --exact/-e option which doesn't automatically add asterisks at both > ends of the string. In my case I was looking for the javax.jms.Connection > class, and since the search is only on the last part of the name, this > returned all classes in all packages which have the word Connection in their > name, which added up to hundreds of results. with --exact I could look for > what I want exactly, or choose to add asterisks at one or both ends > explicitly in the search string if I wanted to. > 2. Add a --local/-l option which adds BundleWiring.LISTRESOURCES_LOCAL to the > listResources method call bitmask. With the current implementation, it > returns both bundles containing the given class name and classes that import > it from other bundles, which is useful in some cases. But with the --local > option it could show only the bundles that actually contain the class > (whether exported or not, unlike the exports command), which is far more > useful in tracking down some classloading issues. > 3. Add the bundle ID (at least) on the beginning of every printed line. This > makes it amenable to grepping (without it a grep loses all bundle > information, which is the whole point of using this command). > 4. As a somewhat more complex alternative to #3, it would be nice if you > could specify a fully qualified class name and not only the last part of the > name. The command can split the search string around periods, pass the last > part to listResources, then internally grep/match the full name. That would > make it truly flexible in finding classes. Asterisks would have to be treated > accordingly. > I think adding these options (#1-#3 are trivial implementations), or at least > some of them, would make the command extremely useful when performing > classloading diagnosis. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KARAF-2508) make osgi:find-class a more useful command
[ https://issues.apache.org/jira/browse/KARAF-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-2508: Fix Version/s: (was: 3.0.3) 3.0.4 > make osgi:find-class a more useful command > -- > > Key: KARAF-2508 > URL: https://issues.apache.org/jira/browse/KARAF-2508 > Project: Karaf > Issue Type: Improvement > Components: karaf-shell >Affects Versions: 2.3.3 >Reporter: Amichai Rothman >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 4.0.0, 2.4.2, 3.0.4 > > > I recently had to track down which bundle contains a certain class, and found > the find-class command wanting. A few simple improvements would make it much > more useful: > 1. Add an --exact/-e option which doesn't automatically add asterisks at both > ends of the string. In my case I was looking for the javax.jms.Connection > class, and since the search is only on the last part of the name, this > returned all classes in all packages which have the word Connection in their > name, which added up to hundreds of results. with --exact I could look for > what I want exactly, or choose to add asterisks at one or both ends > explicitly in the search string if I wanted to. > 2. Add a --local/-l option which adds BundleWiring.LISTRESOURCES_LOCAL to the > listResources method call bitmask. With the current implementation, it > returns both bundles containing the given class name and classes that import > it from other bundles, which is useful in some cases. But with the --local > option it could show only the bundles that actually contain the class > (whether exported or not, unlike the exports command), which is far more > useful in tracking down some classloading issues. > 3. Add the bundle ID (at least) on the beginning of every printed line. This > makes it amenable to grepping (without it a grep loses all bundle > information, which is the whole point of using this command). > 4. As a somewhat more complex alternative to #3, it would be nice if you > could specify a fully qualified class name and not only the last part of the > name. The command can split the search string around periods, pass the last > part to listResources, then internally grep/match the full name. That would > make it truly flexible in finding classes. Asterisks would have to be treated > accordingly. > I think adding these options (#1-#3 are trivial implementations), or at least > some of them, would make the command extremely useful when performing > classloading diagnosis. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KARAF-2508) make osgi:find-class a more useful command
[ https://issues.apache.org/jira/browse/KARAF-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-2508: Fix Version/s: (was: 2.4.1) 2.4.2 > make osgi:find-class a more useful command > -- > > Key: KARAF-2508 > URL: https://issues.apache.org/jira/browse/KARAF-2508 > Project: Karaf > Issue Type: Improvement > Components: karaf-shell >Affects Versions: 2.3.3 >Reporter: Amichai Rothman >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 4.0.0, 3.0.3, 2.4.2 > > > I recently had to track down which bundle contains a certain class, and found > the find-class command wanting. A few simple improvements would make it much > more useful: > 1. Add an --exact/-e option which doesn't automatically add asterisks at both > ends of the string. In my case I was looking for the javax.jms.Connection > class, and since the search is only on the last part of the name, this > returned all classes in all packages which have the word Connection in their > name, which added up to hundreds of results. with --exact I could look for > what I want exactly, or choose to add asterisks at one or both ends > explicitly in the search string if I wanted to. > 2. Add a --local/-l option which adds BundleWiring.LISTRESOURCES_LOCAL to the > listResources method call bitmask. With the current implementation, it > returns both bundles containing the given class name and classes that import > it from other bundles, which is useful in some cases. But with the --local > option it could show only the bundles that actually contain the class > (whether exported or not, unlike the exports command), which is far more > useful in tracking down some classloading issues. > 3. Add the bundle ID (at least) on the beginning of every printed line. This > makes it amenable to grepping (without it a grep loses all bundle > information, which is the whole point of using this command). > 4. As a somewhat more complex alternative to #3, it would be nice if you > could specify a fully qualified class name and not only the last part of the > name. The command can split the search string around periods, pass the last > part to listResources, then internally grep/match the full name. That would > make it truly flexible in finding classes. Asterisks would have to be treated > accordingly. > I think adding these options (#1-#3 are trivial implementations), or at least > some of them, would make the command extremely useful when performing > classloading diagnosis. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KARAF-2508) make osgi:find-class a more useful command
[ https://issues.apache.org/jira/browse/KARAF-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-2508: Fix Version/s: (was: 2.3.9) > make osgi:find-class a more useful command > -- > > Key: KARAF-2508 > URL: https://issues.apache.org/jira/browse/KARAF-2508 > Project: Karaf > Issue Type: Improvement > Components: karaf-shell >Affects Versions: 2.3.3 >Reporter: Amichai Rothman >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 4.0.0, 3.0.3, 2.4.1 > > > I recently had to track down which bundle contains a certain class, and found > the find-class command wanting. A few simple improvements would make it much > more useful: > 1. Add an --exact/-e option which doesn't automatically add asterisks at both > ends of the string. In my case I was looking for the javax.jms.Connection > class, and since the search is only on the last part of the name, this > returned all classes in all packages which have the word Connection in their > name, which added up to hundreds of results. with --exact I could look for > what I want exactly, or choose to add asterisks at one or both ends > explicitly in the search string if I wanted to. > 2. Add a --local/-l option which adds BundleWiring.LISTRESOURCES_LOCAL to the > listResources method call bitmask. With the current implementation, it > returns both bundles containing the given class name and classes that import > it from other bundles, which is useful in some cases. But with the --local > option it could show only the bundles that actually contain the class > (whether exported or not, unlike the exports command), which is far more > useful in tracking down some classloading issues. > 3. Add the bundle ID (at least) on the beginning of every printed line. This > makes it amenable to grepping (without it a grep loses all bundle > information, which is the whole point of using this command). > 4. As a somewhat more complex alternative to #3, it would be nice if you > could specify a fully qualified class name and not only the last part of the > name. The command can split the search string around periods, pass the last > part to listResources, then internally grep/match the full name. That would > make it truly flexible in finding classes. Asterisks would have to be treated > accordingly. > I think adding these options (#1-#3 are trivial implementations), or at least > some of them, would make the command extremely useful when performing > classloading diagnosis. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KARAF-2508) make osgi:find-class a more useful command
[ https://issues.apache.org/jira/browse/KARAF-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-2508: Fix Version/s: (was: 2.3.8) 2.3.9 > make osgi:find-class a more useful command > -- > > Key: KARAF-2508 > URL: https://issues.apache.org/jira/browse/KARAF-2508 > Project: Karaf > Issue Type: Improvement > Components: karaf-shell >Affects Versions: 2.3.3 >Reporter: Amichai Rothman >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 4.0.0, 3.0.3, 2.4.1, 2.3.9 > > > I recently had to track down which bundle contains a certain class, and found > the find-class command wanting. A few simple improvements would make it much > more useful: > 1. Add an --exact/-e option which doesn't automatically add asterisks at both > ends of the string. In my case I was looking for the javax.jms.Connection > class, and since the search is only on the last part of the name, this > returned all classes in all packages which have the word Connection in their > name, which added up to hundreds of results. with --exact I could look for > what I want exactly, or choose to add asterisks at one or both ends > explicitly in the search string if I wanted to. > 2. Add a --local/-l option which adds BundleWiring.LISTRESOURCES_LOCAL to the > listResources method call bitmask. With the current implementation, it > returns both bundles containing the given class name and classes that import > it from other bundles, which is useful in some cases. But with the --local > option it could show only the bundles that actually contain the class > (whether exported or not, unlike the exports command), which is far more > useful in tracking down some classloading issues. > 3. Add the bundle ID (at least) on the beginning of every printed line. This > makes it amenable to grepping (without it a grep loses all bundle > information, which is the whole point of using this command). > 4. As a somewhat more complex alternative to #3, it would be nice if you > could specify a fully qualified class name and not only the last part of the > name. The command can split the search string around periods, pass the last > part to listResources, then internally grep/match the full name. That would > make it truly flexible in finding classes. Asterisks would have to be treated > accordingly. > I think adding these options (#1-#3 are trivial implementations), or at least > some of them, would make the command extremely useful when performing > classloading diagnosis. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KARAF-2508) make osgi:find-class a more useful command
[ https://issues.apache.org/jira/browse/KARAF-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-2508: Fix Version/s: (was: 2.3.7) (was: 3.0.2) 2.3.8 3.0.3 > make osgi:find-class a more useful command > -- > > Key: KARAF-2508 > URL: https://issues.apache.org/jira/browse/KARAF-2508 > Project: Karaf > Issue Type: Improvement > Components: karaf-shell >Affects Versions: 2.3.3 >Reporter: Amichai Rothman >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 4.0.0, 3.0.3, 2.4.1, 2.3.8 > > > I recently had to track down which bundle contains a certain class, and found > the find-class command wanting. A few simple improvements would make it much > more useful: > 1. Add an --exact/-e option which doesn't automatically add asterisks at both > ends of the string. In my case I was looking for the javax.jms.Connection > class, and since the search is only on the last part of the name, this > returned all classes in all packages which have the word Connection in their > name, which added up to hundreds of results. with --exact I could look for > what I want exactly, or choose to add asterisks at one or both ends > explicitly in the search string if I wanted to. > 2. Add a --local/-l option which adds BundleWiring.LISTRESOURCES_LOCAL to the > listResources method call bitmask. With the current implementation, it > returns both bundles containing the given class name and classes that import > it from other bundles, which is useful in some cases. But with the --local > option it could show only the bundles that actually contain the class > (whether exported or not, unlike the exports command), which is far more > useful in tracking down some classloading issues. > 3. Add the bundle ID (at least) on the beginning of every printed line. This > makes it amenable to grepping (without it a grep loses all bundle > information, which is the whole point of using this command). > 4. As a somewhat more complex alternative to #3, it would be nice if you > could specify a fully qualified class name and not only the last part of the > name. The command can split the search string around periods, pass the last > part to listResources, then internally grep/match the full name. That would > make it truly flexible in finding classes. Asterisks would have to be treated > accordingly. > I think adding these options (#1-#3 are trivial implementations), or at least > some of them, would make the command extremely useful when performing > classloading diagnosis. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KARAF-2508) make osgi:find-class a more useful command
[ https://issues.apache.org/jira/browse/KARAF-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-2508: Fix Version/s: (was: 2.3.6) (was: 2.4.0) 2.3.7 2.4.1 > make osgi:find-class a more useful command > -- > > Key: KARAF-2508 > URL: https://issues.apache.org/jira/browse/KARAF-2508 > Project: Karaf > Issue Type: Improvement > Components: karaf-shell >Affects Versions: 2.3.3 >Reporter: Amichai Rothman >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 4.0.0, 3.0.2, 2.4.1, 2.3.7 > > > I recently had to track down which bundle contains a certain class, and found > the find-class command wanting. A few simple improvements would make it much > more useful: > 1. Add an --exact/-e option which doesn't automatically add asterisks at both > ends of the string. In my case I was looking for the javax.jms.Connection > class, and since the search is only on the last part of the name, this > returned all classes in all packages which have the word Connection in their > name, which added up to hundreds of results. with --exact I could look for > what I want exactly, or choose to add asterisks at one or both ends > explicitly in the search string if I wanted to. > 2. Add a --local/-l option which adds BundleWiring.LISTRESOURCES_LOCAL to the > listResources method call bitmask. With the current implementation, it > returns both bundles containing the given class name and classes that import > it from other bundles, which is useful in some cases. But with the --local > option it could show only the bundles that actually contain the class > (whether exported or not, unlike the exports command), which is far more > useful in tracking down some classloading issues. > 3. Add the bundle ID (at least) on the beginning of every printed line. This > makes it amenable to grepping (without it a grep loses all bundle > information, which is the whole point of using this command). > 4. As a somewhat more complex alternative to #3, it would be nice if you > could specify a fully qualified class name and not only the last part of the > name. The command can split the search string around periods, pass the last > part to listResources, then internally grep/match the full name. That would > make it truly flexible in finding classes. Asterisks would have to be treated > accordingly. > I think adding these options (#1-#3 are trivial implementations), or at least > some of them, would make the command extremely useful when performing > classloading diagnosis. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (KARAF-2508) make osgi:find-class a more useful command
[ https://issues.apache.org/jira/browse/KARAF-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-2508: Fix Version/s: (was: 2.3.5) (was: 3.0.1) 2.3.6 3.0.2 4.0.0 > make osgi:find-class a more useful command > -- > > Key: KARAF-2508 > URL: https://issues.apache.org/jira/browse/KARAF-2508 > Project: Karaf > Issue Type: Improvement > Components: karaf-shell >Affects Versions: 2.3.3 >Reporter: Amichai Rothman >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 2.4.0, 4.0.0, 3.0.2, 2.3.6 > > > I recently had to track down which bundle contains a certain class, and found > the find-class command wanting. A few simple improvements would make it much > more useful: > 1. Add an --exact/-e option which doesn't automatically add asterisks at both > ends of the string. In my case I was looking for the javax.jms.Connection > class, and since the search is only on the last part of the name, this > returned all classes in all packages which have the word Connection in their > name, which added up to hundreds of results. with --exact I could look for > what I want exactly, or choose to add asterisks at one or both ends > explicitly in the search string if I wanted to. > 2. Add a --local/-l option which adds BundleWiring.LISTRESOURCES_LOCAL to the > listResources method call bitmask. With the current implementation, it > returns both bundles containing the given class name and classes that import > it from other bundles, which is useful in some cases. But with the --local > option it could show only the bundles that actually contain the class > (whether exported or not, unlike the exports command), which is far more > useful in tracking down some classloading issues. > 3. Add the bundle ID (at least) on the beginning of every printed line. This > makes it amenable to grepping (without it a grep loses all bundle > information, which is the whole point of using this command). > 4. As a somewhat more complex alternative to #3, it would be nice if you > could specify a fully qualified class name and not only the last part of the > name. The command can split the search string around periods, pass the last > part to listResources, then internally grep/match the full name. That would > make it truly flexible in finding classes. Asterisks would have to be treated > accordingly. > I think adding these options (#1-#3 are trivial implementations), or at least > some of them, would make the command extremely useful when performing > classloading diagnosis. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (KARAF-2508) make osgi:find-class a more useful command
[ https://issues.apache.org/jira/browse/KARAF-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-2508: Fix Version/s: (was: 2.3.4) 2.3.5 > make osgi:find-class a more useful command > -- > > Key: KARAF-2508 > URL: https://issues.apache.org/jira/browse/KARAF-2508 > Project: Karaf > Issue Type: Improvement > Components: karaf-shell >Affects Versions: 2.3.3 >Reporter: Amichai Rothman >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 2.4.0, 3.0.1, 2.3.5 > > > I recently had to track down which bundle contains a certain class, and found > the find-class command wanting. A few simple improvements would make it much > more useful: > 1. Add an --exact/-e option which doesn't automatically add asterisks at both > ends of the string. In my case I was looking for the javax.jms.Connection > class, and since the search is only on the last part of the name, this > returned all classes in all packages which have the word Connection in their > name, which added up to hundreds of results. with --exact I could look for > what I want exactly, or choose to add asterisks at one or both ends > explicitly in the search string if I wanted to. > 2. Add a --local/-l option which adds BundleWiring.LISTRESOURCES_LOCAL to the > listResources method call bitmask. With the current implementation, it > returns both bundles containing the given class name and classes that import > it from other bundles, which is useful in some cases. But with the --local > option it could show only the bundles that actually contain the class > (whether exported or not, unlike the exports command), which is far more > useful in tracking down some classloading issues. > 3. Add the bundle ID (at least) on the beginning of every printed line. This > makes it amenable to grepping (without it a grep loses all bundle > information, which is the whole point of using this command). > 4. As a somewhat more complex alternative to #3, it would be nice if you > could specify a fully qualified class name and not only the last part of the > name. The command can split the search string around periods, pass the last > part to listResources, then internally grep/match the full name. That would > make it truly flexible in finding classes. Asterisks would have to be treated > accordingly. > I think adding these options (#1-#3 are trivial implementations), or at least > some of them, would make the command extremely useful when performing > classloading diagnosis. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (KARAF-2508) make osgi:find-class a more useful command
[ https://issues.apache.org/jira/browse/KARAF-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-2508: Fix Version/s: (was: 3.0.0) 3.0.1 > make osgi:find-class a more useful command > -- > > Key: KARAF-2508 > URL: https://issues.apache.org/jira/browse/KARAF-2508 > Project: Karaf > Issue Type: Improvement > Components: karaf-shell >Affects Versions: 2.3.3 >Reporter: Amichai Rothman >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 2.4.0, 3.0.1, 2.3.4 > > > I recently had to track down which bundle contains a certain class, and found > the find-class command wanting. A few simple improvements would make it much > more useful: > 1. Add an --exact/-e option which doesn't automatically add asterisks at both > ends of the string. In my case I was looking for the javax.jms.Connection > class, and since the search is only on the last part of the name, this > returned all classes in all packages which have the word Connection in their > name, which added up to hundreds of results. with --exact I could look for > what I want exactly, or choose to add asterisks at one or both ends > explicitly in the search string if I wanted to. > 2. Add a --local/-l option which adds BundleWiring.LISTRESOURCES_LOCAL to the > listResources method call bitmask. With the current implementation, it > returns both bundles containing the given class name and classes that import > it from other bundles, which is useful in some cases. But with the --local > option it could show only the bundles that actually contain the class > (whether exported or not, unlike the exports command), which is far more > useful in tracking down some classloading issues. > 3. Add the bundle ID (at least) on the beginning of every printed line. This > makes it amenable to grepping (without it a grep loses all bundle > information, which is the whole point of using this command). > 4. As a somewhat more complex alternative to #3, it would be nice if you > could specify a fully qualified class name and not only the last part of the > name. The command can split the search string around periods, pass the last > part to listResources, then internally grep/match the full name. That would > make it truly flexible in finding classes. Asterisks would have to be treated > accordingly. > I think adding these options (#1-#3 are trivial implementations), or at least > some of them, would make the command extremely useful when performing > classloading diagnosis. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (KARAF-2508) make osgi:find-class a more useful command
[ https://issues.apache.org/jira/browse/KARAF-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-2508: Fix Version/s: 2.3.4 3.0.0 2.4.0 > make osgi:find-class a more useful command > -- > > Key: KARAF-2508 > URL: https://issues.apache.org/jira/browse/KARAF-2508 > Project: Karaf > Issue Type: Improvement > Components: karaf-shell >Affects Versions: 2.3.3 >Reporter: Amichai Rothman >Priority: Minor > Fix For: 2.4.0, 3.0.0, 2.3.4 > > > I recently had to track down which bundle contains a certain class, and found > the find-class command wanting. A few simple improvements would make it much > more useful: > 1. Add an --exact/-e option which doesn't automatically add asterisks at both > ends of the string. In my case I was looking for the javax.jms.Connection > class, and since the search is only on the last part of the name, this > returned all classes in all packages which have the word Connection in their > name, which added up to hundreds of results. with --exact I could look for > what I want exactly, or choose to add asterisks at one or both ends > explicitly in the search string if I wanted to. > 2. Add a --local/-l option which adds BundleWiring.LISTRESOURCES_LOCAL to the > listResources method call bitmask. With the current implementation, it > returns both bundles containing the given class name and classes that import > it from other bundles, which is useful in some cases. But with the --local > option it could show only the bundles that actually contain the class > (whether exported or not, unlike the exports command), which is far more > useful in tracking down some classloading issues. > 3. Add the bundle ID (at least) on the beginning of every printed line. This > makes it amenable to grepping (without it a grep loses all bundle > information, which is the whole point of using this command). > 4. As a somewhat more complex alternative to #3, it would be nice if you > could specify a fully qualified class name and not only the last part of the > name. The command can split the search string around periods, pass the last > part to listResources, then internally grep/match the full name. That would > make it truly flexible in finding classes. Asterisks would have to be treated > accordingly. > I think adding these options (#1-#3 are trivial implementations), or at least > some of them, would make the command extremely useful when performing > classloading diagnosis. -- This message was sent by Atlassian JIRA (v6.1#6144)
