[sip-comm-dev] Question regarding Felix properties for SC


#1

Dear all,

last week I did some cleanup of manifest files. While looking at the files
I also checked the runtime properties (Felix runtime properties). There I
noticed a strange ordering of the auto start stuff. Here the order

...

felix.auto.start.42= \
reference:file:sc-bundles/credentialsstorage.jar \
reference:file:sc-bundles/defaultresources.jar

felix.auto.start.45= \
reference:file:sc-bundles/ui-service.jar \

...

What is strange here: the credentialstorage manifest imports packages that are
contained in the ui-service bundle but the ui-service is loaded later.

The credentialstorage is auto-started, thus Felix should check if the ui-service
packages are available (at least this is my understanding of the OSGi mechanics :wink: ).
Can somebody shed some light on this? Thanks.

Best regards,
Werner

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Dear all,

last week I did some cleanup of manifest files. While looking at the files
I also checked the runtime properties (Felix runtime properties). There I
noticed a strange ordering of the auto start stuff. Here the order

...

felix.auto.start.42= \
  reference:file:sc-bundles/credentialsstorage.jar \
  reference:file:sc-bundles/defaultresources.jar

felix.auto.start.45= \
  reference:file:sc-bundles/ui-service.jar \

...

What is strange here: the credentialstorage manifest imports packages that are
contained in the ui-service bundle but the ui-service is loaded later.

The credentialstorage is auto-started, thus Felix should check if the ui-service
packages are available (at least this is my understanding of the OSGi mechanics :wink: ).
Can somebody shed some light on this? Thanks.

The Felix launcher's processing of the auto properties first performs an install on all bundles, then a start (i.e., it is two pass). It does this precisely to avoid ordering issues on startup.

-> richard

···

On 10/24/10 3:22, Werner Dittmann wrote:

Best regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Richard,

thanks a lot - that also explains most of the trace messages I see
during startup of Felix on Android (some traces while reading a file,
in this case loading of Felix bundles, just warnings) before the
services start.

Best regards,
Werner

···

Am 25.10.2010 03:10, schrieb Richard S. Hall:

On 10/24/10 3:22, Werner Dittmann wrote:

Dear all,

last week I did some cleanup of manifest files. While looking at the
files
I also checked the runtime properties (Felix runtime properties). There I
noticed a strange ordering of the auto start stuff. Here the order

...

felix.auto.start.42= \
  reference:file:sc-bundles/credentialsstorage.jar \
  reference:file:sc-bundles/defaultresources.jar

felix.auto.start.45= \
  reference:file:sc-bundles/ui-service.jar \

...

What is strange here: the credentialstorage manifest imports packages
that are
contained in the ui-service bundle but the ui-service is loaded later.

The credentialstorage is auto-started, thus Felix should check if the
ui-service
packages are available (at least this is my understanding of the OSGi
mechanics :wink: ).
Can somebody shed some light on this? Thanks.

The Felix launcher's processing of the auto properties first performs an
install on all bundles, then a start (i.e., it is two pass). It does
this precisely to avoid ordering issues on startup.

-> richard

Best regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net