@ mark: that's why i said "no easy/nice possibility". about the use-cases: there are many different use-cases - i just provided 1-2 of them. (as you can see) i used a more common one in my mail.
i haven't said that it is a new topic ;) @ jason: +1 at least we can try what's working for us. therefore i placed the todo there. regards, gerhard 2012/6/15 Mark Struberg <[email protected]> > > and qualify the exception event > > Theoretically possible, but ... > > This basically comes down to the old discussion about only using > RuntimeExceptions for such cases or adding special Exceptions for each and > every use case. Just s/ Exception with Qualifier now ;) For most users a > misconfiguration is just a deployment pitty and should crash the app... > > > LieGrue, > strub > > > > ----- Original Message ----- > > From: Jason Porter <[email protected]> > > To: [email protected] > > Cc: > > Sent: Friday, June 15, 2012 8:26 PM > > Subject: Re: git commit: DELTASPIKE-196 NO integration with Exception > Handler needed! > > > > In that case, the most flexible way we could do this would be to use the > > DeltaSpike exception handling, and qualify the exception event so the > > application developers can decide the best way to handle those > exceptions. > > As long as we use the same qualifier it could be as easy as creating an > > exception handler that accepts @CustomQualifier Throwable. They could > then > > handle all DeltaSpike exceptions the same way. The affords us the maximum > > flexibility and also would be consistent with how we tell users to handle > > exceptions in their application. > > > > As you've said before Gerhard, and I agree, perf when you're dealing > > with > > exceptions which would stop a process isn't really paramount, I see > adding > > in this bit of logic to pass the exception to the DeltaSpike exception > > handling system as a simple, flexible and workable solution for all > > involved. > > > > On Fri, Jun 15, 2012 at 12:11 PM, Gerhard Petracek < > > [email protected]> wrote: > > > >> hi jason, > >> > >> with the current implementation there is no easy/nice possibility to > handle > >> @ConfigProperty-producer exceptions differently. > >> there are just so many different requirements out there. > >> e.g. a special notification should be sent to an admin, if dyn. > >> config-properties are invalid (and many more). > >> > >> right now: > >> due to the details described in my previous mail, you just can detect a > >> NumberFormatException ( / generic RuntimeException) and even in the > >> application you just can e.g. log it in a general manner. > >> > >> if we are ok with it, we have to document it (that we won't support > > more > >> complex use-cases out-of-the-box). > >> or we throw a qualified NumberFormatException > >> or (since we found the logging issue - as mentioned by mark) we use > >> exceptions defined by deltaspike e.g. > InvalidConfigPropertyFormatException > >> > >> whatever we agree on - imo it should be consistent in almost all parts > of > >> deltaspike. > >> (as we know e.g. the bootstrapping process is special and we might > have to > >> handle it differently,...) > >> > >> regards, > >> gerhard > >> > >> > >> > >> 2012/6/15 Jason Porter <[email protected]> > >> > >> > What was wrong with the idea of a try catch block at the producer > > level? > >> > > >> > Sent from my iPhone > >> > > >> > On Jun 14, 2012, at 19:17, Gerhard Petracek > > <[email protected]> > >> > wrote: > >> > > >> > > it isn't about recovering from it. > >> > > it's about the approach we suggest/support to handle it with > > a custom > >> > > implementation (since there are a lot of different requirements > > out > >> > there). > >> > > > >> > > e.g. > >> > > //... > >> > > public class MyBean > >> > > { > >> > > @Inject > >> > > @ConfigProperty(name = "myProperty") > >> > > private Integer myProperty; > >> > > > >> > > public Integer getMyProperty() > >> > > { > >> > > return myProperty; > >> > > } > >> > > } > >> > > > >> > > in case of an invalid value the producer for this config-property > >> > (provided > >> > > by deltaspike) will throw a NumberFormatException (after a recent > >> commit > >> > > from mark a generic RuntimeException which wraps it). > >> > > since the @ConfigProperty-producers create >dependent > > scoped< values, > >> the > >> > > exception can be caused by any method-call to this bean (even by > > e.g. > >> > > #toString), because those producers get called at the first > > method-call > >> > to > >> > > the bean. > >> > > -> you can't use a simple try/catch block only for > > #getMyProperty to > >> > > integrate a custom/special implementation for handling exceptions > >> thrown > >> > by > >> > > a @ConfigProperty-producer (as mentioned earlier: i'm not > > talking > >> > > about recovering from it) . > >> > > > >> > > for integrating a custom implementation for handling it, there > > are the > >> > > following possibilities: > >> > > > >> > > - throwing a generic RuntimeException with the available > > information > >> > > (that's what was added during this discussion) > >> > > - throwing a custom RuntimeException with the available > > information > >> > > - integrating with the exception handler of deltaspike > > (qualification > >> of > >> > > the exception) > >> > > - some other possibilities which aren't that nice at all > >> > > > >> > > bootstrapping is always a special case - the main part is how we > > handle > >> > > such topics at runtime (after the bootstrapping process). > >> > > since @ConfigProperty is important and quite special at the same > > time > >> and > >> > > the producers are called after the bootstrapping process, we can > > use it > >> > as > >> > > a first example for the whole topic (of using the exception > > handler of > >> > > deltaspike internally). > >> > > > >> > > regards, > >> > > gerhard > >> > > > >> > > > >> > > > >> > > 2012/6/14 Mark Struberg <[email protected]> > >> > > > >> > >> Well, this is split. The native underlying impl is already > > being used > >> > >> during bootstrap by Extensions. > >> > >> The injection stuff can of course only be performed after the > >> container > >> > >> did finally boot. > >> > >> > >> > >> LieGrue, > >> > >> strub > >> > >> > >> > >> > >> > >> > >> > >> ----- Original Message ----- > >> > >>> From: Gerhard Petracek <[email protected]> > >> > >>> To: [email protected] > >> > >>> Cc: > >> > >>> Sent: Thursday, June 14, 2012 11:23 PM > >> > >>> Subject: Re: git commit: DELTASPIKE-196 NO integration > > with Exception > >> > >> Handler needed! > >> > >>> > >> > >>> right now we don't do it during the bootstrapping > > process (it's done > >> > >>> lazily > >> > >>> during runtime). > >> > >>> > >> > >>> the basic question is where and how we integrate our own > > exception > >> > >> handling > >> > >>> mechanism in the rest of deltaspike. > >> > >>> and i think jason is the expert for it since he wrote the > > catch > >> module. > >> > >>> > >> > >>> regards, > >> > >>> gerhard > >> > >>> > >> > >>> > >> > >>> > >> > >>> 2012/6/14 Jason Porter <[email protected]> > >> > >>> > >> > >>>> Gerhard asked me to take a look at this, and I > > didn't have the full > >> > >>> context > >> > >>>> on IRC. In speaking with him it sounded like a good > > idea to use the > >> DS > >> > >>>> exception handling here, however, Mark makes an > > excellent point > >> about > >> > >> not > >> > >>>> really being able to solve this without user > > intervention. We could > >> > use > >> > >>>> exception handling here and if there isn't any > > thing to handle it, > >> we > >> > >>> could > >> > >>>> rethrow the exception and halt the deployment anyway. > >> > >>>> > >> > >>>> Another thought just occurred to me, because > > we're really doing this > >> > >>> before > >> > >>>> the application fully completes deployment, I'm > > not even 100% sure > >> > >>>> DeltaSpike exception handling would work, that's > > probably an > >> > >>> implementation > >> > >>>> specific detail. In light of those two ideas, I'm > > going to stand by > >> > >>> Mark > >> > >>>> and say we should leave it out. > >> > >>>> > >> > >>>> On Thu, Jun 14, 2012 at 12:26 AM, > > <[email protected]> wrote: > >> > >>>> > >> > >>>>> Updated Branches: > >> > >>>>> refs/heads/master 9ca1855d7 -> 1c6354650 > >> > >>>>> > >> > >>>>> > >> > >>>>> DELTASPIKE-196 NO integration with Exception > > Handler needed! > >> > >>>>> > >> > >>>>> The DS Exception Handler is for _business_ > > methods. > >> > >>>>> Technical and configuration issues shall not be > > handled by DS > >> > >>>>> but by the user. We cannot recover from it > > without any > >> > >>>>> user interaction anyway... > >> > >>>>> > >> > >>>>> > >> > >>>>> Project: > >> > >>>> > > http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/repo > >> > >>>>> Commit: > >> > >>>>> > >> > >>>> > >> > >> > >> > > >> > http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/commit/1c635465 > >> > >>>>> Tree: > >> > >>>>> > >> > >>>> > >> > >> > >> > > >> > http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/tree/1c635465 > >> > >>>>> Diff: > >> > >>>>> > >> > >>>> > >> > >> > >> > > >> > http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/diff/1c635465 > >> > >>>>> > >> > >>>>> Branch: refs/heads/master > >> > >>>>> Commit: 1c63546506457e1a74fed6ca92cb9d0c0d54a2fc > >> > >>>>> Parents: 9ca1855 > >> > >>>>> Author: Mark Struberg <[email protected]> > >> > >>>>> Authored: Thu Jun 14 07:55:52 2012 +0200 > >> > >>>>> Committer: Mark Struberg > > <[email protected]> > >> > >>>>> Committed: Thu Jun 14 07:55:52 2012 +0200 > >> > >>>>> > >> > >>>>> > >> > >> > > ---------------------------------------------------------------------- > >> > >>>>> > > .../impl/config/DefaultConfigPropertyProducer.java | 3 --- > >> > >>>>> 1 files changed, 0 insertions(+), 3 deletions(-) > >> > >>>>> > >> > >> > > ---------------------------------------------------------------------- > >> > >>>>> > >> > >>>>> > >> > >>>>> > >> > >>>>> > >> > >>>> > >> > >>> > >> > >> > >> > > >> > > > http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/blob/1c635465/deltaspike/core/impl/src/main/java/org/apache/deltaspike/core/impl/config/DefaultConfigPropertyProducer.java > >> > >>>>> > >> > >> > > ---------------------------------------------------------------------- > >> > >>>>> diff --git > >> > >>>>> > >> > >>>> > >> > >>> > >> > >> > >> > > >> > > > a/deltaspike/core/impl/src/main/java/org/apache/deltaspike/core/impl/config/DefaultConfigPropertyProducer.java > >> > >>>>> > >> > >>>> > >> > >>> > >> > >> > >> > > >> > > > b/deltaspike/core/impl/src/main/java/org/apache/deltaspike/core/impl/config/DefaultConfigPropertyProducer.java > >> > >>>>> index d878139..cd4422e 100644 > >> > >>>>> --- > >> > >>>>> > >> > >>>> > >> > >>> > >> > >> > >> > > >> > > > a/deltaspike/core/impl/src/main/java/org/apache/deltaspike/core/impl/config/DefaultConfigPropertyProducer.java > >> > >>>>> +++ > >> > >>>>> > >> > >>>> > >> > >>> > >> > >> > >> > > >> > > > b/deltaspike/core/impl/src/main/java/org/apache/deltaspike/core/impl/config/DefaultConfigPropertyProducer.java > >> > >>>>> @@ -54,7 +54,6 @@ public class > > DefaultConfigPropertyProducer > >> extends > >> > >>>>> BaseConfigPropertyProducer > >> > >>>>> return null; > >> > >>>>> } > >> > >>>>> > >> > >>>>> - //X TODO integrate with the > > HandledHandler of DeltaSpike > >> > >>>>> return Integer.parseInt(configuredValue); > >> > >>>>> } > >> > >>>>> > >> > >>>>> @@ -69,7 +68,6 @@ public class > > DefaultConfigPropertyProducer > >> extends > >> > >>>>> BaseConfigPropertyProducer > >> > >>>>> return null; > >> > >>>>> } > >> > >>>>> > >> > >>>>> - //X TODO integrate with the > > HandledHandler of DeltaSpike > >> > >>>>> return Long.parseLong(configuredValue); > >> > >>>>> } > >> > >>>>> > >> > >>>>> @@ -108,7 +106,6 @@ public class > > DefaultConfigPropertyProducer > >> > >> extends > >> > >>>>> BaseConfigPropertyProducer > >> > >>>>> } > >> > >>>>> > >> > >>>>> //X TODO think about something like > > @NumberFormat(...) > >> > >>>>> - //X TODO integrate with the > > HandledHandler of DeltaSpike > >> > >>>>> return Float.parseFloat(configuredValue); > >> > >>>>> } > >> > >>>>> } > >> > >>>>> > >> > >>>>> > >> > >>>> > >> > >>>> > >> > >>>> -- > >> > >>>> Jason Porter > >> > >>>> http://lightguard-jp.blogspot.com > >> > >>>> http://twitter.com/lightguardjp > >> > >>>> > >> > >>>> Software Engineer > >> > >>>> Open Source Advocate > >> > >>>> Author of Seam Catch - Next Generation Java Exception > > Handling > >> > >>>> > >> > >>>> PGP key id: 926CCFF5 > >> > >>>> PGP key available at: keyserver.net, pgp.mit.edu > >> > >>>> > >> > >>> > >> > >> > >> > > >> > > > > > > > > -- > > Jason Porter > > http://lightguard-jp.blogspot.com > > http://twitter.com/lightguardjp > > > > Software Engineer > > Open Source Advocate > > Author of Seam Catch - Next Generation Java Exception Handling > > > > PGP key id: 926CCFF5 > > PGP key available at: keyserver.net, pgp.mit.edu > > >
