Felix Meschberger wrote:
Am Mittwoch, den 09.01.2008, 07:35 +0100 schrieb Carsten Ziegeler:
Felix Meschberger wrote:
Hi Carsten,
Am Dienstag, den 08.01.2008, 07:55 +0100 schrieb Carsten Ziegeler:
It's difficult to tell what is going wrong from here, but one possible
problem could be the startup order of the bundles. I've put most of the
"org.apache.felix.*" bundles into the WEB-INF/resources/corebundles
directory which ensures that these bundles are loaded before the bundles
of WEB-INF/resources/bundles.
Except for one case (see below), startup order of bundles MUST not make
a difference. Otherwise there is an issue with the bundles having
problems.
One example might be a registry class (like the now fixed
SlingServletResolver) which does not cope correctly with servlets
registered before the registry class (component) is activated: Here
these servlets are not handled correctly and hence not seen. This is a
problem of the registry and not of the start order.
I think there are more potential problems - one of them being SCR. If
bundles requiring SCR are started before SCR, the services are either
not registerd or not satisfied. I think I had some problems here as the
bundle was started but not really working. And then other bundles
started to use the services which then failt.
Correct. As long as SCR is not running, components (and services
implemented as components) are not active. BUT: Any service must be
prepared to act upon the situation, that a service is missing. This is
part of the OSGi service design AFAIUI.
As soon as SCR was up and running everything was fine.
And I think there were similar issues with the configadmin service. So I
put all bundles implementing stuff from the OSGi compendium into the
corebundles section which prevents potential problems.
Similar case here: A service requiring configuraiton must be prepared to
the situation, that the ConfigurationAdmin is not active and should act
upon it as appropriate: Either use default settings or wait for real
configuration to arrive.
Yes, that's right - so I guess we have to check our code base for these
cases.
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]