The OSGi/camel registry uses OSGi services but not bundle that wiring to find the components (each camel component automatically registers a ComponentProvider service in the OSGi registry). When looking up a service and when there are multiple matches available, the one with the highest ranking is picked up and in case of a tie, the one with the lowest service id (i.e. the one registered first). That's the default OSGi behaviour (see http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/BundleContext.html#getServiceReference(java.lang.String) ).

As a result, if we have two versions of the same components co-exists in the container, it was always the older component was picked up by application bundle unless the older version component was uninstalled.

This can obviously be changed by doing a custom sort on all references instead of delegating the OSGi framework for that. For instance, we could improve either the registration of components (in camel-core) or the lookup (in camel-osgi-core) on the OSGi service or both if needed.

Two solutions:
1. stop/restart older component bundle and then restart application bundle. It will make service id of the older component to be higher so after restarting, the application bundle will be able to pick up the newer version of the component. However, it is only transient since after restarting of the container, the most likely that the older component bundle will get a lower service id again. Therefore, we might have to use start-level to fix it.
So it is not an elegant solution.

2. an improvement on either the registration of components (in camel-core) or the lookup (in camel-osgi-core) or both if needed just as explained in this JIRA.
There are a lot of cases where the user might want to have both versions of the camel components co-exists in the container and use both for backward compatibility or flexibility purposes. Therefore, we might need a flexible registration and lookup of OSGi service for picking up a camel component from different application bundles.