Re: [Dev] [Architecture] [C5] MSF4J Interceptors need to be configurable.

[Ishara Cooray]

Thanks for the update Thusitha.

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Tue, Apr 4, 2017 at 8:52 AM, Thusitha Thilina Dayaratne <
thusit...@wso2.com> wrote:

> Hi Ishara,
>
> We are planning to in co-operating that with the 2.3.0-m2 which scheduled
> to be released by this week.
>
> Thanks
> Thusitha
>
> On Mon, Apr 3, 2017 at 12:18 PM, Ishara Cooray  wrote:
>
>> Hi Vidura/Thusitha,
>>
>> Can we have an update on this please?
>>
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> On Mon, Jan 16, 2017 at 1:13 PM, Thusitha Thilina Dayaratne <
>> thusit...@wso2.com> wrote:
>>
>>> Hi Sagara,
>>>
>>> ViduraN has almost implemented this. We will schedule a meeting tomorrow
>>> or day after tomorrow to discuss the current implementation.
>>>
>>> Thanks
>>> Thusitha
>>>
>>> On Mon, Jan 16, 2017 at 12:44 PM, Sagara Gunathunga 
>>> wrote:
>>>

 Can we have an update or review meeting on this ?

 Thanks !


 On Thu, Jan 5, 2017 at 9:50 AM, Ishara Cooray  wrote:

> Sounds good.
> Thanks Kishanthan.
>
> Thanks & Regards,
> Ishara Cooray
> Senior Software Engineer
> Mobile : +9477 262 9512 <+94%2077%20262%209512>
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> On Wed, Jan 4, 2017 at 5:30 PM, Kishanthan Thangarajah <
> kishant...@wso2.com> wrote:
>
>> We are working on this. We couldn't progress much last week due to
>> other priorities. The plan is to deliver in two weeks time.
>>
>> On Tue, Jan 3, 2017 at 1:40 PM, Ishara Cooray 
>> wrote:
>>
>>> Hi,
>>>
>>> What could be the status of this? Do we have a time line defined?
>>>
>>> Thanks & Regards,
>>> Ishara Cooray
>>> Senior Software Engineer
>>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>>> WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>> On Fri, Dec 9, 2016 at 2:18 PM, Sagara Gunathunga 
>>> wrote:
>>>


 On Fri, Dec 9, 2016 at 2:15 PM, Sanjeewa Malalgoda <
 sanje...@wso2.com> wrote:

> Hi All,
> Please find inline comments.
>
> On Fri, Dec 9, 2016 at 12:49 PM, Sagara Gunathunga <
> sag...@wso2.com> wrote:
>
>>
>>
>> On Thu, Dec 8, 2016 at 6:59 PM, Ishara Cooray 
>> wrote:
>>
>>> To overcome the above limitation where we cannot plug custom
>>> authentication, i came up with the below approach.
>>>
>>> Having one interceptor and delegate authentication to an
>>> interface. Implementation of the interface is configurable so that 
>>> we can
>>> plug custom authentication as well.
>>>
>>> [image: Inline image 1]
>>>
>>> One limitation here is we can have only one auth type active at
>>> a time.
>>>
>>> Hi Sanjeewa,
>>>
>>> Shall we continue with this approach until we get a proper fix
>>> from msf4j?
>>>
>>
>> It's ok to use above  approach as a temporary workaround till we
>> get proper solution from MSF4J, but please make sure to implement 
>> only
>> required features in a simple manner because you have to discard 
>> this and
>> have to use proper MSF4J approach before any release.
>>
>> By looking at issues faced by API-M and IS teams we have few
>> issues to solve,
>>
>>
>> 1. Ability to apply/skip Interceptors in global and per-service
>> levels
>> 2. Ability to define the order of Interceptors
>> 3. Ability to intercept response messages
>>
> Ability to build security and user context in a way we can access
> it from service implementation.
> Most of the other platforms allowed to do that and people who work
> on service implementation can get real advantage of that.
>
>>
>> The good news is JAX-RS 2.0 spec is already solved these issues
>> and we can adopt their concepts easily to MSF4J programming model. 
>> Please
>> refer solution for each issue below.
>>
>>
>> *1. Ability to intercept response messages *
>>
>> JAX-RS defines 2 interfaces as ContainerRequestFilter[1] and
>> ContainerResponseFilter[2] to intercept request and response 
>> messages, IMO
>> these 2 interfaces are much clean and standard then current MSF4J
>> Interceptor[3] concept 

Re: [Dev] [Architecture] [C5] MSF4J Interceptors need to be configurable.

[Thusitha Thilina Dayaratne]

Hi Ishara,

We are planning to in co-operating that with the 2.3.0-m2 which scheduled
to be released by this week.

Thanks
Thusitha

On Mon, Apr 3, 2017 at 12:18 PM, Ishara Cooray  wrote:

> Hi Vidura/Thusitha,
>
> Can we have an update on this please?
>
>
> Thanks & Regards,
> Ishara Cooray
> Senior Software Engineer
> Mobile : +9477 262 9512 <+94%2077%20262%209512>
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> On Mon, Jan 16, 2017 at 1:13 PM, Thusitha Thilina Dayaratne <
> thusit...@wso2.com> wrote:
>
>> Hi Sagara,
>>
>> ViduraN has almost implemented this. We will schedule a meeting tomorrow
>> or day after tomorrow to discuss the current implementation.
>>
>> Thanks
>> Thusitha
>>
>> On Mon, Jan 16, 2017 at 12:44 PM, Sagara Gunathunga 
>> wrote:
>>
>>>
>>> Can we have an update or review meeting on this ?
>>>
>>> Thanks !
>>>
>>>
>>> On Thu, Jan 5, 2017 at 9:50 AM, Ishara Cooray  wrote:
>>>
 Sounds good.
 Thanks Kishanthan.

 Thanks & Regards,
 Ishara Cooray
 Senior Software Engineer
 Mobile : +9477 262 9512 <+94%2077%20262%209512>
 WSO2, Inc. | http://wso2.com/
 Lean . Enterprise . Middleware

 On Wed, Jan 4, 2017 at 5:30 PM, Kishanthan Thangarajah <
 kishant...@wso2.com> wrote:

> We are working on this. We couldn't progress much last week due to
> other priorities. The plan is to deliver in two weeks time.
>
> On Tue, Jan 3, 2017 at 1:40 PM, Ishara Cooray 
> wrote:
>
>> Hi,
>>
>> What could be the status of this? Do we have a time line defined?
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> On Fri, Dec 9, 2016 at 2:18 PM, Sagara Gunathunga 
>> wrote:
>>
>>>
>>>
>>> On Fri, Dec 9, 2016 at 2:15 PM, Sanjeewa Malalgoda <
>>> sanje...@wso2.com> wrote:
>>>
 Hi All,
 Please find inline comments.

 On Fri, Dec 9, 2016 at 12:49 PM, Sagara Gunathunga  wrote:

>
>
> On Thu, Dec 8, 2016 at 6:59 PM, Ishara Cooray 
> wrote:
>
>> To overcome the above limitation where we cannot plug custom
>> authentication, i came up with the below approach.
>>
>> Having one interceptor and delegate authentication to an
>> interface. Implementation of the interface is configurable so that 
>> we can
>> plug custom authentication as well.
>>
>> [image: Inline image 1]
>>
>> One limitation here is we can have only one auth type active at a
>> time.
>>
>> Hi Sanjeewa,
>>
>> Shall we continue with this approach until we get a proper fix
>> from msf4j?
>>
>
> It's ok to use above  approach as a temporary workaround till we
> get proper solution from MSF4J, but please make sure to implement only
> required features in a simple manner because you have to discard this 
> and
> have to use proper MSF4J approach before any release.
>
> By looking at issues faced by API-M and IS teams we have few
> issues to solve,
>
>
> 1. Ability to apply/skip Interceptors in global and per-service
> levels
> 2. Ability to define the order of Interceptors
> 3. Ability to intercept response messages
>
 Ability to build security and user context in a way we can access
 it from service implementation.
 Most of the other platforms allowed to do that and people who work
 on service implementation can get real advantage of that.

>
> The good news is JAX-RS 2.0 spec is already solved these issues
> and we can adopt their concepts easily to MSF4J programming model. 
> Please
> refer solution for each issue below.
>
>
> *1. Ability to intercept response messages *
>
> JAX-RS defines 2 interfaces as ContainerRequestFilter[1] and
> ContainerResponseFilter[2] to intercept request and response 
> messages, IMO
> these 2 interfaces are much clean and standard then current MSF4J
> Interceptor[3] concept where response intercepting is not simple.
>
>
> *2.  Ability to apply/skip Interceptors  in global and per-service
> levels *
>
> Annotation driven NameBinding[4] concept defined for JAX-RS
> Filters is very flexible and easy to use as well. This NameBinding[4]
> feature enables to apply JAX-RS Filters at global, per-Resource or 
> even
> 

Re: [Dev] [Architecture] [C5] MSF4J Interceptors need to be configurable.

[Ishara Cooray]

Hi Vidura/Thusitha,

Can we have an update on this please?


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512 <+94%2077%20262%209512>
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Mon, Jan 16, 2017 at 1:13 PM, Thusitha Thilina Dayaratne <
thusit...@wso2.com> wrote:

> Hi Sagara,
>
> ViduraN has almost implemented this. We will schedule a meeting tomorrow
> or day after tomorrow to discuss the current implementation.
>
> Thanks
> Thusitha
>
> On Mon, Jan 16, 2017 at 12:44 PM, Sagara Gunathunga 
> wrote:
>
>>
>> Can we have an update or review meeting on this ?
>>
>> Thanks !
>>
>>
>> On Thu, Jan 5, 2017 at 9:50 AM, Ishara Cooray  wrote:
>>
>>> Sounds good.
>>> Thanks Kishanthan.
>>>
>>> Thanks & Regards,
>>> Ishara Cooray
>>> Senior Software Engineer
>>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>>> WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>> On Wed, Jan 4, 2017 at 5:30 PM, Kishanthan Thangarajah <
>>> kishant...@wso2.com> wrote:
>>>
 We are working on this. We couldn't progress much last week due to
 other priorities. The plan is to deliver in two weeks time.

 On Tue, Jan 3, 2017 at 1:40 PM, Ishara Cooray  wrote:

