Artemis - CXF

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Artemis - CXF

dkulp

I’m going to start working on replacing RestEASY with CXF for the Artemis REST stuff but wanted to start a quick discussion first about how we should do this.   Looking through the code briefly, I think there are three “types” of code:

1) Pure JAX-RS things and the object models for the mappings to/from the rest<->JMS

2) Some RestEASY things that could be refactored into (1).  There are a bunch of client things (even using deprecated RestEASY classes) that can be refactored into (1)

3) Pure RestEASY bootstrap things

#2 is likely a “no brainer”, IMO.   So the question is what to do about 3?   Should we split the current artemis-rest into three modules?   On that would contain all the non-implementation specific things and one specific for CXF and one for RestEASY?    Would that be artemis-rest-common/artemis-rest-cxf/artemis-rest-resteasy?

The other option is to try and put the CXF and RestEASY code both into artemis-rest and declare all the deps optional+provided and try to determine the impl that is available at runtime and do something smart.  (might be able to detect jersey as well).    That seems a bit convoluted though.

I’m not really considering dropping RestEASY entirely for CXF, but I suppose that is a path to mention just for completeness.

Thoughts?

--
Daniel Kulp
[hidden email] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Reply | Threaded
Open this post in threaded view
|

Re: Artemis - CXF

John D. Ament-2
Is this a big priority to pick up?  Resteasy is already Apache V2 licensed,
so it doesn't cause a licensing conflict, though I agree being able to
leverage the rest api in containers that aren't deploying resteasy would be
beneficial.

The bootstrap code is resteasy specific, but it seems to be used mostly
during tests.  it seems like some of these changes would put pretty big
overheads on how the rest api works.  The current rest api just takes
whatever body came along and converts it to a message, and provides
messages back with the streams directly.

On Tue, Jun 9, 2015 at 5:25 AM Daniel Kulp <[hidden email]> wrote:

>
> I’m going to start working on replacing RestEASY with CXF for the Artemis
> REST stuff but wanted to start a quick discussion first about how we should
> do this.   Looking through the code briefly, I think there are three
> “types” of code:
>
> 1) Pure JAX-RS things and the object models for the mappings to/from the
> rest<->JMS
>
> 2) Some RestEASY things that could be refactored into (1).  There are a
> bunch of client things (even using deprecated RestEASY classes) that can be
> refactored into (1)
>
> 3) Pure RestEASY bootstrap things
>
> #2 is likely a “no brainer”, IMO.   So the question is what to do about
> 3?   Should we split the current artemis-rest into three modules?   On that
> would contain all the non-implementation specific things and one specific
> for CXF and one for RestEASY?    Would that be
> artemis-rest-common/artemis-rest-cxf/artemis-rest-resteasy?
>
> The other option is to try and put the CXF and RestEASY code both into
> artemis-rest and declare all the deps optional+provided and try to
> determine the impl that is available at runtime and do something smart.
> (might be able to detect jersey as well).    That seems a bit convoluted
> though.
>
> I’m not really considering dropping RestEASY entirely for CXF, but I
> suppose that is a path to mention just for completeness.
>
> Thoughts?
>
> --
> Daniel Kulp
> [hidden email] - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Artemis - CXF

dkulp

> On Jun 9, 2015, at 8:48 AM, John D. Ament <[hidden email]> wrote:
> Is this a big priority to pick up?  

It would be my #1 priority, followed closely by OSGi support.  In the whole “scratch the itch” methodology, it’s what I’m planning on working on.


> Resteasy is already Apache V2 licensed,
> so it doesn't cause a licensing conflict, though I agree being able to
> leverage the rest api in containers that aren't deploying resteasy would be
> beneficial.

The problem is parts of the JAX-RS APIs end up having problems if there are multiple JAX-RS implementations available.   It holds onto the various things in statics based on the first implementation that is found.  Thus, those containers that provide JAX-RS based on CXF will have potential issues if Resteasy is brought in as well.   Since Resteasy isn’t needed, it might as well be made optional.     If Artemis is to provide JMS 2.0 support for TomEE or ServiceMix, we need to get CXF support working.

> The bootstrap code is resteasy specific, but it seems to be used mostly
> during tests.  it seems like some of these changes would put pretty big
> overheads on how the rest api works.  The current rest api just takes
> whatever body came along and converts it to a message, and provides
> messages back with the streams directly.

I don’t think any of that would necessarily have to change, but we’ll find out more as we refactor this.   It’s still JAX-RS, it’s just a matter of whether its CXF or RestEasy handling the mapping and unmarshalling and such.

Dan



