RE: [equinox-dev] Logging, exceptions, and the UserAdmin service

["Ron Baldwin" <Ron.Baldwin@xxxxxxxxxxxxxxx>]

Hi BJ,

> > If this is by design (which I assume it 
> > is), then I would suggest that exceptions always be sent to the log 
> > even if they also go to the console.  Does this sound reasonable? 
> > If so, I'll log a enhancement request.
> 
> I suppose, but really the console is generally manned by someone 
> intelligent (or at least a human :-) who has typed in some 
> command and 
> then wants a success or failure indication.
> 
> Again the framework does not send the exception to the log. 
> The bundle 
> lifecycle methods throw an exception and the receiver has to 
> decide what 
> to do. The console implementation could decide to dump all 
> exceptions it 
> encountered into the log as well as display them.
> 
> But how truly useful is this?

As someone who is still learning the way the various pieces of the
framework fit together, it seemed to make sense that significant events
at the framework level (like exceptions when bundles are starting and
stopping) should always go to the log regardless of where else they
might be displayed.  For example, if someone did something from the
console and an exception occurred, an admin who later looked at the logs
could see that the problem occurred.  This could be especially useful if
the exception caused a rippling effect as it could help identify the
cause of other problems that did get logged.

But at this point, I don't have enough experience with OSGi to have a
strong opinion one way or the other--which is why I was asking for
opinions from those with more experience than I.  :-)
 
> > 
> > Also, is there an easy way to get the framework to stop a bundle to 
> > verify that exceptions in the BundleActivator.stop() go to the log? 
> > I've tried programmatically stopping a bundle from another bundle, 
> > but then you end having to handle the exception yourself instead of 
> > the framework handling it.
> 
> Try using StartLevel. By having some bundle at start level 100 for 
> example, when you change the start level to 99, the framework 
> must stop the bundle.

This worked great.  Exceptions thrown when the framework stops a bundle
do indeed go to the log.