> Hi,
>
> What could be the status of this? Do we have a time line defined?
>
> Thanks & Regards,
> Ishara Cooray
> Senior Software Engineer
> Mobile : +9477 262 9512 <+94%2077%20262%209512>
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> On Fri, Dec 9, 2016 at 2:18 PM, Sagara Gunathunga 
> wrote:
>
>>
>>
>> On Fri, Dec 9, 2016 at 2:15 PM, Sanjeewa Malalgoda > > wrote:
>>
>>> Hi All,
>>> Please find inline comments.
>>>
>>> On Fri, Dec 9, 2016 at 12:49 PM, Sagara Gunathunga 
>>> wrote:
>>>


 On Thu, Dec 8, 2016 at 6:59 PM, Ishara Cooray 
 wrote:

> To overcome the above limitation where we cannot plug custom
> authentication, i came up with the below approach.
>
> Having one interceptor and delegate authentication to an
> interface. Implementation of the interface is configurable so that we 
> can
> plug custom authentication as well.
>
> [image: Inline image 1]
>
> One limitation here is we can have only one auth type active at a
> time.
>
> Hi Sanjeewa,
>
> Shall we continue with this approach until we get a proper fix
> from msf4j?
>

 It's ok to use above  approach as a temporary workaround till we
 get proper solution from MSF4J, but please make sure to implement only
 required features in a simple manner because you have to discard this 
 and
 have to use proper MSF4J approach before any release.

 By looking at issues faced by API-M and IS teams we have few issues
 to solve,


 1. Ability to apply/skip Interceptors in global and per-service
 levels
 2. Ability to define the order of Interceptors
 3. Ability to intercept response messages

>>> Ability to build security and user context in a way we can access it
>>> from service implementation.
>>> Most of the other platforms allowed to do that and people who work
>>> on service implementation can get real advantage of that.
>>>

 The good news is JAX-RS 2.0 spec is already solved these issues and
 we can adopt their concepts easily to MSF4J programming model. Please 
 refer
 solution for each issue below.


 *1. Ability to intercept response messages *

 JAX-RS defines 2 interfaces as ContainerRequestFilter[1] and
 ContainerResponseFilter[2] to intercept request and response messages, 
 IMO
 these 2 interfaces are much clean and standard then current MSF4J
 Interceptor[3] concept where response intercepting is not simple.


 *2.  Ability to apply/skip Interceptors  in global and per-service
 levels *

 Annotation driven NameBinding[4] concept defined for JAX-RS Filters
 is very flexible and easy to use as well. This NameBinding[4] feature
 enables to apply JAX-RS Filters at global, per-Resource or even
 per-sub-Resource level.

 *3. Define the order of Interceptors *

 JAX-RS defines several message processing extension points such as
 Pre, PreMatch, Post, it's possible to apply Filters during some of 
 these
 message processing stages, as an example refer PreMatching[5] 
 annotation.

 Further, to define 

Re: [Dev] [Architecture] [C5] MSF4J Interceptors need to be configurable.

[Thusitha Thilina Dayaratne]

Hi Sagara,

ViduraN has almost implemented this. We will schedule a meeting tomorrow or
day after tomorrow to discuss the current implementation.

Thanks
Thusitha

On Mon, Jan 16, 2017 at 12:44 PM, Sagara Gunathunga  wrote:

>
> Can we have an update or review meeting on this ?
>
> Thanks !
>
>
> On Thu, Jan 5, 2017 at 9:50 AM, Ishara Cooray  wrote:
>
>> Sounds good.
>> Thanks Kishanthan.
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> On Wed, Jan 4, 2017 at 5:30 PM, Kishanthan Thangarajah <
>> kishant...@wso2.com> wrote:
>>
>>> We are working on this. We couldn't progress much last week due to other
>>> priorities. The plan is to deliver in two weeks time.
>>>
>>> On Tue, Jan 3, 2017 at 1:40 PM, Ishara Cooray  wrote:
>>>
 Hi,

 What could be the status of this? Do we have a time line defined?

 Thanks & Regards,
 Ishara Cooray
 Senior Software Engineer
 Mobile : +9477 262 9512 <+94%2077%20262%209512>
 WSO2, Inc. | http://wso2.com/
 Lean . Enterprise . Middleware

 On Fri, Dec 9, 2016 at 2:18 PM, Sagara Gunathunga 
 wrote:

>
>
> On Fri, Dec 9, 2016 at 2:15 PM, Sanjeewa Malalgoda 
> wrote:
>
>> Hi All,
>> Please find inline comments.
>>
>> On Fri, Dec 9, 2016 at 12:49 PM, Sagara Gunathunga 
>> wrote:
>>
>>>
>>>
>>> On Thu, Dec 8, 2016 at 6:59 PM, Ishara Cooray 
>>> wrote:
>>>
 To overcome the above limitation where we cannot plug custom
 authentication, i came up with the below approach.

 Having one interceptor and delegate authentication to an interface.
 Implementation of the interface is configurable so that we can plug 
 custom
 authentication as well.

 [image: Inline image 1]

 One limitation here is we can have only one auth type active at a
 time.

 Hi Sanjeewa,

 Shall we continue with this approach until we get a proper fix from
 msf4j?

>>>
>>> It's ok to use above  approach as a temporary workaround till we get
>>> proper solution from MSF4J, but please make sure to implement only 
>>> required
>>> features in a simple manner because you have to discard this and have to
>>> use proper MSF4J approach before any release.
>>>
>>> By looking at issues faced by API-M and IS teams we have few issues
>>> to solve,
>>>
>>>
>>> 1. Ability to apply/skip Interceptors in global and per-service
>>> levels
>>> 2. Ability to define the order of Interceptors
>>> 3. Ability to intercept response messages
>>>
>> Ability to build security and user context in a way we can access it
>> from service implementation.
>> Most of the other platforms allowed to do that and people who work on
>> service implementation can get real advantage of that.
>>
>>>
>>> The good news is JAX-RS 2.0 spec is already solved these issues and
>>> we can adopt their concepts easily to MSF4J programming model. Please 
>>> refer
>>> solution for each issue below.
>>>
>>>
>>> *1. Ability to intercept response messages *
>>>
>>> JAX-RS defines 2 interfaces as ContainerRequestFilter[1] and
>>> ContainerResponseFilter[2] to intercept request and response messages, 
>>> IMO
>>> these 2 interfaces are much clean and standard then current MSF4J
>>> Interceptor[3] concept where response intercepting is not simple.
>>>
>>>
>>> *2.  Ability to apply/skip Interceptors  in global and per-service
>>> levels *
>>>
>>> Annotation driven NameBinding[4] concept defined for JAX-RS Filters
>>> is very flexible and easy to use as well. This NameBinding[4] feature
>>> enables to apply JAX-RS Filters at global, per-Resource or even
>>> per-sub-Resource level.
>>>
>>> *3. Define the order of Interceptors *
>>>
>>> JAX-RS defines several message processing extension points such as
>>> Pre, PreMatch, Post, it's possible to apply Filters during some of these
>>> message processing stages, as an example refer PreMatching[5] 
>>> annotation.
>>>
>>> Further, to define fine grained order of Filters JAX-RS reuse Java's
>>> standard Priority[1] annotation, through this annotation numeric 
>>> priority
>>> value can be define per Filters basis. JAX-RS already provide set of
>>> pre-defined Priories here[6]
>>>
>> Ability to engage in different phases is definitely a good feature.
>> But there can be situations where we need to engage multiple interceptors
>> at same phase with order of execution. As example 

Re: [Dev] [Architecture] [C5] MSF4J Interceptors need to be configurable.

[Sagara Gunathunga]

Can we have an update or review meeting on this ?

Thanks !

On Thu, Jan 5, 2017 at 9:50 AM, Ishara Cooray  wrote:

> Sounds good.
> Thanks Kishanthan.
>
> Thanks & Regards,
> Ishara Cooray
> Senior Software Engineer
> Mobile : +9477 262 9512 <+94%2077%20262%209512>
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> On Wed, Jan 4, 2017 at 5:30 PM, Kishanthan Thangarajah <
> kishant...@wso2.com> wrote:
>
>> We are working on this. We couldn't progress much last week due to other
>> priorities. The plan is to deliver in two weeks time.
>>
>> On Tue, Jan 3, 2017 at 1:40 PM, Ishara Cooray  wrote:
>>
>>> Hi,
>>>
>>> What could be the status of this? Do we have a time line defined?
>>>
>>> Thanks & Regards,
>>> Ishara Cooray
>>> Senior Software Engineer
>>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>>> WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>> On Fri, Dec 9, 2016 at 2:18 PM, Sagara Gunathunga 
>>> wrote:
>>>


 On Fri, Dec 9, 2016 at 2:15 PM, Sanjeewa Malalgoda 
 wrote:

