Quantcast

Package visibility for RedeliveryErrorHandler.RedeliveryData.currentRedeliveryPolicy

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Package visibility for RedeliveryErrorHandler.RedeliveryData.currentRedeliveryPolicy

davide_cavestro
I need to enrich the RedeliveryPolicy with custom attributes, so I have subclassed it.
Then I subclassed DefaultExceptionPolicyStrategy in order to properly map custom RedeliveryPolicy instances to exception types.
On a Processor configured as DeadLetterChannelBuilder.onExceptionOccurred I need to get access to currentRedeliveryPolicy and its custom attributes,  so I subclassed DeadLetterChannel in order to intercept the RedeliveryData parameter of DeadLetterChannel.onExceptionOccurred method calls and save its currentRedeliveryPolicy into an exchange property.

So far it's UGLY.

But at this point I've seen that RedeliveryErrorHandler.RedeliveryData.currentRedeliveryPolicy has package visibility, so I need to introduce a class with package org.apache.camel.processor just to access that field.

The problem is that this easily becomes a MESS when I try to run this in an OSGi environment, cause it makes org.apache.camel.processor a splitted package.

Is there any better way to achieve the same?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Package visibility for RedeliveryErrorHandler.RedeliveryData.currentRedeliveryPolicy

Claus Ibsen-2
Hi

This is not intended for end users to do

On Fri, Feb 17, 2017 at 4:09 PM, davide_cavestro
<[hidden email]> wrote:

> I need to enrich the /RedeliveryPolicy/ with custom attributes, so I have
> subclassed it.
> Then I subclassed /DefaultExceptionPolicyStrategy/ in order to properly map
> custom /RedeliveryPolicy/ instances to exception types.
> On a /Processor/ configured as
> /DeadLetterChannelBuilder.onExceptionOccurred/ I need to get access to
> /currentRedeliveryPolicy/ and its custom attributes,  so I subclassed
> /DeadLetterChannel/ in order to intercept the /RedeliveryData/ parameter of
> /DeadLetterChannel.onExceptionOccurred/ method calls and save its
> /currentRedeliveryPolicy/ into an exchange property.
>
> So far it's UGLY.
>
> But at this point I've seen that
> /RedeliveryErrorHandler.RedeliveryData.currentRedeliveryPolicy/ has package
> visibility, so I need to introduce a class with package
> /org.apache.camel.processor/ just to access that field.
>
> The problem is that this easily becomes a MESS when I try to run this in an
> OSGi environment, cause it makes /org.apache.camel.processor/ a splitted
> package.
>
> Is there any better way to achieve the same?
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Package-visibility-for-RedeliveryErrorHandler-RedeliveryData-currentRedeliveryPolicy-tp5794046.html
> Sent from the Camel - Users mailing list archive at Nabble.com.



--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Package visibility for RedeliveryErrorHandler.RedeliveryData.currentRedeliveryPolicy

davide_cavestro
@Claus could you please elaborate on it?

How can I react to exceptions, based on their types and some related configuration defined for the whole context?
i.e. I need to enrich the original redelivery behavior with further attempts (out-of-process)

Claus Ibsen-2 wrote
Hi

This is not intended for end users to do

On Fri, Feb 17, 2017 at 4:09 PM, davide_cavestro
<[hidden email]> wrote:
> I need to enrich the /RedeliveryPolicy/ with custom attributes, so I have
> subclassed it.
> Then I subclassed /DefaultExceptionPolicyStrategy/ in order to properly map
> custom /RedeliveryPolicy/ instances to exception types.
> On a /Processor/ configured as
> /DeadLetterChannelBuilder.onExceptionOccurred/ I need to get access to
> /currentRedeliveryPolicy/ and its custom attributes,  so I subclassed
> /DeadLetterChannel/ in order to intercept the /RedeliveryData/ parameter of
> /DeadLetterChannel.onExceptionOccurred/ method calls and save its
> /currentRedeliveryPolicy/ into an exchange property.
>
> So far it's UGLY.
>
> But at this point I've seen that
> /RedeliveryErrorHandler.RedeliveryData.currentRedeliveryPolicy/ has package
> visibility, so I need to introduce a class with package
> /org.apache.camel.processor/ just to access that field.
>
> The problem is that this easily becomes a MESS when I try to run this in an
> OSGi environment, cause it makes /org.apache.camel.processor/ a splitted
> package.
>
> Is there any better way to achieve the same?
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Package-visibility-for-RedeliveryErrorHandler-RedeliveryData-currentRedeliveryPolicy-tp5794046.html
> Sent from the Camel - Users mailing list archive at Nabble.com.



--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Package visibility for RedeliveryErrorHandler.RedeliveryData.currentRedeliveryPolicy

Claus Ibsen-2
Study error handler some more it can do a lot.

And if you have Camel in Action 2nd ed book then read the chapter it
cover a lot about error handling and how it works.

On Fri, Feb 17, 2017 at 4:44 PM, davide_cavestro
<[hidden email]> wrote:

> @Claus could you please elaborate on it?
>
> How can I react to exceptions, based on their types and some related
> configuration defined for the whole context?
> i.e. I need to enrich the original redelivery behavior with further attempts
> (out-of-process)
>
>
> Claus Ibsen-2 wrote
>> Hi
>>
>> This is not intended for end users to do
>>
>> On Fri, Feb 17, 2017 at 4:09 PM, davide_cavestro
>> &lt;
>
>> davide.cavestro@
>
>> &gt; wrote:
>>> I need to enrich the /RedeliveryPolicy/ with custom attributes, so I have
>>> subclassed it.
>>> Then I subclassed /DefaultExceptionPolicyStrategy/ in order to properly
>>> map
>>> custom /RedeliveryPolicy/ instances to exception types.
>>> On a /Processor/ configured as
>>> /DeadLetterChannelBuilder.onExceptionOccurred/ I need to get access to
>>> /currentRedeliveryPolicy/ and its custom attributes,  so I subclassed
>>> /DeadLetterChannel/ in order to intercept the /RedeliveryData/ parameter
>>> of
>>> /DeadLetterChannel.onExceptionOccurred/ method calls and save its
>>> /currentRedeliveryPolicy/ into an exchange property.
>>>
>>> So far it's UGLY.
>>>
>>> But at this point I've seen that
>>> /RedeliveryErrorHandler.RedeliveryData.currentRedeliveryPolicy/ has
>>> package
>>> visibility, so I need to introduce a class with package
>>> /org.apache.camel.processor/ just to access that field.
>>>
>>> The problem is that this easily becomes a MESS when I try to run this in
>>> an
>>> OSGi environment, cause it makes /org.apache.camel.processor/ a splitted
>>> package.
>>>
>>> Is there any better way to achieve the same?
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://camel.465427.n5.nabble.com/Package-visibility-for-RedeliveryErrorHandler-RedeliveryData-currentRedeliveryPolicy-tp5794046.html
>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Package-visibility-for-RedeliveryErrorHandler-RedeliveryData-currentRedeliveryPolicy-tp5794046p5794052.html
> Sent from the Camel - Users mailing list archive at Nabble.com.



--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Loading...