Hello all,
thanks for discussing this further and all those helpful information
and pointers.
@Peter yes, I agree. But how does it look like for a OSGi bundle? If
there is no generic mechanism and no "upper-most" platform hook, then I
would need to touch every single try/catch-block. That's not
comfortable.
@Siamak in this special case, which OSGi lifecycle methods would be
candidates for being pointcuts?
The ThreadGroup approach as well as the embedded runtime approaches are
very interesting. That gives a path to catch all unchecked exceptions,
not caught somewhere else. Many other exception cases remain unaddressed
though. Using the threadGroup approach: doesn't that conflict with other
threads (swt ui thread e.g.), and the OSGi runtime itself, e.g. while
using OSGi services?
@Craig thanks.
Thank you.
Regards
Michael
Am Sonntag, den 13.03.2011, 00:54 +0100 schrieb Craig Phillips
<[email protected]>:
Re: Embedded OSGi runtime... I never run OSGi other than embedded,
within a larger framework, which typically provides the distributed
capability(ies), along with [greater] configuration. I don't believe
I
do a "waitForStop()" though (I'll have to check).
However, with that said, I'm not sure if the outer try/catch works,
but it's been a while since I had to track down an uncaught
exception.
The threadGroup looks interesting.
-------------------------
FROM: [email protected] [[email protected]]
on behalf of Siamak Haschemi [[email protected]]
SENT: Saturday, March 12, 2011 11:33 AM
TO: OSGi Developer Mail List
SUBJECT: Re: [osgi-dev] exception aggregation for error reporting?
Hi Michael,
although you mentioned that you don't want to use AOP, it seems to be
the best way for me. And since OSGi has the clear Lifecycle, you
could
define your pointcuts based on the OSGi API methods. You can further
put all your Java-Threads in a ThreadGroup, and overwrite
ThreadGroup.uncaughtException(Thread, Throwable). Finally, an
interesting point is to embed an OSGi Runtime
(http://njbartlett.name/2011/03/07/embedding-osgi.html [1]) and
surround the start of the OSGi framwork by a try-catch block:
try {
framework.waitForStop(0);
} catch(Exception e) {
// one place to catch them all
} finally {
System.exit(0);
}
And yes, the only recovery strategy here would be restarting the
framework.
In summary, Peter is right, it depends.
Cheers,
Siamak
Am 12.03.2011 um 14:31 schrieb Peter Kriens:
Well, this was the central tenet of my blog. Never catch exceptions
when you cannot do something really useful with them (like 99% of the
cases) and let them bubble up to the highest level. At the highest
level you usually have a clear way to report back what went wrong.
E.g. before you call a servlet, etc.
Unfortunately, there is no generic mechanism that I know off and I
expect this is not really possible because it depends.
Kind regards,
Peter Kriens
On 12 mrt 2011, at 09:26, Michael Hüttermann wrote:
Hi Peter,
yes, my question looks strongly like a follow-up to your blog post.
I want to trace/report all exceptions, and I neither want to use AOP,
nor do I want to add additional boiler plate code to every single
try/catch-block. Rather I'm looking for a central place where I'm
informed about all "exceptional behavior". If I would propagate all
exceptions (not catching them at all, as you've written in your
blog),
what would be the central, upper-most location in an OSGi bundle to
catch all exceptions then?
Thank you.
Regards
Michael
Am Freitag, den 11.03.2011, 18:50 +0100 schrieb Peter Kriens :
I am not sure I understand the question, in Java the exceptions
are
thrown to callers so a good design allows the top level to
centralize
handling exceptions (see my blog about Exception Hygiene).
However,
this is kind of orthogonal to OSGi.
Kind regards,
Peter Kriens
On 11 mrt 2011, at 10:21, Michael Hüttermann wrote:
Hello,
I want to aggregate all (or at least a subset of) possible
exceptions in my bundles for error reporting. I'm using bundles that
directly use classes of other bundles as well as services. What is
the
recommended design for this? Or is there any specific feature that
could help here? Can I propagate all exceptions to a central place to
manage them there centrally? (maybe an Activator can help here, but
how?)
Thank you.
Regards
Michael
_______________________________________________
OSGi Developer Mail List
[email protected] [3]
https://mail.osgi.org/mailman/listinfo/osgi-dev [4]
_______________________________________________
OSGi Developer Mail List
[email protected] [5]
https://mail.osgi.org/mailman/listinfo/osgi-dev [6]
_______________________________________________
OSGi Developer Mail List
[email protected] [7]
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Dipl. Inf. (FH) Siamak Haschemi
Humboldt-Universität zu Berlin
Dept. of Computer Science
Room: III.417
Rudower Chaussee 25
12489 Berlin, Germany
+49 30 2093 3121 (phone)
+49 30 2093 3112 (fax)
[email protected] [8]
Website: http://informatik.hu-berlin.de/~haschemi [9]
Private Website: http://www.haschemi.org [10]
Xing profile: Siamak_Haschemi
Skype: siamak.haschemi
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