> Hi All,
> Please find inline comments.
>
> On Fri, Dec 9, 2016 at 12:49 PM, Sagara Gunathunga 
> wrote:
>
>>
>>
>> On Thu, Dec 8, 2016 at 6:59 PM, Ishara Cooray 
>> wrote:
>>
>>> To overcome the above limitation where we cannot plug custom
>>> authentication, i came up with the below approach.
>>>
>>> Having one interceptor and delegate authentication to an interface.
>>> Implementation of the interface is configurable so that we can plug 
>>> custom
>>> authentication as well.
>>>
>>> [image: Inline image 1]
>>>
>>> One limitation here is we can have only one auth type active at a
>>> time.
>>>
>>> Hi Sanjeewa,
>>>
>>> Shall we continue with this approach until we get a proper fix from
>>> msf4j?
>>>
>>
>> It's ok to use above  approach as a temporary workaround till we get
>> proper solution from MSF4J, but please make sure to implement only 
>> required
>> features in a simple manner because you have to discard this and have to
>> use proper MSF4J approach before any release.
>>
>> By looking at issues faced by API-M and IS teams we have few issues
>> to solve,
>>
>>
>> 1. Ability to apply/skip Interceptors in global and per-service
>> levels
>> 2. Ability to define the order of Interceptors
>> 3. Ability to intercept response messages
>>
> Ability to build security and user context in a way we can access it
> from service implementation.
> Most of the other platforms allowed to do that and people who work on
> service implementation can get real advantage of that.
>
>>
>> The good news is JAX-RS 2.0 spec is already solved these issues and
>> we can adopt their concepts easily to MSF4J programming model. Please 
>> refer
>> solution for each issue below.
>>
>>
>> *1. Ability to intercept response messages *
>>
>> JAX-RS defines 2 interfaces as ContainerRequestFilter[1] and
>> ContainerResponseFilter[2] to intercept request and response messages, 
>> IMO
>> these 2 interfaces are much clean and standard then current MSF4J
>> Interceptor[3] concept where response intercepting is not simple.
>>
>>
>> *2.  Ability to apply/skip Interceptors  in global and per-service
>> levels *
>>
>> Annotation driven NameBinding[4] concept defined for JAX-RS Filters
>> is very flexible and easy to use as well. This NameBinding[4] feature
>> enables to apply JAX-RS Filters at global, per-Resource or even
>> per-sub-Resource level.
>>
>> *3. Define the order of Interceptors *
>>
>> JAX-RS defines several message processing extension points such as
>> Pre, PreMatch, Post, it's possible to apply Filters during some of these
>> message processing stages, as an example refer PreMatching[5] annotation.
>>
>> Further, to define fine grained order of Filters JAX-RS reuse Java's
>> standard Priority[1] annotation, through this annotation numeric priority
>> value can be define per Filters basis. JAX-RS already provide set of
>> pre-defined Priories here[6]
>>
> Ability to engage in different phases is definitely a good feature.
> But there can be situations where we need to engage multiple interceptors
> at same phase with order of execution. As example i need to engage both
> authenticate and authorization interceptors in pre invoke phase but
> authenticator first and then authorizer as 2nd interceptor. In that case 
> we
> need to mention phase and order within phase in some way. It seems CXF and
> other run times already handled this in different ways.
>

 This requirement is well handled by the JAX-RS concept 

Re: [Dev] [Architecture] [C5] MSF4J Interceptors need to be configurable.

[Ishara Cooray]

Sounds good.
Thanks Kishanthan.

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Wed, Jan 4, 2017 at 5:30 PM, Kishanthan Thangarajah 
wrote:

> We are working on this. We couldn't progress much last week due to other
> priorities. The plan is to deliver in two weeks time.
>
> On Tue, Jan 3, 2017 at 1:40 PM, Ishara Cooray  wrote:
>
>> Hi,
>>
>> What could be the status of this? Do we have a time line defined?
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> On Fri, Dec 9, 2016 at 2:18 PM, Sagara Gunathunga 
>> wrote:
>>
>>>
>>>
>>> On Fri, Dec 9, 2016 at 2:15 PM, Sanjeewa Malalgoda 
>>> wrote:
>>>
 Hi All,
 Please find inline comments.

 On Fri, Dec 9, 2016 at 12:49 PM, Sagara Gunathunga 
 wrote:

>
>
> On Thu, Dec 8, 2016 at 6:59 PM, Ishara Cooray 
> wrote:
>
>> To overcome the above limitation where we cannot plug custom
>> authentication, i came up with the below approach.
>>
>> Having one interceptor and delegate authentication to an interface.
>> Implementation of the interface is configurable so that we can plug 
>> custom
>> authentication as well.
>>
>> [image: Inline image 1]
>>
>> One limitation here is we can have only one auth type active at a
>> time.
>>
>> Hi Sanjeewa,
>>
>> Shall we continue with this approach until we get a proper fix from
>> msf4j?
>>
>
> It's ok to use above  approach as a temporary workaround till we get
> proper solution from MSF4J, but please make sure to implement only 
> required
> features in a simple manner because you have to discard this and have to
> use proper MSF4J approach before any release.
>
> By looking at issues faced by API-M and IS teams we have few issues to
> solve,
>
>
> 1. Ability to apply/skip Interceptors in global and per-service levels
> 2. Ability to define the order of Interceptors
> 3. Ability to intercept response messages
>
 Ability to build security and user context in a way we can access it
 from service implementation.
 Most of the other platforms allowed to do that and people who work on
 service implementation can get real advantage of that.

>
> The good news is JAX-RS 2.0 spec is already solved these issues and we
> can adopt their concepts easily to MSF4J programming model. Please refer
> solution for each issue below.
>
>
> *1. Ability to intercept response messages *
>
> JAX-RS defines 2 interfaces as ContainerRequestFilter[1] and
> ContainerResponseFilter[2] to intercept request and response messages, IMO
> these 2 interfaces are much clean and standard then current MSF4J
> Interceptor[3] concept where response intercepting is not simple.
>
>
> *2.  Ability to apply/skip Interceptors  in global and per-service
> levels *
>
> Annotation driven NameBinding[4] concept defined for JAX-RS Filters is
> very flexible and easy to use as well. This NameBinding[4] feature enables
> to apply JAX-RS Filters at global, per-Resource or even per-sub-Resource
> level.
>
> *3. Define the order of Interceptors *
>
> JAX-RS defines several message processing extension points such as
> Pre, PreMatch, Post, it's possible to apply Filters during some of these
> message processing stages, as an example refer PreMatching[5] annotation.
>
> Further, to define fine grained order of Filters JAX-RS reuse Java's
> standard Priority[1] annotation, through this annotation numeric priority
> value can be define per Filters basis. JAX-RS already provide set of
> pre-defined Priories here[6]
>
 Ability to engage in different phases is definitely a good feature. But
 there can be situations where we need to engage multiple interceptors at
 same phase with order of execution. As example i need to engage both
 authenticate and authorization interceptors in pre invoke phase but
 authenticator first and then authorizer as 2nd interceptor. In that case we
 need to mention phase and order within phase in some way. It seems CXF and
 other run times already handled this in different ways.

>>>
>>> This requirement is well handled by the JAX-RS concept I described
>>> above.
>>>
>>> Thanks !
>>>


 [1]http://cxf.apache.org/docs/interceptors.html

 Thanks,
 sanjeewa.

>
>
> I have setup a meeting in next Wednesday, if we can cater current
> requirements using above concepts let's go ahead with JAX-RS Filters.
>
>
> [1] 

Re: [Dev] [Architecture] [C5] MSF4J Interceptors need to be configurable.

[Kishanthan Thangarajah]

We are working on this. We couldn't progress much last week due to other
priorities. The plan is to deliver in two weeks time.

On Tue, Jan 3, 2017 at 1:40 PM, Ishara Cooray  wrote:

> Hi,
>
> What could be the status of this? Do we have a time line defined?
>
> Thanks & Regards,
> Ishara Cooray
> Senior Software Engineer
> Mobile : +9477 262 9512 <+94%2077%20262%209512>
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> On Fri, Dec 9, 2016 at 2:18 PM, Sagara Gunathunga  wrote:
>
>>
>>
>> On Fri, Dec 9, 2016 at 2:15 PM, Sanjeewa Malalgoda 
>> wrote:
>>
>>> Hi All,
>>> Please find inline comments.
>>>
>>> On Fri, Dec 9, 2016 at 12:49 PM, Sagara Gunathunga 
>>> wrote:
>>>


 On Thu, Dec 8, 2016 at 6:59 PM, Ishara Cooray  wrote:

> To overcome the above limitation where we cannot plug custom
> authentication, i came up with the below approach.
>
> Having one interceptor and delegate authentication to an interface.
> Implementation of the interface is configurable so that we can plug custom
> authentication as well.
>
> [image: Inline image 1]
>
> One limitation here is we can have only one auth type active at a time.
>
> Hi Sanjeewa,
>
> Shall we continue with this approach until we get a proper fix from
> msf4j?
>

 It's ok to use above  approach as a temporary workaround till we get
 proper solution from MSF4J, but please make sure to implement only required
 features in a simple manner because you have to discard this and have to
 use proper MSF4J approach before any release.

 By looking at issues faced by API-M and IS teams we have few issues to
 solve,


 1. Ability to apply/skip Interceptors in global and per-service levels
 2. Ability to define the order of Interceptors
 3. Ability to intercept response messages

>>> Ability to build security and user context in a way we can access it
>>> from service implementation.
>>> Most of the other platforms allowed to do that and people who work on
>>> service implementation can get real advantage of that.
>>>

 The good news is JAX-RS 2.0 spec is already solved these issues and we
 can adopt their concepts easily to MSF4J programming model. Please refer
 solution for each issue below.


 *1. Ability to intercept response messages *

 JAX-RS defines 2 interfaces as ContainerRequestFilter[1] and
 ContainerResponseFilter[2] to intercept request and response messages, IMO
 these 2 interfaces are much clean and standard then current MSF4J
 Interceptor[3] concept where response intercepting is not simple.


 *2.  Ability to apply/skip Interceptors  in global and per-service
 levels *

 Annotation driven NameBinding[4] concept defined for JAX-RS Filters is
 very flexible and easy to use as well. This NameBinding[4] feature enables
 to apply JAX-RS Filters at global, per-Resource or even per-sub-Resource
 level.

 *3. Define the order of Interceptors *

 JAX-RS defines several message processing extension points such as Pre,
 PreMatch, Post, it's possible to apply Filters during some of these message
 processing stages, as an example refer PreMatching[5] annotation.

 Further, to define fine grained order of Filters JAX-RS reuse Java's
 standard Priority[1] annotation, through this annotation numeric priority
 value can be define per Filters basis. JAX-RS already provide set of
 pre-defined Priories here[6]

