Why are some bundles in resolved state?

171 views
Skip to first unread message

Martin Naughton

unread,
May 19, 2014, 5:06:34 AM5/19/14
to ope...@googlegroups.com
Hello All,
             I am confused why some bundles are not in active state when starting a clean openhab. The start level is at 6 so that means all bundles should be started since most of them at at start level 4. The odd bundle with start level 4 is in active state but a majority of them at in resolved state. They only active when manually started. 

is there some thing i am missing? Will they be active when a bundle that relies on it requires it? 


START LEVEL 6
   ID|State      |Level|Name
    0|Active     |    0|OSGi System Bundle (3.8.2.v20130124-134944)
    1|Resolved   |    4|geronimo Javax Transaction API 1.1.1 spec (1.1.1.v201105
210645)
    2|Active     |    1|Simple Configurator (1.0.301.v20120914-163612)
    3|Resolved   |    4|Logback Classic Module (1.0.7.v20121108-1250)
    4|Resolved   |    4|Logback Core Module (1.0.7.v20121108-1250)
    5|Resolved   |    1|Logback Native SLF4J Logger Module (1.0.7.v20121108-1250
)
    6|Resolved   |    4|Guava: Google Core Libraries for Java 1.5 (10.0.1.v20120
3051515)
    7|Resolved   |    4|Google Guice (No AOP) (3.0.0.v201203062045)
    9|Starting   |    4|International Components for Unicode for Java (ICU4J) Re
placement plug-in (50.1.1.v201304230130)
   10|Resolved   |    4|Apache Geronimo Activation Plug-in (1.1.0.v201211130549)
   11|Resolved   |    4|javax.annotation Bundle (1.1.0.v201209060031)
   12|Resolved   |    4|Atinject Dependency Injection Annotations (1.0.0.v200910
30)
   13|Resolved   |    4|Javax Mail Plug-in (1.4.0.v201005080615)
   14|Resolved   |    4|Servlet API Bundle (3.0.0.v201112011016)
   15|Resolved   |    4|JAXP XML (1.3.4.v201005080400)
   16|Resolved   |    4|XML Binding for Java (2.2.0.v201105210648)
   17|Resolved   |    4|Java XML Streaming API (1.0.1.v201004272200

Kai Kreuzer

unread,
May 19, 2014, 5:10:09 AM5/19/14
to ope...@googlegroups.com
Hi Martin,

In general, openHAB does not automatically start all bundles, but just the things that it needs to be started right away.
All other dependencies stay in resolved state until some code actively requires them.

For the logback bundles in your list, there is another reason: These are actually not bundles, but fragments and fragments cannot be started at all as they only contribute to their host bundle.

Best regards,
Kai


--
You received this message because you are subscribed to the Google Groups "openhab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.
For more options, visit https://groups.google.com/d/optout.

Martin Naughton

unread,
May 19, 2014, 6:53:16 AM5/19/14
to ope...@googlegroups.com
Hello Kai,
             Ok so you are not using the start level framework. Thought since the start level was at 6 that everything would be active since most of the default to 4. 

Trying to reduce the memory by taking out bundles. I had an idea to use the start level to control all the bundle just like init controls the start level for linux.

start level 2 could be the minimum you need to get a basic open hab working. It would include the rules engine etc. IT would not include starting jetty or the ui. you would have to go to level 5 say to start jetty or the ui. Then level 6 could be all plugins are operational because you have the hardware to support all the runtime plugins?

Example make sense? You might of though of that idea before.

              



Martin 

Kai Kreuzer

unread,
May 22, 2014, 3:33:27 PM5/22/14
to ope...@googlegroups.com
Hi Martin,

Example make sense? You might of though of that idea before.

Makes sense, but I so far never thought about using OSGi start levels for this modularization. It is an interesting thought, though.

What I had in mind instead, was a modular packaging where more or less everything becomes an „addon“, which you can choose to install or not.
This would be especially interesting for a minimal system that only runs one binding and sends all events to some other openHAB instance through MQTT. I guess your use case is pretty similar to this. The good thing about this solution would be that you do not have to have the full system on your file system at all. The difficult part is that it requires a lot of packaging, which is not straight-forward either.

Anyhow, I do not plan to put any efforts on this in openHAB 1.x, but will try to incorporate such ideas in Eclipse SmartHome and hence openHAB 2.0.

Best regards,
Kai


Reply all
Reply to author
Forward
0 new messages