>
> On Tue, Jun 9, 2015 at 5:25 AM Daniel Kulp <[hidden email]> wrote:
>
>>
>> I’m going to start working on replacing RestEASY with CXF for the Artemis
>> REST stuff but wanted to start a quick discussion first about how we should
>> do this.   Looking through the code briefly, I think there are three
>> “types” of code:
>>
>> 1) Pure JAX-RS things and the object models for the mappings to/from the
>> rest<->JMS
>>
>> 2) Some RestEASY things that could be refactored into (1).  There are a
>> bunch of client things (even using deprecated RestEASY classes) that can be
>> refactored into (1)
>>
>> 3) Pure RestEASY bootstrap things
>>
>> #2 is likely a “no brainer”, IMO.   So the question is what to do about
>> 3?   Should we split the current artemis-rest into three modules?   On that
>> would contain all the non-implementation specific things and one specific
>> for CXF and one for RestEASY?    Would that be
>> artemis-rest-common/artemis-rest-cxf/artemis-rest-resteasy?
>>
>> The other option is to try and put the CXF and RestEASY code both into
>> artemis-rest and declare all the deps optional+provided and try to
>> determine the impl that is available at runtime and do something smart.
>> (might be able to detect jersey as well).    That seems a bit convoluted
>> though.
>>
>> I’m not really considering dropping RestEASY entirely for CXF, but I
>> suppose that is a path to mention just for completeness.
>>
>> Thoughts?
>>
>> --
>> Daniel Kulp
>> [hidden email] - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>>

--
Daniel Kulp
[hidden email] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Reply | Threaded
Open this post in threaded view
|

Re: Artemis - CXF

andytaylor
The Rest modules were contributed HornetQ but to be honest have never
really been used in anger and there are no devs that have really any
knowledge of it, in fact you are probably the most knowledgeable already
Daniel :). Personally I see no issues with making it optional and
changing what ever API's you need to.

Andy

On 09/06/15 14:13, Daniel Kulp wrote:

>
>> On Jun 9, 2015, at 8:48 AM, John D. Ament <[hidden email]> wrote:
>> Is this a big priority to pick up?
>
> It would be my #1 priority, followed closely by OSGi support.  In the whole “scratch the itch” methodology, it’s what I’m planning on working on.
>
>
>> Resteasy is already Apache V2 licensed,
>> so it doesn't cause a licensing conflict, though I agree being able to
>> leverage the rest api in containers that aren't deploying resteasy would be
>> beneficial.
>
> The problem is parts of the JAX-RS APIs end up having problems if there are multiple JAX-RS implementations available.   It holds onto the various things in statics based on the first implementation that is found.  Thus, those containers that provide JAX-RS based on CXF will have potential issues if Resteasy is brought in as well.   Since Resteasy isn’t needed, it might as well be made optional.     If Artemis is to provide JMS 2.0 support for TomEE or ServiceMix, we need to get CXF support working.
>
>> The bootstrap code is resteasy specific, but it seems to be used mostly
>> during tests.  it seems like some of these changes would put pretty big
>> overheads on how the rest api works.  The current rest api just takes
>> whatever body came along and converts it to a message, and provides
>> messages back with the streams directly.
>
> I don’t think any of that would necessarily have to change, but we’ll find out more as we refactor this.   It’s still JAX-RS, it’s just a matter of whether its CXF or RestEasy handling the mapping and unmarshalling and such.
>
> Dan
>
>
>
>>
>> On Tue, Jun 9, 2015 at 5:25 AM Daniel Kulp <[hidden email]> wrote:
>>
>>>
>>> I’m going to start working on replacing RestEASY with CXF for the Artemis
>>> REST stuff but wanted to start a quick discussion first about how we should
>>> do this.   Looking through the code briefly, I think there are three
>>> “types” of code:
>>>
>>> 1) Pure JAX-RS things and the object models for the mappings to/from the
>>> rest<->JMS
>>>
>>> 2) Some RestEASY things that could be refactored into (1).  There are a
>>> bunch of client things (even using deprecated RestEASY classes) that can be
>>> refactored into (1)
>>>
>>> 3) Pure RestEASY bootstrap things
>>>
>>> #2 is likely a “no brainer”, IMO.   So the question is what to do about
>>> 3?   Should we split the current artemis-rest into three modules?   On that
>>> would contain all the non-implementation specific things and one specific
>>> for CXF and one for RestEASY?    Would that be
>>> artemis-rest-common/artemis-rest-cxf/artemis-rest-resteasy?
>>>
>>> The other option is to try and put the CXF and RestEASY code both into
>>> artemis-rest and declare all the deps optional+provided and try to
>>> determine the impl that is available at runtime and do something smart.
>>> (might be able to detect jersey as well).    That seems a bit convoluted
>>> though.
>>>
>>> I’m not really considering dropping RestEASY entirely for CXF, but I
>>> suppose that is a path to mention just for completeness.
>>>
>>> Thoughts?
>>>
>>> --
>>> Daniel Kulp
>>> [hidden email] - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>>
>>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Artemis - CXF