>>> Ability to engage in different phases is definitely a good feature. But
>>> there can be situations where we need to engage multiple interceptors at
>>> same phase with order of execution. As example i need to engage both
>>> authenticate and authorization interceptors in pre invoke phase but
>>> authenticator first and then authorizer as 2nd interceptor. In that case we
>>> need to mention phase and order within phase in some way. It seems CXF and
>>> other run times already handled this in different ways.
>>>
>>
>> This requirement is well handled by the JAX-RS concept I described above.
>>
>> Thanks !
>>
>>>
>>>
>>> [1]http://cxf.apache.org/docs/interceptors.html
>>>
>>> Thanks,
>>> sanjeewa.
>>>


 I have setup a meeting in next Wednesday, if we can cater current
 requirements using above concepts let's go ahead with JAX-RS Filters.


 [1] - https://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/in
 dex.html?javax/ws/rs/container/ContainerRequestFilter.html
 [2] - https://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/ja
 vax/ws/rs/container/ContainerResponseFilter.html
 [3] - https://github.com/wso2/msf4j/blob/master/core/src/main/ja
 va/org/wso2/msf4j/Interceptor.java
 [4] - 

Re: [Dev] [Architecture] [C5] MSF4J Interceptors need to be configurable.

[Ishara Cooray]

Hi,

What could be the status of this? Do we have a time line defined?

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Fri, Dec 9, 2016 at 2:18 PM, Sagara Gunathunga  wrote:

>
>
> On Fri, Dec 9, 2016 at 2:15 PM, Sanjeewa Malalgoda 
> wrote:
>
>> Hi All,
>> Please find inline comments.
>>
>> On Fri, Dec 9, 2016 at 12:49 PM, Sagara Gunathunga 
>> wrote:
>>
>>>
>>>
>>> On Thu, Dec 8, 2016 at 6:59 PM, Ishara Cooray  wrote:
>>>
 To overcome the above limitation where we cannot plug custom
 authentication, i came up with the below approach.

 Having one interceptor and delegate authentication to an interface.
 Implementation of the interface is configurable so that we can plug custom
 authentication as well.

 [image: Inline image 1]

 One limitation here is we can have only one auth type active at a time.

 Hi Sanjeewa,

 Shall we continue with this approach until we get a proper fix from
 msf4j?

>>>
>>> It's ok to use above  approach as a temporary workaround till we get
>>> proper solution from MSF4J, but please make sure to implement only required
>>> features in a simple manner because you have to discard this and have to
>>> use proper MSF4J approach before any release.
>>>
>>> By looking at issues faced by API-M and IS teams we have few issues to
>>> solve,
>>>
>>>
>>> 1. Ability to apply/skip Interceptors in global and per-service levels
>>> 2. Ability to define the order of Interceptors
>>> 3. Ability to intercept response messages
>>>
>> Ability to build security and user context in a way we can access it from
>> service implementation.
>> Most of the other platforms allowed to do that and people who work on
>> service implementation can get real advantage of that.
>>
>>>
>>> The good news is JAX-RS 2.0 spec is already solved these issues and we
>>> can adopt their concepts easily to MSF4J programming model. Please refer
>>> solution for each issue below.
>>>
>>>
>>> *1. Ability to intercept response messages *
>>>
>>> JAX-RS defines 2 interfaces as ContainerRequestFilter[1] and
>>> ContainerResponseFilter[2] to intercept request and response messages, IMO
>>> these 2 interfaces are much clean and standard then current MSF4J
>>> Interceptor[3] concept where response intercepting is not simple.
>>>
>>>
>>> *2.  Ability to apply/skip Interceptors  in global and per-service
>>> levels *
>>>
>>> Annotation driven NameBinding[4] concept defined for JAX-RS Filters is
>>> very flexible and easy to use as well. This NameBinding[4] feature enables
>>> to apply JAX-RS Filters at global, per-Resource or even per-sub-Resource
>>> level.
>>>
>>> *3. Define the order of Interceptors *
>>>
>>> JAX-RS defines several message processing extension points such as Pre,
>>> PreMatch, Post, it's possible to apply Filters during some of these message
>>> processing stages, as an example refer PreMatching[5] annotation.
>>>
>>> Further, to define fine grained order of Filters JAX-RS reuse Java's
>>> standard Priority[1] annotation, through this annotation numeric priority
>>> value can be define per Filters basis. JAX-RS already provide set of
>>> pre-defined Priories here[6]
>>>
>> Ability to engage in different phases is definitely a good feature. But
>> there can be situations where we need to engage multiple interceptors at
>> same phase with order of execution. As example i need to engage both
>> authenticate and authorization interceptors in pre invoke phase but
>> authenticator first and then authorizer as 2nd interceptor. In that case we
>> need to mention phase and order within phase in some way. It seems CXF and
>> other run times already handled this in different ways.
>>
>
> This requirement is well handled by the JAX-RS concept I described above.
>
> Thanks !
>
>>
>>
>> [1]http://cxf.apache.org/docs/interceptors.html
>>
>> Thanks,
>> sanjeewa.
>>
>>>
>>>
>>> I have setup a meeting in next Wednesday, if we can cater current
>>> requirements using above concepts let's go ahead with JAX-RS Filters.
>>>
>>>
>>> [1] - https://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/in
>>> dex.html?javax/ws/rs/container/ContainerRequestFilter.html
>>> [2] - https://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/ja
>>> vax/ws/rs/container/ContainerResponseFilter.html
>>> [3] - https://github.com/wso2/msf4j/blob/master/core/src/main/ja
>>> va/org/wso2/msf4j/Interceptor.java
>>> [4] - https://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/in
>>> dex.html?javax/ws/rs/NameBinding.html
>>> [5] - https://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/in
>>> dex.html?javax/ws/rs/container/PreMatching.html
>>> [6] - https://jax-rs-spec.java.net/nonav/2.0/apidocs/javax/ws/rs
>>> /Priorities.html
>>>
>>> Thanks !
>>>
 ​


 Thanks & Regards,
 Ishara Cooray
 Senior Software 

Re: [Dev] [Architecture] [C5] MSF4J Interceptors need to be configurable.

[Sagara Gunathunga]

On Fri, Dec 9, 2016 at 2:15 PM, Sanjeewa Malalgoda 
wrote:

> Hi All,
> Please find inline comments.
>
> On Fri, Dec 9, 2016 at 12:49 PM, Sagara Gunathunga 
> wrote:
>
>>
>>
>> On Thu, Dec 8, 2016 at 6:59 PM, Ishara Cooray  wrote:
>>
>>> To overcome the above limitation where we cannot plug custom
>>> authentication, i came up with the below approach.
>>>
>>> Having one interceptor and delegate authentication to an interface.
>>> Implementation of the interface is configurable so that we can plug custom
>>> authentication as well.
>>>
>>> [image: Inline image 1]
>>>
>>> One limitation here is we can have only one auth type active at a time.
>>>
>>> Hi Sanjeewa,
>>>
>>> Shall we continue with this approach until we get a proper fix from
>>> msf4j?
>>>
>>
>> It's ok to use above  approach as a temporary workaround till we get
>> proper solution from MSF4J, but please make sure to implement only required
>> features in a simple manner because you have to discard this and have to
>> use proper MSF4J approach before any release.
>>
>> By looking at issues faced by API-M and IS teams we have few issues to
>> solve,
>>
>>
>> 1. Ability to apply/skip Interceptors in global and per-service levels
>> 2. Ability to define the order of Interceptors
>> 3. Ability to intercept response messages
>>
> Ability to build security and user context in a way we can access it from
> service implementation.
> Most of the other platforms allowed to do that and people who work on
> service implementation can get real advantage of that.
>
>>
>> The good news is JAX-RS 2.0 spec is already solved these issues and we
>> can adopt their concepts easily to MSF4J programming model. Please refer
>> solution for each issue below.
>>
>>
>> *1. Ability to intercept response messages *
>>
>> JAX-RS defines 2 interfaces as ContainerRequestFilter[1] and
>> ContainerResponseFilter[2] to intercept request and response messages, IMO
>> these 2 interfaces are much clean and standard then current MSF4J
>> Interceptor[3] concept where response intercepting is not simple.
>>
>>
>> *2.  Ability to apply/skip Interceptors  in global and per-service
>> levels *
>>
>> Annotation driven NameBinding[4] concept defined for JAX-RS Filters is
>> very flexible and easy to use as well. This NameBinding[4] feature enables
>> to apply JAX-RS Filters at global, per-Resource or even per-sub-Resource
>> level.
>>
>> *3. Define the order of Interceptors *
>>
>> JAX-RS defines several message processing extension points such as Pre,
>> PreMatch, Post, it's possible to apply Filters during some of these message
>> processing stages, as an example refer PreMatching[5] annotation.
>>
>> Further, to define fine grained order of Filters JAX-RS reuse Java's
>> standard Priority[1] annotation, through this annotation numeric priority
>> value can be define per Filters basis. JAX-RS already provide set of
>> pre-defined Priories here[6]
>>
> Ability to engage in different phases is definitely a good feature. But
> there can be situations where we need to engage multiple interceptors at
> same phase with order of execution. As example i need to engage both
> authenticate and authorization interceptors in pre invoke phase but
> authenticator first and then authorizer as 2nd interceptor. In that case we
> need to mention phase and order within phase in some way. It seems CXF and
> other run times already handled this in different ways.
>

This requirement is well handled by the JAX-RS concept I described above.

Thanks !

>
>
> [1]http://cxf.apache.org/docs/interceptors.html
>
> Thanks,
> sanjeewa.
>
>>
>>
>> I have setup a meeting in next Wednesday, if we can cater current
>> requirements using above concepts let's go ahead with JAX-RS Filters.
>>
>>
>> [1] - https://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/
>> index.html?javax/ws/rs/container/ContainerRequestFilter.html
>> [2] - https://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/
>> javax/ws/rs/container/ContainerResponseFilter.html
>> [3] - https://github.com/wso2/msf4j/blob/master/core/src/main/
>> java/org/wso2/msf4j/Interceptor.java
>> [4] - https://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/
>> index.html?javax/ws/rs/NameBinding.html
>> [5] - https://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/
>> index.html?javax/ws/rs/container/PreMatching.html
>> [6] - https://jax-rs-spec.java.net/nonav/2.0/apidocs/javax/ws/
>> rs/Priorities.html
>>
>> Thanks !
>>
>>> ​
>>>
>>>
>>> Thanks & Regards,
>>> Ishara Cooray
>>> Senior Software Engineer
>>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>>> WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>> On Thu, Dec 8, 2016 at 11:23 AM, Ishara Cooray  wrote:
>>>
 Hi Thilina,
