1.First of all, you implementation asssume bundle start sequence isn't a good practice in OSGi world.
2. I can't understand what the system bundle you mean here? Actually the system bundle in OSGi world means the bundle with bundle id 0, it's the OSGi framework core implementation, it's always started at first place. Also we specify other importance service(like log, blueprint, etc) bundles start level in $SMX_HOME/etc/startup.properties, the start level are all below 60.
3. For other bundles, the startlevel are all 60, but I don't think they are system bundle(nor important services need get start early)
4. You mentioned your bundle actually depend on a "System bundle", can you explain how it depend? If it import package from other "System bundle", it won't started before that "system bundle" get started, so shouldn't be a problem at all. It's actually how OSGi works. If your bundle just assume(but no real dependency) some other bundles need start first, honestly it's wrong in OSGi world, you should avoid it.
5. A work around I can come up with is if your bundle need assume some other "System bundle" start first, you can try to add other "System bundle" as Required-Bundle for your bundle, again, it's not good at all.
First of all, to clarify, by "system bundles", I mean the bundles with start level 60 that are installed by default by ESB container, not that System Bundle with ID 0. sorry if this has caused confusion.
From time to time, I can see the following Exception when Servicemix starts up, but it doesn't appear every time. I understand this may be because my bundle depends on some "system installed bundle" but it is started after mine. But I have found no way of identifying which bundle that should be, so I hoped my bundles can be started after all "system bundles" have been started up. If you can help me with what bundle I should specify as "Require-Bundle", it would be great.
You can see from the Exception, I have a CXF WS client to send requests.
Exception in thread "Thread-12" javax.xml.ws.spi.FactoryFinder$ConfigurationError: Provider org.apache.axis2.jaxws.spi.Provider not found
Anyway, I don't think ESB should treat preinstalled bundles and those bundles in deploy directory in the same way. I know bundles are started up in the order of start level, and the order is indeterminate for bundles on the same start level. So there should be some way to let my own bundles start after all system installed bundles, like giving my own bundles higher start levels (like 61, 62).
Thanks for your time...
Well, about the org.apache.axis2.jaxws.spi.Provider not found, it's a known camel bug, and already get fixed.
Copy the solution I metioned from previous discussion
I just provide patch for CAMEL-2528 which should fix this issue.
The workaround currently is that you edit
Again, in OSGi world, you shouldn't assume bundle start sequence, you can use Import-Package to explicitly add dependency between bundles, which guarantee the bundle start sequence. So I don't think we need provide a way to specify customer bundle start level(actually we have if you specify your bundle in startup.properties, but this is used for key services which really need start at very first place).
I saw your post about this before, but, since I don't use camel at all, I don't understand why that would fix the issue.
But I just now tried to add "META-INF.services" to Import-Package header, and seems it works!
I now understand that Import-Package is the correct way to specify bundle dependencies, rather than Require-Bundle. I assume ESB thinks Require-Bundle is satisfied as long as the required bundle and the bundle that requires it are on the same start level. For example, one of my own bundles requires a system installed bundle but both of them have start level of 60, then, when ESB startup logic goes up to this start level, it says, OK, your required bundle is there! but it doesn't guarantee the required one will get started completely before the requiring one -- since they are on the same start level, the order is indeterminate. But what really matters is the Import-Package header. Only when the package containing the required package has started up, can the bundle importing the package start up.
I'm not sure if my understanding is correct, but it's what I got up to now.
As we install some camel feature by default, so when you start smx, some camel feature already get involved, the problem is that camel feature introduce a invalid jaxws-api bundle. So even you are not explicitly use camel feature, actually they are there already.
I understand. but I'm using 220.127.116.11. The file you mentioned is not there.