deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Porter <lightguard...@gmail.com>
Subject Re: git commit: DELTASPIKE-196 NO integration with Exception Handler needed!
Date Fri, 15 Jun 2012 18:26:08 GMT
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 <
gerhard.petracek@gmail.com> 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 <lightguard.jp@gmail.com>
>
> > 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 <gerhard.petracek@gmail.com>
> > 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 <struberg@yahoo.de>
> > >
> > >> 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 <gerhard.petracek@gmail.com>
> > >>> To: deltaspike-dev@incubator.apache.org
> > >>> 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 <lightguard.jp@gmail.com>
> > >>>
> > >>>> 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, <struberg@apache.org> 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 <struberg@apache.org>
> > >>>>> Authored: Thu Jun 14 07:55:52 2012 +0200
> > >>>>> Committer: Mark Struberg <struberg@apache.org>
> > >>>>> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message