>>>>> Steinar Bang <[email protected]>:
> Alternatively: is there a way to set the run level of a feature you
> depend on?
> If so, then my liquibase feature could just depend on the karaf spifly
> feature and set its run-level to be 40.
> And I could simplify the liquibase-karaf-feature even more.
I tried two things.
First (with no success), I tried setting start-level on the feature
dependency in src/main/feature/feature.xml (the template feature file)
<feature name="liquibase-core" start-level="${liquibase-core.start.level}"
version="${liquibase.version}">
<feature>aries-proxy</feature>
<feature start-level="${liquibase-core.start.level}">spifly</feature>
</feature>
That didn't work. The start-level attribute was stripped from
target/feature/feature.xml
Then some success: I set prerequisite="true" on the feature dependency.
<feature name="liquibase-core" start-level="${liquibase-core.start.level}"
version="${liquibase.version}">
<feature>aries-proxy</feature>
<feature prerequisite="true">spifly</feature>
</feature>
Then liquibase ran fine on initial feature install.
But spifly was still running on level 80:
karaf@root()> bundle:list -t 35 | grep -i spi
62 │ Active │ 80 │ 1.3.7 │ Apache Aries SPI Fly Dynamic
Weaving Bundle
karaf@root()>
Which meant that it probably wouldn't work on a karaf restart (and it
didn't).
To put it simply: all liquibase SPI services needs to be activated when
the first DataSource created by jdbc-config arrives.
And jdbc-config is running on level 80:
karaf@root()> bundle:list -t 34 | grep -i "jdbc config"
126 │ Active │ 80 │ 1.5.7 │ OPS4J Pax JDBC Config
karaf@root()>
(So far I have one workaround: install spifly 1.3.6 as a bundle on
start-level=40)
(then it doesn't matter that something else loads spifly 1.3.7 on
start-level=80, it isn't used by liquibase)