>
> And also if there are multiple interceptors and one interceptor
> returns false from its' preCaall then the invocation chain will not
> continue further.
>
> So Is this 

Re: [Dev] [Architecture] [C5] MSF4J Interceptors need to be configurable.

[Sanjeewa Malalgoda]

Hi All,
Please find inline comments.

On Fri, Dec 9, 2016 at 12:49 PM, Sagara Gunathunga  wrote:

>
>
> On Thu, Dec 8, 2016 at 6:59 PM, Ishara Cooray  wrote:
>
>> To overcome the above limitation where we cannot plug custom
>> authentication, i came up with the below approach.
>>
>> Having one interceptor and delegate authentication to an interface.
>> Implementation of the interface is configurable so that we can plug custom
>> authentication as well.
>>
>> [image: Inline image 1]
>>
>> One limitation here is we can have only one auth type active at a time.
>>
>> Hi Sanjeewa,
>>
>> Shall we continue with this approach until we get a proper fix from msf4j?
>>
>
> It's ok to use above  approach as a temporary workaround till we get
> proper solution from MSF4J, but please make sure to implement only required
> features in a simple manner because you have to discard this and have to
> use proper MSF4J approach before any release.
>
> By looking at issues faced by API-M and IS teams we have few issues to
> solve,
>
>
> 1. Ability to apply/skip Interceptors in global and per-service levels
> 2. Ability to define the order of Interceptors
> 3. Ability to intercept response messages
>
Ability to build security and user context in a way we can access it from
service implementation.
Most of the other platforms allowed to do that and people who work on
service implementation can get real advantage of that.

>
> The good news is JAX-RS 2.0 spec is already solved these issues and we can
> adopt their concepts easily to MSF4J programming model. Please refer
> solution for each issue below.
>
>
> *1. Ability to intercept response messages *
>
> JAX-RS defines 2 interfaces as ContainerRequestFilter[1] and
> ContainerResponseFilter[2] to intercept request and response messages, IMO
> these 2 interfaces are much clean and standard then current MSF4J
> Interceptor[3] concept where response intercepting is not simple.
>
>
> *2.  Ability to apply/skip Interceptors  in global and per-service levels *
>
> Annotation driven NameBinding[4] concept defined for JAX-RS Filters is
> very flexible and easy to use as well. This NameBinding[4] feature enables
> to apply JAX-RS Filters at global, per-Resource or even per-sub-Resource
> level.
>
> *3. Define the order of Interceptors *
>
> JAX-RS defines several message processing extension points such as Pre,
> PreMatch, Post, it's possible to apply Filters during some of these message
> processing stages, as an example refer PreMatching[5] annotation.
>
> Further, to define fine grained order of Filters JAX-RS reuse Java's
> standard Priority[1] annotation, through this annotation numeric priority
> value can be define per Filters basis. JAX-RS already provide set of
> pre-defined Priories here[6]
>
Ability to engage in different phases is definitely a good feature. But
there can be situations where we need to engage multiple interceptors at
same phase with order of execution. As example i need to engage both
authenticate and authorization interceptors in pre invoke phase but
authenticator first and then authorizer as 2nd interceptor. In that case we
need to mention phase and order within phase in some way. It seems CXF and
other run times already handled this in different ways.


[1]http://cxf.apache.org/docs/interceptors.html

Thanks,
sanjeewa.

>
>
> I have setup a meeting in next Wednesday, if we can cater current
> requirements using above concepts let's go ahead with JAX-RS Filters.
>
>
> [1] - https://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/
> apidocs/index.html?javax/ws/rs/container/ContainerRequestFilter.html
> [2] - https://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/
> apidocs/javax/ws/rs/container/ContainerResponseFilter.html
> [3] - https://github.com/wso2/msf4j/blob/master/core/src/
> main/java/org/wso2/msf4j/Interceptor.java
> [4] - https://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/
> apidocs/index.html?javax/ws/rs/NameBinding.html
> [5] - https://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/
> apidocs/index.html?javax/ws/rs/container/PreMatching.html
> [6] - https://jax-rs-spec.java.net/nonav/2.0/apidocs/javax/
> ws/rs/Priorities.html
>
> Thanks !
>
>> ​
>>
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> On Thu, Dec 8, 2016 at 11:23 AM, Ishara Cooray  wrote:
>>
>>> Hi Thilina,

 And also if there are multiple interceptors and one interceptor returns
 false from its' preCaall then the invocation chain will not continue
 further.

 So Is this implies if preCall returns 'true' then the invocation chain
 will continue further?

>>>
>>> Yes
>>>
>>> I was thinking to return 'true' if particular auth header type(Basic,
>>> Bearer) is not found in an interceptor, so that it will check the other
>>> available interceptors.
>>> But i guess this approach may also 

Re: [Dev] [Architecture] [C5] MSF4J Interceptors need to be configurable.

[Sagara Gunathunga]

On Thu, Dec 8, 2016 at 6:59 PM, Ishara Cooray  wrote:

> To overcome the above limitation where we cannot plug custom
> authentication, i came up with the below approach.
>
> Having one interceptor and delegate authentication to an interface.
> Implementation of the interface is configurable so that we can plug custom
> authentication as well.
>
> [image: Inline image 1]
>
> One limitation here is we can have only one auth type active at a time.
>
> Hi Sanjeewa,
>
> Shall we continue with this approach until we get a proper fix from msf4j?
>

It's ok to use above  approach as a temporary workaround till we get proper
solution from MSF4J, but please make sure to implement only required
features in a simple manner because you have to discard this and have to
use proper MSF4J approach before any release.

By looking at issues faced by API-M and IS teams we have few issues to
solve,


1. Ability to apply/skip Interceptors in global and per-service levels
2. Ability to define the order of Interceptors
3. Ability to intercept response messages

The good news is JAX-RS 2.0 spec is already solved these issues and we can
adopt their concepts easily to MSF4J programming model. Please refer
solution for each issue below.


*1. Ability to intercept response messages *

JAX-RS defines 2 interfaces as ContainerRequestFilter[1] and
ContainerResponseFilter[2] to intercept request and response messages, IMO
these 2 interfaces are much clean and standard then current MSF4J
Interceptor[3] concept where response intercepting is not simple.


*2.  Ability to apply/skip Interceptors  in global and per-service levels *

Annotation driven NameBinding[4] concept defined for JAX-RS Filters is very
flexible and easy to use as well. This NameBinding[4] feature enables to
apply JAX-RS Filters at global, per-Resource or even per-sub-Resource
level.

*3. Define the order of Interceptors *

JAX-RS defines several message processing extension points such as Pre,
PreMatch, Post, it's possible to apply Filters during some of these message
processing stages, as an example refer PreMatching[5] annotation.

Further, to define fine grained order of Filters JAX-RS reuse Java's
standard Priority[1] annotation, through this annotation numeric priority
value can be define per Filters basis. JAX-RS already provide set of
pre-defined Priories here[6]


I have setup a meeting in next Wednesday, if we can cater current
requirements using above concepts let's go ahead with JAX-RS Filters.


[1] -
https://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/index.html?javax/ws/rs/container/ContainerRequestFilter.html

[2] -
https://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/container/ContainerResponseFilter.html

[3] -
https://github.com/wso2/msf4j/blob/master/core/src/main/java/org/wso2/msf4j/Interceptor.java

[4] -
https://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/index.html?javax/ws/rs/NameBinding.html
[5] -
https://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/index.html?javax/ws/rs/container/PreMatching.html

[6] -
https://jax-rs-spec.java.net/nonav/2.0/apidocs/javax/ws/rs/Priorities.html

Thanks !

> ​
>
>
> Thanks & Regards,
> Ishara Cooray
> Senior Software Engineer
> Mobile : +9477 262 9512 <+94%2077%20262%209512>
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> On Thu, Dec 8, 2016 at 11:23 AM, Ishara Cooray  wrote:
>
>> Hi Thilina,
>>>
>>> And also if there are multiple interceptors and one interceptor returns
>>> false from its' preCaall then the invocation chain will not continue
>>> further.
>>>
>>> So Is this implies if preCall returns 'true' then the invocation chain
>>> will continue further?
>>>
>>
>> Yes
>>
>> I was thinking to return 'true' if particular auth header type(Basic,
>> Bearer) is not found in an interceptor, so that it will check the other
>> available interceptors.
>> But i guess this approach may also fail if the request header type is not
>> provided may be by mistake.
>> Because all the interceptors will return true and will it be taken as a
>> valid authorization?
>>
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> On Wed, Dec 7, 2016 at 5:25 PM, Afkham Azeez  wrote:
>>
>>>
>>>
>>> On Wed, Dec 7, 2016 at 5:17 PM, Ishara Cooray  wrote:
>>>
 Hi Thilina,

 And also if there are multiple interceptors and one interceptor returns
 false from its' preCaall then the invocation chain will not continue
 further.

 So Is this implies if preCall returns 'true' then the invocation chain
 will continue further?

>>>
>>> Yes
>>>
>>>
 If that is the case we can return true in our overridden preCall method
 so that it goes to next Interceptor.


 Thanks & Regards,
 Ishara Cooray
 Senior Software Engineer
 Mobile : 

Re: [Dev] [Architecture] [C5] MSF4J Interceptors need to be configurable.

[Uvindra Dias Jayasinha]

Hi Ishara,

Another possibility for supporting multiple auth types with what you have
proposed is to have a collection Authenticator interfaces(using a Map
possibly) at the RestAPISecurityInterceptor level. Depending on some
condition you could selectively choose what implementation to use at
runtime.

On 9 December 2016 at 07:32, Ishara Cooray  wrote:

