RE: [osgi-dev] exception aggregation for error reporting?
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
lcphill...@praxiseng.com:
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: osgi-dev-boun...@mail.osgi.org [osgi-dev-boun...@mail.osgi.org]
on behalf of Siamak Haschemi [hasch...@informatik.hu-berlin.de]
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
osgi-dev@mail.osgi.org [3]
https://mail.osgi.org/mailman/listinfo/osgi-dev [4]
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org [5]
https://mail.osgi.org/mailman/listinfo/osgi-dev [6]
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org [7]
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Dipl. Inf. (FH) Siamak
RE: [osgi-dev] exception aggregation for error reporting?
Creating a ThreadGroup is one thing, getting rid of it is quite another - you have to call ThreadGroup.destroy() from outside the ThreadGroup after all the member threads have terminated. Otherwise you have a classloader leak: https://developer.opencloud.com/devportal/display/ENGBLOG/2009/03/11/Avoid+ThreadGroup+in+Resource+Adaptors I would recommend against using ThreadGroup in an OSGi environment. As the blogpost points out, starting with SE5 you have Thread.setUncaughtExceptionHandler() available. ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
[osgi-dev] re: OSGI thesis
Hello, I am currently starting my master's program, and I am looking for a topic. I was wandering if there is any aspect of OSGI that can be used for thesis work? I've found one thesis that touches on OSGI as part of it's topic: http://www.polberger.se/components I'm mainly looking for any ideas or direction in which I can start looking. Anything helps - thank you! -Andriy Drozdyuk ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] re: OSGI thesis
Hi Andriy I used the Device Access Specification for an undergraduate thesis. Its subject was integrating HAL (http://www.freedesktop.org/wiki/Software/hal) with this specification for automatic device enumeration. I'd say any part of OSGi is suitable for a thesis. Like any thesis, it depends on what you and your supervisor is interested in. You could also go more high-level and examine topics such as the impact of OSGi on Java modularity on real-life projects, the value of adding OSGi to existing software programmes, etc. There are plenty of other underused Compendium specifications (like Wire Admin) that might be interesting to use in a thesis. Cheers Chris On Sun, 13 Mar 2011 20:01 -0300, Andriy Drozdyuk dro...@gmail.com wrote: Hello, I am currently starting my master's program, and I am looking for a topic. I was wandering if there is any aspect of OSGI that can be used for thesis work? I've found one thesis that touches on OSGI as part of it's topic: http://www.polberger.se/components I'm mainly looking for any ideas or direction in which I can start looking. Anything helps - thank you! -Andriy Drozdyuk ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev -- Christopher Armstrong carmstrong ^^AT^ fastmail dOT com /Dot/ au ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
RE: [osgi-dev] re: OSGI thesis
Hi, I'm pretty much ready to move on from OSGi. It's sort of the mass-has-overcome-agility problem. I have contemplated just creating the next generation on my spare time at home, but that's such a tall proposition. There are numerous things that need to be corrected and addressed, not just OSGi, but the state of the state of the industry. Then again, I have half a mind to throw in the towel and spend all my waking efforts as a studio musician, so go figure. A while back, I created an OSGi builder - more to the point, the notion of source bundles, extensible to any language. In it's most basic form, take a standard bundle, remove the dot.class files, and replace with dot.java files. I think you get the idea. What's mind boggling to me is that, while I'm getting enormous push back on this, at the very same time, scala-in-osgi is getting flying-green-lights. Go figure. But, this would work very well for C++/c as well. You could even bring in dot.net/mono stuff if you wanted, but that's a tad bit reaching. It does bring up the notion of spec supporting other frameworks besides Java (and who knows what the future holds with Oracle at the helm). Back to the point - the state of the state is pretty much abysmal because the framework should be the convention but frameworks have yet to step of to the place and take care of the framework gap; The lack of distributed anything from day 1 has been a plague. Maybe that's why I also embed in other [greater] frameworks (well, there are numerous reasons). Of course, I dread security but it's an essential. I'm pretty much done with all the RSA/cert/truststore stuff. There's just got to be a better way. I'm fairly happy with AES2 - that's usually my crux. And, get away from the current run time framework (e.g., JVM). The key thesis of anybody out there should be to revolutionize the state of the state, which is abysmal. The reality is the framework is the convention; Frameworks almost never take care of the gap and usually only step up the execution time plate. The gap is pretty much everything - usually missing and incomplete. Which leads to all these ridiculous concoctions such as Maven. Which, IMO, illegally tried to hijack the gap; It's illogical, really. The framework is the convention - reality has a way of not moving, no matter how many mojo's you throw / spin at it. So, a la contrivances such as source bundles at least take a small bite out of the problem by putting the build back on the shoulders of the framework, where it has belonged from day 1. There should not even be two commands: java and javac -- there should just be java. The key, to this one small aspect of the problem, is that source is natively deployable. You can deploy obfuscated source if you want. My two cents (and rant). What do I care? I'd rather be a rock-n-roll/progressive/jazz/nin guitar player anyway. Cheers... From: osgi-dev-boun...@mail.osgi.org [osgi-dev-boun...@mail.osgi.org] on behalf of Christopher Armstrong [carmstr...@fastmail.com.au] Sent: Sunday, March 13, 2011 7:17 PM To: OSGi Developer Mail List Subject: Re: [osgi-dev] re: OSGI thesis Hi Andriy I used the Device Access Specification for an undergraduate thesis. Its subject was integrating HAL (http://www.freedesktop.org/wiki/Software/hal) with this specification for automatic device enumeration. I'd say any part of OSGi is suitable for a thesis. Like any thesis, it depends on what you and your supervisor is interested in. You could also go more high-level and examine topics such as the impact of OSGi on Java modularity on real-life projects, the value of adding OSGi to existing software programmes, etc. There are plenty of other underused Compendium specifications (like Wire Admin) that might be interesting to use in a thesis. Cheers Chris On Sun, 13 Mar 2011 20:01 -0300, Andriy Drozdyuk dro...@gmail.com wrote: Hello, I am currently starting my master's program, and I am looking for a topic. I was wandering if there is any aspect of OSGI that can be used for thesis work? I've found one thesis that touches on OSGI as part of it's topic: http://www.polberger.se/components I'm mainly looking for any ideas or direction in which I can start looking. Anything helps - thank you! -Andriy Drozdyuk ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev -- Christopher Armstrong carmstrong ^^AT^ fastmail dOT com /Dot/ au ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