clebertsuconic
@Andy +1

The current Rest module would need to be revamped anyways. For
instance it's using an older version of Rest-Easy, the new one has a
newer API and some dependencies we didn't want (would need to update
the version for that).


@Daniel +1 Go ahead. Change whatever you need.

On Tue, Jun 9, 2015 at 9:21 AM, Andy Taylor <[hidden email]> wrote:

> The Rest modules were contributed HornetQ but to be honest have never really
> been used in anger and there are no devs that have really any knowledge of
> it, in fact you are probably the most knowledgeable already Daniel :).
> Personally I see no issues with making it optional and changing what ever
> API's you need to.
>
> Andy
>
>
> On 09/06/15 14:13, Daniel Kulp wrote:
>>
>>
>>> On Jun 9, 2015, at 8:48 AM, John D. Ament <[hidden email]> wrote:
>>> Is this a big priority to pick up?
>>
>>
>> It would be my #1 priority, followed closely by OSGi support.  In the
>> whole “scratch the itch” methodology, it’s what I’m planning on working on.
>>
>>
>>> Resteasy is already Apache V2 licensed,
>>> so it doesn't cause a licensing conflict, though I agree being able to
>>> leverage the rest api in containers that aren't deploying resteasy would
>>> be
>>> beneficial.
>>
>>
>> The problem is parts of the JAX-RS APIs end up having problems if there
>> are multiple JAX-RS implementations available.   It holds onto the various
>> things in statics based on the first implementation that is found.  Thus,
>> those containers that provide JAX-RS based on CXF will have potential issues
>> if Resteasy is brought in as well.   Since Resteasy isn’t needed, it might
>> as well be made optional.     If Artemis is to provide JMS 2.0 support for
>> TomEE or ServiceMix, we need to get CXF support working.
>>
>>> The bootstrap code is resteasy specific, but it seems to be used mostly
>>> during tests.  it seems like some of these changes would put pretty big
>>> overheads on how the rest api works.  The current rest api just takes
>>> whatever body came along and converts it to a message, and provides
>>> messages back with the streams directly.
>>
>>
>> I don’t think any of that would necessarily have to change, but we’ll find
>> out more as we refactor this.   It’s still JAX-RS, it’s just a matter of
>> whether its CXF or RestEasy handling the mapping and unmarshalling and such.
>>
>> Dan
>>
>>
>>
>>>
>>> On Tue, Jun 9, 2015 at 5:25 AM Daniel Kulp <[hidden email]> wrote:
>>>
>>>>
>>>> I’m going to start working on replacing RestEASY with CXF for the
>>>> Artemis
>>>> REST stuff but wanted to start a quick discussion first about how we
>>>> should
>>>> do this.   Looking through the code briefly, I think there are three
>>>> “types” of code:
>>>>
>>>> 1) Pure JAX-RS things and the object models for the mappings to/from the
>>>> rest<->JMS
>>>>
>>>> 2) Some RestEASY things that could be refactored into (1).  There are a
>>>> bunch of client things (even using deprecated RestEASY classes) that can
>>>> be
>>>> refactored into (1)
>>>>
>>>> 3) Pure RestEASY bootstrap things
>>>>
>>>> #2 is likely a “no brainer”, IMO.   So the question is what to do about
>>>> 3?   Should we split the current artemis-rest into three modules?   On
>>>> that
>>>> would contain all the non-implementation specific things and one
>>>> specific
>>>> for CXF and one for RestEASY?    Would that be
>>>> artemis-rest-common/artemis-rest-cxf/artemis-rest-resteasy?
>>>>
>>>> The other option is to try and put the CXF and RestEASY code both into
>>>> artemis-rest and declare all the deps optional+provided and try to
>>>> determine the impl that is available at runtime and do something smart.
>>>> (might be able to detect jersey as well).    That seems a bit convoluted
>>>> though.
>>>>
>>>> I’m not really considering dropping RestEASY entirely for CXF, but I
>>>> suppose that is a path to mention just for completeness.
>>>>
>>>> Thoughts?
>>>>
>>>> --
>>>> Daniel Kulp
>>>> [hidden email] - http://dankulp.com/blog
>>>> Talend Community Coder - http://coders.talend.com
>>>>
>>>>
>>
>



--
Clebert Suconic
http://community.jboss.org/people/clebert.suconic@...
http://clebertsuconic.blogspot.com