0

I had a bundle deployed in an Apache Felix (Sling, in fact) host. The bundle contained some configurable elements, and its version was 2.0.

I have updated the bundle to v2.0.1 for some small code changes, and now the bundle will not pick up its configuration correctly - it remains at the defaults set in code rather than picking up the values configured in the Felix Web Console.

There is an error message in the log: "[Configuration Updater] org.apache.felix.scr Cannot use configuration pid=com.mypackage.MyClass for bundle inputstream:my-bundle-2.0.1.jar because it belongs to bundle inputstream:my-bundle-1.0.jar" which sounds like the cause of the issue.

However:

  1. I can't edit the inputstream value through the web interface - only by stopping the server, editing the config file manually, and restarting. Surely when I update the bundle, the config should be updated too?

  2. Although the inputstream specifies v1.0, the bundle did not have a problem when it was upgraded to v2.0. What's made the difference here?

  3. I have done the same thing (though perhaps not exactly!) on two servers, and one server seems to have the config specify inputstream=v2.0 (and the bundle at v2.0.1) and it works fine. What caused inputstream version to update on this server? (Presumably the same as the answer to 2 - I imagine it'll depend exactly which steps in the process have been executed and in what order.)

Any advice gratefully received - I haven't been able to find any documentation that gives instructions or troubleshooting suggestions for administering bundles through the Felix Web Console.

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
Nick Golding
  • 53
  • 1
  • 6
  • How did you first install the bundle and how was it updated? – Robert Munteanu May 28 '12 at 15:10
  • I think I installed it via the Felix web console (Install / Update; browse to .jar file; check "Start Bundle"; click Ok) and I definitely updated it that way. However, it's possible I'm misremembering, as the original install was a while ago now. I may have installed it using the maven sling plugin. – Nick Golding May 29 '12 at 08:24

1 Answers1

0

If at all possible, I would simply stop and remove the bundle altogether and install it using Sling , e.g. with the maven-sling-plugin or dropping it in the /apps/myapp/install folder using WebDAV .

I find it easiest to be consistent this way and the installation is nicely automated and it handles bundle upgrades properly.

Robert Munteanu
  • 67,031
  • 36
  • 206
  • 278
  • 1
    Thanks. So are you suggesting that the web console doesn't handle bundle upgrades properly? (My experience is that the maven-sling-plugin is pretty unreliable too.) – Nick Golding May 29 '12 at 15:25
  • @NickGolding - I'm just saying that it's much simpler to have one way of doing things and the maven-sling-plugin is the one I prefer. – Robert Munteanu May 29 '12 at 19:05
  • Ok, thanks. The problem I've had with the plugin is that because it's done with a "mvn install", it rebuilds the bundle each time it installs to a new server - which means the bundle that gets installed on the live servers is not the same as the bundle that was tested, for example. Occasionally this has introduced small changes (despite no code changes!) that have broken the bundle - so I'm a little reluctant to use that, but perhaps I'll give it another go. – Nick Golding May 30 '12 at 12:29
  • By itself the install goal does not repackage the jar file , it just looks for it in a well-known location, see http://sling.apache.org/site/sling.html#Sling-install for details. Perhaps you're binding it to the install phase. You can simply run mvn sling:install and an existing jar is deployed. – Robert Munteanu May 30 '12 at 12:36
  • Ah, that's interesting. I'll try that and see if it works better. Thanks! – Nick Golding May 31 '12 at 08:44