You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@deltaspike.apache.org by st...@apache.org on 2012/06/14 08:26:10 UTC
git commit: DELTASPIKE-196 NO integration with Exception Handler
needed!
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 <st...@apache.org>
Authored: Thu Jun 14 07:55:52 2012 +0200
Committer: Mark Struberg <st...@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);
}
}
Re: git commit: DELTASPIKE-196 NO integration with Exception Handler needed!
Posted by Jason Porter <li...@gmail.com>.
As I said to Gerhard in IRC, if it's something that a user could reasonably
recover in an exception handler, we should do the integration. I'm also
suggesting adding a qualifier to the event fired for exception handling to
1) have those specific handlers looking for ds exceptions handle them first
2) let a user decide if they want to handle it or pass based on the
qualifier (handlers w/o qualifiers, like the rest of CDI have a default
@Any qualifier) by looking at the qualifiers on the exception.
Of course it may be possible that any exceptions we raise in DS simply
aren't able to be handled by a user, in which case we simply leave out the
exception handling integration. For other modules such as JSF or REST, we
should definitely add integration for passing exceptions from those
frameworks through to ds exception handling.
I know that's not a hard and fast rule, but it's probably the best way we
can go.
On Thu, Jun 14, 2012 at 3:23 PM, Gerhard Petracek <
gerhard.petracek@gmail.com> wrote:
> 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 <li...@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, <st...@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 <st...@apache.org>
> > > Authored: Thu Jun 14 07:55:52 2012 +0200
> > > Committer: Mark Struberg <st...@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
Re: git commit: DELTASPIKE-196 NO integration with Exception Handler needed!
Posted by Mark Struberg <st...@yahoo.de>.
Hi Gerhard!
Imo the re-packaging of the Exception in the producer is just a workaround for a bad logging in OWB. Not sure if Weld has a better logging though.
If any producer method creates an Exception, then the CDI container should catch it and shall log a detailed information, e.g. the Bean information.
Of course, by manually repackaging, we now have even better information because we can also add property name and the problematic value to the Exception.
LieGrue,
strub
----- Original Message -----
> From: Jason Porter <li...@gmail.com>
> To: "deltaspike-dev@incubator.apache.org" <de...@incubator.apache.org>
> Cc: "deltaspike-dev@incubator.apache.org" <de...@incubator.apache.org>
> Sent: Friday, June 15, 2012 3:26 AM
> Subject: Re: git commit: DELTASPIKE-196 NO integration with Exception Handler needed!
>
> 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 <ge...@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 <st...@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 <ge...@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 <li...@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, <st...@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 <st...@apache.org>
>>>>>> Authored: Thu Jun 14 07:55:52 2012 +0200
>>>>>> Committer: Mark Struberg <st...@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
>>>>>
>>>>
>>>
>
Re: git commit: DELTASPIKE-196 NO integration with Exception Handler needed!
Posted by Gerhard Petracek <ge...@gmail.com>.
@ 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 <st...@yahoo.de>
> > 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 <li...@gmail.com>
> > To: deltaspike-dev@incubator.apache.org
> > 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 <
> > 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 <li...@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
> > <ge...@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 <st...@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 <ge...@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 <li...@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,
> > <st...@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 <st...@apache.org>
> >> > >>>>> Authored: Thu Jun 14 07:55:52 2012 +0200
> >> > >>>>> Committer: Mark Struberg
> > <st...@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
> >
>
Re: git commit: DELTASPIKE-196 NO integration with Exception Handler needed!
Posted by Mark Struberg <st...@yahoo.de>.
> 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 <li...@gmail.com>
> To: deltaspike-dev@incubator.apache.org
> 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 <
> 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 <li...@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
> <ge...@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 <st...@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 <ge...@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 <li...@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,
> <st...@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 <st...@apache.org>
>> > >>>>> Authored: Thu Jun 14 07:55:52 2012 +0200
>> > >>>>> Committer: Mark Struberg
> <st...@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
>
Re: git commit: DELTASPIKE-196 NO integration with Exception Handler needed!
Posted by Jason Porter <li...@gmail.com>.
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 <li...@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 <ge...@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 <st...@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 <ge...@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 <li...@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, <st...@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 <st...@apache.org>
> > >>>>> Authored: Thu Jun 14 07:55:52 2012 +0200
> > >>>>> Committer: Mark Struberg <st...@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
Re: git commit: DELTASPIKE-196 NO integration with Exception Handler needed!
Posted by Mark Struberg <st...@yahoo.de>.
Gerhard, what you can do in your application is to examine the StackTraceElements and if the NumberFormatException comes from a ConfigProducer then you can trigger special treatment. The information about the property-name, the value we got from the configuration system as well as the Bean of the InjectionPoint (contains classname and field) got added to the NFE already according to your idea.
It's really hard to draw the line between generalism and a too broad approach. Your use case where you do not have access to the log and only like to store 'certain' Exceptions into an application DB is not really a normative use case I fear ;)
LieGrue,
strub
----- Original Message -----
> From: Gerhard Petracek <ge...@gmail.com>
> To: deltaspike-dev@incubator.apache.org
> Cc:
> Sent: Friday, June 15, 2012 8:11 PM
> Subject: Re: git commit: DELTASPIKE-196 NO integration with Exception Handler needed!
>
> 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 <li...@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
> <ge...@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 <st...@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 <ge...@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 <li...@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,
> <st...@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 <st...@apache.org>
>> >>>>> Authored: Thu Jun 14 07:55:52 2012 +0200
>> >>>>> Committer: Mark Struberg <st...@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
>> >>>>
>> >>>
>> >>
>>
>
Re: git commit: DELTASPIKE-196 NO integration with Exception Handler needed!
Posted by Gerhard Petracek <ge...@gmail.com>.
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 <li...@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 <ge...@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 <st...@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 <ge...@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 <li...@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, <st...@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 <st...@apache.org>
> >>>>> Authored: Thu Jun 14 07:55:52 2012 +0200
> >>>>> Committer: Mark Struberg <st...@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
> >>>>
> >>>
> >>
>
Re: git commit: DELTASPIKE-196 NO integration with Exception Handler needed!
Posted by Jason Porter <li...@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 <ge...@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 <st...@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 <ge...@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 <li...@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, <st...@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 <st...@apache.org>
>>>>> Authored: Thu Jun 14 07:55:52 2012 +0200
>>>>> Committer: Mark Struberg <st...@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
>>>>
>>>
>>
Re: git commit: DELTASPIKE-196 NO integration with Exception Handler needed!
Posted by Gerhard Petracek <ge...@gmail.com>.
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 <st...@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 <ge...@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 <li...@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, <st...@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 <st...@apache.org>
> >> > Authored: Thu Jun 14 07:55:52 2012 +0200
> >> > Committer: Mark Struberg <st...@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
> >>
> >
>
Re: git commit: DELTASPIKE-196 NO integration with Exception Handler needed!
Posted by Mark Struberg <st...@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 <ge...@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 <li...@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, <st...@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 <st...@apache.org>
>> > Authored: Thu Jun 14 07:55:52 2012 +0200
>> > Committer: Mark Struberg <st...@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
>>
>
Re: git commit: DELTASPIKE-196 NO integration with Exception Handler needed!
Posted by Gerhard Petracek <ge...@gmail.com>.
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 <li...@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, <st...@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 <st...@apache.org>
> > Authored: Thu Jun 14 07:55:52 2012 +0200
> > Committer: Mark Struberg <st...@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
>
Re: git commit: DELTASPIKE-196 NO integration with Exception Handler needed!
Posted by Jason Porter <li...@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, <st...@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 <st...@apache.org>
> Authored: Thu Jun 14 07:55:52 2012 +0200
> Committer: Mark Struberg <st...@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