> Please find my comments in line.
>
> Yes for the moment lets use this approach. Lets have 2 interceptors for
> authenticate and authorization. From that lets provide way to add pluggable
> authenticators and authorizers.
> I guess you mean having two interfaces for authenticate and
> authorization.What if we have two methods in one interface?Otherwise  we
> will have to maintain two configurations.
>
> Also we may be able to route request through multiple authenticators
> according to predefined order(when we need to support multiple auth types
> at once).
> +1
>
> Also its better both identity and APIM can use same approach as we all are
> doing same thing.
> Identity team is writing JAAS Login Modules
> @Thanuja,
> Do you have any input here
>
> Thanks & Regards,
> Ishara Cooray
> Senior Software Engineer
> Mobile : +9477 262 9512 <+94%2077%20262%209512>
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> On Thu, Dec 8, 2016 at 9:06 PM, Sanjeewa Malalgoda 
> wrote:
>
>> Yes for the moment lets use this approach. Lets have 2 interceptors for
>> authenticate and authorization. From that lets provide way to add pluggable
>> authenticators and authorizers.
>> Also we may be able to route request through multiple authenticators
>> according to predefined order(when we need to support multiple auth types
>> at once).
>> Also its better both identity and APIM can use same approach as we all
>> are doing same thing.
>>
>>
>> Thanks,
>> sanjeewa.
>>
>> On Thu, Dec 8, 2016 at 6:59 PM, Ishara Cooray  wrote:
>>
>>> To overcome the above limitation where we cannot plug custom
>>> authentication, i came up with the below approach.
>>>
>>> Having one interceptor and delegate authentication to an interface.
>>> Implementation of the interface is configurable so that we can plug custom
>>> authentication as well.
>>>
>>> [image: Inline image 1]
>>>
>>> One limitation here is we can have only one auth type active at a time.
>>>
>>> Hi Sanjeewa,
>>>
>>> Shall we continue with this approach until we get a proper fix from
>>> msf4j?
>>> ​
>>>
>>>
>>> Thanks & Regards,
>>> Ishara Cooray
>>> Senior Software Engineer
>>> Mobile : +9477 262 9512 <077%20262%209512>
>>> WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>> On Thu, Dec 8, 2016 at 11:23 AM, Ishara Cooray  wrote:
>>>
 Hi Thilina,
>
> And also if there are multiple interceptors and one interceptor
> returns false from its' preCaall then the invocation chain will not
> continue further.
>
> So Is this implies if preCall returns 'true' then the invocation chain
> will continue further?
>

 Yes

 I was thinking to return 'true' if particular auth header type(Basic,
 Bearer) is not found in an interceptor, so that it will check the other
 available interceptors.
 But i guess this approach may also fail if the request header type is
 not provided may be by mistake.
 Because all the interceptors will return true and will it be taken as a
 valid authorization?


 Thanks & Regards,
 Ishara Cooray
 Senior Software Engineer
 Mobile : +9477 262 9512 <+94%2077%20262%209512>
 WSO2, Inc. | http://wso2.com/
 Lean . Enterprise . Middleware

 On Wed, Dec 7, 2016 at 5:25 PM, Afkham Azeez  wrote:

>
>
> On Wed, Dec 7, 2016 at 5:17 PM, Ishara Cooray 
> wrote:
>
>> Hi Thilina,
>>
>> And also if there are multiple interceptors and one interceptor
>> returns false from its' preCaall then the invocation chain will not
>> continue further.
>>
>> So Is this implies if preCall returns 'true' then the invocation
>> chain will continue further?
>>
>
> Yes
>
>
>> If that is the case we can return true in our overridden preCall
>> method so that it goes to next Interceptor.
>>
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512 <077%20262%209512>
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> On Wed, Dec 7, 2016 at 2:33 PM, Afkham Azeez  wrote:
>>
>>> How about supporting JAXRS filters?
>>>
>>> On Wed, Dec 7, 2016 at 12:52 PM, Thusitha Thilina Dayaratne <
>>> thusit...@wso2.com> wrote:
>>>
 Hi Ishara,

 As you have mentioned, with the current architecture we can't set
 the specific interceptor for a particular service but rather to 

Re: [Dev] [Architecture] [C5] MSF4J Interceptors need to be configurable.

[Ishara Cooray]

Please find my comments in line.

Yes for the moment lets use this approach. Lets have 2 interceptors for
authenticate and authorization. From that lets provide way to add pluggable
authenticators and authorizers.
I guess you mean having two interfaces for authenticate and
authorization.What if we have two methods in one interface?Otherwise  we
will have to maintain two configurations.

Also we may be able to route request through multiple authenticators
according to predefined order(when we need to support multiple auth types
at once).
+1

Also its better both identity and APIM can use same approach as we all are
doing same thing.
Identity team is writing JAAS Login Modules
@Thanuja,
Do you have any input here

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512 <+94%2077%20262%209512>
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Thu, Dec 8, 2016 at 9:06 PM, Sanjeewa Malalgoda 
wrote:

> Yes for the moment lets use this approach. Lets have 2 interceptors for
> authenticate and authorization. From that lets provide way to add pluggable
> authenticators and authorizers.
> Also we may be able to route request through multiple authenticators
> according to predefined order(when we need to support multiple auth types
> at once).
> Also its better both identity and APIM can use same approach as we all are
> doing same thing.
>
>
> Thanks,
> sanjeewa.
>
> On Thu, Dec 8, 2016 at 6:59 PM, Ishara Cooray  wrote:
>
>> To overcome the above limitation where we cannot plug custom
>> authentication, i came up with the below approach.
>>
>> Having one interceptor and delegate authentication to an interface.
>> Implementation of the interface is configurable so that we can plug custom
>> authentication as well.
>>
>> [image: Inline image 1]
>>
>> One limitation here is we can have only one auth type active at a time.
>>
>> Hi Sanjeewa,
>>
>> Shall we continue with this approach until we get a proper fix from msf4j?
>> ​
>>
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512 <077%20262%209512>
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> On Thu, Dec 8, 2016 at 11:23 AM, Ishara Cooray  wrote:
>>
>>> Hi Thilina,

 And also if there are multiple interceptors and one interceptor returns
 false from its' preCaall then the invocation chain will not continue
 further.

 So Is this implies if preCall returns 'true' then the invocation chain
 will continue further?

>>>
>>> Yes
>>>
>>> I was thinking to return 'true' if particular auth header type(Basic,
>>> Bearer) is not found in an interceptor, so that it will check the other
>>> available interceptors.
>>> But i guess this approach may also fail if the request header type is
>>> not provided may be by mistake.
>>> Because all the interceptors will return true and will it be taken as a
>>> valid authorization?
>>>
>>>
>>> Thanks & Regards,
>>> Ishara Cooray
>>> Senior Software Engineer
>>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>>> WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>> On Wed, Dec 7, 2016 at 5:25 PM, Afkham Azeez  wrote:
>>>


 On Wed, Dec 7, 2016 at 5:17 PM, Ishara Cooray  wrote:

> Hi Thilina,
>
> And also if there are multiple interceptors and one interceptor
> returns false from its' preCaall then the invocation chain will not
> continue further.
>
> So Is this implies if preCall returns 'true' then the invocation chain
> will continue further?
>

 Yes


> If that is the case we can return true in our overridden preCall
> method so that it goes to next Interceptor.
>
>
> Thanks & Regards,
> Ishara Cooray
> Senior Software Engineer
> Mobile : +9477 262 9512 <077%20262%209512>
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> On Wed, Dec 7, 2016 at 2:33 PM, Afkham Azeez  wrote:
>
>> How about supporting JAXRS filters?
>>
>> On Wed, Dec 7, 2016 at 12:52 PM, Thusitha Thilina Dayaratne <
>> thusit...@wso2.com> wrote:
>>
>>> Hi Ishara,
>>>
>>> As you have mentioned, with the current architecture we can't set
>>> the specific interceptor for a particular service but rather to all
>>> services in the registry. And also if there are multiple interceptors 
>>> and
>>> one interceptor returns false from its' preCaall then the invocation 
>>> chain
>>> will not continue further.
>>>
>>> IMHO we have few options
>>>
>>>- We can implement a way to register specific interceptors to
>>>specific services
>>>- We can support JAX-RS Filters
>>>- We can provide a way to skip some interceptors for specific
>>>services
>>>
>>> @Azeez WDYT?
>>>

Re: [Dev] [Architecture] [C5] MSF4J Interceptors need to be configurable.

[Sanjeewa Malalgoda]

Yes for the moment lets use this approach. Lets have 2 interceptors for
authenticate and authorization. From that lets provide way to add pluggable
authenticators and authorizers.
Also we may be able to route request through multiple authenticators
according to predefined order(when we need to support multiple auth types
at once).
Also its better both identity and APIM can use same approach as we all are
doing same thing.


Thanks,
sanjeewa.

On Thu, Dec 8, 2016 at 6:59 PM, Ishara Cooray  wrote:

> To overcome the above limitation where we cannot plug custom
> authentication, i came up with the below approach.
>
> Having one interceptor and delegate authentication to an interface.
> Implementation of the interface is configurable so that we can plug custom
> authentication as well.
>
> [image: Inline image 1]
>
> One limitation here is we can have only one auth type active at a time.
>
> Hi Sanjeewa,
>
> Shall we continue with this approach until we get a proper fix from msf4j?
> ​
>
>
> Thanks & Regards,
> Ishara Cooray
> Senior Software Engineer
> Mobile : +9477 262 9512 <077%20262%209512>
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> On Thu, Dec 8, 2016 at 11:23 AM, Ishara Cooray  wrote:
>
>> Hi Thilina,
>>>
>>> And also if there are multiple interceptors and one interceptor returns
>>> false from its' preCaall then the invocation chain will not continue
>>> further.
>>>
>>> So Is this implies if preCall returns 'true' then the invocation chain
>>> will continue further?
>>>
>>
>> Yes
>>
>> I was thinking to return 'true' if particular auth header type(Basic,
>> Bearer) is not found in an interceptor, so that it will check the other
>> available interceptors.
>> But i guess this approach may also fail if the request header type is not
>> provided may be by mistake.
>> Because all the interceptors will return true and will it be taken as a
>> valid authorization?
>>
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> On Wed, Dec 7, 2016 at 5:25 PM, Afkham Azeez  wrote:
>>
>>>
>>>
>>> On Wed, Dec 7, 2016 at 5:17 PM, Ishara Cooray  wrote:
>>>
 Hi Thilina,

 And also if there are multiple interceptors and one interceptor returns
 false from its' preCaall then the invocation chain will not continue
 further.

 So Is this implies if preCall returns 'true' then the invocation chain
 will continue further?

