Hi - thanks for replying, Richard!
On 03/17/2015 01:37 PM, Richard S. Hall wrote:
On 3/17/15 04:34 , Anders Engström wrote:
Hi!
I'm deploying bundles at runtime in a Felix container and was expecting
the container to generate a FrameworkEvent (of type ERROR) if a call to
`Bundle#start()` fails with an exception.
[snip]
Is this by design - or should a failure to start a bundle trigger a
FrameworkEvent.ERROR?
I don't believe the specification indicates that a framework event is fired in
this case, does it?
Yupp - you're correct.. Looks like none of the `Bundle` methods triggers
FrameworkEvents. I guess it makes sense since a failing bundle isn't
really an issue with "the framework".
Alright - so Felix behaves as expected. Any suggestions for how to solve
my problem? :)
Some context: I'm writing an integration test that verifies that a set
of bundles can be cleanly deployed into our container. My assumption
was that I could check if there are any failure by listening to
Framework events and fail the test if there are any ERRORS.
Actually - I'm deploying a set of bundles from an ESA (sub-system
bundle) installed by a custom FileInstall ArtifactListener. I don't
(_want to_) know which bundles will be installed -- I basically only
want to check that there are no errors.
Here are some idea - any additional suggestions are welcome:
- Check that one or more 'known bundles' gets installed (this is what I
do now).
- Hack another custom FileInstall Artifact Listener that is published
in the OSGi container. The ArtifactListener would delegate to the
'real' ArtifactListener but catch any exception and fail the test.
- Install a (Synchronous) BundleListener that checks for bundles that
are INSTALLED/STARTING and then goes to STOPPED (without being STARTED). This
would indicate that there was an error starting the bundle.
- Hack my custom Artifact Listener to do some custom notification when
deploying (and failing) subsystem bundles. Maybe using the Event Admin
or by calling custom (whiteboard style) listeners.
Best regards //Anders
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
