How to activate bundles at boot time

[ulrichromahn]

I have added a larger number of bundles to the standalone.xml as capabilities in the OSGi subsystem. Those bundles contain a set of services needed for my applications to be deployed onto JBoss AS.

When I start JBoss, all bundles get successfully resolved (from my local Maven repo). However, when I check the status in the JBoss Console, except for the system.bundle, none of the other bundles are in the ACTIVE state.

However, I need some way to automatically activate bundles at boot time of JBoss AS so I can run some initialization of OSGi services at boot time of JBoss in the bundle activator.

Is there an easy way to do this?

P.S. I am currently testing JBoss AS 7.2.1.Alpha1.SNAPSHOT (yesterday's daily build)

[ulrichromahn]

I get to reply to my own question above...

I just figured out, that by default all bundles defined as capabilities in the config xml are supposed to be started, if...

...ALL of them could be resolved!

The issue, however, is the following: if one bundle could not be resolved, i.e. it is only loaded but has some unresolved dependencies, none of the other bundles are started!

I would consider this a bug since there may be many bundles that are completely unrelated to the unresolved bundle which could and should be started!

I acually may create a JIRA for this unless someone tells me that this is not a bug until Monday.

[thomas.diesler]

The idea is that the bootstrap configuration must be valid, otherwise the Framework cannot reach it's ACTIVE state. So any capability that you configure must resolve for the subsystem to startup properly.

We might still need to do something about the behaviour that you describe - the log should be clear about what is happening and the subsystem should end up in a defined state (i.e. Framework creaed but not initialized).

[ulrichromahn]

Thomas,

thank you for responding. However, I need to disagree with your proposed approach here.

I think the bundle activation during boot in JBoss OSGi is not as one would expect.

The specification is pretty clear about how to resolve bundles and what defines their validity. All of this should be correctly implemented in Apache Felix which JBoss OSGi is using. However, the specificaion is slient on the fact what should be done when a single bundle could not completely be resolved.

In the case of JBoss, it is chosen to not activate any bundle unless *all* bundles could be resolved and are deemed valid. This behavior is completely different from other runtime environments, such as Apache Karaf or Eclipse, where the bundles still get activated, even if one bundle could not be resolved.

So, instead, during bootstrap, JBoss OSGi should go through all bundles and try to resolve and validate them. If they are valid, i.e. all *required* imports could be resolved, it should invoke the start method and hence activate the bundle. If a bundle could not be completely resolved, then it should not be started.

Just to mention another use case illustrating the current issue I have with JBoss OSGi: let's assume JBoss is booted and the OSGi subsystem active with a bunch of active bundles. Someone now tries to load a bundle that cannot be completely resolved? How does this get handled? Does JBoss now stop all other running bundles? I don't think so, and this is how it should be handled at boot time as well.

By the way: there is another issue with JBoss OSGi, which may be a real bug: when a bundle has an optional dependency, it should be listed in the "resolved" state and not just "loaded".

Try to add the following bundle to you resource: "org.ops4j.pax.web:pax-web-extender-whiteboard:2.1.0"

It has an optional dependency to the package "org.ops4j.pax.web.service,version=2.1.0" provided by "org.ops4j.pax.web:pax-web-runtime:2.1.0", and you'll see that it does not get listed in the resolved state and that I cannot activate it without adding the "optional" bundle, although this should be possible.

[thomas.diesler]

Generally, a framework does not have a notion of initial capabilities - this is something we add in the context of AS7. There is a notion of persistent bundles on framework restart, but this is not what we are talking about here, right?

If a bundle could not be completely resolved, then it should not be started.

This is the behaviour you get when you deploy a bundle.

I consider the initial capabilities as part of the server configuration, so IMHO it is a invalid to confige a capability that does not resolve. Initial capabilities are processed before persistent bundles which is supposed to bring the environment to a known state before any user bundle is resoved.

Please monitor https://issues.jboss.org/browse/AS7-5831

Try to add the following bundle to you resource: "org.ops4j.pax.web:pax-web-extender-whiteboard:2.1.0"

We are providing webapp functionallity natively via JBossWeb. That this cannot resolve may be unrelated to the optional imort. What does the debug log say? We are talking in the context of the latest build from https://github.com/jbossas/jboss-as, right?

[ulrichromahn]

I think I start to understand your reasoning behing this behaviour.

What you are saying is that bundles defined as "capabilities" in the standalone.xml (or domain.xml) should be considered "initial core capabilities" which should all resolve (and hence properly start) at boot time. If one of those capabilities fails, you do not want the entire OSGi subsystem to be active.

I guess, I start to buy into that...

Regarding the bundle "org.ops4j.pax.web:pax-web-extender-whiteboard:2.1.0" mentioned before, this is just meant to be an example containing an optional dependency. If you deploy this, it will refuse to resolve and subsequently start because of an alleged "missing dependency", although the missing one is optional. This works correctly in Apache Karaf, e.g. the bundle gets loaded and I can activate it and this is the behavior I would expect from JBoss.

I started monitoring the JIRA you created regarding the logging - thank you for that.

Finally, yes we are talking about the latest build from Github (which I have cloned and are hacking here).

[thomas.diesler]

I cannot reproduce this any more

13:15:27,734 INFO  [org.jboss.osgi.framework] (MSC service thread 1-1) JBOSGI011011: Starting bundles for start level: 1

13:15:27,747 INFO  [org.jboss.osgi.framework] (MSC service thread 1-1) JBOSGI011002: Bundle started: org.jboss.as.osgi.http:0.0.0

13:15:27,864 INFO  [org.jboss.osgi.framework] (MSC service thread 1-1) JBOSGI011002: Bundle started: org.apache.felix.log:1.0.0

13:15:27,897 INFO  [org.jboss.osgi.framework] (MSC service thread 1-1) JBOSGI011002: Bundle started: jboss-osgi-logging:1.0.0

13:15:27,964 INFO  [org.jboss.osgi.framework] (MSC service thread 1-1) JBOSGI011002: Bundle started: org.apache.felix.configadmin:1.2.8

13:15:27,986 INFO  [org.jboss.osgi.framework] (MSC service thread 1-1) JBOSGI011002: Bundle started: jboss-as-osgi-configadmin:7.2.0.Alpha1-SNAPSHOT

13:15:28,057 WARN  [org.ops4j.pax.web.extender.whiteboard.internal.Activator] (MSC service thread 1-1) Filters tracking has been disabled as the WebContainer (Pax Web) is not available

13:15:28,057 WARN  [org.ops4j.pax.web.extender.whiteboard.internal.Activator] (MSC service thread 1-1) Event Listeners tracking has been disabled as the WebContainer (Pax Web) is not available

13:15:28,058 WARN  [org.ops4j.pax.web.extender.whiteboard.internal.Activator] (MSC service thread 1-1) JSP mappings tracking has been disabled as the WebContainer (Pax Web) is not available

13:15:28,060 INFO  [org.jboss.osgi.framework] (MSC service thread 1-1) JBOSGI011002: Bundle started: org.ops4j.pax.web.pax-web-extender-whiteboard:2.1.0

13:15:28,068 INFO  [org.jboss.osgi.framework] (MSC service thread 1-1) JBOSGI011000: OSGi Framework started

Perhaps it was related to https://issues.jboss.org/browse/AS7-5803

[ulrichromahn]

I tried it myself again with the latest build from master and I can't reproduce it myself. Could be something that was fixed with a recent changes in master.

In addition, it also does not seem to be present in 7.1.3.Final (which I built myself using the tagged source).

[ejroberts]

Does that mean enterprise should not be shipped with JBoss AS then ?

[thomas.diesler]

The org.osgi.enterprise-4.2.0.jar bundle should not be deployed. It is good practise that every implementation of a given API also comes with the API it implements. The resolver has a preference on hte higest version of an API. This can lead to resulution errors if the implementation cannot substitute its API with that in enterprise.

[ejroberts]

Understood. Thanks Thomas