>>>
>>> Yes
>>>
>>>
 If that is the case we can return true in our overridden preCall method
 so that it goes to next Interceptor.


 Thanks & Regards,
 Ishara Cooray
 Senior Software Engineer
 Mobile : +9477 262 9512 <077%20262%209512>
 WSO2, Inc. | http://wso2.com/
 Lean . Enterprise . Middleware

 On Wed, Dec 7, 2016 at 2:33 PM, Afkham Azeez  wrote:

> How about supporting JAXRS filters?
>
> On Wed, Dec 7, 2016 at 12:52 PM, Thusitha Thilina Dayaratne <
> thusit...@wso2.com> wrote:
>
>> Hi Ishara,
>>
>> As you have mentioned, with the current architecture we can't set the
>> specific interceptor for a particular service but rather to all services 
>> in
>> the registry. And also if there are multiple interceptors and one
>> interceptor returns false from its' preCaall then the invocation chain 
>> will
>> not continue further.
>>
>> IMHO we have few options
>>
>>- We can implement a way to register specific interceptors to
>>specific services
>>- We can support JAX-RS Filters
>>- We can provide a way to skip some interceptors for specific
>>services
>>
>> @Azeez WDYT?
>>
>> Thanks
>> Thusitha
>>
>>
>> On Wed, Dec 7, 2016 at 10:56 AM, Ishara Cooray 
>> wrote:
>>
>>> HI,
>>>
>>> We are using MSF4J interceptor for securing REST APIs in API
>>> Manager. [1] As for now Interceptor registration happens at the class 
>>> level
>>> @Component annotation as below.
>>>
>>> @Component(
>>> name = "org.wso2.carbon.apimgt.rest.a
>>> pi.common.interceptors.OAUTH2SecurityInterceptor",
>>> service = Interceptor.class,
>>> immediate = true
>>> )
>>> The limitations here are
>>>
>>>1. it is not possible to have more than one interceptor that
>>>will dynamically pick when an api call is received(Because the order
>>>matters and we are not certain which interceptor will take into 
>>> effect ).
>>>2. We cannot explicitly configure to use Custom interceptors
>>>because of the above[1] reason.
>>>
>>> Do we have any plans for these limitations?
>>>
>>> Thanks & Regards,
>>> Ishara Cooray

Re: [Dev] [Architecture] [C5] MSF4J Interceptors need to be configurable.

[Ishara Cooray]

To overcome the above limitation where we cannot plug custom
authentication, i came up with the below approach.

Having one interceptor and delegate authentication to an interface.
Implementation of the interface is configurable so that we can plug custom
authentication as well.

[image: Inline image 1]

One limitation here is we can have only one auth type active at a time.

Hi Sanjeewa,

Shall we continue with this approach until we get a proper fix from msf4j?
​


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Thu, Dec 8, 2016 at 11:23 AM, Ishara Cooray  wrote:

> Hi Thilina,
>>
>> And also if there are multiple interceptors and one interceptor returns
>> false from its' preCaall then the invocation chain will not continue
>> further.
>>
>> So Is this implies if preCall returns 'true' then the invocation chain
>> will continue further?
>>
>
> Yes
>
> I was thinking to return 'true' if particular auth header type(Basic,
> Bearer) is not found in an interceptor, so that it will check the other
> available interceptors.
> But i guess this approach may also fail if the request header type is not
> provided may be by mistake.
> Because all the interceptors will return true and will it be taken as a
> valid authorization?
>
>
> Thanks & Regards,
> Ishara Cooray
> Senior Software Engineer
> Mobile : +9477 262 9512 <+94%2077%20262%209512>
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> On Wed, Dec 7, 2016 at 5:25 PM, Afkham Azeez  wrote:
>
>>
>>
>> On Wed, Dec 7, 2016 at 5:17 PM, Ishara Cooray  wrote:
>>
>>> Hi Thilina,
>>>
>>> And also if there are multiple interceptors and one interceptor returns
>>> false from its' preCaall then the invocation chain will not continue
>>> further.
>>>
>>> So Is this implies if preCall returns 'true' then the invocation chain
>>> will continue further?
>>>
>>
>> Yes
>>
>>
>>> If that is the case we can return true in our overridden preCall method
>>> so that it goes to next Interceptor.
>>>
>>>
>>> Thanks & Regards,
>>> Ishara Cooray
>>> Senior Software Engineer
>>> Mobile : +9477 262 9512 <077%20262%209512>
>>> WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>> On Wed, Dec 7, 2016 at 2:33 PM, Afkham Azeez  wrote:
>>>
 How about supporting JAXRS filters?

 On Wed, Dec 7, 2016 at 12:52 PM, Thusitha Thilina Dayaratne <
 thusit...@wso2.com> wrote:

> Hi Ishara,
>
> As you have mentioned, with the current architecture we can't set the
> specific interceptor for a particular service but rather to all services 
> in
> the registry. And also if there are multiple interceptors and one
> interceptor returns false from its' preCaall then the invocation chain 
> will
> not continue further.
>
> IMHO we have few options
>
>- We can implement a way to register specific interceptors to
>specific services
>- We can support JAX-RS Filters
>- We can provide a way to skip some interceptors for specific
>services
>
> @Azeez WDYT?
>
> Thanks
> Thusitha
>
>
> On Wed, Dec 7, 2016 at 10:56 AM, Ishara Cooray 
> wrote:
>
>> HI,
>>
>> We are using MSF4J interceptor for securing REST APIs in API Manager.
>> [1] As for now Interceptor registration happens at the class level
>> @Component annotation as below.
>>
>> @Component(
>> name = "org.wso2.carbon.apimgt.rest.a
>> pi.common.interceptors.OAUTH2SecurityInterceptor",
>> service = Interceptor.class,
>> immediate = true
>> )
>> The limitations here are
>>
>>1. it is not possible to have more than one interceptor that will
>>dynamically pick when an api call is received(Because the order 
>> matters and
>>we are not certain which interceptor will take into effect ).
>>2. We cannot explicitly configure to use Custom interceptors
>>because of the above[1] reason.
>>
>> Do we have any plans for these limitations?
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Thusitha Dayaratne
> Software Engineer
> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>
> Mobile  +94712756809 <071%20275%206809>
> Blog  alokayasoya.blogspot.com
> Abouthttp://about.me/thusithathilina
> 
>
>
> 

Re: [Dev] [Architecture] [C5] MSF4J Interceptors need to be configurable.

[Ishara Cooray]

>
> Hi Thilina,
>
> And also if there are multiple interceptors and one interceptor returns
> false from its' preCaall then the invocation chain will not continue
> further.
>
> So Is this implies if preCall returns 'true' then the invocation chain
> will continue further?
>

Yes

I was thinking to return 'true' if particular auth header type(Basic,
Bearer) is not found in an interceptor, so that it will check the other
available interceptors.
But i guess this approach may also fail if the request header type is not
provided may be by mistake.
Because all the interceptors will return true and will it be taken as a
valid authorization?


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Wed, Dec 7, 2016 at 5:25 PM, Afkham Azeez  wrote:

>
>
> On Wed, Dec 7, 2016 at 5:17 PM, Ishara Cooray  wrote:
>
>> Hi Thilina,
>>
>> And also if there are multiple interceptors and one interceptor returns
>> false from its' preCaall then the invocation chain will not continue
>> further.
>>
>> So Is this implies if preCall returns 'true' then the invocation chain
>> will continue further?
>>
>
> Yes
>
>
>> If that is the case we can return true in our overridden preCall method
>> so that it goes to next Interceptor.
>>
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512 <077%20262%209512>
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> On Wed, Dec 7, 2016 at 2:33 PM, Afkham Azeez  wrote:
>>
>>> How about supporting JAXRS filters?
>>>
>>> On Wed, Dec 7, 2016 at 12:52 PM, Thusitha Thilina Dayaratne <
>>> thusit...@wso2.com> wrote:
>>>
 Hi Ishara,

 As you have mentioned, with the current architecture we can't set the
 specific interceptor for a particular service but rather to all services in
 the registry. And also if there are multiple interceptors and one
 interceptor returns false from its' preCaall then the invocation chain will
 not continue further.

 IMHO we have few options

- We can implement a way to register specific interceptors to
specific services
- We can support JAX-RS Filters
- We can provide a way to skip some interceptors for specific
services

 @Azeez WDYT?

 Thanks
 Thusitha


 On Wed, Dec 7, 2016 at 10:56 AM, Ishara Cooray 
 wrote:

> HI,
>
> We are using MSF4J interceptor for securing REST APIs in API Manager.
> [1] As for now Interceptor registration happens at the class level
> @Component annotation as below.
>
> @Component(
> name = "org.wso2.carbon.apimgt.rest.a
> pi.common.interceptors.OAUTH2SecurityInterceptor",
> service = Interceptor.class,
> immediate = true
> )
> The limitations here are
>
>1. it is not possible to have more than one interceptor that will
>dynamically pick when an api call is received(Because the order 
> matters and
>we are not certain which interceptor will take into effect ).
>2. We cannot explicitly configure to use Custom interceptors
>because of the above[1] reason.
>
> Do we have any plans for these limitations?
>
> Thanks & Regards,
> Ishara Cooray
> Senior Software Engineer
> Mobile : +9477 262 9512 <+94%2077%20262%209512>
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


 --
 Thusitha Dayaratne
 Software Engineer
 WSO2 Inc. - lean . enterprise . middleware |  wso2.com

 Mobile  +94712756809 <071%20275%206809>
 Blog  alokayasoya.blogspot.com
 Abouthttp://about.me/thusithathilina
 


 ___
 Architecture mailing list
 architect...@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


