Great idea. We should use the bundle start level to filter what we display on the screen. By default it is equal to 50 but that means that the client must add it in its project bundles and that we add it in the camel, karaf, servicemix bundles too. Otherwise, the list will not be filtered
In this case we could provide as a parameter the bundle start level as an option : osgi:list -l 50 l = level from which we would like to display the bundles or maybe osgi:list -l 50-100 to be able to display range of bundles Regards Charles On Fri, Aug 13, 2010 at 1:17 PM, Adrian Trenaman <trena...@progress.com>wrote: > Hi Charles, > > I think these are great ideas. Let me add another: we need to modify Karaf > so that when you do an osgi:list, you see only the application bundles, not > the system bundles. We should only see the system/infrastructure bundles if > we do something like 'osgi:list -s' or 'osgi:list -v'. There's very little > value for most users that when they do 'osgi:list' they get between 80 and > 170 bundles listed, flying up their screen. Less is more: we should expose > the interesting things easily, and allow users to see the background > 'under-the-hood' stuff only when they like and when they're ready. > > Thoughts? > Ade. > > > On 13/08/2010 09:54, Charles Moulliard wrote: > >> Hi, >> >> OSGI is an amazing world for architect and developers. They bring a new >> concept in the development life cycle compare to monolithic J2EE application >> and their WAR / EAR. The "modularity" provides advantages and of course >> disadvantages like any other specification/technology. >> >> To improve OSGI projects, I would like to suggest that in the future we do >> two things : >> >> 1) Bundle Start Level >> I suggest that we add the start bundle value for our camel components in >> the feature xml file. This feature is available since Karaf 2.0. So we can >> group what I call infrastructure bundles together and dissociate them from >> project bundles. In this way, they will be activated and started before the >> bundle projects. Using bundle start level is interesting but not enough in >> some cases. So I suggest to do the following for by example HTTP, CXF >> components >> >> 2) Declarative Service >> I suggest that we expose some services like CXF, HTTP, Servlet to allow a >> project or camel to use OSGI Declarative Service ( >> http://felix.apache.org/site/apache-felix-service-component-runtime.html). >> In this case, the project can react or be informed if by example jetty http >> or cxf is not up and running. In the meantime, the infrastructure team or >> the development project has no idea about the origin of the issue when web >> service (configured through a camel route using cxf:bean) is not answering. >> Is it because the bundles of cxf are not yet started or because the http >> service of jetty is not running !! >> >> I'm pretty sure that these suggestions will improve our ServiceMix >> platform and will help architect to design more professional solutions for >> their clients. >> >> What do you think about that ? >> >> Kind regards, >> >> Charles Moulliard >> >> Senior Enterprise Architect (J2EE, .NET, SOA) >> Apache Camel - Karaf - ServiceMix Committer >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Blog : http://cmoulliard.blogspot.com | Twitter : >> http://twitter.com/cmoulliard >> Linkedin : http://www.linkedin.com/in/charlesmoulliard | Skype: >> cmoulliard >> >