>>>
>>>
>>> --
>>> *Afkham Azeez*
>>> Senior Director, Platform Architecture; WSO2, Inc.; http://wso2.com
>>> Member; Apache Software Foundation; http://www.apache.org/
>>> * *
>>> *email: **az...@wso2.com* 
>>> * cell: +94 77 3320919 <+94%2077%20332%200919>blog: *
>>> *http://blog.afkham.org* 
>>> *twitter: **http://twitter.com/afkham_azeez*
>>> 
>>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez
>>> *
>>>
>>> *Lean . Enterprise . Middleware*
>>>
>>
>>
>
>
> --
> *Afkham Azeez*
> Senior Director, Platform Architecture; WSO2, Inc.; http://wso2.com
> Member; Apache Software Foundation; 

Re: [Dev] [Architecture] [C5] MSF4J Interceptors need to be configurable.

[Afkham Azeez]

On Wed, Dec 7, 2016 at 5:17 PM, Ishara Cooray  wrote:

> Hi Thilina,
>
> And also if there are multiple interceptors and one interceptor returns
> false from its' preCaall then the invocation chain will not continue
> further.
>
> So Is this implies if preCall returns 'true' then the invocation chain
> will continue further?
>

Yes


> If that is the case we can return true in our overridden preCall method so
> that it goes to next Interceptor.
>
>
> Thanks & Regards,
> Ishara Cooray
> Senior Software Engineer
> Mobile : +9477 262 9512 <077%20262%209512>
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> On Wed, Dec 7, 2016 at 2:33 PM, Afkham Azeez  wrote:
>
>> How about supporting JAXRS filters?
>>
>> On Wed, Dec 7, 2016 at 12:52 PM, Thusitha Thilina Dayaratne <
>> thusit...@wso2.com> wrote:
>>
>>> Hi Ishara,
>>>
>>> As you have mentioned, with the current architecture we can't set the
>>> specific interceptor for a particular service but rather to all services in
>>> the registry. And also if there are multiple interceptors and one
>>> interceptor returns false from its' preCaall then the invocation chain will
>>> not continue further.
>>>
>>> IMHO we have few options
>>>
>>>- We can implement a way to register specific interceptors to
>>>specific services
>>>- We can support JAX-RS Filters
>>>- We can provide a way to skip some interceptors for specific
>>>services
>>>
>>> @Azeez WDYT?
>>>
>>> Thanks
>>> Thusitha
>>>
>>>
>>> On Wed, Dec 7, 2016 at 10:56 AM, Ishara Cooray  wrote:
>>>
 HI,

 We are using MSF4J interceptor for securing REST APIs in API Manager.
 [1] As for now Interceptor registration happens at the class level
 @Component annotation as below.

 @Component(
 name = "org.wso2.carbon.apimgt.rest.a
 pi.common.interceptors.OAUTH2SecurityInterceptor",
 service = Interceptor.class,
 immediate = true
 )
 The limitations here are

1. it is not possible to have more than one interceptor that will
dynamically pick when an api call is received(Because the order matters 
 and
we are not certain which interceptor will take into effect ).
2. We cannot explicitly configure to use Custom interceptors
because of the above[1] reason.

 Do we have any plans for these limitations?

 Thanks & Regards,
 Ishara Cooray
 Senior Software Engineer
 Mobile : +9477 262 9512 <+94%2077%20262%209512>
 WSO2, Inc. | http://wso2.com/
 Lean . Enterprise . Middleware


 ___
 Dev mailing list
 Dev@wso2.org
 http://wso2.org/cgi-bin/mailman/listinfo/dev


>>>
>>>
>>> --
>>> Thusitha Dayaratne
>>> Software Engineer
>>> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>>>
>>> Mobile  +94712756809 <071%20275%206809>
>>> Blog  alokayasoya.blogspot.com
>>> Abouthttp://about.me/thusithathilina
>>> 
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> architect...@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Afkham Azeez*
>> Senior Director, Platform Architecture; WSO2, Inc.; http://wso2.com
>> Member; Apache Software Foundation; http://www.apache.org/
>> * *
>> *email: **az...@wso2.com* 
>> * cell: +94 77 3320919 <+94%2077%20332%200919>blog: *
>> *http://blog.afkham.org* 
>> *twitter: **http://twitter.com/afkham_azeez*
>> 
>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez
>> *
>>
>> *Lean . Enterprise . Middleware*
>>
>
>


-- 
*Afkham Azeez*
Senior Director, Platform Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* *
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*

*twitter: **http://twitter.com/afkham_azeez*

*linked-in: **http://lk.linkedin.com/in/afkhamazeez
*

*Lean . Enterprise . Middleware*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [C5] MSF4J Interceptors need to be configurable.

[Ishara Cooray]

Hi Thilina,

And also if there are multiple interceptors and one interceptor returns
false from its' preCaall then the invocation chain will not continue
further.

So Is this implies if preCall returns 'true' then the invocation chain will
continue further?
If that is the case we can return true in our overridden preCall method so
that it goes to next Interceptor.


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Wed, Dec 7, 2016 at 2:33 PM, Afkham Azeez  wrote:

> How about supporting JAXRS filters?
>
> On Wed, Dec 7, 2016 at 12:52 PM, Thusitha Thilina Dayaratne <
> thusit...@wso2.com> wrote:
>
>> Hi Ishara,
>>
>> As you have mentioned, with the current architecture we can't set the
>> specific interceptor for a particular service but rather to all services in
>> the registry. And also if there are multiple interceptors and one
>> interceptor returns false from its' preCaall then the invocation chain will
>> not continue further.
>>
>> IMHO we have few options
>>
>>- We can implement a way to register specific interceptors to
>>specific services
>>- We can support JAX-RS Filters
>>- We can provide a way to skip some interceptors for specific services
>>
>> @Azeez WDYT?
>>
>> Thanks
>> Thusitha
>>
>>
>> On Wed, Dec 7, 2016 at 10:56 AM, Ishara Cooray  wrote:
>>
>>> HI,
>>>
>>> We are using MSF4J interceptor for securing REST APIs in API Manager.
>>> [1] As for now Interceptor registration happens at the class level
>>> @Component annotation as below.
>>>
>>> @Component(
>>> name = "org.wso2.carbon.apimgt.rest.a
>>> pi.common.interceptors.OAUTH2SecurityInterceptor",
>>> service = Interceptor.class,
>>> immediate = true
>>> )
>>> The limitations here are
>>>
>>>1. it is not possible to have more than one interceptor that will
>>>dynamically pick when an api call is received(Because the order matters 
>>> and
>>>we are not certain which interceptor will take into effect ).
>>>2. We cannot explicitly configure to use Custom interceptors because
>>>of the above[1] reason.
>>>
>>> Do we have any plans for these limitations?
>>>
>>> Thanks & Regards,
>>> Ishara Cooray
>>> Senior Software Engineer
>>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>>> WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> Thusitha Dayaratne
>> Software Engineer
>> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>>
>> Mobile  +94712756809 <071%20275%206809>
>> Blog  alokayasoya.blogspot.com
>> Abouthttp://about.me/thusithathilina
>> 
>>
>>
>> ___
>> Architecture mailing list
>> architect...@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Afkham Azeez*
> Senior Director, Platform Architecture; WSO2, Inc.; http://wso2.com
> Member; Apache Software Foundation; http://www.apache.org/
> * *
> *email: **az...@wso2.com* 
> * cell: +94 77 3320919 <+94%2077%20332%200919>blog: *
> *http://blog.afkham.org* 
> *twitter: **http://twitter.com/afkham_azeez*
> 
> *linked-in: **http://lk.linkedin.com/in/afkhamazeez
> *
>
> *Lean . Enterprise . Middleware*
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [C5] MSF4J Interceptors need to be configurable.

[Afkham Azeez]

How about supporting JAXRS filters?

On Wed, Dec 7, 2016 at 12:52 PM, Thusitha Thilina Dayaratne <
thusit...@wso2.com> wrote:

> Hi Ishara,
>
> As you have mentioned, with the current architecture we can't set the
> specific interceptor for a particular service but rather to all services in
> the registry. And also if there are multiple interceptors and one
> interceptor returns false from its' preCaall then the invocation chain will
> not continue further.
>
> IMHO we have few options
>
>- We can implement a way to register specific interceptors to specific
>services
>- We can support JAX-RS Filters
>- We can provide a way to skip some interceptors for specific services
>
> @Azeez WDYT?
>
> Thanks
> Thusitha
>
>
> On Wed, Dec 7, 2016 at 10:56 AM, Ishara Cooray  wrote:
>
>> HI,
>>
>> We are using MSF4J interceptor for securing REST APIs in API Manager. [1]
>> As for now Interceptor registration happens at the class level @Component
>> annotation as below.
>>
>> @Component(
>> name = "org.wso2.carbon.apimgt.rest.a
>> pi.common.interceptors.OAUTH2SecurityInterceptor",
>> service = Interceptor.class,
>> immediate = true
>> )
>> The limitations here are
>>
>>1. it is not possible to have more than one interceptor that will
>>dynamically pick when an api call is received(Because the order matters 
>> and
>>we are not certain which interceptor will take into effect ).
>>2. We cannot explicitly configure to use Custom interceptors because
>>of the above[1] reason.
>>
>> Do we have any plans for these limitations?
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Thusitha Dayaratne
> Software Engineer
> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>
> Mobile  +94712756809 <071%20275%206809>
> Blog  alokayasoya.blogspot.com
> Abouthttp://about.me/thusithathilina
> 
>
>
> ___
> Architecture mailing list
> architect...@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Afkham Azeez*
Senior Director, Platform Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* *
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*

*twitter: **http://twitter.com/afkham_azeez*

*linked-in: **http://lk.linkedin.com/in/afkhamazeez
*

*Lean . Enterprise . Middleware*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev